3 ms·

You can create named pipes explicitly: $ mkfifo ~/pipe $ ./background.sh > ~/pipe & $ tail -f ~/pipe http://www.linuxjournal.com/article/2156 http

You can create named pipes explicitly: $ mkfifo ~/pipe $ ./background.sh > ~/pipe & $ tail -f ~/pipe http://www.linuxjournal.com/article/2156 http://www.linuxjournal.com/article/2156

runn1ng 13y ago
Yes, but I have always found that cumbersome and I was never sure which program has which pipe, and what will exactly happen if one of the reading/writing programs dies. (I am still not sure.) So I am glad that what OP wrote exists.
- mtdewcmu 13y ago
  True. I've known about that feature of bash, but I have found precious few good opportunities to use it. As someone mentioned below, if a program expects a file and you give it a pipe, it may try to seek and cause the whole thing to fail. So trying to use it is always a gamble. Moreover, a named pipe is an object in the filesystem that bash has to create, only to remove it a moment later. So it is not really any cleaner than using a temp file. The only case where you'd clearly benefit is when the amount of data is too big to justify temporarily writing it out to a file.
  - thwarted 13y ago
    bash doesn't create named pipe filesystem objects when you use process substitution, it passes file descriptors via the dynamically created kernel managed /dev/fd paths. There is nothing to clean up.
    - mtdewcmu 13y ago
      Oh, I think I see what you're saying. So calling them named pipes is inaccurate, then. If I'm not mistaken, using features of the /dev filesystem would be dependent on Linux, then. Either way, it isn't really a very robust design. Not like a pipe returned by pipe(2) and passed to a program that is expecting it. Simple unnamed pipes are a fundamental part of unix. Here's what the man page says: Process substitution is supported on systems that support named pipes (FIFOs) or the /dev/fd method of naming open files. It takes the form of <(list) or >(list). The process list is run with its input or output connected to a FIFO or some file in /dev/fd. The name of this file is passed as an argument to the current command as the result of the expansion. If the >(list) form is used, writing to the file will provide input for list. If the <(list) form is used, the file passed as an argument should be read to obtain the output of list. So it's done with /dev/fd if that's available, which basically means Linux with that filesystem mounted. Otherwise it falls back on named pipes.
- ams6110 13y ago
  One thing to keep in mind is that if nothing ever consumes the data in the pipe, the pipe stays around and you eventually will run out of open file descriptors. So if you're scripting with named pipes, be sure you have adequate cleanup in case of errors.
  - recuter 13y ago
    Am I right in guessing there will be approx. 65536 file descriptors available? :)

You can create named pipes explicitly: $ mkfifo ~/pipe $ ./background.sh > ~/pipe & $ tail -f ~/pipe http://www.linuxjournal.com/article/2156 http://www.linuxjournal.com/article/2156

runn1ng 13y ago

Yes, but I have always found that cumbersome and I was never sure which program has which pipe, and what will exactly happen if one of the reading/writing programs dies. (I am still not sure.) So I am glad that what OP wrote exists.

mtdewcmu 13y ago
True. I've known about that feature of bash, but I have found precious few good opportunities to use it. As someone mentioned below, if a program expects a file and you give it a pipe, it may try to seek and cause the whole thing to fail. So trying to use it is always a gamble. Moreover, a named pipe is an object in the filesystem that bash has to create, only to remove it a moment later. So it is not really any cleaner than using a temp file. The only case where you'd clearly benefit is when the amount of data is too big to justify temporarily writing it out to a file.
- thwarted 13y ago
  bash doesn't create named pipe filesystem objects when you use process substitution, it passes file descriptors via the dynamically created kernel managed /dev/fd paths. There is nothing to clean up.
  - mtdewcmu 13y ago
    Oh, I think I see what you're saying. So calling them named pipes is inaccurate, then. If I'm not mistaken, using features of the /dev filesystem would be dependent on Linux, then. Either way, it isn't really a very robust design. Not like a pipe returned by pipe(2) and passed to a program that is expecting it. Simple unnamed pipes are a fundamental part of unix. Here's what the man page says: Process substitution is supported on systems that support named pipes (FIFOs) or the /dev/fd method of naming open files. It takes the form of <(list) or >(list). The process list is run with its input or output connected to a FIFO or some file in /dev/fd. The name of this file is passed as an argument to the current command as the result of the expansion. If the >(list) form is used, writing to the file will provide input for list. If the <(list) form is used, the file passed as an argument should be read to obtain the output of list. So it's done with /dev/fd if that's available, which basically means Linux with that filesystem mounted. Otherwise it falls back on named pipes.
ams6110 13y ago
One thing to keep in mind is that if nothing ever consumes the data in the pipe, the pipe stays around and you eventually will run out of open file descriptors. So if you're scripting with named pipes, be sure you have adequate cleanup in case of errors.
- recuter 13y ago
  Am I right in guessing there will be approx. 65536 file descriptors available? :)