Re: About problems with named pipes

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

Hi,

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

Greg Wooledge wrote:
> As a controlled one-time laboratory experiment on a system that you
> don't particularly care about, eh... all right, I can respect the
> scientific curiosity.  But if that had actually *worked*, you might
> have executed whatever the decompressed contents of that .gz file were.

I was unspecifically cowardish and first tried with
  echo | MyFifo

But it would be quite odd if a fifo would take data from some input
file descriptor of a process (the shell) which has opened a file
descriptor to the fifo, too, and then write these data to the fifo's
output (where the shell could expect program code).

The risk of execution would rather be imposed by some other process
which does what one usually does with a fifo:

  zcat /dvdbuffer/debian-11.0.0-amd64-DVD-1.list.gz >MyFifo

while the shell is waiting for program data at the fifo.


I tried this too, but with harmless input:
  echo > MyFifo
For what reason ever, the zcat|MyFifo pipe then ends with
  -bash: /home/thomas/MyFifo: Permission denied


> Just to clarify and hopefully END this nonsense,

Indeed. The pipe-to-pipe madness has been squeezed out to the max. :))


> the original command presented by Van Snyder was:
>
>   zcat TheFile.gz | MyFifo
>
> and that | is a typo.  It should have been > instead.

I'm curiously waiting for more info about the data consumer program.
It seems unlikely that "zcat TheFile.gz" alone can hang depending on
the size of TheFile.gz (compressed or uncompressed).


Have a nice day :)

Thomas