emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add shell-quasiquote.


From: Random832
Subject: Re: [PATCH] Add shell-quasiquote.
Date: Thu, 22 Oct 2015 09:41:20 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

David Kastrup <address@hidden> writes:
> Eli Zaretskii <address@hidden> writes:
>> OK, but that still boils down to binding some more variables.  If we
>> want to help users with these factoids, we could have a small database
>> of the known Posix shells and their requirements.

I couldn't find an easy way to do let-style binding of environment
variables, though I didn't look very hard. And the point of what I was
suggesting is to let *packages* do this, not *users*, so the "database"
would have to be part of code that decides what to actually do.

> I think that's overdoing it with regard to shell-quote-argument and
> friends.  We don't need a full POSIX shell, just something with the most
> basic quoting conventions of it.  /bin/sh should be fine here.

I think there might be a basic miscommunication here. If you don't care
about being able to execute arbitrary POSIX shell commands as well as is
possible on a given system, what's even the point of *having* functions
like shell-quote-argument, shell-command, etc, instead of call-process?

In these discussions I've been starting from the assumption that these
functions actually have a point and that being able to execute complex
shell commands (which may use advanced redirection, if/case/for/etc,
parameter expansion, and so forth) from within elisp scripts is a
desirable feature.

> That's all the guarantee you get for calling commands/scripts with
> `system'.  I don't think we should require more than that or try
> providing some guarantees in that regard.

On an actual POSIX system, it's guaranteed that "sh" from PATH (not
necessarily /bin/sh) will be a POSIX shell, and that 'system' will
execute it and not some other shell. (AIUI this is generally still
implemented by a hardcoded path, just one which is not necessarily
/bin/sh)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]