On Sun, 7 Sept 2025 at 12:40, Koichi Murase <[email protected]> wrote:
> 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 I was (subconsciously) thinking along these lines when initially choosing ';'. > 2025年9月6日(土) 21:16 Martin D Kealey <[email protected]>: > > ${ > > *commands* > > } > > This is already a valid syntax for normal function substitutions. In addition to this ship having already sailed, using newline like this would get very tiresome, eg. a simple "${;cat;}" to grab complete stdin would instead become "${ cat;}", with the forced newline being very disruptive to the (visual) flow of the code. > > 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 I like '@N' because it's extensible, and analogous to parameter transformations. However, there isn't currently a ${parameter@N}, and even if there were it would probably be ${parameter@n} to _actually_ strip trailing newlines. It could also introduce confusion by suggesting that the other existing parameter transformations could be used, eg. ${@U cmd ;}, which isn't the case, at least not without a lot of extra work (and some may not even make sense for command substitution, eg. @a). I liked the '&flag' approach from [8], except that in the context of bash, I associate '&' with "run async in background" (whereas '&' would make more sense in the context of URL query-string fields). So I think I still prefer ';' to these. I had a brief look at the other single-char possibilities; many have obvious problems, and none stood out (to me, anyway) as being significantly better. Kev
