Is 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 that as a plus.
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.
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)
…you get hit by a barrel. Three hits and you turn it into a Python module with a __main__.py or an if __name__ == “__main__” at the bottom.
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.)
My experience is different. For me, Python has a good balance of readability, access to system functions and consistent, predictable interfaces. I'm not saying you're wrong, just that "it depends". I'm pretty adequate at writing BASH, but it's not my "daily driver" programming language, so I have to still try things out, google a lot of things that aren't easily obvious, and excessive trial and error. But as a Java programmer I also know that Java, with all of its abstractions and verbosity, is a complete non-starter for shell scripting. For me, Python has often been a helpful compromise.
Part of this may also be that I've never learned to do a great job at organizing a BASH shell "project". So, those often get unwieldy maintenance nightmares. At plenty of time me and my peers have agreed: when your BASH script exceeds [some low number of] lines, find another language.
Again, it matters a lot what your team's culture and comforts are. If that's BASH for you, then r.e.s.p.e.c.t.
You’re comparing Python and Bash as programming languages, not as shells. Python’s great as a programming language, but it’s a terrible shell. Likewise, Bash is a terrible programming language, but as a shell is pretty good and is probably the most used shell. The point parent was making is that it’s far more difficult in Python to run a process, capture the output, and grep something from it, than it is in Bash. In Bash this is a one liner with extremely minimal syntax. In Python, this is a big multi-line affair invoking several modules and multiple functions. Python isn’t a shell purely because you can’t execute an executable file by typing the bare name of the file. Python also doesn’t pass the cut & paste test - you normally can’t paste snippets from somewhere into a Python repl due to indentation issues, this alone makes it very difficult to use as an interactive shell. And Python is not meant to be an interactive shell, so there isn’t much of a problem.
It might take a few more lines of code to do stuff in a real programming language like Python (I would recommend Deno actually) but at least there's a decent chance it will actually work reliably.
> then seamlessly come back up to a more fully featured language to deal with that data
That's the thing - I don't see how you can do that. The command blocks return nil or error, but not the output, so that you'd have to dump that to a temporary file, scrape the file separately, remember to delete it, and so on. I can make it work, but it doesn't live up to the idea of seamlessness.
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.
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 first two lines are pure overhead.
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}”.
In 200 bytes half of which is overhead. That's not a great start.
> The last line is the equivalent of a shell script one liner
It's slower and requires much much more typing, and anything I want to add isn't going to go in the right place. It has a gross hack to support "tmux", and produces other spurious output (bugs). I don't want my X sessions or other ptys; I have reverse DNS disabled, and I really just want IP addresses.
This is what I would write in shell:
last -a|sed -e 's/.* \([0-9a-f]*[:.][0-9a-f.:]*\)$/\1/;t;d'|sort -u
> now has all the advantages of a language that supports “\N{clown face}”.
This is a joke right? I have twenty cores, this is going to use three. Python is going to use one. 30% less typing, less bugs, faster. Those things are important. A fucking emoji is not.
for those of us with not as much grey in our beards (+1 this response if you get the joke) the python example is a ton more readable to me. Now that probably doesn't matter if the utility is only for you. I've a number of helper programs/scripts/etc that I use that I wrote and are only for my consumption.
Re the paralell stuff and python it's easy to import multiprocessing and take advantage of all cores. I think where python wins is how easy it is to handle errors and organize things as it's a full fat programming language vs a shell scripting language like Bash + the gnu userland.
> the python example is a ton more readable to me.
The python example is also wrong, as in it produces the wrong output: Maybe if you are only worried about your own consumption you can ignore all those poor souls running literally any other application besides ssh and tmux, but at some point you're going to have to stop admiring how "readable" it is and fix it, and then what?
I don't buy that conservative coder mentality of keeping the code clean and readable, because one drop of shit is going to be impossible to remove later. In fact, I think that's bananas. Get correct first, then improve.
> Re the paralell stuff and python it's easy to import multiprocessing and take advantage of all cores
You jest.
> I think where python wins is how easy it is to handle errors
Pray tell what errors do you think we need to handle?
Your shell thing is honestly fine. The emoji thing was a joke, sorry that wasn’t clear.
The thing is with 1 IP lookup in N addresses a grep is also fine, but with M IP lookups the set is O(1) instead of O(N) and that makes a difference.
It’s not just theoretical. Bash slowness adds up fast and you will need to upgrade to a real language anyway.
Example: IPv6 addresses need to be truncated to /64 but last prints them with 0 truncation. Good luck doing that in bash. You’ll need a fully fledged IPv6 address parser, if it’s code that has to survive.
You make a fine point, honestly, about what you can get away with in shell scripting. The bigger picture is that literally nothing ever survives the sticky fingers if many engineers over time if it is a shell script. It gets worse and worse until it is ported, at which point it begins a new life as maintainable code.
> Unholy one liners are not limited to shell scripting
You’re mostly proving the parent’s point here. Yours isn’t a one liner, and even in Bash people don’t write multi-line for loops in one line. I don’t know what you mean about the first two lines being overhead; this doesn’t work without them, and you have magical options “shell” and “text” in there that matter. Your script doesn’t pass the result to another process, so you need another line. This also splits output on spaces, it should be more generic. Doing that involves another module (regex), another function call (or more likely several), and several more lines.
Compared to “last -a | grep tmux | process”, your script is much closer on a log scale to 30 lines than 1, even if the parent’s 30 is a little exaggerated, and even if we use the 5 lines you showed and not the ~10-12 lines it really would be.
I don't have exact rules, but if it's (1) quick, (2) simple to read/write in shell, (3) separate from my app's business logic, then I'll use a shell script.
For example, to take a line off of the end of a file, sed is pretty easy:
sed -i '' -e '$ d' file.txt
After a few pipes, I will reach for Python. Regarding line count, after a `if __name__ == '__main__':` block and some helpful docstrings, it ends up being about thirty lines or so. "\N{man shrugging}"
Check out marcel (https://marceltheshell.org). Marcel is a shell that allows the use of Python functions, and pipes Python values between commands. E.g. remove the files/directories listed in victims.txt (one per line):
read victims.txt | args [f: rm -rf (f)]
Parens delimit Python expressions, so (f) just returns the value of f, one of the values read from victims.txt.
Marcel also provides a Python module so that Python can be used for scripting much more conveniently than in straight Python (i.e. without the marcel module). E.g., print the names of recently changed files in the current directory:
import os
from marcel.api import *
for file in (ls(os.getcwd(), file=True, recursive=True) |
select(lambda f: now() - f.mtime < days(1))):
print(file)
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.
This 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.
Really cool concept. I like the idea of scripting in a "safe" language and then dropping into a command block to do all the system level stuff. It's the best of bash and python, in a way.
I'm not sure when I would use something like this. The verbosity definitely means I wouldn't use it as my actual shell, and I don't think that is the intention. Maybe something like a big service / orchestration script where I need to do all sorts of file manipulation, command processing, etc but there's enough logic and complexity to make it annoying to do in bash.
The 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.
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.
> 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).
Why do we need a one true shell that implements the standard? Am I misunderstanding you…? The whole point of a standard is that everyone implements it so the different implementations don’t matter (and everyone does implement it, in the case of POSIX shell, minus a couple things like [ -t ] and some bash defaults).
Given developers testing against shells that implement the spec, and a solid spec, and a variety of implementations that correctly implement that spec then I'm in full agreement with you. However, the moment you add caveats to that description you have, well… caveats to that description.
The situation - as I see it - is that we have a spec, and we have systems that ship a /bin/sh that implements something like it. If people are targetting their system's /bin/sh, then they're writing scripts for their /bin/sh implementation not posix compliant shells. For example, my install uses dash which has features beyond the posix spec which I have to eschew to produce portable scripts.
As a sibling comment points out shellcheck will point out a lot problems, but it requires people choosing to use it. You only have to dive around /usr/bin for a little while to see its usage isn't universal ;)
Of course, if the differences in implementation don't affect your usecase then it simply doesn't matter.
It wasn't that long ago that a fresh Unix install of any flavor didn't come with Perl, Python, zsh, or other common shell or scripting languages. And there's already a trend away from installing those by default. Since adding them now takes mere seconds, the barrier is low.
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.
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.
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.
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.
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".
I'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.
The reality is that blame shaming devs for not learning something isn't effective. No matter your personal beliefs, nobody is getting fired for not knowing the intricacies of sed or bash or awk. The only options are keeping archaic artifacts around and have the elders maintain it, or improve it for everyone. I have tremendous respect for our unix/posix legacy but at the same time they didn't get everything right. How could they?
That said, it's harder to build consensus today. Currently people are replacing shell scripts with all kinds of stuff, and that's not good either. We need something good enough and ubiquitous, imo.
As you can probably guess from my username, I am among the last people who would disagree on the usefulness of common shell utils, and the benefit of knowing them.
But I still hold that one should rewrite into a proper programming language, as soon as a shell script becomes too large, and that point is usually around the 100 LOC mark. Yes, I can do amazing things just with sh/bash and the coreutils. But a small Go program or python script, is just alot more readable, at least imho, because they impose STRUCTURE, which the shell lacks on purpose: It's a CLI first, and a programming language second.
I can read through several hundred lines of Go in one sitting. When asked with analyzing some old bash script, and `wc -l` tells me something along the lines of 400+, I grab the coffee machine and bring it to my desk.
This looks neat. The command blocks are an interesting solution to the question of how to impose more structure on things without imposing a lot of additional syntax where it isn't wanted.
Note to author: the part with actual shell examples is buried too deep, I didn't think it was capable of actual shell things (seemed more like a scripting language) until I came across the 'Shell Capabilities' chapter. Seems like an obvious title but I completely glossed over it while perusing until I did a keyword search for 'redirection', and I imagine many people will too.
Consider putting everything on a single page like oil shell does [http://www.oilshell.org/release/latest/doc/oil-language-tour...], so that simply scrolling down will show the shell examples without having to manually click click click the next button.
I agree. As a language which intends to replace shell scripts, I would show first that the syntax is pretty much the same in Hush. I would put this page first https://hush-shell.github.io/cmd/index.html
To add to this, an example using pipes would be great too. I assume it's done the normal Bash way within command blocks. But I have no idea whether it's supported, after all the point is to use a different, more maintainable language.
But otherwise I think it's great, it has all the basics I'd expect from a modern language and still seems simple enough for quick scripts. I'll try it alone for the better syntax and the imho neat idea to return stdout & stderr separately in a dict.
This seems worth a try; some interesting design choices here!
Definitely put the shell scripting examples up front if you want to call it a shell scripting language. I had to click through ten pages before finding out how to execute a command.
I wonder how usable it would be as an interactive shell with some conveniences. For example, the prompt could pre-type a "{ }" for you and put the cursor between them, so you can immediately enter commands, or decide to backspace over the "{" if you want to write more complex expressions.
I wonder if the name of this language is a reference to Goodnight Moon. The language is inspired by Lua, and one of the occupants of the room in Goodnight Moon is
This looks really cool! I think I found a few errors in the docs:
1. On https://hush-shell.github.io/intro/basic-constructs.html you say that `let x = array[5]` should panic, but the array has enough items. Perhaps you wrote that, then added more items to the array and forgot to change it?
Wouldn't the value of the fifth index be executed there, which is false and would hence fail?
Not sure either though
> safe_div_mod and sometimes safe_division
Aren't those different things? Save division wouldn't use mod by default, right?
The function for save division is missing though, but it might just be a built-in
I'll make the mandatory hn comment since I have not seen it yet. A website introducing a new language should show said language on the first page. It's like introducing a car by saying
- safe
- can ride on 4 wheels
- 2 car seats included
- highway compatible
Yes, this is the first thing that struck me. I don't know why people invest so much time inventing new languages and then fail at the last mile.
If the front page of a new lang site doesn't have language examples showing not just hello world but core differentiating use-cases, why should I bother?
First, this is a pretty nice language, which achieves much with very few, very general constructs. It's distinctly higher level than Bash, while using much fewer concepts. Here I applause.
Its shell capabilities are also minimalist, but should be ergonomic enough to avoid nearly all of the ceremony that Python's `popen()` usually requires.
OTOH I'm certain that prefixing all standard functions with `std` will get tiresome soon; I'd go with prefixing them with a `@` or `:` or another short special-case glyph. Also, the fact that `1 != 1.0` scratches me the wrong way; I'd rather have an integer be equal to a float when the float's fractional part is exactly zero. It does make mathematical sense, and is cheap to implement.
In general, Hush looks like a great language for cases when writing Bash becomes tiresome, and you'd rather reach for Python, Ruby, or Perl, but know that each incurs its own pain when used as a shell language.
Hush would also make a very nice embeddable language, much like Lua on which it is based.
Yes, I find it odd how there's a massive blind spot when it comes to powershell.
Proponents of strong typing everywhere in their programming languages are put off by a shell that dares pipe objects rather than having everything as strings.
I get that Unix has a long tradition and it's hard to change, but powershell is genuinely a modern shell that while uncomfortably verbose without aliases is extremely powerful and feels modern.
Typical verbosity argument is nonsense - people should use aliases. With cross platform shell, first time we have some reason not to use them, to make script more portable. Besides, this verbosity is form of documentation - you really must consider that any bash script comes with invisible man that you usually must check even after years of usage. When you factor that in, even fully verbose PowerShell is joy.
Most of Unix haters seem to bi bigots. I have never seen good argument against PowerShell, apart of that it could be faster for specific use cases.
It seems like the powershell occupies a different niche than sh/bash, etc. It seems more oriented towards manipulating system properties than sorting and grepping. At least, the examples are always about system objects and properties. I wouldn't even know how to integrate normal unix commands in the powershell. Things like this look pretty counter-intuitive: https://devblogs.microsoft.com/commandline/integrate-linux-c...
Sorting and grepping in PowerShell are an every-day trivial thing.
I even use it to as data analytics tool to query moderate amount of data because its just simpler then using anything else (given that ConvertFromTo-XML,Json,Csv etc. are integrated, standard, and don't require bunch of other tools like jq, miler etc.) and I can send it to anybody along with the data to reproduce it or tweak it without having to install anything or learn any new language.
> At least, the examples are always about system objects and properties
Not sure where you get that idea from. Third party examples are not important at all. Majority of usage has nothing to do with the system and its properties.
Not sure why you mentioned that particular method of invoking WSL stuff. If anything, it shows how powerful PowerShell is.
But you can - `cat` is alias to Get-Content (one of).
Better, use `gc` Its shorter then `cat` and almost immediately guessable what it does if you know that aliases in pwsh are also named by the standard. "Cat" on the other hand has almost nothing to do with original intent (I am not concatenating stuff, I am getting a content so, the problem with that name is the same as with "magic numbers" in general programming)
This is first level ignorance. Which is super amusing when coming from folks that otherwise pride themselves on reading long and dry manuals.
PowerShell has aliases. And it comes with a ton of them already defined, they're even listed in the command help page. Get-Content is gc. Heck, Get-Content is even cat.
I think a lot of it boils down to knee-jerk reactions about MS products. When I speak of powershell with colleagues, their first reaction is usually "I couldn't use a non-free shell!"... Even though powershell has been MIT licensed and open source for years now.
As for the verbosity, this isn't a good argument. In my mind there are two "modes" of powershell:
* Day to day shell use, which should definitely use aliases. Nobody wants to type Get-ChildItem to get the list of files in a folder ten times in a row.
* Script writing, which should use the long form of commands. Any good text editor (e.g. vscode does it) should be able to translate aliases into long form commands.
I think they really hit the sweet spot when considering these two aspects. Long scripts are readable without referring to manpages all the time, while day to day shell is quick and easy.
Thanks for the resource. I have been using Clojure and Babashka to bring the feeling of functional programming to the shell but have not been happy so far.
191 comments
[ 2.7 ms ] story [ 243 ms ] threadAre there any other comparable alternatives?
Would Node/TS-Node be a suitable replacement with a few shell helper functions?
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 that as a plus.
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.
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.
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:
…you get hit by a barrel. Three hits and you turn it into a Python module with a __main__.py or an if __name__ == “__main__” at the bottom.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.)
The syntax can be weird, but I still think it really shines in cases like these.
Part of this may also be that I've never learned to do a great job at organizing a BASH shell "project". So, those often get unwieldy maintenance nightmares. At plenty of time me and my peers have agreed: when your BASH script exceeds [some low number of] lines, find another language.
Again, it matters a lot what your team's culture and comforts are. If that's BASH for you, then r.e.s.p.e.c.t.
That's the thing - I don't see how you can do that. The command blocks return nil or error, but not the output, so that you'd have to dump that to a temporary file, scrape the file separately, remember to delete it, and so on. I can make it work, but it doesn't live up to the idea of seamlessness.
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.
Didn't mean to come across as REPLs consisted only items in the set of { programming , shells }.
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}”.
In 200 bytes half of which is overhead. That's not a great start.
> The last line is the equivalent of a shell script one liner
It's slower and requires much much more typing, and anything I want to add isn't going to go in the right place. It has a gross hack to support "tmux", and produces other spurious output (bugs). I don't want my X sessions or other ptys; I have reverse DNS disabled, and I really just want IP addresses.
This is what I would write in shell:
> now has all the advantages of a language that supports “\N{clown face}”.This is a joke right? I have twenty cores, this is going to use three. Python is going to use one. 30% less typing, less bugs, faster. Those things are important. A fucking emoji is not.
Re the paralell stuff and python it's easy to import multiprocessing and take advantage of all cores. I think where python wins is how easy it is to handle errors and organize things as it's a full fat programming language vs a shell scripting language like Bash + the gnu userland.
The python example is also wrong, as in it produces the wrong output: Maybe if you are only worried about your own consumption you can ignore all those poor souls running literally any other application besides ssh and tmux, but at some point you're going to have to stop admiring how "readable" it is and fix it, and then what?
I don't buy that conservative coder mentality of keeping the code clean and readable, because one drop of shit is going to be impossible to remove later. In fact, I think that's bananas. Get correct first, then improve.
> Re the paralell stuff and python it's easy to import multiprocessing and take advantage of all cores
You jest.
> I think where python wins is how easy it is to handle errors
Pray tell what errors do you think we need to handle?
The thing is with 1 IP lookup in N addresses a grep is also fine, but with M IP lookups the set is O(1) instead of O(N) and that makes a difference.
It’s not just theoretical. Bash slowness adds up fast and you will need to upgrade to a real language anyway.
Example: IPv6 addresses need to be truncated to /64 but last prints them with 0 truncation. Good luck doing that in bash. You’ll need a fully fledged IPv6 address parser, if it’s code that has to survive.
You make a fine point, honestly, about what you can get away with in shell scripting. The bigger picture is that literally nothing ever survives the sticky fingers if many engineers over time if it is a shell script. It gets worse and worse until it is ported, at which point it begins a new life as maintainable code.
Bash is a shell. Not a programming language.
You’re mostly proving the parent’s point here. Yours isn’t a one liner, and even in Bash people don’t write multi-line for loops in one line. I don’t know what you mean about the first two lines being overhead; this doesn’t work without them, and you have magical options “shell” and “text” in there that matter. Your script doesn’t pass the result to another process, so you need another line. This also splits output on spaces, it should be more generic. Doing that involves another module (regex), another function call (or more likely several), and several more lines.
Compared to “last -a | grep tmux | process”, your script is much closer on a log scale to 30 lines than 1, even if the parent’s 30 is a little exaggerated, and even if we use the 5 lines you showed and not the ~10-12 lines it really would be.
For example, to take a line off of the end of a file, sed is pretty easy:
After a few pipes, I will reach for Python. Regarding line count, after a `if __name__ == '__main__':` block and some helpful docstrings, it ends up being about thirty lines or so. "\N{man shrugging}"Marcel also provides a Python module so that Python can be used for scripting much more conveniently than in straight Python (i.e. without the marcel module). E.g., print the names of recently changed files in the current directory:
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.
[1] https://github.com/shelljs/shelljs
Exactly like any other shell, and consider how inconvenient and hazardous a transpiler "to a common shell script" would be.
¹ https://hush-shell.github.io/error-handling.html#try-operato...
I'm not sure when I would use something like this. The verbosity definitely means I wouldn't use it as my actual shell, and I don't think that is the intention. Maybe something like a big service / orchestration script where I need to do all sorts of file manipulation, command processing, etc but there's enough logic and complexity to make it annoying to do in bash.
... 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.
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.
Side note: it's also one of (or the ?) most popular Haskell projects out there: https://github.com/koalaman/shellcheck/
Why do we need a one true shell that implements the standard? Am I misunderstanding you…? The whole point of a standard is that everyone implements it so the different implementations don’t matter (and everyone does implement it, in the case of POSIX shell, minus a couple things like [ -t ] and some bash defaults).
The situation - as I see it - is that we have a spec, and we have systems that ship a /bin/sh that implements something like it. If people are targetting their system's /bin/sh, then they're writing scripts for their /bin/sh implementation not posix compliant shells. For example, my install uses dash which has features beyond the posix spec which I have to eschew to produce portable scripts.
As a sibling comment points out shellcheck will point out a lot problems, but it requires people choosing to use it. You only have to dive around /usr/bin for a little while to see its usage isn't universal ;)
Of course, if the differences in implementation don't affect your usecase then it simply doesn't matter.
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.
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://www.oilshell.org/
(note: if - like me - you're not seeing syntax highlighting for hush then enable JS)
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.
FYI, "2>1" and "2 >1" already have very different results in Bourne shell. So I don't think it's an unforgivable sin.
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.
(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-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:
Rather than 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 :)
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.
That said, it's harder to build consensus today. Currently people are replacing shell scripts with all kinds of stuff, and that's not good either. We need something good enough and ubiquitous, imo.
As long as Powershell dies I'm more than happy to agree that any bash script that exceeds 24 lines should probably be written in something newer.
Granted, it's a bigger more complex system, but in many cases it gets stuff done a whole lot better.
But I still hold that one should rewrite into a proper programming language, as soon as a shell script becomes too large, and that point is usually around the 100 LOC mark. Yes, I can do amazing things just with sh/bash and the coreutils. But a small Go program or python script, is just alot more readable, at least imho, because they impose STRUCTURE, which the shell lacks on purpose: It's a CLI first, and a programming language second.
I can read through several hundred lines of Go in one sitting. When asked with analyzing some old bash script, and `wc -l` tells me something along the lines of 400+, I grab the coffee machine and bring it to my desk.
Consider putting everything on a single page like oil shell does [http://www.oilshell.org/release/latest/doc/oil-language-tour...], so that simply scrolling down will show the shell examples without having to manually click click click the next button.
But otherwise I think it's great, it has all the basics I'd expect from a modern language and still seems simple enough for quick scripts. I'll try it alone for the better syntax and the imho neat idea to return stdout & stderr separately in a dict.
Other than that, kudos on a clean syntax.
Looks like you can get something similar in Rust with cmd_lib[1].
[1] https://github.com/rust-shell-script/rust_cmd_lib
Definitely put the shell scripting examples up front if you want to call it a shell scripting language. I had to click through ten pages before finding out how to execute a command.
I wonder how usable it would be as an interactive shell with some conveniences. For example, the prompt could pre-type a "{ }" for you and put the cursor between them, so you can immediately enter commands, or decide to backspace over the "{" if you want to write more complex expressions.
> a quiet old lady who was whispering "hush"
1. On https://hush-shell.github.io/intro/basic-constructs.html you say that `let x = array[5]` should panic, but the array has enough items. Perhaps you wrote that, then added more items to the array and forgot to change it?
2. On https://hush-shell.github.io/error-handling.html you sometimes have safe_div_mod and sometimes safe_division.
Not sure either though
> safe_div_mod and sometimes safe_division
Aren't those different things? Save division wouldn't use mod by default, right? The function for save division is missing though, but it might just be a built-in
- safe - can ride on 4 wheels - 2 car seats included - highway compatible
And then keep pictures for page 6.
If the front page of a new lang site doesn't have language examples showing not just hello world but core differentiating use-cases, why should I bother?
Its shell capabilities are also minimalist, but should be ergonomic enough to avoid nearly all of the ceremony that Python's `popen()` usually requires.
OTOH I'm certain that prefixing all standard functions with `std` will get tiresome soon; I'd go with prefixing them with a `@` or `:` or another short special-case glyph. Also, the fact that `1 != 1.0` scratches me the wrong way; I'd rather have an integer be equal to a float when the float's fractional part is exactly zero. It does make mathematical sense, and is cheap to implement.
In general, Hush looks like a great language for cases when writing Bash becomes tiresome, and you'd rather reach for Python, Ruby, or Perl, but know that each incurs its own pain when used as a shell language.
Hush would also make a very nice embeddable language, much like Lua on which it is based.
I'd really like to see more small languages like this for doing productive things with computers.
import "std" _
Which would allow using functions like print directly.
Proponents of strong typing everywhere in their programming languages are put off by a shell that dares pipe objects rather than having everything as strings.
I get that Unix has a long tradition and it's hard to change, but powershell is genuinely a modern shell that while uncomfortably verbose without aliases is extremely powerful and feels modern.
Typical verbosity argument is nonsense - people should use aliases. With cross platform shell, first time we have some reason not to use them, to make script more portable. Besides, this verbosity is form of documentation - you really must consider that any bash script comes with invisible man that you usually must check even after years of usage. When you factor that in, even fully verbose PowerShell is joy.
Most of Unix haters seem to bi bigots. I have never seen good argument against PowerShell, apart of that it could be faster for specific use cases.
I even use it to as data analytics tool to query moderate amount of data because its just simpler then using anything else (given that ConvertFromTo-XML,Json,Csv etc. are integrated, standard, and don't require bunch of other tools like jq, miler etc.) and I can send it to anybody along with the data to reproduce it or tweak it without having to install anything or learn any new language.
> At least, the examples are always about system objects and properties
Not sure where you get that idea from. Third party examples are not important at all. Majority of usage has nothing to do with the system and its properties.
Not sure why you mentioned that particular method of invoking WSL stuff. If anything, it shows how powerful PowerShell is.
As long as I have to type `Get-Content` instead of `cat`, that's argument enough for me.
Better, use `gc` Its shorter then `cat` and almost immediately guessable what it does if you know that aliases in pwsh are also named by the standard. "Cat" on the other hand has almost nothing to do with original intent (I am not concatenating stuff, I am getting a content so, the problem with that name is the same as with "magic numbers" in general programming)
PowerShell has aliases. And it comes with a ton of them already defined, they're even listed in the command help page. Get-Content is gc. Heck, Get-Content is even cat.
As for the verbosity, this isn't a good argument. In my mind there are two "modes" of powershell:
* Day to day shell use, which should definitely use aliases. Nobody wants to type Get-ChildItem to get the list of files in a folder ten times in a row.
* Script writing, which should use the long form of commands. Any good text editor (e.g. vscode does it) should be able to translate aliases into long form commands.
I think they really hit the sweet spot when considering these two aspects. Long scripts are readable without referring to manpages all the time, while day to day shell is quick and easy.
It can be done with script Expand-Alias[1] that can be used even as CI/CD action so people don't have to think about this.
I prefer to look into longer code in its aliased form..... mhm... we definitely need Unexpanding...
[1]: https://github.com/WormieCorp/Wormies-AU-Helpers/blob/develo...