Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hush, a modern shell scripting language

hush-shell.github.io

Post reply on HN
Print view View original

101–110 of 192 posts

Re: Hush, a modern shell scripting language

#101

Post by dale_glass »

paskozdilar wrote: post #99
jiggawatts wrote: post #93

Earlier quoted context omitted.

Most of those features are in PowerShell, especially version 7. It uses strict ('reliable') argument passing, strong typing, etc.. It has a bazillion independent streams such as "Debug", "Verbose", "Warning", "Error", "Progress", "Output", "Information", etc... It has "foreach -parallel", which is a fun way to make the CPU fan spin up. > "Recurse through this directory, while ignoring .git and vim backup files". Read…

> it's more unix than unix. Would you please elaborate what exactly do you mean by this?

Powershell improves on Unix commands being based on text streams, and makes them based on objects. Which means you're pretty much never extracting stuff with cut and awk, and instead can just get whatever field you want. Eg:

    C:\Windows> Get-AuthenticodeSignature .\explorer.exe
    
        Directory: C:\Windows

    SignerCertificate                         Status                    StatusMessage             Path
    -----------------                         ------                    -------------             ----
    BBD2C438000344F439BFDFE5ABAC3223357CD67F  Valid                     Signature verified.       explorer.exe
    
    C:\Windows> (Get-AuthenticodeSignature .\explorer.exe).SignerCertificate
    
    Thumbprint                                Subject              EnhancedKeyUsageList
    ----------                                -------              --------------------
    BBD2C438000344F439BFDFE5ABAC3223357CD67F  CN=Microsoft Window… {Windows System Component Verification, Code     Signing}

    C:\Windows> (Get-AuthenticodeSignature .\explorer.exe).SignerCertificate.Subject
    CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
    C:\Windows>
This of course works with pipes:

    C:\Windows> Get-ChildItem . | Where-Object { $_.Length -gt 1000000 } | Sort-Object Length

        Directory: C:\Windows

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---           8/11/2021  1:56 AM        1075712 HelpPane.exe
    -a---           1/15/2018 12:40 PM        2856800 RtlExUpd.dll
    -a---           4/25/2022  1:17 PM        5122632 explorer.exe
Isn't that awesome?

One of the nice things about it is that you can add stuff easily. You don't have to worry that every script that parses the output of your command will now break because you added an extra column or added extra functionality.

Re: Hush, a modern shell scripting language

#102

Post by alpaca128 »

SPBS wrote: post #27

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 p…

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.

Re: Hush, a modern shell scripting language

#103

Post by majkinetor »

dale_glass wrote: post #97
jiggawatts wrote: post #93

Earlier quoted context omitted.

Most of those features are in PowerShell, especially version 7. It uses strict ('reliable') argument passing, strong typing, etc.. It has a bazillion independent streams such as "Debug", "Verbose", "Warning", "Error", "Progress", "Output", "Information", etc... It has "foreach -parallel", which is a fun way to make the CPU fan spin up. > "Recurse through this directory, while ignoring .git and vim backup files". Read…

PowerShell is indeed excellent, but there's nothing wrong with it having a bit of competition. Some of it is also less than ideal, but rather less than bash. Issues in powershell I can think of: * It leaks environment variables. Set an env var, and it propagates to the shell from which it was called from! * It can't comfortably import environment from batch files. Working with vcvars is an annoyance. You'd think some…

> It leaks environment variables

It is easy to show that it doesn't:

    $env:x=1
    pwsh
    $env:x=2
    exit
    $env:x
    # shows 1
> It can't comfortably import environment from batch files

Nor bash can import vars from xonsh or whatever. BTW, there are ready available scripts that can do that, CBB to find it.

> Argument passing in Windows is a bloody horror.

What?

> For some reason you can't quote the command itself.

The reason is that its taken as literal string as per semantics of pwsh. Just add dot before it:

    ."C:\Program Files\Git\bin\git.exe" checkout "blah"
