Command hangs when using process substitution
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux snorkack 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 21 Release Status: release Description: The following command, when run in bash, should copy the word "foo" to the X primary selection (by process substitution), output the line "fxx", and exit: echo foo | tee >(xclip -i) | tr o x The command does print "fxx" but then it hangs. The same command behaves correctly when run in zsh. Repeat-By: 1. Run the command: echo foo | tee >(xclip -i) | tr o x 2. The command copies "foo" to the X primary selection, prints "fxx", and then hangs. 3. Pressing ctrl-D does not cause the command to exit. 4. Pressing ctrl-C kills the command
Re: Command hangs when using process substitution
On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the GNU Bourne Again SHell wrote: > echo foo | tee >(xclip -i) | tr o x > > The command does print "fxx" but then it hangs. > > The same command behaves correctly when run in zsh. For the record, here's what processes are running on the terminal while it's in the "hanging" state: unicorn:~$ ps f -ft pts/28 UID PIDPPID C STIME TTY STAT TIME CMD greg 1082506 1082504 0 09:21 pts/28 Ss 0:00 bash greg 1082862 1082506 0 09:35 pts/28 S+ 0:00 \_ tr o x greg 1082864 1 0 09:35 pts/28 S+ 0:00 xclip -i The tee process has exited, but somehow the tr process has not -- which must mean that tr's stdin is still open. One additional observation: if I highlight something (e.g. that ps output), this causes the pipeline to terminate. I assume the xclip process somehow notices the highlighting and exits, which causes tr to exit, because (presumably) it's the orphaned xclip process whose output was still connected to tr's input. Without copy/pasting anything, it'll be a bit annoying to diagnose, but let's try: unicorn:~$ ps f -ft pts/28 UID PIDPPID C STIME TTY STAT TIME CMD greg 1082506 1082504 0 09:21 pts/28 Ss 0:00 bash greg 1082907 1082506 0 09:39 pts/28 S+ 0:00 \_ tr o x greg 1082909 1 0 09:39 pts/28 S+ 0:00 xclip -i unicorn:~$ ls -l /proc/1082907/fd total 0 lr-x-- 1 greg greg 64 Nov 18 09:39 0 -> 'pipe:[29847034]' lrwx-- 1 greg greg 64 Nov 18 09:39 1 -> /dev/pts/28 lrwx-- 1 greg greg 64 Nov 18 09:39 2 -> /dev/pts/28 unicorn:~$ ls -l /proc/1082909/fd total 0 lr-x-- 1 greg greg 64 Nov 18 09:39 0 -> 'pipe:[29848673]' l-wx-- 1 greg greg 64 Nov 18 09:39 1 -> 'pipe:[29847034]' lrwx-- 1 greg greg 64 Nov 18 09:39 2 -> /dev/pts/28 lrwx-- 1 greg greg 64 Nov 18 09:39 3 -> 'socket:[29847035]' In this run, I can confirm that the stdout of xclip is indeed attached to the stdin of tr, via pipe:[29847034]. Therefore, as a workaround, I would suggest: unicorn:~$ echo foo | tee >(xclip -i >/dev/null) | tr o x fxx unicorn:~$ That should work as desired, in whichever shell you're using that has process substitutions.
Re: Command hangs when using process substitution
On Nov 18 2023, Greg Wooledge wrote: > On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the > GNU Bourne Again SHell wrote: >> echo foo | tee >(xclip -i) | tr o x >> >> The command does print "fxx" but then it hangs. >> >> The same command behaves correctly when run in zsh. > > For the record, here's what processes are running on the terminal while > it's in the "hanging" state: > > unicorn:~$ ps f -ft pts/28 > UID PIDPPID C STIME TTY STAT TIME CMD > greg 1082506 1082504 0 09:21 pts/28 Ss 0:00 bash > greg 1082862 1082506 0 09:35 pts/28 S+ 0:00 \_ tr o x > greg 1082864 1 0 09:35 pts/28 S+ 0:00 xclip -i > > The tee process has exited, but somehow the tr process has not -- > which must mean that tr's stdin is still open. > > One additional observation: if I highlight something (e.g. that ps > output), this causes the pipeline to terminate. I assume the xclip > process somehow notices the highlighting and exits, which causes > tr to exit, because (presumably) it's the orphaned xclip process > whose output was still connected to tr's input. xclip puts itself into the background, unless it is called with -quiet or -verbose. -silent fork into the background to wait for requests, no informational output, errors only (default) -quiet show informational messages on the terminal and run in the fore- ground -verbose provide a running commentary of what xclip is doing -- 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."
Re: Command hangs when using process substitution
On November 18, 2023, Greg Wooledge wrote: >On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the >GNU Bourne Again SHell wrote: >> echo foo | tee >(xclip -i) | tr o x >> >> The command does print "fxx" but then it hangs. >> >> The same command behaves correctly when run in zsh. > [...] >I can confirm that the stdout of xclip is indeed attached >to the stdin of tr, via pipe:[29847034]. Therefore, as a workaround, >I would suggest: > >unicorn:~$ echo foo | tee >(xclip -i >/dev/null) | tr o x Wow, Greg, thank you so much for taking the time to write your rapid and super-informative reply! If it's helpful, here's another interesting piece of the puzzle: the "xsel -i" command (which also copies stdin to the X primary selection, like "xclip -i" does) works fine in the original pipeline, without needing the redirect to /dev/null: $ echo foo | tee >(xsel -i) | tr o x fxx -- Dan Barrett dbarr...@blazemonger.com
Re: Command hangs when using process substitution
Perhaps some background would help here; I start by highlighting this section in "man xclip": -l, -loops number of X selection requests (pastes into X applications) to wait for before exiting, with a value of 0 (default) causing xclip to wait for an unlimited number of requests until another application (possibly another invocation of xclip) takes ownership of the selection What's mentioned here as "the selection" is approximately what you probably think of as "the clipboard". X-windows does not itself hold the clipboard. Instead, that responsibility falls to the program offering the copy. When a program goes "copy", it notifies the WM that it has a "selection" available; then subsequent requests for pasting are forwarded to that program, and it replies with the selection to be pasted. The WM notifies the original program when the selection is no longer required, in particular, when it has been supplanted by a notification from another program. If the original program dies or exits, the clipboard dies with it. This means that xclip must notify the WM that it has a selection and then stay active so that a later program can ask for it, but at the same time, xclip is expected to exit immediately once it's captured its stdin. It manages to do both simply by forking. However the new child process thus created does not close its stdin, stdout or stderr. The forked child will exit when the WM tells it that its selection is no longer required, and that's the delay that you're seeing. On Sat, 18 Nov 2023 at 23:36, dbarrett--- via Bug reports for the GNU Bourne Again SHell wrote: > The following command, when run in bash, should copy the word "foo" to > the X primary selection (by process substitution), output the line > "fxx", and exit: > > echo foo | tee >(xclip -i) | tr o x > > The command does print "fxx" but then it hangs > The same command behaves correctly when run in zsh > If zsh is not connecting the output of xclip to the input of tr, I would regard that as INcorrect. I note that both the follow "hang" the same in zsh and bash: xclip (xclip -i) ) | tr o x ... because both wait for the forked child of xclip to finish. The fact that you don't *want* the output of xclip connected to tr (because it makes tr wait for xclip *and all its children* to finish, while the shell waits for tr to finish) does not make zsh "correct". -Martin
Re: Command hangs when using process substitution
On Nov 18 2023, Daniel Barrett via Bug reports for the GNU Bourne Again SHell wrote: > If it's helpful, here's another interesting piece of the puzzle: the > "xsel -i" command (which also copies stdin to the X primary selection, > like "xclip -i" does) works fine in the original pipeline, without > needing the redirect to /dev/null: > > $ echo foo | tee >(xsel -i) | tr o x > fxx That's because xsel is properly daemonizing itself, disconnecting from its stdin/out/err. -- 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."
Re: Command hangs when using process substitution
Date:Sun, 19 Nov 2023 07:40:00 +1000 From:Martin D Kealey Message-ID: | The fact that you don't *want* the output of xclip connected to tr | (because it makes tr wait for xclip *and all its children* to finish, | while the shell waits for tr to finish) does not make zsh "correct". It all depends upon the definition of what is supposed to happen to the stdout of a process created as a process substitution which is to read from its stdin (as in the example in question) or what it should do with its stdin if intended to write output through the named pipe or whatever. Since process substitution is not a standardised feature, every shell is able to decide for itself, and others are free to express opinions about which they feel is better (more useful). "Correct" is not the appropriate term to use. Personally, just as a background process created in a non job control context gets its stdin altered to /dev/null (it shouldn't read from there, but just in case it does) I'd think it generally better to redirect the unused stdin or stdout (whichever is not connected to the invoking process via the fifo, or whatever) be similarly redirected to /dev/null, so output it should not be producing doesn't corrupt the real output, and other processes aren't, like here, left hanging waiting for potential output from that process that is never going to come. In the unusual case where this default redirect isn't wanted, an explicit redirect can always be used to override it. kre
fc can segfault if history is cleared
Greetings: I recall reporting a long time ago that "fc -0" would cause a segfault. It appears that this behavior remains when the history is cleared prior to invoking the "fc -0" command... $ history -c; fc -0 Segmentation fault (core dumped) Can someone else confirm this? Best, -- Jason Franklin
Re: fc can segfault if history is cleared
Date:Sat, 18 Nov 2023 21:55:23 -0500 From:Jason Franklin Message-ID: | $ history -c; fc -0 | Segmentation fault (core dumped) | | Can someone else confirm this? Which bash version are you using? I just tried that on GNU bash, version 5.2.21(1)-release (x86_64--netbsd) No core dump, just my editor with an empty file. kre
Re: fc can segfault if history is cleared
On Sun, Nov 19, 2023 at 10:31:59AM +0700, Robert Elz wrote: > | $ history -c; fc -0 > | Segmentation fault (core dumped) > | > | Can someone else confirm this? > > Which bash version are you using? > > I just tried that on > GNU bash, version 5.2.21(1)-release (x86_64--netbsd) > > No core dump, just my editor with an empty file. Thanks for the sanity check, Robert. Indeed, it looks like my version of Bash was just too old. I am using version 5.1.16(1)-release. I switched to 5.2.15(1)-release, and I got the behavior you described. Sorry for the false alarm. Best, -- Jason Franklin
