My co-worker is visually impaired, and he uses a custom emacs.  His
EDITOR is set to something like "~/bin/xemacs -nw".  When git-commit
runs, it complains:

% git-commit
git-commit: line 582: ~/bin/xemacs -nw: No such file or directory

So, I fiddled with the following line in git-commit:

        ${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/COMMIT_EDITMSG"

and changed it to:

        eval ${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/COMMIT_EDITMSG"

and it seems to work as I would expect in this case.

Is this a reasonable fix?


Bill
-

[ message continues ]

Why not set EDITOR="$HOME/bin/xemacs -nw"? It should work well IMHO.

-- 
Duy
-

[ message continues ]

Of course, and one could use a full path also, but tilde is a
perfectly valid replacement for $HOME, and I think git should support
it, and not force the user to work around it.


Bill
-

[ message continues ]

>>>>> "Bill" == Bill Lear <rael@zopyra.com> writes:

Bill> Of course, and one could use a full path also, but tilde is a
Bill> perfectly valid replacement for $HOME,

Only to a shell.  The kernel has no clue about it.  I'd even say "only
to *some* shells" as well, but most modern shells now understand it.

Bill>  and I think git should support
Bill> it, and not force the user to work around it.

The eval solution is wrong on multiple levels.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-

[ message continues ]

Well it is certainly valid to a user to set their EDITOR in that way,
both in bash and zsh, so "only to a shell" is false, not even
considering that he works with this every day with plenty of other
tools, and has not seen a problem with them.  I do notice that
cvs pukes on this, however:

% cd bin
% ln -s /usr/bin/vim vingo
% cd ~/testo
% EDITOR="~/bin/vingo -C"
% cvs commit
cvs commit: cannot exec ~/bin/vingo: No such file or directory

Fine with me: that's why I brought it up and asked the question.  How
would you propose to fix it?  If git-commit were rewritten in C, I
can see an argument "C does not understand tilde", but I can't
see this as a valid argument for not supporting it.


Bill
-

[ message continues ]

C does not have tilde expansion or "eval", but it has "system()":

int main () {
        system("~/bin/scripts/moy-editor.sh foo.txt");
}

works as you'd expect.

-- 
Matthieu
-

[ message continues ]

>>>>> "Matthieu" == Matthieu Moy <Matthieu.Moy@imag.fr> writes:

Matthieu> C does not have tilde expansion or "eval", but it has "system()":

Matthieu> int main () {
Matthieu>         system("~/bin/scripts/moy-editor.sh foo.txt");
Matthieu> }

Matthieu> works as you'd expect.

And that's because it forks a /bin/sh to process that.  And your modern
/bin/sh apparently understands tilde expansion.  *that* wouldn't have worked
back when /bin/sh was really the bourne shell and not some cheap over-featured
(read "GNU") clone.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-

[ message continues ]

Yes. That's a good reason not to use system() on hardcoded values. I
wouldn't write the line of code above in a real-life program. But
here, the argument of system() comes from the user-configuration. If
he's running on a machine whose shell does tilde expansion, he can use
tilde-expansion in his configuration. On windows, I believe system()
has some windows-specific things, but the user probably expects to be
able to use them if he runs windows.

-- 
Matthieu
-

[ message continues ]

This one is not a good argument. If you write this:

export EDITOR=~/bin/emacs

the shell does the tilde expansion, and git doesn't have to worry

I just checked, and at least less, svn, cvs and mutt do the tilde
expansion themselves (the way you expect). To me, that is an argument:
if a setup works with most unix-ish tools, it should work for git too.

Now, for the good news: with the latest git, it just works!

commit 08874658b450600e72bb7cb0d0747c1ec4b0bfe1
Author: David Kastrup <dak@gnu.org>
Date:   Wed Aug 1 23:47:20 2007 +0200

-- 
Matthieu
-

[ message continues ]

I don't see how this line could trigger an error like the one you get.

Your error message doesn't tell you it doesn't expand the tilde, it tells
you it uses the whole string ! It is looking for a "xemacs -nw" file under
$HOME/bin, which obviously doesn't exist.

Now, theorically, this should not happen unless you quote the whole
variable substitution thing.

What is your co-worker's shell ?

Mike
-

[ message continues ]

$ (x='a b'; $x)
bash: a: command not found
$ (x='~/a b'; $x)
bash: ~/a: No such file or directory

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber
-

[ message continues ]

Your point being ?

Mike
-

[ message continues ]

That your point is wrong. Shell will perform word splitting after
variable expansion. But it will perform variable expansion after tilde
expansion, and that's the trouble.

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber
-

[ message continues ]

That's exactly what I said. It should only happen if ${VISUAL:-${EDITOR:-vi}}
was quoted.

And yet, look at his error message.

Mike
-

[ message continues ]

Ah, yeah, sorry. Apparently, I've already worked too much today. ;-)

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber
-

[ message continues ]

You then are apparently mistaken in your reasoning.  1) It was
definitely not quoted; 2) the EDITOR setting was as I said; and 3) the
error message came out exactly as I said.


Bill
-

[ message continues ]

As I said, EDITOR is set to "~/bin/xemacs -nw", that is, he did
something like this:


zsh, but I use bash and it failed for me as well.


Bill
-

[ message continues ]

The right question is more, what is your /bin/sh.

$ EDITOR="~/bin/xemacs -nw"; ${VISUAL:-${EDITOR:-vi}} foo
bash: ~/bin/xemacs: No such file or directory

$ EDITOR="~/bin/xemacs -nw"; ${VISUAL:-${EDITOR:-vi}} foo
dash: ~/bin/xemacs: not found

Mike
-

[ message continues ]

It's not clear to me how this ever would have worked.  Programs *can*
execute $EDITOR with system(3), but it's possible they could execute it
with exec, in which case the binary "~/bin/xemacs -nw" definitely would
not be found.

The right solution to this IMO is to do both of the following:

(1) Create a shell script ~/bin/xemacs-nox that contains

#! /bin/bash
xemacs -nw "$@"

(2) Set the editor to

EDITOR=~/bin/xemacs-nox

Note the distinct LACK of double quotes around the value, which will
result in the shell expanding the ~ before assigning the value to $EDITOR.

Kyle

-

[ message continues ]

EDITOR=~/bin/xemacs\ -nw

No need for the script.
-

[ message continues ]

As I stated in the message to which you replied, that only works if the
calling program is guaranteed to use system or its equivalent to load
the $EDITOR.  Git et al. may do that, but I don't know that there's any
guarantee of it working universally: other programs do use $EDITOR, you
know. ;-)  That's why I recommend a script: simple and universal.

Kyle

-

[ message continues ]