In this particular case its because of space in directory name, you could do:

    C:\Progra~1\Git\bin\git.exe checkout "blah"

Re: Hush, a modern shell scripting language

#104

Post by hussainbilal »

hussainbilal wrote: post #81

Why use types? Why not introduce built in parsers to provide validations instead? (i.e. https://github.com/antlr/grammars-v4 ) I think hush is going in the wrong direction. The majority of shell automation is associated with running IaC and container images / orchestration tools. Shell scripts don't need to follow functional programming or OOP. They need to be container-oriented / VM-oriented / image-oriented with a…

Side note: The most straightforward way to incoporate YAML as an elevated text "type" would be to define a new type of pipeable file descriptor on all commands, specifically meant for replacing shell script options / flags. (That way options aren't mixed with stdin)

Edit: and you get typing validation for free by running your yaml options through a yaml schema validator should you choose to do so

Re: Hush, a modern shell scripting language

#105

Post by dale_glass »

majkinetor wrote: post #103
dale_glass wrote: post #97

Earlier quoted context omitted.

PowerShell is indeed excellent, but there's nothing wrong with it having a bit of competition. Some of it is also less than ideal, but rather less than bash. Issues in powershell I can think of: * It leaks environment variables. Set an env var, and it propagates to the shell from which it was called from! * It can't comfortably import environment from batch files. Working with vcvars is an annoyance. You'd think some…

> It leaks environment variables It is easy to show that it doesn't: $env:x=1 pwsh $env:x=2 exit $env:x # shows 1 > It can't comfortably import environment from batch files Nor bash can import vars from xonsh or whatever. BTW, there are ready available scripts that can do that, CBB to find it. > Argument passing in Windows is a bloody horror. What? > For some reason you can't quote the command itself. The reason is t…

> It is easy to show that it doesn't:

Here:

    C:\Users\User\Documents> type .\test.ps1
    $Env:TESTENV = "Hello"
    C:\Users\User\Documents> echo $Env:TESTENV
    C:\Users\User\Documents> .\test.ps1
    C:\Users\User\Documents> echo $Env:TESTENV
    Hello
> What?

https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...

Unlike sane architectures, on Windows, WinMain gets the entire command line as a single string, which means it's each process individually what breaks it into separate arguments.

Re: Hush, a modern shell scripting language

#106

Post by majkinetor »

dale_glass wrote: post #101
paskozdilar wrote: post #99

Earlier quoted context omitted.

> it's more unix than unix. Would you please elaborate what exactly do you mean by this?

Powershell improves on Unix commands being based on text streams, and makes them based on objects. Which means you're pretty much never extracting stuff with cut and awk, and instead can just get whatever field you want. Eg: C:\Windows> Get-AuthenticodeSignature .\explorer.exe Directory: C:\Windows SignerCertificate Status StatusMessage Path ----------------- ------ ------------- ---- BBD2C438000344F439BFDFE5ABAC3223…

Yes it is.

Its not awesome however to write Where-Object and Foreach-Object instead ? and %. It really turns one down. I can understand fanboyism for not using other aliases but those 2 are special and not using them brings the wrong picture about the pwsh.

Re: Hush, a modern shell scripting language

#108

Post by majkinetor »

dale_glass wrote: post #105
majkinetor wrote: post #103

Earlier quoted context omitted.

> It leaks environment variables It is easy to show that it doesn't: $env:x=1 pwsh $env:x=2 exit $env:x # shows 1 > It can't comfortably import environment from batch files Nor bash can import vars from xonsh or whatever. BTW, there are ready available scripts that can do that, CBB to find it. > Argument passing in Windows is a bloody horror. What? > For some reason you can't quote the command itself. The reason is t…

> It is easy to show that it doesn't: Here: C:\Users\User\Documents> type .\test.ps1 $Env:TESTENV = "Hello" C:\Users\User\Documents> echo $Env:TESTENV C:\Users\User\Documents> .\test.ps1 C:\Users\User\Documents> echo $Env:TESTENV Hello > What? https://docs.microsoft.com/en-us/windows/win32/api/winbase/n... Unlike sane architectures, on Windows, WinMain gets the entire command line as a single string, which means it's…

> Here

Well... there is still no leak as there is no new shell spawn. I personally find this behavior way more natural then that of bash. If you don't want it, use variables. I can imagine coming from bash background that this irritates you.

> WinMain gets the entire command line as a single string

This has nothing to do with PowerShell which imposes its own parameter parsing standard so that no individual scripts do that. Also, when we are at it, I guess this "unsane" architecture is more flexible.

Re: Hush, a modern shell scripting language

#109

Post by Izkata »

paskozdilar wrote: post #94
dale_glass wrote: post #76

If 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…

Bash is definitely painful to write - I write shell scripts a lot and I enjoy it (in a masochistic kind of way), and I wholeheartedly agree with most of the criticisms you've written. However, the greatest strength of Bash is its ubiquity - it is available on almost every modern Unix-like environment - and when combined with standard POSIX tools it can provide a-little-less-painful environment for writing reliable sh…

> > 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.

> Do not evaluate arguments directly in shell, use xargs to feed the arguments as standard input. E.g.:

> find ./directory/ -type f | xargs SOME_COMMAND

That'll have problems with characters like spaces, you either have to use the -print0 construct or just stick with find:

  find ./directory/ -type f -exec SOME_COMMAND {} +
The + means "stack up as many results as you can, up to the length limit".

Re: Hush, a modern shell scripting language

#110

Post by dale_glass »

majkinetor wrote: post #108
dale_glass wrote: post #105

Earlier quoted context omitted.

> It is easy to show that it doesn't: Here: C:\Users\User\Documents> type .\test.ps1 $Env:TESTENV = "Hello" C:\Users\User\Documents> echo $Env:TESTENV C:\Users\User\Documents> .\test.ps1 C:\Users\User\Documents> echo $Env:TESTENV Hello > What? https://docs.microsoft.com/en-us/windows/win32/api/winbase/n... Unlike sane architectures, on Windows, WinMain gets the entire command line as a single string, which means it's…

> Here Well... there is still no leak as there is no new shell spawn. I personally find this behavior way more natural then that of bash. If you don't want it, use variables. I can imagine coming from bash background that this irritates you. > WinMain gets the entire command line as a single string This has nothing to do with PowerShell which imposes its own parameter parsing standard so that no individual scripts do…

> Well... there is still no leak as there is no new shell spawn. I personally find this behavior way more natural then that of bash. If you don't want it, use variables. I can imagine coming from bash background that this irritates you.

It's a serious annoyance when you're doing build scripts that do stuff like setting $PATH. Suddenly, stuff breaks randomly depending on what you ran in that particular powershell window before. And there's a length limit too, so if you append to a variable you may find stuff breaks on the 5th invocation of the script.

It also has the annoying "feature" of leaving you in the last directory the script changed to. Most annoying for debugging stuff.

> This has nothing to do with PowerShell which imposes its own parameter parsing standard so that no individual scripts do that.

It's not specifically powershell related, but if you're running on Windows, the Windows design problems apply to everything, including powershell.

> Also, when we are at it, I guess this "unsane" architecture is more flexible.

And more failure prone. It may mean there's no way whatsoever to pass a given path to a program. If a program internally doesn't handle quoting and spaces right, you're screwed.

It can also mean security issues. No matter how well you write your code, a malicious party can give you a filename like "data.txt /deleteeverything ", and the program you're calling may choose to interpret that as an argument, regardless of any quoting you might do.

For that matter, if you want to have the same flexibility on Unix, you can just concatenate all of argv, and then do your own parsing.

Post reply on HN