I vote for ${; cmd; }. It now seems to make sense to me. It initially
appeared to be strange, but it seems to be a matter of whether you've
gotten used to it. We already have ${| cmd; }, and there are still
many command delimiters (where `|' belongs to), such as `&', `;',
`||', `&&', `|&', `;;', `;&', `;;&', and it doesn't seem to be
necessary to explore a larger namespace for variations of command
substitutions for now. Among them, I'd associate `;' with something
related to the end, which has some affinity with the current feature
of preserving newlines at the end of the command output.
I think it is good to keep the namespace ${<word><space><string>;} for
possible future extensions, such as user-defined substitutions
suggested in Ref. [1,2], for now. Here, <word> can be e.g. an
arbitrary user-defined function name (including `+', `@N', `↓',
`ᚹᛟᚱᚦᚱ', and `NOTRIM'), and should be quoted properly when an
arbitrary function name [3] is implemented (such as ${'a&b' cmd; } for
« function 'a&b' {...} »).
2025年9月6日(土) 21:16 Martin D Kealey <mar...@kurahaupo.gen.nz>:
> ${
> *commands*
> }
This is already a valid syntax for normal function substitutions.
> (Ordinarily I wouldn't suggest re-purposing “existing” syntax, but this
> feature has only existed for a brief while, so perhaps we can still get
> away with changing it?)
Ksh seems to have released the no-fork command substitutions in 2008
[4,5]. Mksh seems to have released the function substitutions in 2013
[6,7]. The current Bash behavior of starting funsub with `${<newline>'
is not new but consistent with these implementations.
[4]
https://github.com/ksh93/ksh/blob/310b28220776c6bc023678e8ee1058188724b466/src/cmd/ksh93/TYPES#L88-L90
[5] https://www.in-ulm.de/~mascheck/various/shells/ksh_versions.html
[6]
https://github.com/MirBSD/mksh/commit/bfe7d78d40560070adae184efcaaca220da75f83
[7] https://github.com/MirBSD/mksh/releases/tag/mksh-R41b
> Alternatively, does it have to be a single byte?
> ${@N *whitespace* *commands* ;}
Ref..[8] suggests & used to introduce a named flag in a similar way.
[8] https://lists.gnu.org/archive/html/bug-bash/2021-01/msg00269.html
> Are we allowed to venture into the realm of UTF-8?
What happens under LC_CTYPE=C or any other non-UTF-8 locales? As long
as you are in GUI environments of modern Linux/BSD/macOS/Windows, you
might be able to assume the UTF-8 support, but what to do with limited
environments such as Linux consoles and embedded systems? It is fine
to allow user-defined functions to have Unicode names, where the user
is responsible for managing the locale properly, but it is strange
that the feature set of the language changes depending on the locale.
--
Koichi
