4 ms·

The language looks really quite interesting. I could see myself using it for quick scripts. I think I'd prefer bash's noclobber behaviour to be the default re

by JNRowe 5y ago

The language looks really quite interesting. I could see myself using it for quick scripts. I think I'd prefer bash's noclobber behaviour to be the default redirection style. The explicitness of being forced to >| always feels like a nice safety feature to me, which would tie in nicely with their other defaults for safer scripting. Also, not sure I'm keen on their minor change to the redirection syntax¹. It suggests that "2>1" and "2> 1" have very different results, which feels like an odd change to make when you're keeping the other aspects of that syntax. Probably says more about me though, I want 100% match or a complete break to force me to think. I think it is interesting to compare the approach of oil², which has overlapping goals but is attacking the problem of improving shell scripting while attempting to keep the syntax. ¹ https://hush-shell.github.io/cmd/basic.html https://hush-shell.github.io/cmd/basic.html ² https://www.oilshell.org/ https://www.oilshell.org/ (note: if - like me - you're not seeing syntax highlighting for hush then enable JS)

nine_k 5y ago
Frankly, I think that only, say, three things are worth keeping from traditional shells: pipes, redirections, and $-variables. Most of the rest in them are design choices dictated by highly constrained machine resources and, most of all, incremental evolution. I'd say that Bash as a language is larger than Hush, while being conceptually much less clean, and in many regards less ergonomic.
pxeger1 5y ago
> It suggests that "2>1" and "2> 1" have very different results FYI, "2>1" and "2 >1" already have very different results in Bourne shell. So I don't think it's an unforgivable sin.
- chubot 5y ago
  Yeah this is the crazy thing about shell redirect syntax 2>&1 # descriptor redirect 2>& 1 # identical to above 2 >&1 # runs a command "2" and then does a descriptor redirect And likewise for 2>1 2> 1 2 >1 The 2 is really part of the operator, but the 1 isn't !
- JNRowe 5y ago
  Ick, you're right. I was thinking solely about the change with their version of the "2>&1" vs "2>& 1" case. Although making such an error in my example doesn't seem to invalidate my point. It takes an already odd syntax and makes it subtly different, instead of tightening it up.
chubot 5y ago
attacking the problem of improving shell scripting while attempting to keep the syntax (Oil author here) Slight correction, The project has two parts (1) OSH (bin/osh) will run your existing scripts, so in that sense it does keep the syntax (2) The Oil language (bin/oil) is an upgrade from OSH, but it can also be thought of as a clean slate language: https://www.oilshell.org/release/latest/doc/oil-language-tour.html https://www.oilshell.org/release/latest/doc/oil-language-tou... It's really the same interpreter with a few parse time and runtime options. There were surprisingly few compromises (probably the biggest one is the shell-like string literal syntax, which I mention.) The biggest changes are that we take over ( ) and { } , so you can write stuff like: if (x > 0) { echo 'positive' | tac } Rather than if test "$x" -gt 0; then echo 'positive' | tac fi We add a Python-like expression language between () and surprisingly few things need to change to make it feel like a "new language". Thanks for mentioning Oil :)

by JNRowe 5y ago

nine_k 5y ago

Frankly, I think that only, say, three things are worth keeping from traditional shells: pipes, redirections, and $-variables. Most of the rest in them are design choices dictated by highly constrained machine resources and, most of all, incremental evolution. I'd say that Bash as a language is larger than Hush, while being conceptually much less clean, and in many regards less ergonomic.

pxeger1 5y ago

> It suggests that "2>1" and "2> 1" have very different results FYI, "2>1" and "2 >1" already have very different results in Bourne shell. So I don't think it's an unforgivable sin.

chubot 5y ago
Yeah this is the crazy thing about shell redirect syntax 2>&1 # descriptor redirect 2>& 1 # identical to above 2 >&1 # runs a command "2" and then does a descriptor redirect And likewise for 2>1 2> 1 2 >1 The 2 is really part of the operator, but the 1 isn't !
JNRowe 5y ago
Ick, you're right. I was thinking solely about the change with their version of the "2>&1" vs "2>& 1" case. Although making such an error in my example doesn't seem to invalidate my point. It takes an already odd syntax and makes it subtly different, instead of tightening it up.

chubot 5y ago

attacking the problem of improving shell scripting while attempting to keep the syntax (Oil author here) Slight correction, The project has two parts (1) OSH (bin/osh) will run your existing scripts, so in that sense it does keep the syntax (2) The Oil language (bin/oil) is an upgrade from OSH, but it can also be thought of as a clean slate language: https://www.oilshell.org/release/latest/doc/oil-language-tour.html https://www.oilshell.org/release/latest/doc/oil-language-tou... It's really the same interpreter with a few parse time and runtime options. There were surprisingly few compromises (probably the biggest one is the shell-like string literal syntax, which I mention.) The biggest changes are that we take over ( ) and { } , so you can write stuff like: if (x > 0) { echo 'positive' | tac } Rather than if test "$x" -gt 0; then echo 'positive' | tac fi We add a Python-like expression language between () and surprisingly few things need to change to make it feel like a "new language". Thanks for mentioning Oil :)