Re: sdiff: subsidiary program 'emacsclient -c -nw' not found

Eric Blake <[email protected]> Tue, 14 Oct 2014 07:23:49 -0600
Newsgroups	gmane.comp.gnu.utils.bugs,gmane.comp.standards.posix.austin.general
Organization	Red Hat, Inc.
Message-ID	<[email protected]>
[adding the Austin Group]

On 10/14/2014 05:23 AM, Faru Guredo wrote:
>> EDITOR is supposed to be a program, not a program with arguments.

And I've seen more programs that pass $EDITOR to the shell unquoted,
specifically to allow such arguments, than programs that do not do so.
I think sdiff is in the minority here for trying to pass "$EDITOR" as a
single shell word, so _I_ would agree with the change, but I'm not the
maintainer.  On the other hand, I just experimented on my system (Fedora
20); POSIX specifies that both crontab and more will honor EDITOR, but
in my testing, crontab allowed arguments while more tried to treat it as
a single shell word.

(I help maintain a program 'virsh' for my day job, and I changed that to
intentionally honors EDITOR with arguments several years ago [1], but as
that is not a standard program, you can discount that anecdote by
considering me to be biased)

[1] libvirt.org/git/?p=libvirt.git;a=commitdiff;h=f3661756

> Neither POSIX-2008 nor any other standard I know doesn’t specify what
> EDITOR should contain.

POSIX _does_ give a hint about it:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html

"Invoke an editor to edit the current file being examined. If standard
input is being examined, the results are unspecified. The name of the
editor shall be taken from the environment variable EDITOR, or shall
default to vi. If the last pathname component in EDITOR is either vi or
ex, the editor shall be invoked with a -c linenumber command line
argument, where linenumber is the line number of the file line
containing the display line currently displayed as the first line of the
screen. It is implementation-defined whether line-setting options are
passed to editors other than vi and ex."

which implies that EDITOR typically ends in a pathname component, not in
arguments, if 'more' is supposed to use 'basename($EDITOR)' as its
determination of whether to pass '-c linenumber' as additional
arguments.  But it is worth raising a defect to the Austin Group (the
people in charge of POSIX) if you think the standard should give more
details and either explicitly allow or deny the interpretation of EDITOR
as a program with arguments.

It would certainly be worth opening a bug report at
http://austingroupbugs.net/bug_report_page.php, but I don't have a good
feel for whether the behavior of treating EDITOR with arguments should
be allowed, forbidden, or left implementation-defined on a per-usage basis.

>> EDITOR is supposed to be a program, not a program with arguments.  Create
>> a shell script called 'foo' that does what you want and set EDITOR to 'foo'.

This solution will always work, no matter what POSIX says about EDITOR.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc (application/pgp-signature, 539 B)