* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
@ 2017-11-05 11:37 Pierre Neidhardt
2017-11-05 13:58 ` Noam Postavsky
0 siblings, 1 reply; 34+ messages in thread
From: Pierre Neidhardt @ 2017-11-05 11:37 UTC (permalink / raw
To: 29157
- emacs -Q
- M-x eshell
> date +%Z
Invalid time specification
> date "+%Z"
Invalid time specification
> date #+%Z
Sun Nov 5 12:35:51 2017
> echo $PATH | sed "s/[^o]foo[^o]/bar/g"
Unknown predicate character ‘b’
Am I misunderstanding Eshell's syntax?
In GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.16)
of 2017-11-05 built on dhiov23k
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description: Gentoo Base System release 2.4.1
Configured using:
'configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable-dependency-tracking
--disable-silent-rules --docdir=/usr/share/doc/emacs-25.3
--htmldir=/usr/share/doc/emacs-25.3/html --libdir=/usr/lib64
--program-suffix=-emacs-25 --infodir=/usr/share/info/emacs-25
--localstatedir=/var
--enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
--with-gameuser=:gamestat --without-compress-install
--with-file-notification=inotify --enable-acl --without-dbus
--without-modules --without-gpm --without-hesiod --without-kerberos
--without-kerberos5 --with-xml2 --without-selinux --with-gnutls
--without-wide-int --with-zlib --with-sound=alsa --with-x --without-ns
--without-gconf --without-gsettings --without-toolkit-scroll-bars
--with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm
--with-imagemagick --with-xft --without-cairo --without-libotf
--without-m17n-flt --with-x-toolkit=gtk3 --without-xwidgets
GENTOO_PACKAGE=app-editors/emacs-25.3 'CFLAGS=-march=ivybridge -O2
-pipe' CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND NOTIFY ACL GNUTLS LIBXML2
FREETYPE XFT ZLIB GTK3 X11
Important settings:
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-05 11:37 bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed" Pierre Neidhardt
@ 2017-11-05 13:58 ` Noam Postavsky
2017-11-05 14:16 ` Pierre Neidhardt
2017-11-05 15:16 ` Andreas Schwab
0 siblings, 2 replies; 34+ messages in thread
From: Noam Postavsky @ 2017-11-05 13:58 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157
Pierre Neidhardt <ambrevar@gmail.com> writes:
> - emacs -Q
> - M-x eshell
>
> > date +%Z
> Invalid time specification
~/src/emacs $ which date
eshell/date is an alias for ‘current-time-string’ in ‘em-unix.el’.
~/src/emacs $ which *date
/bin/date
~/src/emacs $ *date +%Z
EST
> > echo $PATH | sed "s/[^o]foo[^o]/bar/g"
> Unknown predicate character ‘b’
M-x toggle-debug-on-error gives more hints about this. Apparently this
matches a "history reference":
(defun eshell-history-reference (reference)
"Expand directory stack REFERENCE.
The syntax used here was taken from the Bash info manual.
Returns the resultant reference, or the same string REFERENCE if none
matched."
;; `^string1^string2^'
;; Quick Substitution. Repeat the last command, replacing
;; STRING1 with STRING2. Equivalent to `!!:s/string1/string2/'
Debugger entered--Lisp error: (error "Unknown predicate character ‘b’")
signal(error ("Unknown predicate character ‘b’"))
error("Unknown predicate character `%c'" 98)
eshell-parse-modifiers()
eshell-hist-parse-modifier("printf '<<%s>>\\n' \"s/[^o]foo/\"" ":s/o]foo[/o]/bar/g\"/")
eshell-history-reference("\"s/[^o]foo[^o]/bar/g\"")
eshell-expand-history-references(#<marker at 43 in *eshell*> 81)
run-hook-with-args(eshell-expand-history-references #<marker at 43 in *eshell*> 81)
eshell-send-input(nil)
funcall-interactively(eshell-send-input nil)
call-interactively(eshell-send-input nil nil)
command-execute(eshell-send-input)
My suggestion for this is just to stop adding
eshell-expand-history-references to eshell-expand-input-functions, and
maybe even deprecate eshell-expand-history-references. I find the
history expansion mechanism to be an annoyance in bash as well.
--- i/lisp/eshell/em-hist.el
+++ w/lisp/eshell/em-hist.el
@@ -218,9 +218,6 @@ eshell-input-filter-initial-space
(defun eshell-hist-initialize ()
"Initialize the history management code for one Eshell buffer."
- (add-hook 'eshell-expand-input-functions
- 'eshell-expand-history-references nil t)
-
(when (eshell-using-module 'eshell-cmpl)
(add-hook 'pcomplete-try-first-hook
'eshell-complete-history-reference nil t))
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-05 13:58 ` Noam Postavsky
@ 2017-11-05 14:16 ` Pierre Neidhardt
2017-11-23 3:13 ` Noam Postavsky
2017-11-05 15:16 ` Andreas Schwab
1 sibling, 1 reply; 34+ messages in thread
From: Pierre Neidhardt @ 2017-11-05 14:16 UTC (permalink / raw
To: Noam Postavsky; +Cc: 29157
Noam Postavsky <npostavs@users.sourceforge.net> writes:
> Pierre Neidhardt <ambrevar@gmail.com> writes:
>
>> - emacs -Q
>> - M-x eshell
>>
>> > date +%Z
>> Invalid time specification
>
> ~/src/emacs $ which date
> eshell/date is an alias for ‘current-time-string’ in ‘em-unix.el’.
> ~/src/emacs $ which *date
> /bin/date
> ~/src/emacs $ *date +%Z
> EST
Duh! That was stupid, sorry. 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'.
>> > echo $PATH | sed "s/[^o]foo[^o]/bar/g"
>> Unknown predicate character ‘b’
>
> M-x toggle-debug-on-error gives more hints about this. Apparently this
> matches a "history reference":
>
> (defun eshell-history-reference (reference)
> "Expand directory stack REFERENCE.
> The syntax used here was taken from the Bash info manual.
> Returns the resultant reference, or the same string REFERENCE if none
> matched."
> ;; `^string1^string2^'
> ;; Quick Substitution. Repeat the last command, replacing
> ;; STRING1 with STRING2. Equivalent to `!!:s/string1/string2/'
>
> Debugger entered--Lisp error: (error "Unknown predicate character ‘b’")
> signal(error ("Unknown predicate character ‘b’"))
> error("Unknown predicate character `%c'" 98)
> eshell-parse-modifiers()
> eshell-hist-parse-modifier("printf '<<%s>>\\n' \"s/[^o]foo/\"" ":s/o]foo[/o]/bar/g\"/")
> eshell-history-reference("\"s/[^o]foo[^o]/bar/g\"")
> eshell-expand-history-references(#<marker at 43 in *eshell*> 81)
> run-hook-with-args(eshell-expand-history-references #<marker at 43 in *eshell*> 81)
> eshell-send-input(nil)
> funcall-interactively(eshell-send-input nil)
> call-interactively(eshell-send-input nil nil)
> command-execute(eshell-send-input)
>
>
> My suggestion for this is just to stop adding
> eshell-expand-history-references to eshell-expand-input-functions, and
> maybe even deprecate eshell-expand-history-references. I find the
> history expansion mechanism to be an annoyance in bash as well.
>
> --- i/lisp/eshell/em-hist.el
> +++ w/lisp/eshell/em-hist.el
> @@ -218,9 +218,6 @@ eshell-input-filter-initial-space
>
> (defun eshell-hist-initialize ()
> "Initialize the history management code for one Eshell buffer."
> - (add-hook 'eshell-expand-input-functions
> - 'eshell-expand-history-references nil t)
> -
> (when (eshell-using-module 'eshell-cmpl)
> (add-hook 'pcomplete-try-first-hook
> 'eshell-complete-history-reference nil t))
That does it for me. I did not even know this feature existed. I'd it
proves more useful in an environment with poor selection / editing
capabilities, i.e. a terminal shell. Emacs does not need that when you
can fuzzy-search your history and modify your prompt with arbitrary
bindings / Lisp code.
--
Pierre Neidhardt
There are more things in heaven and earth than any place else.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-05 13:58 ` Noam Postavsky
2017-11-05 14:16 ` Pierre Neidhardt
@ 2017-11-05 15:16 ` Andreas Schwab
2017-11-10 2:04 ` Noam Postavsky
1 sibling, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2017-11-05 15:16 UTC (permalink / raw
To: Noam Postavsky; +Cc: 29157, Pierre Neidhardt
On Nov 05 2017, Noam Postavsky <npostavs@users.sourceforge.net> wrote:
> ;; `^string1^string2^'
> ;; Quick Substitution. Repeat the last command, replacing
> ;; STRING1 with STRING2. Equivalent to `!!:s/string1/string2/'
That substitution is only supposed to be performed when occuring at the
start of the line.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-05 15:16 ` Andreas Schwab
@ 2017-11-10 2:04 ` Noam Postavsky
0 siblings, 0 replies; 34+ messages in thread
From: Noam Postavsky @ 2017-11-10 2:04 UTC (permalink / raw
To: Andreas Schwab; +Cc: 29157, Pierre Neidhardt
Andreas Schwab <schwab@linux-m68k.org> writes:
> On Nov 05 2017, Noam Postavsky <npostavs@users.sourceforge.net> wrote:
>
>> ;; `^string1^string2^'
>> ;; Quick Substitution. Repeat the last command, replacing
>> ;; STRING1 with STRING2. Equivalent to `!!:s/string1/string2/'
>
> That substitution is only supposed to be performed when occuring at the
> start of the line.
Hmm, I see that's the case by experimenting with bash, although the bash
manual doesn't seem to actually say that.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-05 14:16 ` Pierre Neidhardt
@ 2017-11-23 3:13 ` Noam Postavsky
2017-11-23 6:55 ` Pierre Neidhardt
0 siblings, 1 reply; 34+ messages in thread
From: Noam Postavsky @ 2017-11-23 3:13 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
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?
> That does it for me. I did not even know this feature existed. I'd it
> proves more useful in an environment with poor selection / editing
> capabilities, i.e. a terminal shell. Emacs does not need that when you
> can fuzzy-search your history and modify your prompt with arbitrary
> bindings / Lisp code.
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).
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1803 bytes --]
From c2753c383e603acfe15f70ee0cb3c93e624c6c39 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 22 Nov 2017 21:59:35 -0500
Subject: [PATCH] Disable history expansion in eshell (Bug#29157)
History expansion is not so useful since interactive history commands
are already provided. It can produce surprising errors when the user
is not aware of the history designator syntax.
* lisp/eshell/em-hist.el (eshell-hist-initialize): Don't add
eshell-expand-history-references to eshell-expand-input-functions.
* etc/NEWS: Announce it.
---
etc/NEWS | 9 +++++++++
lisp/eshell/em-hist.el | 3 ---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index c47ca42d27..5a01b912ec 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -109,6 +109,15 @@ Snake and Pong are more playable on HiDPI displays.
*** Completing filenames in the minibuffer via 'C-TAB' now uses the
styles as configured by the variable 'completion-styles'.
+** Eshell
+
+---
+*** Expansion of history event designators is disabled by default.
+To restore the old behavior, use
+
+ (add-hook 'eshell-expand-input-functions
+ #'eshell-expand-history-references)
+
\f
* New Modes and Packages in Emacs 27.1
diff --git a/lisp/eshell/em-hist.el b/lisp/eshell/em-hist.el
index 8084c12653..df462a7058 100644
--- a/lisp/eshell/em-hist.el
+++ b/lisp/eshell/em-hist.el
@@ -218,9 +218,6 @@ eshell-input-filter-initial-space
(defun eshell-hist-initialize ()
"Initialize the history management code for one Eshell buffer."
- (add-hook 'eshell-expand-input-functions
- 'eshell-expand-history-references nil t)
-
(when (eshell-using-module 'eshell-cmpl)
(add-hook 'pcomplete-try-first-hook
'eshell-complete-history-reference nil t))
--
2.11.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-23 3:13 ` Noam Postavsky
@ 2017-11-23 6:55 ` Pierre Neidhardt
2017-11-23 12:59 ` Noam Postavsky
2017-12-03 20:43 ` Noam Postavsky
0 siblings, 2 replies; 34+ messages in thread
From: Pierre Neidhardt @ 2017-11-23 6:55 UTC (permalink / raw
To: Noam Postavsky; +Cc: 29157
[-- 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 --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-23 6:55 ` Pierre Neidhardt
@ 2017-11-23 12:59 ` Noam Postavsky
2017-11-23 16:26 ` Eli Zaretskii
2017-12-03 20:43 ` Noam Postavsky
1 sibling, 1 reply; 34+ messages in thread
From: Noam Postavsky @ 2017-11-23 12:59 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
Pierre Neidhardt <ambrevar@gmail.com> writes:
> 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 isn't exactly the same as bash or zsh. You can use M-x shell if
you prefer them.
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).
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1349 bytes --]
From ab25f638ccff0ebec36b78f9b47092fe9fb103b3 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Thu, 23 Nov 2017 07:51:13 -0500
Subject: [PATCH] eshell/date: use external date for any arguments (Bug#29157)
* lisp/eshell/em-unix.el (eshell/date): Throw `eshell-external' if
given any arguments.
(eshell-unix-initialize): Add "date" to `eshell-complex-commands'.
---
lisp/eshell/em-unix.el | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lisp/eshell/em-unix.el b/lisp/eshell/em-unix.el
index c486d2c51d..342a045d42 100644
--- a/lisp/eshell/em-unix.el
+++ b/lisp/eshell/em-unix.el
@@ -148,13 +148,18 @@ eshell-unix-initialize
(make-local-variable 'eshell-complex-commands)
(setq eshell-complex-commands
(append '("grep" "egrep" "fgrep" "agrep" "glimpse" "locate"
- "cat" "time" "cp" "mv" "make" "du" "diff")
+ "cat" "date" "time" "cp" "mv" "make" "du" "diff")
eshell-complex-commands)))
-(defalias 'eshell/date 'current-time-string)
(defalias 'eshell/basename 'file-name-nondirectory)
(defalias 'eshell/dirname 'file-name-directory)
+(defun eshell/date (&rest args)
+ (when args
+ (throw 'eshell-external
+ (eshell-external-command "date" args)))
+ (current-time-string))
+
(defvar em-interactive)
(defvar em-preview)
(defvar em-recursive)
--
2.11.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-23 12:59 ` Noam Postavsky
@ 2017-11-23 16:26 ` Eli Zaretskii
2017-11-25 17:54 ` Pierre Neidhardt
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-23 16:26 UTC (permalink / raw
To: Noam Postavsky; +Cc: 29157, ambrevar
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 23 Nov 2017 07:59:10 -0500
> Cc: 29157@debbugs.gnu.org
>
> > 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 isn't exactly the same as bash or zsh. You can use M-x shell if
> you prefer them.
>
> 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.
Eshell has both internal and external implementations because it wants
to be able to handle Lisp objects and Lisp-like syntax, not just
files, pipes, and other shell stuff. So people who expect Eshell to
be just another shell are expecting something that Eshell was never
designed to be. That's why Eshell offers the possibility to
optionally invoke the external implementation -- but it should be done
explicitly by the users, not by us second-guessing what they mean,
because reliably guessing which arguments are for an external command
and which for the internal Eshell implementation is impossible.
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, and those features are not
just an accident, they were intentionally included in Eshell.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-23 16:26 ` Eli Zaretskii
@ 2017-11-25 17:54 ` Pierre Neidhardt
2017-11-25 18:32 ` Michael Albinus
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Pierre Neidhardt @ 2017-11-25 17:54 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29157, Noam Postavsky
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> 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, and those features are not
> just an accident, they were intentionally included in Eshell.
I think you are right. I did not know that eshell/date could be used
this way.
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. Maybe
create a package if that does not fit the philosophy of mainline Emacs.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 17:54 ` Pierre Neidhardt
@ 2017-11-25 18:32 ` Michael Albinus
2017-11-25 18:35 ` Pierre Neidhardt
2017-11-25 18:50 ` Noam Postavsky
2017-11-25 19:29 ` Eli Zaretskii
2 siblings, 1 reply; 34+ messages in thread
From: Michael Albinus @ 2017-11-25 18:32 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157, Noam Postavsky
Pierre Neidhardt <ambrevar@gmail.com> writes:
Hi Piere,
> The issue here is mostly my lack of awareness about what is an Elisp
> command and what is a system program.
You can always use `which' in the eshell buffer:
--8<---------------cut here---------------start------------->8---
~ $ which date
eshell/date is an alias for ‘current-time-string’ in ‘em-unix.el’.
~ $ which *date
/bin/date
--8<---------------cut here---------------end--------------->8---
And `which' itself is an eshell function:
--8<---------------cut here---------------start------------->8---
~ $ which which
eshell/which is a compiled Lisp function in ‘esh-cmd.el’.
~ $ which *which
/usr/bin/which
--8<---------------cut here---------------end--------------->8---
See also (info "(eshell) Built-ins")
Best regards, Michael.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 18:32 ` Michael Albinus
@ 2017-11-25 18:35 ` Pierre Neidhardt
0 siblings, 0 replies; 34+ messages in thread
From: Pierre Neidhardt @ 2017-11-25 18:35 UTC (permalink / raw
To: Michael Albinus; +Cc: 29157, Noam Postavsky
[-- Attachment #1: Type: text/plain, Size: 116 bytes --]
Of course, I know that, but I meant "off the top of my head".
Knowing which one is which requires some experience.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 17:54 ` Pierre Neidhardt
2017-11-25 18:32 ` Michael Albinus
@ 2017-11-25 18:50 ` Noam Postavsky
2017-11-25 19:50 ` Eli Zaretskii
2017-11-25 19:29 ` Eli Zaretskii
2 siblings, 1 reply; 34+ messages in thread
From: Noam Postavsky @ 2017-11-25 18:50 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157
Pierre Neidhardt <ambrevar@gmail.com> writes:
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 17:54 ` Pierre Neidhardt
2017-11-25 18:32 ` Michael Albinus
2017-11-25 18:50 ` Noam Postavsky
@ 2017-11-25 19:29 ` Eli Zaretskii
2017-11-25 19:36 ` Pierre Neidhardt
2017-11-26 3:21 ` John Wiegley
2 siblings, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-25 19:29 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157, npostavs
> From: Pierre Neidhardt <ambrevar@gmail.com>
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, 29157@debbugs.gnu.org
> Date: Sat, 25 Nov 2017 18:54:51 +0100
>
> > ~/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, and those features are not
> > just an accident, they were intentionally included in Eshell.
>
> I think you are right. I did not know that eshell/date could be used
> this way.
Not just eshell/date: many Eshell built-ins behave like that, and they
do that on purpose.
> The issue here is mostly my lack of awareness about what is an Elisp
> command and what is a system program.
Why do you need to know that?
If you want to know that so you could always get the same responses as
from another system shell, then perhaps we should have an option to
tell Eshell to always invoke an external program (maybe we already
have such an option, but I couldn't find it).
> 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.
Isn't it true that a verb that doesn't begin with a '*' is _never_ a
system program in Eshell?
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 19:29 ` Eli Zaretskii
@ 2017-11-25 19:36 ` Pierre Neidhardt
2017-11-25 19:57 ` Eli Zaretskii
2017-11-26 3:21 ` John Wiegley
1 sibling, 1 reply; 34+ messages in thread
From: Pierre Neidhardt @ 2017-11-25 19:36 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29157, npostavs
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> The issue here is mostly my lack of awareness about what is an Elisp
>> command and what is a system program.
>
> Why do you need to know that?
>
> If you want to know that so you could always get the same responses as
> from another system shell, then perhaps we should have an option to
> tell Eshell to always invoke an external program (maybe we already
> have such an option, but I couldn't find it).
No, not like that, more like a friendly reminder: "this 'date' behaves
the Eshell way, while that 'rmdir' is the 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.
>
> Isn't it true that a verb that doesn't begin with a '*' is _never_ a
> system program in Eshell?
I'm tempted to answer "no, it's not true", but we might be
misunderstood.
As far as I got it, the '*' is here to force Eshell to use the system
program, while no '*' tells Eshell to use its own version if available,
or the system program otherwise.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 18:50 ` Noam Postavsky
@ 2017-11-25 19:50 ` Eli Zaretskii
2017-11-25 20:06 ` Noam Postavsky
2017-11-26 3:21 ` John Wiegley
0 siblings, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-25 19:50 UTC (permalink / raw
To: Noam Postavsky; +Cc: 29157, ambrevar
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 19:36 ` Pierre Neidhardt
@ 2017-11-25 19:57 ` Eli Zaretskii
2017-11-26 9:17 ` Pierre Neidhardt
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-25 19:57 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157, npostavs
> From: Pierre Neidhardt <ambrevar@gmail.com>
> Cc: npostavs@users.sourceforge.net, 29157@debbugs.gnu.org
> Date: Sat, 25 Nov 2017 20:36:36 +0100
>
> > If you want to know that so you could always get the same responses as
> > from another system shell, then perhaps we should have an option to
> > tell Eshell to always invoke an external program (maybe we already
> > have such an option, but I couldn't find it).
>
> No, not like that, more like a friendly reminder: "this 'date' behaves
> the Eshell way, while that 'rmdir' is the system program".
But the answer to that question depends on the arguments and sometimes
on the switches, doesn't it? E.g., Eshell's 'rm' can delete processes
and buffers, and unintern symbols, in addition to deleting files.
What exactly it does depends on the arguments. And if you invoke it
with -d switch, it will call the external program, but if you invoke
with -f or -i or -n, it will use the built-in. So just given the
verb, I don't see how you can have that indication.
> > Isn't it true that a verb that doesn't begin with a '*' is _never_ a
> > system program in Eshell?
>
> I'm tempted to answer "no, it's not true", but we might be
> misunderstood.
>
> As far as I got it, the '*' is here to force Eshell to use the system
> program, while no '*' tells Eshell to use its own version if available,
> or the system program otherwise.
So you want to have an indication when there's _no_ built-in
implementation at all, is that it?
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 19:50 ` Eli Zaretskii
@ 2017-11-25 20:06 ` Noam Postavsky
2017-11-25 20:25 ` Eli Zaretskii
2017-11-26 3:21 ` John Wiegley
1 sibling, 1 reply; 34+ messages in thread
From: Noam Postavsky @ 2017-11-25 20:06 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29157, ambrevar
Eli Zaretskii <eliz@gnu.org> writes:
> By "unrecognized arguments" do you mean unrecognized switches? If so,
> this is not the same issue as the one I was raising.
Ah, I see. I wan't really aware of that distinction.
>> 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
Ugh, stop taking me so literally, and just read my mind! ;P
How about checking for a set of arguments that is compatible with what
current-time-string accepts.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 20:06 ` Noam Postavsky
@ 2017-11-25 20:25 ` Eli Zaretskii
2017-11-25 21:41 ` Noam Postavsky
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-25 20:25 UTC (permalink / raw
To: Noam Postavsky; +Cc: 29157, ambrevar
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: 29157@debbugs.gnu.org, ambrevar@gmail.com
> Date: Sat, 25 Nov 2017 15:06:01 -0500
>
> > ~ $ date 42 "EDT-5"
> > Thu Jan 1 05:00:42 1970
> > ~ $ date (list 23065 51329 644000 0)
> > Sat Nov 25 21:46:09 2017
>
> Ugh, stop taking me so literally, and just read my mind! ;P
>
> How about checking for a set of arguments that is compatible with what
> current-time-string accepts.
Is it really possible to do that reliably?
Or maybe you meant to catch errors signaled by current-time-string,
and invoke the external command then. If so, I'd agree. But we
should then allow customization of the external command's name,
because on Windows it will be something like 'gdate', to avoid calling
the incompatible Windows shell's built-in (which also prompts
interactively for input).
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 20:25 ` Eli Zaretskii
@ 2017-11-25 21:41 ` Noam Postavsky
2017-11-26 3:35 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Noam Postavsky @ 2017-11-25 21:41 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29157, ambrevar
Eli Zaretskii <eliz@gnu.org> writes:
>> How about checking for a set of arguments that is compatible with what
>> current-time-string accepts.
>
> Is it really possible to do that reliably?
Should be okay if we err on the side of current-time-string:
(pcase (cl-list* (nth 0 args) (nth 1 args) (nthcdr 2 args)))
(`(,(or (pred listp) (pred integerp))
,(or 'nil 't 'wall (pred stringp)))
t))
> Or maybe you meant to catch errors signaled by current-time-string,
That's another possibility, it would be more precise.
> and invoke the external command then. If so, I'd agree. But we
> should then allow customization of the external command's name,
> because on Windows it will be something like 'gdate', to avoid calling
> the incompatible Windows shell's built-in (which also prompts
> interactively for input).
I'm not in front of a Windows box at the moment, but I thought a cmd.exe
builtin like that could only be invoked by doing calling "cmd /C date".
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 19:29 ` Eli Zaretskii
2017-11-25 19:36 ` Pierre Neidhardt
@ 2017-11-26 3:21 ` John Wiegley
2017-11-26 15:33 ` Eli Zaretskii
1 sibling, 1 reply; 34+ messages in thread
From: John Wiegley @ 2017-11-26 3:21 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29157, Pierre Neidhardt, npostavs
>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> Not just eshell/date: many Eshell built-ins behave like that, and they do
EZ> that on purpose.
eshell/date is an alias for `current-time-string'. The fact that this Lisp
function accepts arguments, and those arguments can be passed on the Eshell
command-line, isn't something I thought of at the time.
In hindsight, a separate eshell/date function should have been created that
would handle its arguments like the system command.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 19:50 ` Eli Zaretskii
2017-11-25 20:06 ` Noam Postavsky
@ 2017-11-26 3:21 ` John Wiegley
2017-11-26 15:35 ` Eli Zaretskii
1 sibling, 1 reply; 34+ messages in thread
From: John Wiegley @ 2017-11-26 3:21 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Noam Postavsky, 29157, ambrevar
>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> That's one way of looking at Eshell, although it's not my way. Eshell was
EZ> intended to be used from Lisp programs, and that's why its built-ins
EZ> accept Lisp objects, values, and expressions as arguments.
Eshell was intended to be a UNIX-like environment on non-UNIX systems, and as
a bonus to provide useful interactions with Lisp. It wasn't built first as a
Lisp interaction mode.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 21:41 ` Noam Postavsky
@ 2017-11-26 3:35 ` Eli Zaretskii
0 siblings, 0 replies; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-26 3:35 UTC (permalink / raw
To: Noam Postavsky; +Cc: 29157, ambrevar
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: 29157@debbugs.gnu.org, ambrevar@gmail.com
> Date: Sat, 25 Nov 2017 16:41:52 -0500
>
> > and invoke the external command then. If so, I'd agree. But we
> > should then allow customization of the external command's name,
> > because on Windows it will be something like 'gdate', to avoid calling
> > the incompatible Windows shell's built-in (which also prompts
> > interactively for input).
>
> I'm not in front of a Windows box at the moment, but I thought a cmd.exe
> builtin like that could only be invoked by doing calling "cmd /C date".
By default, yes. But people tend to do weird things with shell setup
in Emacs. And customization is an opt-in feature, so the default is
unaffected.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-25 19:57 ` Eli Zaretskii
@ 2017-11-26 9:17 ` Pierre Neidhardt
2017-11-26 15:53 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Pierre Neidhardt @ 2017-11-26 9:17 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29157, npostavs
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> > If you want to know that so you could always get the same responses as
>> > from another system shell, then perhaps we should have an option to
>> > tell Eshell to always invoke an external program (maybe we already
>> > have such an option, but I couldn't find it).
>>
>> No, not like that, more like a friendly reminder: "this 'date' behaves
>> the Eshell way, while that 'rmdir' is the system program".
>
> But the answer to that question depends on the arguments and sometimes
> on the switches, doesn't it? E.g., Eshell's 'rm' can delete processes
> and buffers, and unintern symbols, in addition to deleting files.
> What exactly it does depends on the arguments. And if you invoke it
> with -d switch, it will call the external program, but if you invoke
> with -f or -i or -n, it will use the built-in. So just given the
> verb, I don't see how you can have that indication.
Wow, I did not know that. This is not documented in the docstring, but
I just saw it is mentioned in the help message.
That maybe it the root of the issue: what's the standard way of
documenting 'eshell/*' commands?
I think both `-h' and `C-h f' should document the same thing, it's
confusing otherwise. Lest users suffer too much from the "Where did I
find that valuable help again?" syndrom.
>> > Isn't it true that a verb that doesn't begin with a '*' is _never_ a
>> > system program in Eshell?
>>
>> I'm tempted to answer "no, it's not true", but we might be
>> misunderstood.
>>
>> As far as I got it, the '*' is here to force Eshell to use the system
>> program, while no '*' tells Eshell to use its own version if available,
>> or the system program otherwise.
>
> So you want to have an indication when there's _no_ built-in
> implementation at all, is that it?
No. Basically if I write "rm" in Eshell, Eshell will _always_ call
eshell/rm. Only afterwards it will make a call to /bin/rm, depending on
the arguments.
As a user, what I want to know is what Eshell will call _first_, because
then I can know the starting point of what Eshell is going to do.
Basically, my idea is simple:
- If 'eshell/foo' exists, use some eshell-builtin face on "foo". The
user will then know that s/he should lookup the documentation of
eshell/foo.
- Otherwise use the normal face. The user will then refer to the man
page and the like.
--
Pierre Neidhardt
If the grass is greener on other side of fence, consider what may be
fertilizing it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-26 3:21 ` John Wiegley
@ 2017-11-26 15:33 ` Eli Zaretskii
2017-11-26 21:45 ` John Wiegley
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-26 15:33 UTC (permalink / raw
To: John Wiegley; +Cc: 29157, ambrevar, npostavs
> From: "John Wiegley" <johnw@gnu.org>
> Cc: Pierre Neidhardt <ambrevar@gmail.com>, 29157@debbugs.gnu.org, npostavs@users.sourceforge.net
> Date: Sat, 25 Nov 2017 19:21:01 -0800
>
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>
> EZ> Not just eshell/date: many Eshell built-ins behave like that, and they do
> EZ> that on purpose.
>
> eshell/date is an alias for `current-time-string'. The fact that this Lisp
> function accepts arguments, and those arguments can be passed on the Eshell
> command-line, isn't something I thought of at the time.
Maybe not in this case, but other Eshell commands definitely feature
similar behaviors, and there you cannot convince me it's an accident,
because the behavior is documented in the doc string.
> In hindsight, a separate eshell/date function should have been created that
> would handle its arguments like the system command.
There is such a function: *date.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-26 3:21 ` John Wiegley
@ 2017-11-26 15:35 ` Eli Zaretskii
2017-11-26 21:44 ` John Wiegley
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-26 15:35 UTC (permalink / raw
To: John Wiegley; +Cc: npostavs, 29157, ambrevar
> From: "John Wiegley" <johnw@gnu.org>
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>, 29157@debbugs.gnu.org, ambrevar@gmail.com
> Date: Sat, 25 Nov 2017 19:21:49 -0800
>
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>
> EZ> That's one way of looking at Eshell, although it's not my way. Eshell was
> EZ> intended to be used from Lisp programs, and that's why its built-ins
> EZ> accept Lisp objects, values, and expressions as arguments.
>
> Eshell was intended to be a UNIX-like environment on non-UNIX systems, and as
> a bonus to provide useful interactions with Lisp. It wasn't built first as a
> Lisp interaction mode.
Well, maybe historically I'm wrong, but factually I'm right: what we
have now is a shell that can act on Lisp objects and Lisp expressions,
and this fact is even documented in the manual. I personally find
this feature useful and a lot of fun, and I think it would be a pity
to lose it.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-26 9:17 ` Pierre Neidhardt
@ 2017-11-26 15:53 ` Eli Zaretskii
0 siblings, 0 replies; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-26 15:53 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157, npostavs
> From: Pierre Neidhardt <ambrevar@gmail.com>
> Cc: npostavs@users.sourceforge.net, 29157@debbugs.gnu.org
> Date: Sun, 26 Nov 2017 10:17:30 +0100
>
> > But the answer to that question depends on the arguments and sometimes
> > on the switches, doesn't it? E.g., Eshell's 'rm' can delete processes
> > and buffers, and unintern symbols, in addition to deleting files.
> > What exactly it does depends on the arguments. And if you invoke it
> > with -d switch, it will call the external program, but if you invoke
> > with -f or -i or -n, it will use the built-in. So just given the
> > verb, I don't see how you can have that indication.
>
> Wow, I did not know that. This is not documented in the docstring, but
> I just saw it is mentioned in the help message.
>
> That maybe it the root of the issue: what's the standard way of
> documenting 'eshell/*' commands?
>
> I think both `-h' and `C-h f' should document the same thing, it's
> confusing otherwise.
Patches to that effect are welcome.
> > So you want to have an indication when there's _no_ built-in
> > implementation at all, is that it?
>
> No. Basically if I write "rm" in Eshell, Eshell will _always_ call
> eshell/rm. Only afterwards it will make a call to /bin/rm, depending on
> the arguments.
> As a user, what I want to know is what Eshell will call _first_, because
> then I can know the starting point of what Eshell is going to do.
>
> Basically, my idea is simple:
>
> - If 'eshell/foo' exists, use some eshell-builtin face on "foo". The
> user will then know that s/he should lookup the documentation of
> eshell/foo.
>
> - Otherwise use the normal face. The user will then refer to the man
> page and the like.
Well, I think you said the same thing I did, just from a different
POV. So we are in agreement. Feel free to work on such a feature.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-26 15:35 ` Eli Zaretskii
@ 2017-11-26 21:44 ` John Wiegley
0 siblings, 0 replies; 34+ messages in thread
From: John Wiegley @ 2017-11-26 21:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: npostavs, 29157, ambrevar
>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> Well, maybe historically I'm wrong, but factually I'm right: what we have
EZ> now is a shell that can act on Lisp objects and Lisp expressions, and this
EZ> fact is even documented in the manual. I personally find this feature
EZ> useful and a lot of fun, and I think it would be a pity to lose it.
Sure, very much agreed, it was an unintended result but a welcome one. :)
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-26 15:33 ` Eli Zaretskii
@ 2017-11-26 21:45 ` John Wiegley
2017-11-27 3:32 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: John Wiegley @ 2017-11-26 21:45 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29157, ambrevar, npostavs
>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> Maybe not in this case, but other Eshell commands definitely feature similar
> behaviors, and there you cannot convince me it's an accident, because the
> behavior is documented in the doc string.
Wait, not trying to convince you of anything, just responding to what
eshell/date acts weird when given arguments. It's "news to me" in other words.
>> In hindsight, a separate eshell/date function should have been created that
>> would handle its arguments like the system command.
> There is such a function: *date.
I mean, an implementation that works when no system "date" command exists, yet
accepts arguments similar to what system date accepts.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-26 21:45 ` John Wiegley
@ 2017-11-27 3:32 ` Eli Zaretskii
2017-12-21 8:17 ` John Wiegley
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2017-11-27 3:32 UTC (permalink / raw
To: John Wiegley; +Cc: 29157, ambrevar, npostavs
> From: John Wiegley <johnw@gnu.org>
> Cc: ambrevar@gmail.com, 29157@debbugs.gnu.org, npostavs@users.sourceforge.net
> Date: Sun, 26 Nov 2017 13:45:30 -0800
>
> >> In hindsight, a separate eshell/date function should have been created that
> >> would handle its arguments like the system command.
>
> > There is such a function: *date.
>
> I mean, an implementation that works when no system "date" command exists, yet
> accepts arguments similar to what system date accepts.
If someone wants to work on Eshell's 'date' so that it accepts more
complicated arguments that the Coreutils version does, they should
feel free, of course.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-23 6:55 ` Pierre Neidhardt
2017-11-23 12:59 ` Noam Postavsky
@ 2017-12-03 20:43 ` Noam Postavsky
2017-12-04 8:43 ` John Wiegley
1 sibling, 1 reply; 34+ messages in thread
From: Noam Postavsky @ 2017-12-03 20:43 UTC (permalink / raw
To: Pierre Neidhardt; +Cc: 29157
close 29157 27.1
quit
Pierre Neidhardt <ambrevar@gmail.com> writes:
>> 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.
Pushed to master [1: 1cdd0e8cd8]. Closing the bug as it's basically
"working as designed" (although enhanced versions of eshell/date would
be welcomed as mentioned earlier on this bug thread).
[1: 1cdd0e8cd8]: 2017-12-03 15:39:02 -0500
Disable history expansion in eshell (Bug#29157)
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1cdd0e8cd801aa1d6f04ab4d8e6097a46af8c951
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-12-03 20:43 ` Noam Postavsky
@ 2017-12-04 8:43 ` John Wiegley
2017-12-04 12:51 ` Noam Postavsky
0 siblings, 1 reply; 34+ messages in thread
From: John Wiegley @ 2017-12-04 8:43 UTC (permalink / raw
To: Noam Postavsky; +Cc: 29157, Pierre Neidhardt
>>>>> "NP" == Noam Postavsky <npostavs@users.sourceforge.net> writes:
NP> Pushed to master [1: 1cdd0e8cd8]. Closing the bug as it's basically
NP> "working as designed" (although enhanced versions of eshell/date would be
NP> welcomed as mentioned earlier on this bug thread).
Hi Noam, if would have been nice for you to discuss your change in this thread
before pushing it.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-12-04 8:43 ` John Wiegley
@ 2017-12-04 12:51 ` Noam Postavsky
0 siblings, 0 replies; 34+ messages in thread
From: Noam Postavsky @ 2017-12-04 12:51 UTC (permalink / raw
To: John Wiegley; +Cc: 29157, Pierre Neidhardt
"John Wiegley" <johnw@gnu.org> writes:
>>>>>> "NP" == Noam Postavsky <npostavs@users.sourceforge.net> writes:
>
> NP> Pushed to master [1: 1cdd0e8cd8]. Closing the bug as it's basically
> NP> "working as designed" (although enhanced versions of eshell/date would be
> NP> welcomed as mentioned earlier on this bug thread).
>
> Hi Noam, if would have been nice for you to discuss your change in this thread
> before pushing it.
Hmm, I believe I have discussed it, see:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29157#8 // initial post of the change
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29157#11 // Pierre agreed with it
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29157#20 // Full change with NEWS posted
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29157#23 // Pierre agreed again
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29157#95 // Pushed after more than 1 week and no objections
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
2017-11-27 3:32 ` Eli Zaretskii
@ 2017-12-21 8:17 ` John Wiegley
0 siblings, 0 replies; 34+ messages in thread
From: John Wiegley @ 2017-12-21 8:17 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 29157, ambrevar, npostavs
>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> If someone wants to work on Eshell's 'date' so that it accepts more
EZ> complicated arguments that the Coreutils version does, they should feel
EZ> free, of course.
I imagine it would start somewhere like this:
--8<---------------cut here---------------start------------->8---
(defun eshell/date (&rest args)
"Implementation of date in Lisp."
(setq args (eshell-flatten-list args))
(eshell-eval-using-options
"rm" args
'(
(?d "date" nil nil "display time described by STRING, not 'now'")
(nil "debug" nil nil "annotate the parsed date and warn about questionable usage")
(?f "file" nil nil "like --date; once for each line of DATEFILE")
(?I "iso-8601" nil nil "output date/time in ISO 8601 format")
(?R "rfc-email" nil nil "output date and time in RFC 5322 format")
(nil "rfc-3339" nil nil "output date/time in RFC 3339 format")
(?r "reference" nil nil "display the last modification time of FILE")
(?s "set" nil nil "set time described by STRING")
(?u "utc" nil nil "print or set Coordinated Universal Time (UTC)")
(nil "universal" nil nil "print or set Coordinated Universal Time (UTC)")
(nil "help" nil nil "display this help and exit")
(nil "version" nil nil "output version information and exit")
:preserve-args
:external "date"
:show-usage
:usage "[OPTION]... [+FORMAT]
Display the current time in the given FORMAT, or set the system date.")
(while args
(let ((entry (car args)))
)
(setq args (cdr args)))
nil))
--8<---------------cut here---------------end--------------->8---
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2017-12-21 8:17 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-05 11:37 bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed" Pierre Neidhardt
2017-11-05 13:58 ` Noam Postavsky
2017-11-05 14:16 ` Pierre Neidhardt
2017-11-23 3:13 ` Noam Postavsky
2017-11-23 6:55 ` Pierre Neidhardt
2017-11-23 12:59 ` Noam Postavsky
2017-11-23 16:26 ` Eli Zaretskii
2017-11-25 17:54 ` Pierre Neidhardt
2017-11-25 18:32 ` Michael Albinus
2017-11-25 18:35 ` Pierre Neidhardt
2017-11-25 18:50 ` Noam Postavsky
2017-11-25 19:50 ` Eli Zaretskii
2017-11-25 20:06 ` Noam Postavsky
2017-11-25 20:25 ` Eli Zaretskii
2017-11-25 21:41 ` Noam Postavsky
2017-11-26 3:35 ` Eli Zaretskii
2017-11-26 3:21 ` John Wiegley
2017-11-26 15:35 ` Eli Zaretskii
2017-11-26 21:44 ` John Wiegley
2017-11-25 19:29 ` Eli Zaretskii
2017-11-25 19:36 ` Pierre Neidhardt
2017-11-25 19:57 ` Eli Zaretskii
2017-11-26 9:17 ` Pierre Neidhardt
2017-11-26 15:53 ` Eli Zaretskii
2017-11-26 3:21 ` John Wiegley
2017-11-26 15:33 ` Eli Zaretskii
2017-11-26 21:45 ` John Wiegley
2017-11-27 3:32 ` Eli Zaretskii
2017-12-21 8:17 ` John Wiegley
2017-12-03 20:43 ` Noam Postavsky
2017-12-04 8:43 ` John Wiegley
2017-12-04 12:51 ` Noam Postavsky
2017-11-05 15:16 ` Andreas Schwab
2017-11-10 2:04 ` Noam Postavsky
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).