[deleted]
Hush, a modern shell scripting language
31–40 of 192 posts
Re: Hush, a modern shell scripting language
#32Is 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.
I feel like you just described Perl, and I use Perl almost every day for this kind of thing, but people seem to hate it these days.
The syntax can be weird, but I still think it really shines in cases like these.
Re: Hush, a modern shell scripting language
#33Interesting language/script. Are there any other comparable alternatives? Would Node/TS-Node be a suitable replacement with a few shell helper functions?
Re: Hush, a modern shell scripting language
#34Is 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…
I love Python, but if all I need to do is grab one part of one line of something, and put it into some other command, then I'm just going to use some unholy mixture of sed, awk, or whatever. If I did the same thing in Python, I'd end up with thirty lines or more.
Thirty lines? Unholy one liners are not limited to shell scripting:
from subprocess import check_output
sh = lambda script: check_output(script, shell=True, text=True)
ips = set(line.split()[-1]
for line in sh('last -a').splitlines()
if line and 'tmux' not in line)
The last line is the equivalent of a shell script one liner but now has all the advantages of a language that supports “\N{clown face}”.
Re: Hush, a modern shell scripting language
#35Is 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.
Every shell is a REPL
Using your editor to drive a shell is a huge win because it: (a) flips the development bit in your brain, and (b) creates a shared history across all your machines.
Combine that with literate programming and you have a `duck-talking` history of every development or outage response tied to what you actually did.
Re: Hush, a modern shell scripting language
#36Is 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…
The point is that you can do things like create external processes, pipe them together, redirect output to files, with the same ultra-lightweight syntax of bash etc. Compare that to all the nonsense you have to do in Node or Python to pipe two processes together!
You’re right in that writing Python using shell paradigms is awful.
Writing Python that shells out to do stuff — but using Python paradigms — isn’t so bad. Particularly if you are used to calving off your shell stuff into shell functions that run something and massage the output. In Python you end up doing something pretty similar: yield the text you want and use that as arguments to the next call to subprocess.run.
Basically “| xargs command” but nicer.
Re: Hush, a modern shell scripting language
#37Is 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…
The purpose of OP's project kind of reminded me of shell.js (shx) [1] which is a nodejs library that wraps all kinds of common UNIX commands to their own synchronously executed methods.
I guess that most shell projects start off as wanting to be a cross-platform solution to other operating systems, but somewhere in between either escalate to being their own programming language (like all the powershell revamps) or trying to reinvent the backwards-compatibility approach and/or POSIX standards (e.g. oil shell or zsh).
What I miss among all these new shell projects is a common standardization effort like sh/dash/bash/etc did back in the days. Without creating something like POSIX that also works on Windows and MacOS, all these shell efforts remain being only toy projects of developers without the possibility that they could actually replace the native shells of other operating systems.
Most projects in the node.js area I've seen migrate their build scripts at some point to node.js, because maintaining packages and runtimes on Windows is a major shitshow. node.js has the benefit (compared to other environments) that it's a single .exe that you have to copy somewhere and then you're set to go.
When I compare that with python, for example, it is super hard to integrate. All the anaconda- or python-based bundles for ML engineers are pretty messed up environments on Windows; and nobody actually knows where their site-packages/libraries are really coming from and how to even update them correctly with upstream.
Re: Hush, a modern shell scripting language
#38Earlier quoted context omitted.
Counterpoint: I work at the REPL of scripting languages roughly as much as I do the shell prompt.
Every shell is a REPL Using your editor to drive a shell is a huge win because it: (a) flips the development bit in your brain, and (b) creates a shared history across all your machines. Combine that with literate programming and you have a `duck-talking` history of every development or outage response tied to what you actually did.
Don’t you ever use a debugger? Don’t you consider that a REPL? It’s the same paradigm as a REPL with the same upsides and downsides.
Re: Hush, a modern shell scripting language
#39This 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.
Destructuring and a little bit of pattern matching could go a long way here.
Re: Hush, a modern shell scripting language
#40The 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 dunno, I think the future of interesting shell scripting languages can either be a.) the basis for a new distro, which will decide to use it for the system scripts, b.) be intended for use with containers in some manner and can simply be added as another dependency, or c.) be primarily intended to be used interactively in some unique way, so it'll just be installed by individuals.
There will always be a place for the universal shells and text editors. Bash and vim aren't going away any time soon. But there are plenty of places for non-default choices. Vim's existence doesn't mean Sublime doesn't have a place.