Re: [PATCH?] Nofork and removing newlines

[Bart Schaefer <schaefer@brasslantern.com>]

On Fri, Mar 8, 2024 at 2:15 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> Bart Schaefer wrote:
> > Every other character already has another meaning in that position, as
> > far as I can tell.
>
> It could be nice to have ${= cmd } as a shorter alternative to
> ${=${ cmd }}

Unfortunately the lexer needs to be able to do this with one-character
peek-ahead.  So it can't distinguish dollar-brace-equal-space from
dollar-brace-equal, and the latter has to be treated as a parameter
expansion.

> > There is one other possibility:  ${||command}, that is,
> > ${|var|command} with an empty var name.
>
> The logic does at least follow from the usage with a variable. One way
> to avoid the resemblance to an "or" is if ${| |command} also works.

That might be possible.  Right now the lexer sees "${|" and branches
to scanning something that looks like a function body (closely
approximate to how $(command) scans ahead to the closing paren without
really "understanding" what it's skipping over).  That happens to not
care whether the next "|" is in a sensible position, just that it's
something that can be skipped while looking for the closing brace.

Then at the point of actual substitution, when there's a leading "|"
it looks for an identifier followed by another "|".  So you can't
write
  ... ${|paste|read} ...
and expect $REPLY to be set as the default by read, instead $paste
will be set (probably to nothing).  Anyway the upshot is it could
probably also look for whitespace followed by another "|" without
confusing anything.  Right now it just attempts to evaluate the
equivalent of { |commmand } which is a parse error.

> It could perhaps be combined so ${||<file} slurps a file unmodified.

That's messy because you can write
  <file somecommand
and it means the same as
  somecommand <file
so again it's not enough to see "||<" ... we'd actually have to
special-case READNULLCMD or something.

> Why does it print command not found errors for things like ${|=|:},
> ${|*|:} and ${|?|:}, I'd rather have $? than it globbing for a single
> character file.

See above about the requirement for it to look like ${|ident|...}.
Since = * and ? are not identifiers, this is like writing { =|: } etc.
and you get the same errors.  All of the non-identifier special
parameters are read-only so it doesn't make sense to assign to them,
and the |ident| has to be assignable for the expansion to mean
anything, so why allow them in that position? Unless you're just going
for side-effects, but then why use the |var| form?