GNU bug report logs - #55236
29.0.50; Surprising behaviors with Eshell expansions

Previous Next

Package: emacs;

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: 55236 <at> debbugs.gnu.org
Subject: bug#55236: 29.0.50; Surprising behaviors with Eshell expansions
Date: Mon, 2 May 2022 20:41:04 -0700
(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.