unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Heads up: Recent changes to Eshell expansions
@ 2022-05-03 19:50 Jim Porter
  0 siblings, 0 replies; only message in thread
From: Jim Porter @ 2022-05-03 19:50 UTC (permalink / raw)
  To: emacs-devel

Recently in bug#55236, I made some changes to how Eshell expansions 
work. While I think these changes should make it easier to use Eshell 
expansions in more-complex cases, I wanted to call out the changes so 
that people can be on the lookout for any regressions.

The changes (in commits f7a82699, 06423b5d, and a3a7279a) all have NEWS 
and manual entries if you'd like to see the details, but I'll quickly 
summarize them here as well.

First, when using an expansion inside double-quotes, the result is now a 
string (previously, double-quotes had no effect on the result). This 
gives more control over how expansions are, well, expanded. For example:

   ;; Existing behavior:
   ~ $ echo ${/bin/echo -e "foo\nbar"}
   ("foo" "bar")

   ;; New behavior:
   ~ $ echo "${/bin/echo -e \"foo\nbar\"}"
   foo
   bar

In the first case, the output of the subcommand is split by lines into a 
list. In the second, the result is a single string with the newline 
preserved.

Second, Eshell subcommands (e.g. ${COMMAND}) have always converted 
numeric strings into actual numbers, but only for a single number. Now, 
if the subcommand's output is a list of numeric strings, one per line, 
the result is a list of numbers:

   ;; Existing behavior:
   ~ $ type-of ${/bin/echo "1"}
   integer

   ;; New behavior:
   ~ $ echo ${/bin/echo -e "1\n2"}
   (1 2)

This allows you to do arithmetic on the output like so:

   ~ $ apply #'+ ${/bin/echo -e "1\n2"}
   3

Note that this conversion only occurs if *all* lines are numeric. If 
there are some non-numeric lines, then the result is a list of strings 
(that way there's never a situation where the output has mixed types).

Finally, concatenating expansions works differently now. For the simple 
case, where both sides expand to strings, there are no changes, but 
concatenating to a list now concatenates "adjacent" elements. This is 
similar to how most other shells (e.g. dash, bash, zsh) work, so if 
you're familiar with the behavior there, you shouldn't face any 
surprises. For example:

   ~ $ $ echo $(list "a" "b")c$(list "d" "e")
   ("a" "bcd" "e")

Previously, Eshell would convert lists to strings before concatenating 
the operands, which produced odd results (see bug#12689 for example).

Hopefully these changes will make it easier to use Eshell expansions in 
more complex cases while keeping the common cases unchanged, but if 
anyone encounters any problems, let me know.

- Jim




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-05-03 19:50 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-03 19:50 Heads up: Recent changes to Eshell expansions Jim Porter

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