From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Bernd Eggink <rz2a022@uni-hamburg.de>
Cc: Bernd Eggink <eggink@uni-hamburg.de>, zsh-users@math.gatech.edu
Subject: zsh vs. ksh coproc redirection semantics
Date: Tue, 5 May 1998 10:03:05 -0700 [thread overview]
Message-ID: <980505100306.ZM9156@candle.brasslantern.com> (raw)
In-Reply-To: <Pine.A32.3.91.980505114905.10480A-100000@rzaixsrv2.rrz.uni-hamburg.de>
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
next prev parent reply other threads:[~1998-05-05 17:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-05-02 22:24 exit value of intermediate program in pipe Steve Talley
1998-05-03 0:50 ` Sweth Chandramouli
1998-05-03 1:38 ` Timothy J Luoma
1998-05-03 2:08 ` Bart Schaefer
1998-05-03 6:17 ` Sweth Chandramouli
1998-05-03 9:30 ` Bart Schaefer
1998-05-03 22:15 ` Sweth Chandramouli
1998-05-04 1:35 ` Bart Schaefer
1998-05-04 4:54 ` Sweth Chandramouli
1998-05-04 9:43 ` Bernd Eggink
1998-05-04 11:42 ` Bart Schaefer
1998-05-04 12:03 ` Bernd Eggink
1998-05-04 15:59 ` Bart Schaefer
1998-05-05 11:39 ` Bernd Eggink
1998-05-05 17:03 ` Bart Schaefer [this message]
1998-05-06 10:47 ` zsh vs. ksh coproc redirection semantics Bernd Eggink
1998-05-06 16:00 ` Bart Schaefer
1998-05-07 7:17 ` Zoltan Hidvegi
1998-05-07 8:34 ` Andrew Main
1998-05-07 9:26 ` Bart Schaefer
1998-05-07 9:34 ` Andrew Main
1998-05-07 17:02 ` Zoltan Hidvegi
1998-05-07 9:18 ` Bart Schaefer
1998-05-07 17:10 ` Zoltan Hidvegi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=980505100306.ZM9156@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=eggink@uni-hamburg.de \
--cc=rz2a022@uni-hamburg.de \
--cc=zsh-users@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).