Well you can't read either from /dev/null, and I don't think that's just a question of permissions. I'm pretty sure it's impossible to get /dev/null to behave like an executable.

You can read from /dev/null—it just behaves as a zero-length file, immediately returning EOF.

This makes /dev/null a valid source file in many languages, C included.

/dev/null behaves like an empty file, which is (or used to be?) a valid executable.

Cf http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html or https://twitter.com/rob_pike/status/966896123548872705

In most contexts empty file is indeed a valid executable. Debian folks learned this the hard way recently:

https://bugs.debian.org/919341

However, executing /dev/null doesn't seem to work on Linux:

  $ sudo chmod 777 /dev/null 
  $ /dev/null
  bash: /dev/null: Permission denied

Interesting question.

You could write a executable that accepts piped input and throws it away.

When would it exit though? Would it exit successfully at the end of the input stream? That sounds sensible.

That would be behaving like an executable wouldn't it?

> When would it exit though? Would it exit successfully at the end of the input stream?

A process that attempts to read from a closed pipe receives SIGPIPE. The default disposition for SIGPIPE is to terminate the program (similar to SIGTERM or SIGINT). So yeah, assuming that the previous program in the pipeline closes its stdout at some point (either explicitly, or implicitly by just exiting), then our program would die of SIGPIPE the when it tries to read() from stdin and the pipe's buffer has been depleted.

However, our program could also set SIGPIPE to ignored and ignore the EPIPE errors that read() would return in that case. In that case, it could run indefinitely. But at this point, you're way past normal behavior.

As long as it does not exit you can still catch it through /proc/