Re: [PATCH?] Nofork and removing newlines

[Oliver Kiddle <opk@xxxxxxx>]

Bart Schaefer wrote:
> On Fri, Mar 8, 2024 at 2:15 PM Oliver Kiddle <opk@xxxxxxx> wrote:
> >
> > Why does it print command not found errors for things like ${|=|:},
> > ${|*|:} and ${|?|:}, I'd rather have $? than it globbing for a single
>
> Bart Schaefer wrote:
> > See above about the requirement for it to look like ${|ident|...}.
> > Since = * and ? are not identifiers, this is like writing { =|: } etc.

Considering this explanation, it is apparent that allowing |ident| is
not fully compatible with mksh where ${|ls| cat -} runs ls.
Not that I think that matters as such. In usage, it is probably wise to
make a convention of always having a space before the command starts.
And this leads on to the later question as we probably don't want to
expand considerably on what is valid between the vertical bars.

> This can be done with e.g.
>
> typeset -n bang=!
> ... ${|bang|...} ...

Yes that works. Is nice to see namerefs coming up in nifty solutions. I
hadn't checked the code for what supporting ? / ! would involve. If
trivial why not, but I well understand not wanting to do anything that
involves the lexer.

> However:
>
> Returning to the original context here, we were talking about how to
> make ${ ... } more newline-trimming-compatible with $(...) while still
> providing a way to specify that newlines not be trimmed, and using
> ${||...} for the latter came up.
>
> In thinking about ${|?|...} etc. I realized that there's no real
> reason a set of non-identifier characters couldn't be allowed to
> follow the first vertical bar.  It'd have to be simpler than just
> tossing parameter expansion flags in there, but I could investigate
> whether we could do things like ${|=|...} is the same as ${=${ ... }},
> ${|~|...} is ${~${ ... }}, etc.  That only saves 1 character, though,
> and I'm not sure it's clearer.

Would that potentially also extend to something like ${|=var| ... }
That might look like a default value assignment to someone used to a
language where vertical bars delimit closure parameters. Coming within
the vertical bars the character has a closer syntactic attachment to the
variable implying a semantic attachment. If it is hard to support
${= ... } then not doing it at all is probably better.

Given that the ${|var| ... } form appears to create a function-like
scope, should var perhaps be auto-declared local for that scope and the
local value be substituted?

> It does mean, though, that we could use something like ${|<|...} for
> non-trimming command substitution, instead of "empty" || meaning that.
> Just from a "clean look" standpoint, though, I still like the quoting
> approach better.

The quoting approach is clean and logical and is probably my preferred
option. I was initially bothered by the lack of consistency with $(...)
(where quoting prevents word splitting) but it can be useful if the lack
of fork is not the only thing which makes ${ ... } different and because
of the syntactic resemblance, consistency with ${var} is perhaps more
important - it does word splitting based on the shwordsplit option.

> Separately, it's definitely possible to make zsh-mode ${ ... } trim
> only one newline instead of all of them.

Only one is probably the most useful. I would mostly associate the fact
that $(...) strips multiple with the fact that it does word splitting
and so drops repeated newlines (empty words) also from the middle.
Admittedly "$(...)" preserves empty words in the middle but still drops
those at the end.

Oliver