Re: Bash-5.1-beta available
On Sep 21 2020, Dale R. Worley wrote: > Andreas Schwab writes: >> On Sep 10 2020, Chet Ramey wrote: >> >>> yy. Process substitution processes now get their input from /dev/null, since >>> they are asynchronous, not interactive, and not jobs. >> >> That breaks scripts that want to filter stdin with a process >> substitution, eg: >> >> while read ...; do ...; done < <(filter) > > I'm assuming you mean "<( ... )" process substitutions, Which is exactly what I wrote. > I assume that if you really want the old effect, you can still do That point is that it silently breaks existing scripts. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
bug-bash@gnu.org
On Tue, Sep 22, 2020 at 2:01 PM Robert Elz wrote:
> Date:Tue, 22 Sep 2020 10:02:07 +0800
> From:Clark Wang
> Message-ID: <
> cadv8-ogf0hev-ckegxy9dq1ypcz4bdpkjy_7aex83o1db93...@mail.gmail.com>
>
> | In an interactive shell (in case this matters), run bash -c 'sleep 5
> &' and
> | it exits immediately without waiting for the sleep to complete. But ssh
> | user@host 'sleep 5 &' (with bash as the login shell) would wait for
> sleep
> | to complete. Why the difference?
>
> It isn't bash waiting for the sleep to complete, it is ssh waiting for
> the connection to close. Neither ssh nor the sshd at the target know that
> "sleep" doesn't write any output, so they have to keep the connection alive
> (and hencs ssh running on the client end) until the command has completed
> (actually, until it closes its fds, so you could do
>
> ssh user@host 'sleep 5 >&- 2>&- &'
>
> if you wanted (no need to worry about stdin, because it is an async
> process, that gets connected to /dev/null anyway). This shows
> stdout & stderr being closed - that part is not important (just the
> briefest sane example to give) - you could also redirect them to
> anywhere else (just remember that it has to be both of them).
>
Ah right. I misunderstood something else. When I run
$ ssh 127.0.0.1 '{ sleep 120 | cat; } & exit'
and on another tty I did this
$ pgrep -af sleep
83207 ssh 127.0.0.1 { sleep 120 | cat; } & exit
83215 bash -c { sleep 120 | cat; } & exit
83216 sleep 120
I wrongly thought the process 'bash -c ...' in pgrep's output is the parent
bash but it should be the forked child bash.
Then, how should we explain that
$ ssh -t 127.0.0.1 'sleep 120 &'
would complete immediately?
-clark
bug-bash@gnu.org
Date:Tue, 22 Sep 2020 16:47:39 +0800
From:Clark Wang
Message-ID:
| Ah right. I misunderstood something else. When I run
|
| $ ssh 127.0.0.1 '{ sleep 120 | cat; } & exit'
Yes, in that case the shell running the command list (the {} thing)
typically hangs around to wait for the pipe to finish. There might
be a bash shopt that can alter that. The "exit" at the end accomplishes
nothing (unless you give it an arg to set a non-default exit code).
| Then, how should we explain that
|
| $ ssh -t 127.0.0.1 'sleep 120 &'
|
| would complete immediately?
With -t, there's no pty, when the shell exits, everything ends up
closed - but the mechanism for this escapes me (what bash &/or sshd
sees differently). You'd do better to ask on an ssh related list
I expect.
kre
Re: Build fails with Xcode 12
On 9/21/20 11:57 AM, Adam Stewart wrote: > Thanks Chet, > > That patch did the trick! All tests pass now. Thanks again for your help! Glad to help. > P.S. I'm going to add this patch to the Spack package manager. Would you or > anyone else be interested in "maintaining" Spack's bash build recipe? You > don't have to be a Spack expert, it just gives us someone to ping when users > report build errors or submit PRs to modify the recipe. If so, just send me > your GitHub handle(s). I'm going to have to decline, sorry. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
bug-bash@gnu.org
On Tue, Sep 22, 2020 at 5:07 PM Robert Elz wrote: > > With -t, there's no pty, when the shell exits, everything ends up > closed - but the mechanism for this escapes me (what bash &/or sshd > sees differently). You'd do better to ask on an ssh related list > I expect. > Found the question at https://unix.stackexchange.com/questions/346549/ . The accepted answer does not look correct to me. Posted a new answer there. -clark
bug-bash@gnu.org
On 9/22/20 5:07 AM, Robert Elz wrote: > | Then, how should we explain that > | > | $ ssh -t 127.0.0.1 'sleep 120 &' > | > | would complete immediately? > > With -t, there's no pty The opposite -- -t forces pty allocation. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Confusing documentation of `ENV` in section "Bash variables"
The documentation says: 'ENV' Similar to 'BASH_ENV'; used when the shell is invoked in POSIX Mode (*note Bash POSIX Mode::). However, as described elsewhere in the manual, BASH_ENV is used specifically for non-interactive shells, whereas ENV is used specifically for interactive shells. From the quoted section above, one might get the erroneous impression that ENV is just like BASH_ENV but for POSIX mode. If I've not misunderstood, maybe a little more explanation in the quoted section would be a good idea? Even just changing "invoked" to "invoked interactively". Although that then runs the risk of implying that BASH_ENV is also used in interactive mode. Alternatively, remove "Similar to 'BASH_ENV';". -- https://rrt.sc3d.org
bug-bash@gnu.org
Clark Wang writes: > Then, how should we explain that > > $ ssh -t 127.0.0.1 'sleep 120 &' > > would complete immediately? One thing to check is whether ssh is giving you a pty in various circumstances. Execute the "tty" command, e.g. "ssh 127.0.0.1 tty". Once you know whether the remote Bash has a pty and that it has been given a command on the command line, you can start sorting out what mode Bash is running in and exactly what "&" does. Dale
Re: Bash-5.1-beta available
Andreas Schwab writes: > On Sep 21 2020, Dale R. Worley wrote: > >> Andreas Schwab writes: >>> On Sep 10 2020, Chet Ramey wrote: >>> yy. Process substitution processes now get their input from /dev/null, since they are asynchronous, not interactive, and not jobs. >>> >>> That breaks scripts that want to filter stdin with a process >>> substitution, eg: >>> >>> while read ...; do ...; done < <(filter) >> >> I'm assuming you mean "<( ... )" process substitutions, > > Which is exactly what I wrote. By "you" in the above, I meant the author of item "yy" above. Sorry about the inexactness. Dale
