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
