GNU bug report logs - #29157
25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"

Previous Next

Package: emacs;

Reported by: Pierre Neidhardt <ambrevar <at> gmail.com>

Date: Sun, 5 Nov 2017 11:38:02 UTC

Severity: normal

Found in version 25.3

Fixed in version 27.1

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Pierre Neidhardt <ambrevar <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29157 <at> debbugs.gnu.org
Subject: Re: bug#29157: 25.3;
 Eshell parsing fails sometimes, e.g. "date" and "sed"
Date: Sat, 25 Nov 2017 13:50:46 -0500
Pierre Neidhardt <ambrevar <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> We could fallback to the external command if given arguments.  This is
>>> being done currently for other commands like eshell/rm (for unrecognized
>>> arguments, that is).

>> That doesn't sound right to me (for rm as well): it will fail in
>> strange ways for systems where the external command is absent or
>> deficient.

Currently eshell falls back to external command for unrecognized
arguments when passing :external to eshell-eval-using-options.  A quick
grep for :external brings up: rm, mkdir, rmdir, mv, cp, ln, cat, du,
time, env, ls.

>> Observe:
>>
>> 	~/git/emacs/branch $ date 42
>> 	Wed Dec 31 19:00:42 1969
>> But
>> 	~/git/emacs/branch $ *date 42
>> 	/bin/date: invalid date ‘42’
>>
>> So I'm not sure such a naïve solution is TRT in this case, because we
>> are losing valuable features by doing that,

So we could also check for an integer argument.

>> and those features are not
>> just an accident, they were intentionally included in Eshell.

Hmm, my impression of eshell is more like "throw a bunch of features at
the wall and see what sticks" but without the "see what sticks" part.

> The issue here is mostly my lack of awareness about what is an Elisp
> command and what is a system program.
>
> Maybe having different syntax highlighting for the "verb" depending on
> whether it's a system program or an Elisp command would help avoiding
> the pitfall.
>
> Is there a trivial way to do this?  If not I'll work on it.

There is no such feature, as far as I know.





This bug report was last modified 7 years and 159 days ago.

Previous Next


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