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.) [email protected] 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
