Interesting language/script. Are there any other comparable alternatives? Would Node/TS-Node be a suitable replacement with a few shell helper functions?
Hush, a modern shell scripting language
11–20 of 192 posts
Re: Hush, a modern shell scripting language
#12This looks nice. I'm slightly surprised by the error handling though: if std.type() == "error" then It seems (a) a bit verbose and (b) a bit hacky to compare the type against the string "error". I wonder if more ergonomic error handling is something the author is planning.
The section on the try operator¹ includes an example showing the syntactic sugar to reduce the verbosity. It does feel like it might be better to introduce it earlier on, as I was feeling the same way as you until I saw that.
¹ https://hush-shell.github.io/error-handling.html#try-operato...
Re: Hush, a modern shell scripting language
#13Is this really a shell scriping language? Hush isn't an interactive shell, nor does it compile to a common shell script. The only way to run these scripts is to install the hush interpreter and run the script through it. Isn't that just a normal scripting language? What's the real benefit of using this over Node or Python? I suppose the syntax is more aesthetically similar to shell scripts... but I don't exactly see…
System level stuff sucks in Python. Dealing with files, I/O, permissions, etc is a real pain. It easily takes 5x as long and as many loc to do the same thing as in bash.
I can see the benefit of dropping to a command block to, say, run a command and filter the output with some | grep | awk | sort of whatever, and then seamlessly come back up to a more fully featured language to deal with that data.
Re: Hush, a modern shell scripting language
#14The 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
(note: if - like me - you're not seeing syntax highlighting for hush then enable JS)
Re: Hush, a modern shell scripting language
#15The unfortunate truth of all such projects: if it isn't pre-installed on all reasonably complete Linux distos, it can truly succeed, no matter how awesome and cool it is... ... which is why I try to write as much stuff as POSIX sh as possible, and sometimes I have to throw in a Bashism to get by. And I say this as someone that wishes sh was better, semi-lovingly.
This isn't really true at all. We have an ungodly amount of operational process and knowledge tied up in bash scripts deployed across our fleet, but we could easily deploy a different shell, and use that. We don't use bash because it's the least common denominator on our systems --- in fact, I think in an era of AMIs and Dockerfiles, few people do. We use it because of path dependance.
Re: Hush, a modern shell scripting language
#16The unfortunate truth of all such projects: if it isn't pre-installed on all reasonably complete Linux distos, it can truly succeed, no matter how awesome and cool it is... ... which is why I try to write as much stuff as POSIX sh as possible, and sometimes I have to throw in a Bashism to get by. And I say this as someone that wishes sh was better, semi-lovingly.
I think part of the problem is that we still don't have a standard /bin/sh even though there is a written standard. It feels fair to me to suggest that you can call dash the working standard on Linux, but you can't trust that beyond Linux systems(and I'm ignoring installs that are busybox-based here too).
And that also feels like the problem with extending a script with a few bashisms too, as you're suddenly trying to remember when that feature appeared. Off the top of my head I'm wondering what things won't be available to Mac users because it ships with a pre-GPLv3 bash for example.
Re: Hush, a modern shell scripting language
#17Is this really a shell scriping language? Hush isn't an interactive shell, nor does it compile to a common shell script. The only way to run these scripts is to install the hush interpreter and run the script through it. Isn't that just a normal scripting language? What's the real benefit of using this over Node or Python? I suppose the syntax is more aesthetically similar to shell scripts... but I don't exactly see…
Counterpoint: I work at the REPL of scripting languages roughly as much as I do the shell prompt.
Re: Hush, a modern shell scripting language
#18[deleted]
Re: Hush, a modern shell scripting language
#19I've changed my mind about this sort of thing recently. I disagree with the widespread belief that one should part with shell scripts as soon as possible.
Yeah, there are definitely eventually scripts where one should rewrite the work in another language, but we now just have too many people who have no idea what getopts is, too many people who think bash is available everywhere, too many people who think it's a good and safe idea to put all of your program arguments in environment variables, too many people who have no idea where POSIX specifications are and why they're useful, too many people who don't know how to simply reach for manual pages and do all their learning exclusively off Stack Overflow and Medium, etc.
You don't need advanced knowledge of all of this stuff, but when you're outright afraid of it, there's a professional problem involved. I'm not asking for people to have a comprehensive knowledge of awk, but if you've avoided every opportunity to simply understand what 'set -e' 'if' and 'test'/[]' are, you're intentionally atrophying your professional development.
Re: Hush, a modern shell scripting language
#20Is this really a shell scriping language? Hush isn't an interactive shell, nor does it compile to a common shell script. The only way to run these scripts is to install the hush interpreter and run the script through it. Isn't that just a normal scripting language? What's the real benefit of using this over Node or Python? I suppose the syntax is more aesthetically similar to shell scripts... but I don't exactly see…
System level stuff sucks in Python. Dealing with files, I/O, permissions, etc is a real pain. It easily takes 5x as long and as many loc to do the same thing as in bash. I can see the benefit of dropping to a command block to, say, run a command and filter the output with some | grep | awk | sort of whatever, and then seamlessly come back up to a more fully featured language to deal with that data.
This is very true, particularly if your script is just an imperative list of commands to run.
Python scripts win when you actually need to handle errors, or non trivial output parsing, or when the concept of “list of things” doesn’t fit neatly into the “lines of text / pipe symbol” paradigm.
I try to think of it like Donkey Kong. Every time you do something like this:
var=$(command | awk -vID=$ID ‘$6 ~ /foo/ and $7 == ID {print $1 “ “ $2} | head -3)
If it’s a truism that most shell scripts are better off written in Python, it’s just as true that all Python scripts are better off as reusable modules (that may also be standalone scripts.)