zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: [PATCH?] Nofork and removing newlines
Date: Tue, 12 Mar 2024 21:13:09 -0700	[thread overview]
Message-ID: <CAH+w=7aFbL8c=RLcrkKJU4R-o2ZhNJgS+zi60STswpFbE4BWqg@mail.gmail.com> (raw)
In-Reply-To: <25344-1710285573.990297@5-7t._0Mp.XRXG>

On Tue, Mar 12, 2024 at 4:19 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> > 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.

Hm, yes.  Although I wasn't really aiming for compatibility, rather
for borrowing the idea (via Sebastian's original attempt at it).  I
was also I confess a bit stuck on the idea that every case would look
like ${|REPLY=...} when of course piping to "read" etc. are also valid
ways to assign to REPLY.  How often would there be a command name with
no arguments in that position?

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

I hesitate in suggesting this, but ... is there any existing case in
which "${{" is valid?  If not, I think I can change ${|var|...} to be
${{var}...} without too much violence (except to the doc, bleah).

> Yes that works. Is nice to see namerefs coming up in nifty solutions. I
> hadn't checked the code for what supporting ? / ! would involve.

Mostly it involves rejiggering valid_refname() to behave more like
itype_end(), if you mean supporting e.g. ${|?|...}.

> If trivial why not, but I well understand not wanting to do anything
> that involves the lexer.

That (and using {var} instead of |var|) would except for a single
conditional test all happen in subst.c, the lexer already skips ahead.

> Bart Schaefer wrote:
> > [...] 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| ... }

It could, yes.

> That might look like a default value assignment to someone

Would ${{=var}...} look better?  The doubled braces do give me pause.

> 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?

I considered that but
(a) the implementation is messy, as the state of the parameter scope
has to be carried around subst.c a lot longer than with the single
known scalar "REPLY"
(b) it diverges even farther from the idea that REPLY is a
semi-special thing -- note that REPLY is automatically saved and
restored around ${|... REPLY=...}
(c) creating it local doesn't really add much that you can't do with
${ local value; ... } and
(d) part of the point was to be able to push the variable up to the
caller as a side effect, so you don't have to write
  value=${|value| ... value=...}
although I guess you do have to declare it somewhere so that's not
entirely helpful.

> The quoting approach is clean and logical and is probably my preferred
> option.  [...]  consistency with ${var} is perhaps more
> important - it does word splitting based on the shwordsplit option.

Thanks for the vote.

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

This is the code diff to make emulation trim all, ${ ... } trim one,
"${ ... }" trim none ... not re-doing the doc diff yet.

diff --git a/Src/subst.c b/Src/subst.c
index 49f7336bb..9d20a2d0e 100644
--- a/Src/subst.c
+++ b/Src/subst.c
@@ -1900,6 +1900,7 @@ paramsubst(LinkList l, LinkNode n, char **str,
int qt, int pf_flags,
        /* The command string to be run by ${|...;} */
        char *cmdarg = NULL;
        size_t slen = 0;
+       int trim = (!EMULATION(EMULATE_ZSH)) ? 2 : !qt;
        inbrace = 1;
        s++;

@@ -2005,10 +2006,13 @@ paramsubst(LinkList l, LinkNode n, char **str,
int qt, int pf_flags,
                int onoerrs = noerrs, rplylen;
                noerrs = 2;
                rplylen = zstuff(&cmdarg, rplytmp);
-               if (! EMULATION(EMULATE_ZSH)) {
+               if (trim) {
                    /* bash and ksh strip trailing newlines here */
-                   while (rplylen > 0 && cmdarg[rplylen-1] == '\n')
+                   while (rplylen > 0 && cmdarg[rplylen-1] == '\n') {
                        rplylen--;
+                       if (trim == 1)
+                           break;
+                   }
                    cmdarg[rplylen] = 0;
                }
                noerrs = onoerrs;


  reply	other threads:[~2024-03-13  4:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05  5:52 Bart Schaefer
2024-03-05  6:56 ` Stephane Chazelas
2024-03-05 22:48   ` Bart Schaefer
2024-03-06 17:57     ` Stephane Chazelas
2024-03-06 19:45       ` Bart Schaefer
2024-03-06 22:22         ` Mikael Magnusson
2024-03-06 22:42           ` Bart Schaefer
2024-03-07  4:53           ` Bart Schaefer
2024-03-07  7:02             ` Lawrence Velázquez
2024-03-07  8:09               ` ${<file} (Was: [PATCH?] Nofork and removing newlines) Stephane Chazelas
2024-03-08  1:29               ` [PATCH?] Nofork and removing newlines Bart Schaefer
2024-03-08 22:15                 ` Oliver Kiddle
2024-03-08 23:28                   ` Bart Schaefer
2024-03-09 20:43                     ` Oliver Kiddle
2024-03-10  6:11                       ` Bart Schaefer
2024-03-12 17:54                         ` Bart Schaefer
2024-03-12 23:19                           ` Oliver Kiddle
2024-03-13  4:13                             ` Bart Schaefer [this message]
2024-03-14 22:15                               ` Oliver Kiddle
2024-03-15  8:42                                 ` Stephane Chazelas
2024-03-27  1:16                                   ` Bart Schaefer
2024-03-27  7:05                                 ` Bart Schaefer
2024-03-07  7:10             ` Stephane Chazelas
2024-03-08  0:37               ` Bart Schaefer
2024-03-07  6:52           ` Lawrence Velázquez
2024-03-07  8:26             ` Mikael Magnusson
2024-03-07 19:02               ` Bart Schaefer
2024-04-02  6:45                 ` Lawrence Velázquez
2024-03-06 19:43     ` Stephane Chazelas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7aFbL8c=RLcrkKJU4R-o2ZhNJgS+zi60STswpFbE4BWqg@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).