101–110 of 260 posts
Earlier quoted context omitted.
This is misleading because you use plural for both and I'm sure most of these UX missteps were _each_ made by a _single_ person, and there were >1 users even at the time.
I think he meant that at that time all users were programmers. Yes, _all_ .
So if i happen to know the numbers of other file descriptors of the process (listed in /proc), i can redirect to other files opened in the current process? 2>&1234? Or is it restricted to 0/1/2 by the shell? Would probably be hard to guess since the process may not have opened any file once it started.
> Would probably be hard to guess since the process may not have opened any file once it started.
You need to not only inspect the current state, but also race the process before the assignments change.
It also teaches how && and || work, their relation to [output redirection][3] and [command piping][2], [(...) versus {...}][4], and tricky parts like [word expansion][5], even a full grammar. It's not exciting reading, but it's mostly all there, and works on all POSIXy shells, e.g. sh, bash, ksh, dash, ash, zsh.
[1]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html
[2]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html...
[3]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html...
[4]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html...
[5]: https://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html...
It's a reminder of how archaic the systems we use are. File descriptors are like handing pointers to the users of your software. At least allow us to use names instead of numbers. And sh/bash's syntax is so weird because the programmer at the time thought it was convenient to do it like that. Nobody ever asked a user.
You can use /dev/stdin, /dev/stdout, /dev/stderr in most cases, but it's not perfect.
So if i happen to know the numbers of other file descriptors of the process (listed in /proc), i can redirect to other files opened in the current process? 2>&1234? Or is it restricted to 0/1/2 by the shell? Would probably be hard to guess since the process may not have opened any file once it started.
It is not. You can use any arbitrary numbers provided they're initialized properly. These values are just file descriptors.
For Example -> https://gist.github.com/valarauca/71b99af82ccbb156e0601c5df8...
I've used (see: example) to handle applications that just dump pointless noise into stdout/stderr, which is only useful when the binary crashes/fails. Provided the error is marked by a non-zero return code, this will then correctly display the stdout/stderr (provided there is <64KiB of it).
It's a reminder of how archaic the systems we use are. File descriptors are like handing pointers to the users of your software. At least allow us to use names instead of numbers. And sh/bash's syntax is so weird because the programmer at the time thought it was convenient to do it like that. Nobody ever asked a user.
2>/dev/stdout
And of course I wish you could use a friendlier name for STDERR instead of `2>`
Earlier quoted context omitted.
This is misleading because you use plural for both and I'm sure most of these UX missteps were _each_ made by a _single_ person, and there were >1 users even at the time.
> and there were >1 users even at the time. Are you sure there wasn't >&1 users... Sorry I'll get my coat.
Earlier quoted context omitted.
> bash's syntax is so weird What should be the syntax according to contemporary IT people? JSON? YAML? Or just LLM prompt?
There's a movement to write JSON to fd 3, as a machine-parsable alternative to rickety fd 1.
Earlier quoted context omitted.
Another fun consequence of this is that you can initialize otherwise-unset file descriptors this way: $ cat foo.sh #!/usr/bin/env bash >&1 echo "will print on stdout" >&2 echo "will print on stderr" >&3 echo "will print on fd 3" $ ./foo.sh 3>&1 1>/dev/null 2>/dev/null will print on fd 3 It's a trick you can use if you've got a super chatty script or set of scripts, you want to silence or slurp up all of their output,…
Interesting. Is this just literally “fun”, or do you see real world use cases?
$ aws s3api get-object --bucket foo --key bar /dev/stdout | pv ...
You can, though, do the following:
$ aws s3api get-object --bucket foo --key bar /dev/fd/3 3>&1 >/dev/null | pv ...
The comments on stackoverflow say the words out of my mouth so I'll just copy & paste here: > but then shouldn't it rather be &2>&1? > & is only interpreted to mean "file descriptor" in the context of redirections. Writing command &2>& is parsed as command & and 2>&1 That's where all the confusion comes from. I believe most people can intuitively understand > is redirection, but the asymmetrical use of & throws them…