Re: [PATCH] Add shell-quasiquote.

[Taylan Ulrich Bayırlı/Kammer]

Paul Eggert <address@hidden> writes:

> On 10/19/2015 06:53 AM, Taylan Ulrich Bayırlı/Kammer wrote:
>> If there's a /bin/if on the system, (shqq (if blah blah)) will call it.
>> Not very useful, but consistent.
>
> No, it's not consistent. If there's a file named "sh" in the working
> directory, shqq will not attempt to call it unless "." precedes "/bin"
> and "/usr/bin" in PATH (which is not a good idea for other reasons).
> More amusingly, although there is a file named "." in the working
> directory, shqq will not attempt to call it, and instead will invoke a
> builtin shell command that allows injection of arbitrary shell code.
>
> To quote a file name that one wants to execute one must also prefix it
> with './', unless the unquoted name starts with '/'. That would be
> more consistent. Of course, it would also be incorrect for strings
> intended to be the command's arguments. This means that neither
> shqq--quote-string nor shell-quote-argument should be used blindly to
> quote command names. In this sense, shell-quote-argument has a better
> name than shqq--quote-string does, since the word "argument" means the
> function is intended for command arguments, as opposed to arbitrary
> strings.
>
> All in all there does not seem to be a good reason to have a separate
> function shqq--quote-string. Any improvement that it has over
> shell-quote-argument should be folded into shell-quote-argument.

I have honestly no idea what you're talking about at this point.

Who ever talked about running files in the current directory?

No, the shell does not try to run the . file as a script, no matter what
PATH is.  (How is PATH even relevant to the topic?)


I'm not motivated to waste any more time on this discussion.  People
seem to be bringing up even weirder and weirder pseudo-reasons to reject
perfectly working code with well-defined semantics.  If you don't want
it, fine.

Taylan