Does echo -n | ... send an EOF to the pipe? I.e.,

echo -n | sth

Will sth recieve an EOF on its stdin?

  • 2
    please note that : 1) you should replace echo -n "something" (shell dependant, and OS dependent) with : printf "%s" "something" (the portable way. ) see unix.stackexchange.com/a/65819/27616 : And 2) if you intend to pipe to another command, if that command expect a TEXT, a (last) line without a terminating "\n" is often not considered valid and will be discarded... ex: printf "a\nb\nc\n" | wc -l # 3 lines, 3 words, 6 chars printf "a\nb\nc" | wc # 2 lines, 3 words, 5 chars! , ie wc -l doesn't count the last line, even though it has characters on it! – Olivier Dulac Sep 21 at 12:20

There is no EOF that is represented as data in a file or stream. It is merely a status associated with the file descriptor.

When the echo terminates (which will be almost immediately), the write end of the pipe is closed.

The next time sth reads (assuming it has read all data previously written to the file) the pipe status changes to EOF and the read issued by sth returns with the EOF condition. The process can continue with any processing it requires, it just cannot read any more from the pipe.

| improve this answer | |
  • 1
    “it just cannot read any more from the pipe” — that's true here, but it wouldn't be the case with a named pipe. With a named pipe, the reader could continue reading and would receive data if another process opens the named pipe for writing and writes to it. – Gilles 'SO- stop being evil' Sep 20 at 17:44
  • @Gilles'SO-stopbeingevil' Agreed -- I answered the question on the basis of a shell simple anonymous pipe. I believe a construct like { echo; sleep 5; echo bar; } | cat lets all three processes inherit the pipe fd for writing. – Paul_Pedant Sep 20 at 17:59
  • 1
    EOF is not a status associated with a file descriptor, or with the file object the file descriptor refers to. – user431397 Sep 21 at 3:03

There's no EOF to send or receive.

EOF is just an api fiction that only exists in the stdio library. It's a status flag of a FILE* stdio input stream which is usually set after a read(2) system call on the underlying file descriptor has returned 0. And a macro for -1 which is the value returned by fgetc(3) and similar functions when called on a input stream with its EOF flag on.

While you can speak metaphorically of "sending an EOF" as "indirectly cause some future read(2) to return 0", that's quite sloppy, and will create the false impression that EOF is some kind of inline signal, or a status of the underlying file descriptor or device that could be set from the other end.

On a pipe, read(2) will return 0 if

  1. the pipe buffer is empty, and
  2. there's no open handle to its writing end

Both conditions are transient, which is consistent with the way the EOF conditions are transient on regular files or terminals.

In particular, notice that on Linux, all pipes are effectively named pipes: as long as a process still has an open handle to the reading end of a pipe, you can also revive its writing end by opening the pipe in write mode via /proc/<pid>/fd/<fd>. While that may not be that easy on other systems, having a sticky EOF on an "anonymous" pipe is not part of its interface.

| improve this answer | |

Yes. A program that reads from a pipe sees an end-of-file on the pipe when the program that writes to the pipe closes the writing end. More precisely, the end-of-file event happens when the last file descriptor that was open on the pipe gets closed. Ways to close a file descriptor include explicit closing and a process exiting.

Here there's just one process writing to the pipe and running echo -n, which depending on the shell either writes -n and a newline, or nothing. When that process has finished writing and exits, the writing end of the pipe is closed, so sth sees EOF on the pipe. (It's also possible that the shell runs the left-hand side of the pipe without forking, in which case the shell closes the pipe explicitly when it's done writing: this optimization doesn't make any difference to the right-hand side of the pipe.)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.