>&/filename is a synonym for &> (bash and zsh)

[o11c]

This is used by Debian's default .bashrc (excerpted below), which is notable enough that people will copy from it and expect it to work.

If nothing else, it should be a more specific error message.

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
    # We have color support; assume it's compliant with Ecma-48
    # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
    # a case would tend to support setf rather than setaf.)
    color_prompt=yes
    else
    color_prompt=
    fi
fi

[andychu]

Hm I'm not seeing the issue. What happens now, and what do you expect to happen?

[o11c]

Ah, this only happens when force_color_prompt=yes is uncommented. I'd forgotten that some people haven't done that.

osh$ . .bashrc
      if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
                                                ^~~~~~~~~
.bashrc:51: Invalid descriptor '/dev/null'.  Expected D, -, or D- where D is an integer

[andychu]

Oh geez, it looks like zsh supports both of them too... mksh doesn't support it.

This is very lame and confusing... it's like if you made a typo of ** as ^ in Python and they changed the meaning based on the type of the argument.

[andychu]

This is the kind of thing I really wish people would patch upstream... it's utterly trivial, and Oil will likely not run such rc files unmodified anyway.

See the analogy to Clang and GCC here.

http://www.oilshell.org/blog/2020/01/ambitions.html#appendix-comments-that-add-color

In other words, Clang has been around for 15+ years, and it builds Android and Chrome and Apple's stuff, but every distro still has to patch tons of things to build with Clang. I think the situation will be similar with Oil.

I'm prioritizing having everything be "possible" and having Oil be fast first. Once there are users they will be motivated to either patch Oil or upstream these changes (which IMO make the code clearer).

[andychu]

This also reminds me I want to redesign the redirect syntax, but that will be left out of Oil v1.

Oil will have consistent meanings for < > << >>, rather than the weird asymmetry where >> means append and << means here doc. Here docs will be more like here strings without the operator <<<.

I haven't thought about what "stderr and stdout" looks like, but it has to be better than &> vs. >& ...

[andychu]

I think we are going through a process of "conceding to reality" now, so I'm more open to this :-/

Although I would want it hidden behind shopt --set strict_redirect for Oil/YSH

(Fundamentally it irks me when random typos become valid code)