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

[Koichi Murase]

2021年5月13日(木) 0:27 Peng Yu <pengyu.ut@gmail.com>:
> > 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
>
> [...]
>
> The statement "POSIX-ish shells like ... zsh" is wrong or not precise,
> as zsh is not POSIX compatible by default as mentioned below.

I think that's implied by "-ish". Zsh is not at all POSIX compatible
by default, but is relatively far closer to the POSIX shell compared
to the other "alternative shells" (AltShells).

> > Some of them try to improve the Bash syntax,
>
> To me, improve the syntax is important but secondary, I think that it
> is to separate its parser with the backend so that optimization can be
> done at the backend.
>
> At this moment, it seems that in the bash code the front-end parsing
> and back-end evaluation are tied together, making optimization not
> easy to do. Maybe if an AST can be parsed, then a lot of new things
> can be done with the bash language?

This is similar to what the author of oilshell (which manages the
above list of AltShells) is saying. Although oilshell seems to finally
want to depart from the Bash syntax, they maintain two different
versions of shells `osh' for the Bash-compatible shell and `oil' for a
new syntax. The oil has been in development for a long time and seems
to be not yet ready for daily use, but you may be interested in their
ideas and discussions.

> For example, I am thinking whether
> built-in program can be written in bash language instead of in C as
> they are current written.

What is "built-in program"? Do you mean the Bash version of loadable
builtins? But what is the difference with shell functions? Or maybe
are you talking about the JIT compiling of shell functions?

> The analogy is like cython vs python. For the cython tutorial, it
> looks like cython is very similar to python. Having this similarity
> should be a boost to productively as people can write python code and
> then make minor changes to get cython performance. Doing requires some
> extension in cython. I think there are certain extensions for the bash
> language to do something similar.
>
> https://cython.readthedocs.io/en/latest/src/tutorial/cython_tutorial.html

Oh, I see. So you mean compiling the Bash code to a binary and then
load it later as a loadable builtin.

> Taking about math, one thing that could be done in bash is to have a
> math mode like this, so that it allows many math operations. I think
> it is not even impossible to implement a MATLAB syntax in this mode to
> allow full-fledged math operations (of course matrix must be supported
> as a datatype).
>
> ((
>  x = 4
>  y = 7
>  z = x + y
> ))

I have once thought similar things. Zsh extends the arithmetic
expressions to support different types (floating numbers) and also to
add the function call syntax, which means that in principle we can
extend the arithmetic expressions to support full C language or some
part of C++. Oil seems to have tried to support more general
expressions with the deprecated arithmetic substitutions $[...], but I
don't know the details. I'm not sure MATLAB syntax can be implemented
with the POSIX arithmetic expressions kept working.

> > 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 ».
>
> This is not a comparible example to the case of >&-. Both "a = b" and
> "a=b" are commonly seen in C. But I just don't remember I've seen ">&
> -" in any tutorials when I first learn bash.

It's just an example for illustration. There are many other ways of
writing that are valid but no one uses. For example, I have never seen
codes writing "return -1" as "return-1", then what would you think if
someone proposed to make "return-1" ill-formed in C? Someone might
agree with it, but it is clear that there will be many objections.

> This is almost a philosophical question: Whether the evolution of
> anything should be compatible to all past features, or just be
> compatible with the majority of them. I know Windows takes the former,
> which makes their API full of functions with number suffixes. Is it
> good or bad? I think that it depends. For people who needs to learn
> such an API, it is definitely bad, but for people who just run the
> program, it is definitely good. So there is a subtle balance between
> the two.
>
> I do think there is no need to be 100% backward compatible.

I agree with this point, but at the same time, for practical reasons,
I don't think it is a good idea to change every detail of the
established behavior slightly. If there is a clear problem in the old
behavior, or if the new behavior largely changes the programming
style, I think it's worth changing. But if every behavior is slightly
changed, those who use both the old and new shells need to remember
the behavior differences for all the microscopic details. If we could
perfectly forget about the old-style shell, it would be fine to pursue
the rational behavior of the details, but it's not realistic. To come
back to the original discussion, to allow or disallow ">& 1" is a very
small change that doesn't affect the real shell programming, so I
think it is better to keep the current behavior even in a new shell
for practical reasons. Yes, it's just practical reasons but is
inevitable if we want to think about useful languages for real people
with old experiences.

> The real question is whether a feature is commonly used or. It is a
> feature few people use, then there is no reason to keep it.

No strong reasons to keep it, but no strong enough reasons to change
it. Changing it doesn't change anything in real shell programs but
just confuses those "few" people (who are probably not just repeating
the tutorials but writing their code by themselves).

> One way to evaluate how many people are potentially affected. It can
> be done to evaluate all the open-source code (e.g., on github) to see
> how likely things like "3>& 1" is used. If it is rarely used, then it
> could be a candidate for removal.

That kind of survey is usually done to introduce new functionality to
the language. Is there any case that the breaking change of a language
has been made to just prohibit a small way of writing that effectively
doesn't change a life?

> > 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 »
>
> For the above piece of code, fd will not be `-`. I would require `-`
> in `>&-` must be written explicitly as `-`'s really means closing. So,
> I wouldn't allow something like the following to work.

Oh, I see. I have been misthinking that you talk about both ">& -" and
">& 1". But anyway, I wanted to say they can be natural for some
people although you might think it is strange. There are always some
regions in the syntax details that different people have different
ways of thinking. Ultimately, we can't know how others think, so we
need to be careful for breaking changes.

> > or « exec 4>&$fd- », in
> > which the file descriptor and - are clearly not the part of the
> > redirection operator.
>
> Bash can know a problem for this case.

Oh, OK. Thank you. I didn't know we can't write in this way.

--
Koichi