help / color / mirror / code / Atom feed
From: Dominik Vogt <dominik.vogt@gmx.de>
To: Zsh Users <zsh-users@zsh.org>
Subject: Re: Using file lines as "input files"
Date: Sun, 10 Jul 2022 01:42:10 +0100	[thread overview]
Message-ID: <YsogYlt8Tfpjc6PI@gmx.de> (raw)
In-Reply-To: <CAHYJk3T9G+VZO9prf_qm2P4yAYVJ-qi_urSBzGTWDhnn9dPTdw@mail.gmail.com>

On Sat, Jul 09, 2022 at 04:21:37AM +0200, Mikael Magnusson wrote:
> I realized I misinterpreted the question originally, and the following
> doesn't seem to work 100% but it was a fun idea:
> % mkfifo apipe
> % foo[265000]='' # number of lines in the file

> % cksum apipe$^foo # pass "apipe" to cksum 265000 times

For some mysterious reason that doesn't work with the shwordsplit
option active:

  $ foo[9]=''
  $ setopt shwordsplit
  $ echo x^foo
  x x
  $ unsetopt shwordsplit
  $ echo x^foo
  x x x x x x x x x

> (in another terminal or job control etc)
> % while read; do echo $REPLY > apipe; done < infile
> When I tried the above on some test data, I got about 10 broken pipes.
> Also several lines sometimes get passed through the pipe without an
> intervening EOF, I'll admit I don't know the finer points of pipe/fifo
> behavior when you open and close them rapidly.

Hm, a fifo created with mkfifo is automatically blocking.  So,
when either end is opened while the other is not present, it
blocks until the other end is opened.

The reader gets an EOF when there's no more data and no writer has
the fifo open.  Otherwise it waits for more data.

1) Multiple lines processed by a single reader:

 * writer opens the fifo and blocks for a reader
 * reader opens the fifo and blocks for data
 * writer writes its data and closes the fifo
 * the next writes opens the fifo
 * the reader processes the first writer's data but gets no EOF
   because the new writer has the fifo open
 * the new writer writes another line to the fifo and terminates
 * the reader reads the next line, gets an EOF because no writer
   is open and terminates itself.

2) SIGPIPE may be generated in this case:

 * writer opens the fifo and blocks for a reader
 * reader opens the fifo and blocks for data
 * the writer unblocks, writes its data and closes.
 * the reader unblocks consumes the data and gets an EOF
 * the next writer opens the pipe without blocking because the
   reader has not yet closed the fifo
 * the reader closes the fifo
 * the writer tries to write data but gets SIGPIPE because there
   is no reader

Unfortunately fifos have no notion of an EOF as part of the data

> That said, this also seems to take around 4-5 seconds to run.

A pity that pipes are so uncomfortable to handle in Unix.  I like
that approach.


Dominik ^_^  ^_^


Dominik Vogt

  reply	other threads:[~2022-07-10  0:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 20:58 Dominik Vogt
2022-07-08 21:58 ` Mikael Magnusson
2022-07-08 22:04 ` Bart Schaefer
2022-07-08 23:17   ` Dominik Vogt
2022-07-09  2:21     ` Mikael Magnusson
2022-07-10  0:42       ` Dominik Vogt [this message]
2022-07-10  0:45         ` Dominik Vogt
2022-07-10  3:27         ` Bart Schaefer
2022-07-10 17:49           ` Bart Schaefer

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YsogYlt8Tfpjc6PI@gmx.de \
    --to=dominik.vogt@gmx.de \
    --cc=zsh-users@zsh.org \


* 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


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