in reply to named pipe and "Text file busy"

I'm trying to recreate your problem, but if this is incorrect, let me know. I can't recreate your particular error, but I think this is what you are trying to do (again, correct me if I'm wrong).

This script opens the fifo if it doesn't exist and then starts the writer process in the background. It then opens the other end of the FIFO by cat'ing it to /dev/null. IF you don't open both ends of the FIFO, then the open call will block.

#!/bin/sh # Make the FIFO (first time only) if [ ! -p "file.fifo" ] then mkfifo file.fifo fi # run script to write to FIFO and wait for it to finish ./writefifo.sh & cat file.fifo >/dev/null # open other end wait && echo "writer done" rm -f file.fifo exit 0
This is the writer script, which simply echo's a line to the FIFO, sleeps a bit and then exits.
#!/bin/sh echo "a line to the fifo" >> file.fifo sleep 5
This seems to work fine for me, even when I Control-C the main script before the writer finishes. Do you have any processes still running after your primary Ctrl-C that may be blocking on an open call?

---
echo S 1 [ Y V U | perl -ane 'print reverse map { $_ = chr(ord($_)-1) } @F;'
Warning: Any code posted by tuxz0r is untested, unless otherwise stated, and is used at your own risk.

Replies are listed 'Best First'.
Re^2: named pipe and "Text file busy"
by finpro (Novice) on Nov 25, 2007 at 08:20 UTC
    yes, you're right with your example: in my case instead of cat file.fifo >/dev/null i use my Perl script to read the FIFO.
    Your example works fine for me as well, so i believe there's smth wrong with my Perl script.
    I've checked there are no processes left after Ctrl-C the script. Here's the sequence of steps i perform:
    1. Start the script that opens file.fifo and wait for data to arrive
    2. in the shell: echo "test" > file.fifo. This works fine, the script reads "test" with no problems
    3. Ctrl-C my Perl script
    4. do echo "test" > file.fifo again. Result - "Text file busy"
      From your steps, it looks like you start the reader (the perl script), then write something to the file, then kill the reader, then try to write to the file again. I think this is expected behavior (unless the FIFO is opened in non-blocking mode) because an open for reading or writing will block unless another open for the opposite is done (both ends need to be opened, reading and writing). When you kill the reader end of the named pipe your writer blocks because there is no one on the other end to read from it.

      I can't get my examples to recreate the ETXTBSY error, but I suspect that is what this is referring too. If you tail the FIFO in another terminal window and then do that last echo you should work w/o the error.

      ---
      echo S 1 [ Y V U | perl -ane 'print reverse map { $_ = chr(ord($_)-1) } @F;'
      Warning: Any code posted by tuxz0r is untested, unless otherwise stated, and is used at your own risk.

        The expected behavior will be for the writer to block (unless open in non-blocking mode) - not to exit with an error. You can test this in the shell with "echo" and "cat". "text file busy" results after the writer tries to open the FIFO - it does not even get to the writing stage. I can confirm that with the C program i wrote that tries to open the FIFO with "open" system call and then returns errno 26 - "text file busy".