Reading the Capture section, it seems if you want to do a command substitution you’ll always capture both stdout and stderr. Which is a showstopper if stderr is used to print progress, interactive prompts, etc.
Hush, a modern shell scripting language
71–80 of 192 posts
Re: Hush, a modern shell scripting language
#72PowerShell is really good. Like, amazingly good.
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.
Re: Hush, a modern shell scripting language
#73What is a valid reason to add a "null" into a modern language? I thought it's a commonly established truth that it has been a mistake
Re: Hush, a modern shell scripting language
#74What is a valid reason to add a "null" into a modern language? I thought it's a commonly established truth that it has been a mistake
This is a dynamically typed language. Null makes sense there.
It also makes sense in a statically typed language with union types, think `string | undefined` in TypeScript. The extra layer added by Some/None is not fundamentally necessary for safety.
Re: Hush, a modern shell scripting language
#75Earlier quoted context omitted.
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 suppo…
> The first two lines are pure overhead. 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…
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.
Re: Hush, a modern shell scripting language
#76If this wants to sell itself as a shell scripting language, it should very quickly advertise what is it that makes it superior to say, bash for typical shell scripting tasks.
Shell scripts with bash are painful to the point that if I find myself writing more than around 10 lines of shell, I tend to stop and switch to Perl instead. But Perl hasn't been too popular lately and isn't ideal either, so I'm very much up for something better.
Here's some features I want from a shell scripting language:
* 100% reliable argument passing. That is, when I run `system("git", "clone", $url);` in Perl, I know with exact precision what arguments Git is going to get, and that no matter what weirdness $url contains, it'll be passed down as a single argument. Heck, make that mandatory.
* 100% reliable file iteration. I want to do a "for each file in this directory" in a manner that doesn't ever run into trouble with spaces, newlines or unusual characters.
* No length limits. If I'm processing 10K files, I don't want to run into the problem that the command line is too long.
* Excellent path parsing. Such as filename, basename, canonicalization, finding the file extension and "find the relative path between A and B".
* Good error handling and reporting
* Easy capture of stdout and stderr, at the same time. Either together or individually, as needed.
* Excellent process management. We're in 2022, FFS. We have 128 core CPUs. A modern shell scripting language should make it trivial to do something like: take these 50000 files, and feed them all through imagemagick, using every core available, while being able to report progress, record each failure, and abort the entire thing if needed.
* Excellent error reporting. I don't want things failing with "Command failed, aborted". I want things to fail with "Command 'git checkout https://....' exited with return code 3, and here's for good measure the stdout and stderr even if I redirected them somewhere".
* Give me helpers for common situations. Eg, "Recurse through this directory, while ignoring .git and vim backup files". Read this file into an array, splitting by newline, in a single line of code. It's tiresome to implement that kind of thing in every script I write. At the very least it should be simple and comfortable.
That's the kind of thing I care about for shell scripting. A better syntax is nice, but actually getting stuff done without having to work around gotchas and issues is what I'm looking for.
Re: Hush, a modern shell scripting language
#77For me the reason for pursuing scripting languages over sh is because of multi-platform projects that I've had to support in the past where every little shell nuance, every tool nuance has introduced bugs in one platform or the other. It's too easy to create problems and too time consuming to find them. You need special resources to test/debug and so on.
The installer and the build system were the areas that caused the most pain - e.g. trying to debug build errors because some system has a slightly different version of some tool like sed.....
I felt that including a portable language in the installer would mostly eliminate this problem since one could eliminate the use of these hard-to-standardise tools. I don't care about POSIX standard command-line tools - IMO they are an example of how to encourage the proliferation of variants by blocking progress.
Some installers include Java which is a nightmare - big and not helpful. IIRC InstallJammer included TCL which was not bad.
I think GNU make (even though it is old school it's very commonly used) needs a shell that can work on windows AND UNIX operating systems equally and is fast to load up (i.e. not cygwin). The problem with e.g. using python as the make shell is that it has a bigger startup time than e.g. bash which is ok for most usecases but does matter in a build.
So I sort of like the idea of hush but I need to find out how portable it is and what's the startup time.
Re: Hush, a modern shell scripting language
#78For Lisp/Scheme fans, take a look at Rash as well https://rash-lang.org/
This looks really cool! Is it your daily driver?
Re: Hush, a modern shell scripting language
#79PowerShell is really good. Like, amazingly good.
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…
It blows my mind too.
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.
Re: Hush, a modern shell scripting language
#80If this wants to sell itself as a shell scripting language, it should very quickly advertise what is it that makes it superior to say, bash for typical shell scripting tasks. Shell scripts with bash are painful to the point that if I find myself writing more than around 10 lines of shell, I tend to stop and switch to Perl instead. But Perl hasn't been too popular lately and isn't ideal either, so I'm very much up for…
Oh my god, your first point. I had to pass arbitrary arguments through a couple layers of shell and I couldn't do it. Gave up and rewrote it all in Python, even though it's annoying in other ways, and I'm decent at shell scripting. It's a nightmare.