Re: Do `>& -` and `<& -` also work?

[Koichi Murase]

2021年5月11日(火) 13:06 Peng Yu <pengyu.ut@gmail.com>:
> I totally understand what you are saying. But there are
> POSIX-noncompliant shells that are also very popular. See the
> following shell. It says "fish is ranked 2nd while bash is ranked
> 3rd." I don't know how trustworthy that fish is more popular than
> bash. At least, it should be very popular. So being POSIX-compliant or
> not is not something dictate whether a shell is popular or not. In
> this sense, completely POSIX-compliance is not that important.

You have told me in another thread that you are not discussing the
change to the existing code of Bash, but rather talking about
hypothetical design when one would have implemented a new one from
scratch based on the experience on Bash. If that is also the same for
this discussion, I think maybe you could have first clarified it
before starting the discussion in order to avoid unnecessary conflicts
something like "that's not the direction of Bash, etc."

> I checked the syntax of fish, which seems to be too far away from the
> bash syntax. I'd rather have something similar to bash but fixing the
> bad designs over the last 40 years. For this reason, it would
> beneficial to evaluate what syntax designs are good and what designs
> are bad in bash (which can come from POSIX). If there were somebody
> who starts with a better shell similar to bash, that could serve as a
> reasonable good starting point.

There are already many attempts for "better syntax" in shells. You can
find a list of such shells (that are free from the constraints of the
POSIX) at:

https://github.com/oilshell/oil/wiki/Alternative-Shells

Some of them try to improve the Bash syntax, and some try to invent a
completely different syntax.

Also, the reason that fish became popular isn't its syntax. Fish is
just popular for an interactive shell with eye candies like syntax
highlighting and autosuggestions, and almost no one writes scripts in
Fish (except for its configuration for interactive uses). Actually,
Fish has many serious defects in its syntax design which cannot be
fixed for backward compatibility. Bash is far better than Fish as a
scripting language. I guess it is very interesting for you to read
GitHub issues of the Fish shell listed at

https://github.com/pirate/fish-utils/blob/master/README.md

> For the case of [n]>&word, I doubt most people would add space before
> word. The syntax is just too difficult to be fully understood for
> beginners, most people just copy and paste something that works, which
> is heavily affected by available tutorials. The following is an
> example. In fact, I don't remember I ever seen any tutorials use the
> form with space before word when it is a number or "-". There could be
> spaces when "word" is a filename though.
>
> https://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html

I think every language has such an aspect in syntax; there is always a
way of writing that most people don't use but syntactically correct.
For example, in C language, most tutorials and texts put spaces around
operators like « a = b » but we can also write « a=b ». Rejecting the
redirection with space "3>& 1" or "3>& -" under the reason that you
happened to know it only recently is something like requesting C
language to change to prohibit « a=b » by the reason that you recently
know the way of writing and most people and tutorials don't do that
way. It's a strange request from the viewpoint of those who get used
to the syntax. Maybe you can design such a new shell, but I'm not sure
if it's worthwhile to change the existing behavior taking the risk to
confuse the people who know that "3>& -" is possible in traditional
POSIX shells. Actually, they are not that surprising for people who
use « exec {fd}> xxx » and « echo >&$fd » or « exec 4>&$fd- », in
which the file descriptor and - are clearly not the part of the
redirection operator.

> In that sense, if the goal is not to be POSIX compatible, but to have
> something as compatible as to existing bash, and getting off those bad
> features that most people don't use anyway, it would be helpful to
> analyze the existing syntax. I hope that you understand the logic
> reasoning here.

You are talking about the goal of this specific discussion but not the
goal of Bash, right?