zsh-users
 help / color / mirror / code / Atom feed
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


  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).