bug#55236: 29.0.50; Surprising behaviors with Eshell expansions

[Jim Porter]

(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).