On Fri, May 24, 2024 at 03:24:10PM +0000, Laurent Bercot wrote:
>
> > > 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?
That is a cleaner example, yes.
> 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?
>
That is correct.
> 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.
>
I don't understand what you mean by that; $foo/${foo} in $newfiles won't
expand because multisubstitute is being used to expand both $foo and
$newfiles.
And, as you know, you don't have to worry about $files in $foo or
$newfiles; the elglob files * command already ran and expanded $files
at this point; it cannot expand $files again in the value of foo.
> 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.
>
I am sorry, but I don't understand what case you think is problematic.
> 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.
>
I don't see why you need to do this though, you just need to be able to
expand the values at the same time with a multisubstitute.
> And that has nothing to do with the suggested "defines" command,
> which does not help at all in this situation. (Or others.)
>
Can you explain this better with some example values? I really can't
understand what you think is the problem defines in multisubstitute
won't solve.
> --
> Laurent
>
o/
emanuele6
Received on Fri May 24 2024 - 17:54:13 CEST