How to expand possibly non-existent user constructed variable name?

[voxik]

I have this snippet:

$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval "%{expand:%{%{gsub %{name} - _}_prerelease}}"
.dev

But if the name does not match to the next definition, the non existing variable is printed out:

$ rpm -D "name foo" -D "string_io_prerelease .dev" --eval "%{expand:%{%{gsub %{name} - _}_prerelease}}"
%{foo_prerelease}

But I would like to just ignore such output, but this (the additional ?) does not work (the output is always empty):

$ rpm -D "name foo" -D "string_io_prerelease .dev" --eval "%{expand:%{?%{gsub %{name} - _}_prerelease}}"

$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval "%{expand:%{?%{gsub %{name} - _}_prerelease}}"

[voxik]

Actually, it seems that I have found a cure:

$ rpm -D "name foo" -D "string_io_prerelease .dev" --eval '%{expand:%{%{quote:?}%{gsub %{name} - _}_prerelease}}'

$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%{expand:%{%{quote:?}%{gsub %{name} - _}_prerelease}}'
.dev

But why the quote macro makes a difference?

[pmatilai]

It would help to understand the actual use-case behind this.

I'll also note that this is in already in the territory where doing things in Lua with proper program logic will be much easier to both write and read.

[voxik]

It would help to understand the actual use-case behind this.

This is the original macro:

https://src.fedoraproject.org/rpms/ruby/blob/05a6c9c8f3bbc26d12835736791431c74d07552d/f/macros.rubygems#_15

And here you can see its usage:

https://src.fedoraproject.org/rpms/ruby/blob/05a6c9c8f3bbc26d12835736791431c74d07552d/f/ruby.spec#_137
https://src.fedoraproject.org/rpms/ruby/blob/05a6c9c8f3bbc26d12835736791431c74d07552d/f/ruby.spec#_1588-1598

When the gems are in pre-release version, the version typically looks like 3.5.5.dev and I wanted to make 3.5.5~dev RPM version out of it, therefore I wanted to make e.g. test_unit_prerelease macro to contain the .dev suffix

I'll also note that this is in already in the territory where doing things in Lua with proper program logic will be much easier to both write and read.

Funnily enough, we were forced to use Lua for c9s, because RPM does not support %{sub:...} there. ATM, I don't think it is more readable nor shorter. But admittedly, it could also be written different way ...

[pmatilai]

Funnily enough, we were forced to use Lua for c9s, because RPM does not support %{sub:...} there. ATM, I don't think it is more readable nor shorter. But admittedly, it could also be written different way ...

Yeah you'd want to write the whole macro in Lua, not just parts of it. And format like you would do regular code - just as a silly example:

%mymacro() %{lua:
    local function helper(myarg)
        return myarg.."-helper"
    end

    if arg[1] then
        print(helper(arg[1]))
    else
        print("no arguments")
    end
}

I don't remember offhand whether RHEL9 supports empty lines in a macro definition like the above, but even if you have to replace it with a comment it'll be way more readable than the average one-line obfuscated perl contest the average complicated plain-macro macros tend to look like. Hrm, actually RHEL9 doesn't have the "Lua integration" stuff yet so arg[1] wont work there either.

[voxik]

Either way, Lua or not, I still find surprising that plain ? does not work in the expand.

[pmatilai]

I haven't had a chance to dig into that construct, it just looks so fishy that my recommendation is simply: don't bother, use lua.

[mlschroe]

You just need to escape the first % in the expand macro:

rpm -D "name string-io" -D "string_io_prerelease .dev" --eval "%{expand:%%{?%{gsub %{name} - _}_prerelease}}"
.dev

Without the expand:

$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval "%%{?%{gsub %{name} - _}_prerelease}"
%{?string_io_prerelease}
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval "%{?%{gsub %{name} - _}_prerelease}"
$

As you can see, the expand macro does not get anything to expand if you do not escape the %.