Writing to pipe files command

Vani

HI,

I am a newbie to Linux and am trying to create a pipe file with the below command:

mkfifo pone

Now I am trying to write data to the file with the following command on the command prompt:

echo asdadsasdasdasdasdasd >./pone

But after i enter this command- the screen hangs up and doesnt proceed ahead.

Same thing happened when I tried writing using:

gedit pone

Can anyone help me resolve this issue?

jjex22

Hi there!

Good news is you've got the syntax correct!

echo blahblahblah > named_pipe

Is taking the output from the echo command and putting it in the pipe.

Here's the thing: The pipe is what is known as "Blocked" - there is no output at the other end, so your original command is still waiting. (you can cancel it by pressing CTRL+C)

If you open another virtual terminal (or tab in your emulator) you can now read from the named pipe:

less < named_pipe

(press 'q' to quit less)
and you will see the output of echo read by less in the second virtual terminal, whilst in the first virtual terminal, the command completes and you are returned to a prompt.


Are you sure you need a named pipe? remember that a named pipe is exactly what it says on the tin - a pipe with a name assigned by you instead of the system, it behaves in exactly the same way. For example, if we repeat the steps above, and create a new named pipe "test" in our home directory:

mkfifo ~/test

Then we echo 'mic check check check' down the pipe:

echo mic check check check > ~/test

we notice that our command is suspended by the kernal, so we open a new virtual terminal and pick up the pipe:

less < ~/test

(notice that we use < not > as we are reading as input not writing as output)
we see the output in the other virtual terminal and the command completes in the first, as expected. Now, let's try and repeat the last step:

less < ~/test

Uh - oh! the command hung, the pipe is again 'blocked' - we have no input. Even though we used a file as a pipe, the data is not stored. Don't quit the command yet, let's got to the first virtual terminal again, and type:

echo oops! > ~/test

See how now the pipe is 'unblocked' it completes in both virtual terminals? there is no persistence with a named pipe, it just allows you to redirect a pipe across unrelated virtual terminals and applications.

In your example a normal file would work better.

echo put this in a file > ~/new_file
less ~/new_file

Here the '>' writes the output OVER the file, if no file is found, it creates it. You could use '>>' if you want to APPEND to the end of the file and not erase it. Generally it is risky to '>' to a new file as you may not have checked if the file already exists and accidentally loose data. You can create a blank file to use with:

touch new_file

Generally though, the alternative for users would be the 'tee' command. Similar to its' name, the 'tee' command can be thought of as a 'T' junction: it passes the input straight to the output (down the road) whilst also redirecting a copy to a file (turning off at the intersection). To use your example:

touch pone
echo asdadsasdasdasdasdasd | tee pone

echo completes, and if we check:

less pone

Our data has persisted.

If you wanted to use tee between two commands:

touch tee_file
echo would you like a cuppa? | tee tee_file | cat

And yes, you can use named pipes in place of the unnamed pipes here too to send this accross termials!
Terminal 1:

touch ~/cup
mkfifo ~/coffee
echo Thanks a latte! > ~/coffee

Terminal 2:

tee ~/cup <~/coffee | cat

Remember, our cup file has 'Thanks a latte!' in it because it is persistent, but out coffee named pipe has retained no data. We asked echo to print to the screen, which it did, our shell then redirected that output down a pipe called 'coffee' to the tee command, which took it as input, saved it to a file called 'cup' then passed it back to the shell which sent it down a pipe with no name (well a kernel assigned name)to the cat command which printed it back to screen.

Hope it helps!