About problems with named pipes

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i wrote:
> > i think it is worth a mail thread to investigate the problem mentioned
> > by Van Snyder in the course of thread "where does command output go".

> Really? After they insulted a contributor?

I did not see an insult but only some backtalk.
In any case the mail was about a technical problem with Debian.
So i consider it on topic. Just not properly presented on the first
try.


> > -bash: MyFifo : Permission denied

> Either you doctored the output

Are you telling me that this accusation is not meant as insult ?

> or your config is dangerously broken.

Technical question:
If you use a file object that was freshly made by mkfifo(1) as command in
a pipe, what complaint from bash do you get ?


Darac Marjal wrote:
> According to it's [mkfifo's] man
> page[1], the option "-m, --mode=MODE" can be used to set permissions "to
> MODE, not a=rw", which I interpret to mean that, if this option is not
> supplied, the default permissions are "a=rw". So, invoking "mkfifo MyFifo"
> will create a named pipe with permissions "a=rw".

Well, if i give the named pipe x-premission, then
  zcat file.gz | MyFifo
hangs. (I assume the shell waits for script bytes to appear in MyFifo.)

But that's not what Van Snyder describes:
> > > If one of the files is big, instead of zcat blocking until my program
> > > consumes more data, they both block. So I stopped compressing the big files,
> > > where I would have had the most advantage.

I read this as statement that it works for Van Snyder with small files.
But if i do with x-permission on MyFifo
  echo | MyFifo
and
  wc MyFifo
then both hang.


Darac Marjal wrote:
> So, I contend that writing to MyFifo (aka "zcat TheFile.gz > MyFifo") is the
> the correct command. Attempting to execute MyFifo and pipe into it's stdin
> seems - to me - to be the "dangerously broken" option and the "permission
> denied" error was the safety net.

I agree. There may be exotic use cases where an executable fifo is
useful. But i would not expect this with the described case of zcat
and a data consumer program.


Nicolas George wrote:
> Have you tried running the command? I mean the command
> “zcat TheFile.gz | MyFifo”, exactly like that without altering the
> paths. Did you get the same error message? 

On Debian 12:

  $ mkfifo MyFifo
  $ zcat /dvdbuffer/debian-11.0.0-amd64-DVD-1.list.gz | MyFifo
  -bash: /home/thomas/MyFifo: Permission denied
  $

On Sid (updated after Debian 13 came out):

  $ mkfifo MyFifo
  $ zcat libisoburn-1.5.0.tar.gz | MyFifo
  -bash: /home/thomas/MyFifo: Permission denied
  $

(I hope that using my own loitering .gz files is not invalidating the
result.)


tomas@tuxteam.de wrote:
> As an additional hint: perhaps, if you set MyFifo's executable bit...
> (no, don't do it: i'm half-joking here).

On Debian 12:

  $ chmod u+x MyFifo
  $ zcat /dvdbuffer/debian-11.0.0-amd64-DVD-1.list.gz | MyFifo

hangs until i do in another terminal:

  $ echo > MyFifo
  $

Then the zcat|MyFifo pipe ends with

  -bash: /home/thomas/MyFifo: Permission denied
  $

The same happens when i only pipe one byte into MyFifo
  echo | MyFifo
and then do in another terminal:
  echo > MyFifo

So whatever i try, i don't get a situation where the (in my eyes
insane) pipe works with small input but hangs with large input.


Have a nice day :)

Thomas