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

[Pierre Neidhardt <ambrevar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]


Noam Postavsky <npostavs@users.sourceforge.net> writes:

> Pierre Neidhardt <ambrevar@gmail.com> writes:
>
>> Anyways, that might ring an alarm here: maybe eshell/date should not
>> exist.  What's the point of having it?  I'm not sure.  It is obviously
>> less powerful than the system `date'.
>
> Eshell has lots of commands like that.  I guess it makes it more portable?

I'm really not sure where to go from here.

Disabling eshell/date makes Eshell less portable on one system at least,
that is Windows.  But what does "portability" mean in this context?  Are
the coreutils meant to be part of Eshell?  Why?  Supporting `date' but not
its arguments does not make up for actual portability I believe.  Case
in point: I got fooled.

Let's take the case of BSD vs. GNU: bash or zsh do not wrap around `ls',
so the behaviour will not be the same on BSD and GNU.  Why should Eshell
be any different?

Eshell is meant to be interactive: does portability matter in that case?

My current stance leans towards removing `date' and other commands that
seem to be here for "portability" only.

Wrappers like `grep' have a clear purpose: redirecting to a dedicated buffer.
I think it's find to keep such commands.

> I agree.  Although the expansion in this case is arguably a bug (as
> Andreas pointed out), I don't have much interest in fixing it.  I
> propose just to disable it by default (in master).

Thank you.

--
Pierre Neidhardt

Would the last person to leave Michigan please turn out the lights?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]