Well, not exactly. He merely suggested using another one. But I thought it would be good to talk something a little bit more specific. And I am not sure he knows there are already others available (for shell scripts at least fd[0-9]).
After all, /dev/std{in,out,err} are more or less just convenience links (allowed extensions of POSIX). But using /dev/stderr might fail on some POSIX compliant systems.
Not breaking stdin and stdout is key. Looking at the output from that shell, text parsing tools like awk are not going to integrate if you dont have a compatible tool yet. Everything in a base Linux install has to be rewritten to work.
Personally i prefer the keep it simple approach. Id much rather /etc/hosts stayed the way it is rather than becoming xml, json or binary.
The whole idea of "Power" shell is broken if you ask me. Shell should be simple. If it isnt, write some proper code. And do some code review, and testing first!
Shell stopped being simple long long ago, at the latest when bash and ksh were introduced. (Re)writing the base utilities has happened many times, and is quite doable.
Yes, backward compatibility is important; that’s why I think adding a new named stream could be the way to go, since it wouldn’t break almost anything (I guess someone might have to reroute something, if it happens to be on the fd that is chosen for the link).
I honestly don’t know how much work it would entail from OS devs, but once you have it in Linux and BSDs/Mac that’s basically it. Microsoft could take the chance to be an early adopter, considering they already have all the machinery to output structured data in PS; at that point, whether it’s pure posix or not would matter little in practice.
I don’t particularly like PS for a number of reasons, but I do admit that its output facilities can be quite nice. Having something like that in Bash for the few times one really needs it, with standard interfaces and without having to learn a completely new paradigm, would be a nice win imho.
This doesn’t mean we should touch /etc/hosts or anything, btw.
I know quite a few places where shell scripts would probably blow up if some arbitrary FD number >2 would be used... Opening a file in bash (and I suppose other shells too) is done by specifying the FD number explicitly:
exec 3<> somefile.txt
That might trigger some very weird behaviour when piping data from a 'stddata' aware tool into shell scripts - something which is guaranteed to happen somewhere.
After all, /dev/std{in,out,err} are more or less just convenience links (allowed extensions of POSIX). But using /dev/stderr might fail on some POSIX compliant systems.