>> But that is wrong; you are assuming that cmdA does not create/deletes
>> files; I don't think it is that unreasonable to want to use the same
>> list of files for two commands instead of expanding *.c twice that
>> results in different values.
I don't understand. The globbing happens at elglob time (whether
it's run inside a multisubstitute or not), only once; so $cfiles *is*
the same list of files everywhere, no matter how many times or where
it appears in the command line.
Anyway, if I'm trying to steelman your argument, the problem seems to
be the following:
elglob files *
backtick foo { something using $files }
importas -i foo foo
cmdB argB $foo $files
but $files might contain "$foo" or "${foo}", which will incorrectly
be substituted. Right?
And to avoid that, you want to rename files to newfiles, and figure
that a "defines" command would do the trick, by allowing you to write
the following:
elglob files *
backtick foo { something using $files }
multisubstitute
{
importas -i foo foo
defines newfiles { $files }
}
cmdB argB $foo $newfiles
Am I correctly summarizing what you want?
If so: my issue is that your suggested solution does not address
the problem at all. Because the problem is the appearance of $foo or
${foo} in the list of files, not the appearance of $files anywhere.
$foo might still appear in the expansion of $newfiles, and that's what
will cause issues.
That is unfortunately an intrinsic problem to mixing control and data:
in the absence of proper quoting, your data may be misinterpreted as
control commands. And there is nothing execline, or you, or I, can do
about it.
The only 100% solution would be to first quote the expansion of $files
to ensure no $ appears at the start, and then have the consumer of that
expansion, here cmdB, do the unquoting. It's impossible for execline to
provide a generic unquoting command because you would then have to put
the result into your own command line in order to use it, so you'd need
a substitution, etc.
Barring that, we have to work with 99% solutions, and that means
choosing a control command that you're reasonably certain will not
appear in your data. In these situations, "foo" might not be a very
good variable naming choice. "uNiQuE_eXeClInE_vArIaBlE_420XXX69"
might be better - it hurts your eyes, yes, it hurts mine too (and my
aesthetic sensibilities in general), but chances are it won't fail
you for the lifetime of your script.
And that has nothing to do with the suggested "defines" command,
which does not help at all in this situation. (Or others.)
--
Laurent
Received on Fri May 24 2024 - 17:24:10 CEST