GNU bug report logs - #23590
25.0.94; Errors in default lgrep command

Previous Next

Full log

Message #14 received at 23590 <at> debbugs.gnu.org (full text, mbox):

From: John Mastro <john.b.mastro <at> gmail.com>
To: 23590 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Alex <agrambot <at> gmail.com>
Subject: Re: bug#23590: 25.0.94; Errors in default lgrep command
Date: Sat, 23 Jul 2016 09:57:02 -0700

Eli Zaretskii <eliz <at> gnu.org> wrote:
> Shell commands that Emacs emits support /bin/sh and compatible
> shells.  Zsh's default treatment of unmatched wildcards isn't.
>
> I don't know how it happened that lgrep invokes zsh on OP's system,
> but if that is due to user customizations, they should be corrected.
> If that is Emacs's fault (i.e. Emacs invokes zsh without any
> customizations), it should be fixed.

Emacs invokes whichever shell is the value of the user's SHELL
environment variable.

My reading of the code is that this is the result of a call chain from
`lgrep', to `compilation-start', to `start-file-process-shell-command',
to `start-file-process'. The only way `shell-file-name' is disregarded
in favor of /bin/sh is if `default-directory' is remote:

(defun start-file-process-shell-command (name buffer &rest args)
  (start-file-process
   ...
   (if (file-remote-p default-directory) "/bin/sh" shell-file-name)
   ...))

And shell-file-name is initialized to the value of SHELL in
init_callproc():

char *sh;
...
sh = getenv ("SHELL");
Vshell_file_name = build_string (sh ? sh : "/bin/sh");

So the user may not have intended to customize Emacs per se, but setting
SHELL does so indirectly.

This is my first time looking at most of this code but, if the intent is
for `lgrep' to always use /bin/sh, the least ugly way I see of doing
that is to let-bind `shell-file-name' in `lgrep'.

Obviously it would remain the case that Emacs uses shell-file-name for
other commands, but since AFAIK that hasn't been a problem more
generally a minimal change may be best.

> Yes, but I don't understand why the OP says these are errors.  They
> aren't; they are just informative messages from Grep.

I'm guessing this was just a misunderstanding about how `lgrep' works.
If the reporter thought of it as "call grep on all files", and didn't
think of directories as files, then it might be surprising at first to
see those messages.

        John

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.