Hello Workers, I can't explain the behavior of the following on my system: With zsh -f: $ while :; do read; echo | xclip; echo loop; done RET loop loop loop ... (In the above, RET is the only user input.) Bash does not have this problem. This is independent from the terminal I use, it even has the same behavior on a X11-free TTY (with DISPLAY set correctly). I'd find it strange that it be xclip related, but could not find any other program that caused this. Bug, feature, PEBKAC? Cheers, Michaël
[-- Attachment #1: Type: text/plain, Size: 898 bytes --] On Wed, Sep 7, 2022 at 2:44 PM Michaël Cadilhac <michael@cadilhac.name> wrote: > $ while :; do read; echo | xclip; echo loop; done > Bash executes the left side of a pipeline in the current shell and the right side in a forked subshell. Zsh does the opposite, which means xclip is a process group leader with access to the terminal. xclip itself then forks and clones a copy which continues running. That copy has control of the terminal, which causes "read" to see an I/O error and immediately fail. You can see read exiting failure if you change the loop to be while :; do read; echo $?; echo | xclip; echo loop; done You're not testing the return value of read, so the shell goes on to the next statement and the effect repeats. Each new xclip causes the previous xclip to exit (cf. xclip -l option) by grabbing the selection, so you never run out of processes. [-- Attachment #2: Type: text/html, Size: 1252 bytes --]