Re: Parameter assignment in a redirection word
"Mark J. Reed" <[email protected]> Sun, 26 Oct 2025 13:06:45 -0400
| Newsgroups | gmane.comp.shells.zsh.user |
|---|---|
| Message-ID | <CAA=-s3zOJ62rhZspkaTEY6oua0Y2G=_ya=FgLi-6=ykw5LprOg@mail.gmail.com> |
I'm not sure why the parameter expansion happens post-fork, though. The redirect, sure. But the parameter expansion should presumably happen before any of that stuff as part of parsing the command line. Why isn't the assignment already done by the time it forks the subshell? Mark J. Reed <[email protected]> On Sun, Oct 26, 2025 at 13:01 Peter Stephenson <[email protected]> wrote: > On Sun, 2025-10-26 at 10:16 +0100, Alexey Sukhoguzov wrote: > > Please help me to clarify this situation: > > > > $ (echo foo) > ${myvar:=tmpfile} > > $ echo ${myvar:-still unset} > > still unset > > It's a bit of a headbanger, and I don't see it explicitly documented, but > the main point of what's going on is that whenever zsh executes a command > that's not going to run in the main shell, any redirection is done after > the fork. This is really for convenience --- if it was done before, then > standard output would have to be saved in the parent shell, and redirected > back to the originall file afterwards. As this is a pain in the neck, a > lot of shells do what zsh does, as you've found. > > Hopefully that's already clear, but to be explicit, the alternatives are > > 1. Fork for external command > 2. Perform any redirections > 3. Execute the external command (whic then simply exits, cleaing up > naturally) > > or > > 1. Save I/O state > 2. Perform redirections > 3. For for external command > 4. Execute the external command > 5. Back in the main shell, restore the I/O state > > (else the main shell would still be sending output to tempfile). > > You've already been shown some workarounds, hopefullly it makes a bit more > sense why they work. > > cheers > pws > >