Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
zsh vs. ksh coproc redirection semantics
- X-seq: zsh-users 1518
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Bernd Eggink <rz2a022@xxxxxxxxxxxxxx>
- Subject: zsh vs. ksh coproc redirection semantics
- Date: Tue, 5 May 1998 10:03:05 -0700
- Cc: Bernd Eggink <eggink@xxxxxxxxxxxxxx>, zsh-users@xxxxxxxxxxxxxxx
- In-reply-to: <Pine.A32.3.91.980505114905.10480A-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- References: <Pine.A32.3.91.980505114905.10480A-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On May 5, 1:39pm, Bernd Eggink wrote:
} Subject: Re: exit value of intermediate program in pipe
}
} On Mon, 4 May 1998, Bart Schaefer wrote:
}
} > cat <&p
} >
} > what happens? The input _of cat_ is connected to the _output_ of the
} > coproc, right?
}
} Hm, I admit that I never tried this in zsh... In fact, it works
} like this in zsh, but exactly the OTHER way round in ksh.
So you're saying that in ksh, cat <&p means that the coproc input is
closed and cat takes its input from wherever the coproc was getting its
input? That makes no sense at all. (Which tells me that `exec 3<&p`
must be doing something special in ksh, if indeed it acts as you say.)
} In ksh 3<&p means "duplicate the coproc input to unit 3".
I think maybe we're having a cognitive dissonance here. The coproc is a
two-way pipe:
out +--- zsh ----+ in
| |
>&p <&p
| |
in +-- coproc --+ out
According to what you're saying, ksh does it like this:
in +--- ksh ----+ out
| |
>&p <&p
| |
in +-- coproc --+ out
Is that correct?
} IMHO this is more consistent and intuitive than what zsh does.
Really? I think having inputs connected to outputs is more intuitive
than having inputs duplicated.
} After looking into the doc, I even suspect that this may be a bug...
} Quoting from chapter 6, "redirection":
}
} <&p
} >&p The input/output from/to the coprocess is moved to the
} standard input/output.
}
} If 'input' corresponds to <&p, this is fact what ksh does and what
} zsh DOESN'T!
Re-parse that doc:
<&p The input from the coprocess is moved to the standard input.
>&p The output to the coprocess is moved to the standard output.
Note "input _from_" not "input of", and "output _to_" not "output of".
out to +--- zsh ----+ in from
| |
>&p <&p
| |
in of +-- coproc --+ out of
This may be the reverse of what ksh does, but I think zsh's doc tells
accurately (if not all that clearly) how zsh behaves.
However, I'm really surprised to hear that this is backwards in ksh.
That seems completely unintuitive to me. If I say
cat <&3
That means I want cat to read from fd 3, does it not? So if I say
cat <&p
That should mean I want cat to read from the coproc. Which should mean
that <&p refers to "the input _from_ the coproc" which means the output
_of_ the coproc. No?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author