bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"


From: Eli Zaretskii
Subject: bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
Date: Sat, 25 Nov 2017 21:50:05 +0200

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  29157@debbugs.gnu.org
> Date: Sat, 25 Nov 2017 13:50:46 -0500
> 
> >> 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.

By "unrecognized arguments" do you mean unrecognized switches?  If so,
this is not the same issue as the one I was raising.

> >> 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.

But it isn't just integers:

  ~ $ date 42 "EDT-5"
  Thu Jan  1 05:00:42 1970
  ~ $ date (list 23065 51329 644000 0)
  Sat Nov 25 21:46:09 2017

> >> 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.

That's one way of looking at Eshell, although it's not my way.  Eshell
was intended to be used from Lisp programs, and that's why its
built-ins accept Lisp objects, values, and expressions as arguments.





reply via email to

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