3 ms·

The fact that zsh is a parent doesn't necessarily hurt performance. The parent and child can share the stdin fd, and the child could be the only one reading fro

The fact that zsh is a parent doesn't necessarily hurt performance. The parent and child can share the stdin fd, and the child could be the only one reading from it.

LukeShu 10y ago
That's not what I was referring to. Though I should have been more clear: I don't believe that zsh inserts itself in the mentioned situation; just that it does insert itself in some situations, and that makes it an exception to my general "once the process is spawned, the calling shell doesn't matter" statement. As an example of what I was referring to, in zsh, this a >&2 | b is equivalent to Bourne shell: a | tee /dev/stderr | b except that `tee` is implemented as part of zsh, rather than a separate program (for no difference in performance). That is, zsh inserted itself into the middle of the pipeline. There are two pipes instead of one; zsh/tee reads from the a pipe, and then writes that data to the b pipe (and stderr). This does hurt performance.
- asdfaoeu 10y ago
  This doesn't seem to be the case for me -> % python test.py 2>&1 | python test.py COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME [snip] python 24150 someone 0u CHR 136,0 0t0 3 /dev/pts/0 python 24150 someone 1w FIFO 0,8 0t0 72772851 pipe python 24150 someone 2w FIFO 0,8 0t0 72772851 pipe python 24150 someone 3w CHR 5,0 0t0 1049 /dev/tty COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME [snip] python 24151 someone 0r FIFO 0,8 0t0 72772851 pipe python 24151 someone 1u CHR 136,0 0t0 3 /dev/pts/0 python 24151 someone 2u CHR 136,0 0t0 3 /dev/pts/0 python 24151 someone 3w CHR 5,0 0t0 1049 /dev/tty someone@arch-two [01:29:00] [~] -> % echo $ZSH_VERSION 5.2 someone@arch-two [01:29:16] [~] -> % cat test.py import os import sys import subprocess with open("/dev/tty", "w") as f: subprocess.check_call(["lsof", "-p", str(os.getpid())], stdout=f) Edit: Ok so I misread your comment and you were talking about >&2. Which is weird because it actually has different behaviour in bash vs zsh. Having said I can't think why you would want the bash behaviour, although the bash behaviour does seem more consistent.
  - LukeShu 10y ago
    In the particular example I used, the Bourne shell behavior probably has no practical use (but I can write code of no practical use in many languages). It's not particularly surprising that the zsh behavior is different than bash; zsh redirections are only Bourne shell-like in simple cases. I dislike zsh's behavior because it isn't what the user typed. It should be simple to look at a command line and see how many pipes it makes; see the processes that will be involved in the pipeline. Zsh's behavior seems to me to be clever and implicit; I'd much rather have dumb and explicit.

The fact that zsh is a parent doesn't necessarily hurt performance. The parent and child can share the stdin fd, and the child could be the only one reading from it.

LukeShu 10y ago

That's not what I was referring to. Though I should have been more clear: I don't believe that zsh inserts itself in the mentioned situation; just that it does insert itself in some situations, and that makes it an exception to my general "once the process is spawned, the calling shell doesn't matter" statement. As an example of what I was referring to, in zsh, this a >&2 | b is equivalent to Bourne shell: a | tee /dev/stderr | b except that `tee` is implemented as part of zsh, rather than a separate program (for no difference in performance). That is, zsh inserted itself into the middle of the pipeline. There are two pipes instead of one; zsh/tee reads from the a pipe, and then writes that data to the b pipe (and stderr). This does hurt performance.

asdfaoeu 10y ago
This doesn't seem to be the case for me -> % python test.py 2>&1 | python test.py COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME [snip] python 24150 someone 0u CHR 136,0 0t0 3 /dev/pts/0 python 24150 someone 1w FIFO 0,8 0t0 72772851 pipe python 24150 someone 2w FIFO 0,8 0t0 72772851 pipe python 24150 someone 3w CHR 5,0 0t0 1049 /dev/tty COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME [snip] python 24151 someone 0r FIFO 0,8 0t0 72772851 pipe python 24151 someone 1u CHR 136,0 0t0 3 /dev/pts/0 python 24151 someone 2u CHR 136,0 0t0 3 /dev/pts/0 python 24151 someone 3w CHR 5,0 0t0 1049 /dev/tty someone@arch-two [01:29:00] [~] -> % echo $ZSH_VERSION 5.2 someone@arch-two [01:29:16] [~] -> % cat test.py import os import sys import subprocess with open("/dev/tty", "w") as f: subprocess.check_call(["lsof", "-p", str(os.getpid())], stdout=f) Edit: Ok so I misread your comment and you were talking about >&2. Which is weird because it actually has different behaviour in bash vs zsh. Having said I can't think why you would want the bash behaviour, although the bash behaviour does seem more consistent.
- LukeShu 10y ago
  In the particular example I used, the Bourne shell behavior probably has no practical use (but I can write code of no practical use in many languages). It's not particularly surprising that the zsh behavior is different than bash; zsh redirections are only Bourne shell-like in simple cases. I dislike zsh's behavior because it isn't what the user typed. It should be simple to look at a command line and see how many pipes it makes; see the processes that will be involved in the pipeline. Zsh's behavior seems to me to be clever and implicit; I'd much rather have dumb and explicit.