4 ms·

More Lego rules: (7) and common signalling facility (8) also nice if some files have magic properties like /dev/random or /proc or /dev/null (9) every progra

More Lego rules: (7) and common signalling facility (8) also nice if some files have magic properties like /dev/random or /proc or /dev/null (9) every program starts with 3 streams, stdin/stdout for work and stderr for out of band errors

enedil 6y ago
(9) every program starts with 3 streams, stdin/stdout for work and stderr for out of band errors This is false - if a process closes stdin/out/err, its children won't have these files open.
- imglorp 6y ago
  That's correct, which is why I said _starts_ with the streams. The child can do what it wants with them after that.
  - DSMan195276 6y ago
    His point was that if you close stdin/stdout/stderr and then fork a child, the new child will not have all of those streams when it starts - the three streams are a convention, not something enforced by the kernel when creating a new process. That said, it's still a bit of a pedantic point, you can expect to always have those three fds in the same way you can expect `argv[0]` to represent the name of your executable (Which also isn't enforced by the kernel).
    - JdeBP 6y ago
      Actually, it's not a pedantic point. It's a security flaw waiting to happen (as it actually has) if one assumes that one always has three open file descriptors. The privileged program opens a sensitive data file for writing, it gets assigned (say) file descriptor 2, because someone in a parent process took some advice to "close your standard I/O because you are a dæmon" to heart, other completely unrelated library code somewhere else blithely logs network-supplied input to standard error without sanitizing it, and (lo!) there's a remotely accessible file overwrite exploit of the sensitive data file. Ironically, the correct thing to do as a dæmon is to not close standard I/O, but to leave setting it up to the service management subsystem, and use it as-is. That way, when the service management subsystem connects standard output and error to a pipe and arranges to log everything coming out the other end, daemontools-style, the idea actually works. (-:
hhas01 6y ago
I defy anyone to build their error-handling logic off the back of stderr…
- imglorp 6y ago
  Logic, not in this case, just messages. The point of separate error streams echoes the main Unix philosophy of doing small things, on the happy path, that work quietly or break early. Your happy results can be chained on to the next thing and your errors go somewhere for autopsy if necessary. Eg, p1 | p2 | p3 > result.txt 2> errors.txt will not contaminate your result file with any stderr gripes. You may need to arrange error streams from p1 and p2 using () or their own redirection. If it dies, it will die early. BUT speaking of logic, the concept is close to Railway Oriented Programming, where you can avoid all the failure conditionals and just pass a monad out of a function, which lets you chain happy path neatly. Eg, nice talk here https://fsharpforfunandprofit.com/posts/recipe-part2/ https://fsharpforfunandprofit.com/posts/recipe-part2/

enedil 6y ago

(9) every program starts with 3 streams, stdin/stdout for work and stderr for out of band errors This is false - if a process closes stdin/out/err, its children won't have these files open.

imglorp 6y ago
That's correct, which is why I said _starts_ with the streams. The child can do what it wants with them after that.
- DSMan195276 6y ago
  His point was that if you close stdin/stdout/stderr and then fork a child, the new child will not have all of those streams when it starts - the three streams are a convention, not something enforced by the kernel when creating a new process. That said, it's still a bit of a pedantic point, you can expect to always have those three fds in the same way you can expect `argv[0]` to represent the name of your executable (Which also isn't enforced by the kernel).
  - JdeBP 6y ago
    Actually, it's not a pedantic point. It's a security flaw waiting to happen (as it actually has) if one assumes that one always has three open file descriptors. The privileged program opens a sensitive data file for writing, it gets assigned (say) file descriptor 2, because someone in a parent process took some advice to "close your standard I/O because you are a dæmon" to heart, other completely unrelated library code somewhere else blithely logs network-supplied input to standard error without sanitizing it, and (lo!) there's a remotely accessible file overwrite exploit of the sensitive data file. Ironically, the correct thing to do as a dæmon is to not close standard I/O, but to leave setting it up to the service management subsystem, and use it as-is. That way, when the service management subsystem connects standard output and error to a pipe and arranges to log everything coming out the other end, daemontools-style, the idea actually works. (-:

hhas01 6y ago

I defy anyone to build their error-handling logic off the back of stderr…

imglorp 6y ago
Logic, not in this case, just messages. The point of separate error streams echoes the main Unix philosophy of doing small things, on the happy path, that work quietly or break early. Your happy results can be chained on to the next thing and your errors go somewhere for autopsy if necessary. Eg, p1 | p2 | p3 > result.txt 2> errors.txt will not contaminate your result file with any stderr gripes. You may need to arrange error streams from p1 and p2 using () or their own redirection. If it dies, it will die early. BUT speaking of logic, the concept is close to Railway Oriented Programming, where you can avoid all the failure conditionals and just pass a monad out of a function, which lets you chain happy path neatly. Eg, nice talk here https://fsharpforfunandprofit.com/posts/recipe-part2/ https://fsharpforfunandprofit.com/posts/recipe-part2/