3 ms·

I twitched horribly at the final sentence, screaming inwardly "you don't pipe to /dev/null, you redirect to it". And now I feel like an arsehole.

analpaper 8y ago
redirect your feelings to /dev/null, because a pipe will just give us a Permission denied
- benj111 8y ago
  Chmod +x /dev/null (havent tried above, not sure I recommend that you do)
  - jgtrosh 8y ago
    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.
    - arghwhat 8y ago
      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.
    - benj111 8y ago
      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?
      - jacquesm 8y ago
        As long as it does not exit you can still catch it through /proc/
      - majewsky 8y ago
        > 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.
    - tripa 8y ago
      /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 http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html or https://twitter.com/rob_pike/status/966896123548872705 https://twitter.com/rob_pike/status/966896123548872705
      - jwilk 8y ago
        In most contexts empty file is indeed a valid executable. Debian folks learned this the hard way recently: https://bugs.debian.org/919341 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
    - anthk 8y ago
      http://peetm.com/blog/?p=55 http://peetm.com/blog/?p=55
benj111 8y ago
Hmm well, the Unix shell seems to follow a plumbing metaphor. You could direct, or redirect the flow to /dev/null. Or pipe to /dev/null. Or redirect the pipe to /dev/null? So from a metaphor point of view either would fit. Although of course you don't use the pipe construct to direct to a file. Which would suggest piping is wrong? And then on the third hand, we all know what it means so what's the problem. So I would say theres war, famine and injustice in the world. Don't worry about posix shell semantics. :)

analpaper 8y ago

redirect your feelings to /dev/null, because a pipe will just give us a Permission denied

benj111 8y ago
Chmod +x /dev/null (havent tried above, not sure I recommend that you do)
- jgtrosh 8y ago
  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.
  - arghwhat 8y ago
    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.
  - benj111 8y ago
    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?
    - jacquesm 8y ago
      As long as it does not exit you can still catch it through /proc/
    - majewsky 8y ago
      > 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.
  - tripa 8y ago
    /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 http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html or https://twitter.com/rob_pike/status/966896123548872705 https://twitter.com/rob_pike/status/966896123548872705
    - jwilk 8y ago
      In most contexts empty file is indeed a valid executable. Debian folks learned this the hard way recently: https://bugs.debian.org/919341 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
  - anthk 8y ago
    http://peetm.com/blog/?p=55 http://peetm.com/blog/?p=55

benj111 8y ago

Hmm well, the Unix shell seems to follow a plumbing metaphor. You could direct, or redirect the flow to /dev/null. Or pipe to /dev/null. Or redirect the pipe to /dev/null? So from a metaphor point of view either would fit. Although of course you don't use the pipe construct to direct to a file. Which would suggest piping is wrong? And then on the third hand, we all know what it means so what's the problem. So I would say theres war, famine and injustice in the world. Don't worry about posix shell semantics. :)