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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55236 in the body.
You can then email your comments to 55236 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 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).

Message #8 received at 55236 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: 55236 <at> debbugs.gnu.org
Subject: Re: bug#55236: [PATCH] 29.0.50; Surprising behaviors with Eshell
 expansions
Date: Mon, 2 May 2022 20:45:25 -0700

[Message part 1 (text/plain, inline)]

Here are the patches. Each patch corresponds to one of the headings in 
the original email. Hopefully they're fairly self-explanatory since I've 
added documentation to the manual as well as NEWS entries for each. I 
debated whether these should count as incompatible changes, but for most 
cases, I think there shouldn't be any incompatibility.

The highest-risk patch is the second one, since it converts multi-line 
numeric output from subcommands into a list of numbers. However, this 
helps a lot in fixing some of the problems in the third issue 
(concatenating expansions), and I think it's more consistent overall 
than before. However, it could make sense to provide a defcustom to opt 
out of the behavior if people think that would be helpful.

[0001-Eshell-variable-expansion-should-always-return-strin.patch (text/plain, attachment)]

[0002-Return-a-list-of-numbers-if-all-lines-of-an-Eshell-s.patch (text/plain, attachment)]

[0003-Improve-the-behavior-of-concatenating-parts-of-Eshel.patch (text/plain, attachment)]

Message #11 received at 55236 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: 55236 <at> debbugs.gnu.org
Subject: Re: bug#55236: [PATCH v2] 29.0.50; Surprising behaviors with Eshell
 expansions
Date: Mon, 2 May 2022 21:20:06 -0700

[Message part 1 (text/plain, inline)]

On 5/2/2022 8:45 PM, Jim Porter wrote:
> Here are the patches. Each patch corresponds to one of the headings in 
> the original email. Hopefully they're fairly self-explanatory since I've 
> added documentation to the manual as well as NEWS entries for each. I 
> debated whether these should count as incompatible changes, but for most 
> cases, I think there shouldn't be any incompatibility.
> 
> The highest-risk patch is the second one, since it converts multi-line 
> numeric output from subcommands into a list of numbers. However, this 
> helps a lot in fixing some of the problems in the third issue 
> (concatenating expansions), and I think it's more consistent overall 
> than before. However, it could make sense to provide a defcustom to opt 
> out of the behavior if people think that would be helpful.

Spelling is hard. I fixed a typo in the documentation for the second 
patch (`eshell-convert-numeric-agument' -> 
`eshell-convert-numeric-arguments').

[0001-Eshell-variable-expansion-should-always-return-strin.patch (text/plain, attachment)]

[0002-Return-a-list-of-numbers-if-all-lines-of-an-Eshell-s.patch (text/plain, attachment)]

[0003-Improve-the-behavior-of-concatenating-parts-of-Eshel.patch (text/plain, attachment)]

Message #14 received at 55236 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 55236 <at> debbugs.gnu.org
Subject: Re: bug#55236: 29.0.50; Surprising behaviors with Eshell expansions
Date: Tue, 03 May 2022 11:32:07 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> From "emacs -Q --eval '(eshell)'":

Unrelated to this bug, but convenient in general: The same can be done by

emacs -Q -f eshell

Best regards, Michael (always lazy).

Message #17 received at 55236 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 55236 <at> debbugs.gnu.org
Subject: Re: bug#55236: 29.0.50; Surprising behaviors with Eshell expansions
Date: Tue, 03 May 2022 18:24:45 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

>> The highest-risk patch is the second one, since it converts
>> multi-line numeric output from subcommands into a list of
>> numbers. However, this helps a lot in fixing some of the problems in
>> the third issue (concatenating expansions), and I think it's more
>> consistent overall than before. However, it could make sense to
>> provide a defcustom to opt out of the behavior if people think that
>> would be helpful.

I guess it makes sense to wait to see whether anybody requests a
defcustom before adding it here.

> Spelling is hard. I fixed a typo in the documentation for the second
> patch (`eshell-convert-numeric-agument' ->
> `eshell-convert-numeric-arguments').

Thanks; pushed to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.