GNU bug report logs -
#55236
29.0.50; Surprising behaviors with Eshell expansions
Previous Next
Reported by: Jim Porter <jporterbugs <at> gmail.com>
Date: Tue, 3 May 2022 03:42:02 UTC
Severity: normal
Found in version 29.0.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
(Note: this is closely related to bug#12689, but this isn't *quite* a
fix for that bug. This bug is also somewhat broader in scope, so it felt
like a new bug was the best place for it. I'll comment on that bug
shortly with further details.)
There are several inconsistencies with how Eshell expansions are, well,
expanded. These are arguably separate bugs, but they're closely-enough
related that I think it's best to discuss them all at once so that
everyone can see the full context (especially since any changes here
could conceivably cause incompatibilities).
1. Quoted Expansions
--------------------
From "emacs -Q --eval '(eshell)'":
~ $ type-of 1
integer
~ $ type-of "1"
string
~ $ setq foo 1
1
~ $ type-of $foo
integer
~ $ type-of "$foo"
integer
Surprisingly, the last line shows that "$foo" is an integer, even though
double-quotes are used in Eshell to disable conversion to numbers. For
another example, first try this in your favorite shell (tested in dash,
bash, and zsh):
$ cat args
#!/usr/bin/env python3
import sys
print(sys.argv[1:])
$ ./args $(/bin/echo -e "foo\nbar")
['foo', 'bar']
$ ./args "$(/bin/echo -e "foo\nbar")"
['foo\nbar']
Now in "emacs -Q --eval '(eshell)'":
~ $ ./args ${/bin/echo -e "foo\nbar"}
['foo', 'bar']
~ $ ./args "${/bin/echo -e \"foo\nbar\"}"
['foo', 'bar']
Again, wrapping the Eshell expansion in double-quotes doesn't do
anything. It should probably work like other shells.
2. Converting subcommand output to numbers
------------------------------------------
From "emacs -Q --eval '(eshell)'":
~ $ type-of ${/bin/echo "1"}
integer
~ $ echo ${/bin/echo -e "1\n2"}
("1" "2")
~ $ type-of ${/bin/echo -e "1\n2"}[0]
string
Eshell converts ${SUBCOMMAND} output to a number, but only if there's a
*single* number. If there are multiple lines with numbers, you just get
a list of strings. This is somewhat inconvenient, since you might want
to add the numbers up, e.g. by typing:
~ $ apply #'+ ${/bin/echo -e "1\n2"}
Wrong type argument: number-or-marker-p, "1"
(This might seem unrelated, but it ties directly into the next issue.)
3. Concatenating expansions
---------------------------
Like in other shells, you can concatenate expansions with strings or
other expansions. From "emacs -Q --eval '(eshell)'":
~ $ echo ${*echo "1"}2
12
~ $ type-of ${*echo "1"}2
integer
That's fine (at least once you know to expect it), but there are some
odd corner cases:
~ $ setq foo "1"
1
~ $ type-of $foo
string
~ $ type-of $'foo'2
integer
Here, concatenating two strings produces an integer, since the string
"12" looks numeric. I think that's an overly-aggressive conversion.
Similarly, when the expansion returns a list, the result is surprising
(this is one of the things bug#12689 is about):
~ $ ./args ${/bin/echo -e "foo\nbar"}-baz
['("foo" "bar")-baz']
This time, the result is the list of lines from /bin/echo, converted to
a string, and then concatenated with "-baz" into a single string. That's
surprising, since doing the same sort of thing in dash/bash/zsh produces
the following:
$ ./args $(/bin/echo -e "foo\nbar")-baz
['foo', 'bar-baz']
I'll post patches for these shortly (just getting a bug number).
This bug report was last modified 3 years and 19 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.