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

121–130 of 192 posts

Re: Hush, a modern shell scripting language

#121

Post by majkinetor »

paskozdilar wrote: post #118
dale_glass wrote: post #101

Earlier quoted context omitted.

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…

> Powershell improves on Unix commands being based on text streams, and makes them based on objects I assume this means that PowerShell is deeply integrated with the .NET ecosystem? I don't like .NET very much, so that's a downside for me. One of the reasons I use Bash is the decades-old ecosystem of various utilities people have written. Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-st…

> I don't like .NET very much, so that's a downside for me.

LOL. So arbitrary... do you like java vm or python?

> Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-stream processing pipelines like Bash, or is it .NET objects only?

Sure. Even better, it can convert wall of text into array of lines on the fly :)

You should forget about parsing text in shell though. Because it sux and we know better now. Parsing text in pwsh is once-a-year thing.

Re: Hush, a modern shell scripting language

#123

Post by renox »

> 1 == 1.0, # false, int and float are always distinct.

Uh?? If int and floats are always distinct then you should disallow int and float comparison (panic) instead of allowing it and always returning false!

That said it is probably a good idea to disable comparison for floats algother: maybe == would be int&bool&string only but for floats there would be ~= (approximate relative equality) but of course the issue is that not everybody will agree on the correct percentage tolerated for equality: 0.1%, less?

And still in https://hush-shell.github.io/intro/basic-constructs.html , the example ( # this would cause a panic: # let x = array[5] ) is probably wrong now: 5 is a valid index in the array..

Re: Hush, a modern shell scripting language

#124

Post by [deleted] »

majkinetor wrote: post #121
paskozdilar wrote: post #118

Earlier quoted context omitted.

> Powershell improves on Unix commands being based on text streams, and makes them based on objects I assume this means that PowerShell is deeply integrated with the .NET ecosystem? I don't like .NET very much, so that's a downside for me. One of the reasons I use Bash is the decades-old ecosystem of various utilities people have written. Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-st…

> I don't like .NET very much, so that's a downside for me. LOL. So arbitrary... do you like java vm or python? > Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-stream processing pipelines like Bash, or is it .NET objects only? Sure. Even better, it can convert wall of text into array of lines on the fly :) You should forget about parsing text in shell though. Because it sux and we know…

[deleted]

Re: Hush, a modern shell scripting language

#125

Post by paskozdilar »

Izkata wrote: post #109
paskozdilar wrote: post #94

Earlier quoted context omitted.

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…

Nice, I didn't know about that. Thanks for sharing!

Re: Hush, a modern shell scripting language

#126

Post by paskozdilar »

majkinetor wrote: post #121
paskozdilar wrote: post #118

Earlier quoted context omitted.

> Powershell improves on Unix commands being based on text streams, and makes them based on objects I assume this means that PowerShell is deeply integrated with the .NET ecosystem? I don't like .NET very much, so that's a downside for me. One of the reasons I use Bash is the decades-old ecosystem of various utilities people have written. Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-st…

> I don't like .NET very much, so that's a downside for me. LOL. So arbitrary... do you like java vm or python? > Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-stream processing pipelines like Bash, or is it .NET objects only? Sure. Even better, it can convert wall of text into array of lines on the fly :) You should forget about parsing text in shell though. Because it sux and we know…

Yeah? Well, you know, that's just, like, uh, your opinion, man.

Re: Hush, a modern shell scripting language

#127

Post by dahart »

sverhagen wrote: post #53
dahfizz wrote: post #13

Earlier quoted context omitted.

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.

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

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.

Re: Hush, a modern shell scripting language

#128

Post by kerblang »

dahfizz wrote: post #13
chaorace wrote: post #4

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…

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.

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

Re: Hush, a modern shell scripting language

#129

Post by klibertp »

hnlmorg wrote: post #98
stormbrew wrote: post #69

> Traditional shell scripting languages are notoriously limited I feel like people looking to replace shells and shell languages need to really think deep and hard about this if it's something they believe. Shell scripts are really anything but limited, and in fact most replacements are more limited (either by design or by accident), often imposing awkward control flow on you or making things that should be simple mu…

I couldn't agree with this statement more. As someone who has developed their own shell over the last decade I've been keeping a close eye on what other people have been building too. So often I see people writing shells that are inspired by programming languages so their syntax looks amazing in documents. But they always strike me as being hugely tedious for repetitive and often quite dull tasks. The kind of 5 minut…

> We need better shells.

Obviously. I don't think this is the most important missing part, though. I would say it differently: we need way, way better REPLs.

IPython is an example of a REPL that's passable as a shell. It can run in a terminal and has a GUI version based on Qt, which allows displaying images inline. You can drop into a "real" shell with a single `!` character (you get pipes, output capture, and (Python) variable interpolation), and it even has some syntactic shortcuts for the parts where Python's own syntax is irritatingly verbose. If you like Python, then IPython can be your day-to-day shell right now. You just need to remember not to start ncurses programs from within qtconsole (works ok in terminal). I used it for a few years when I was forced to work on Windows. Before my time, I heard it was popular to use tclsh as a shell on Windows.

I think that it proves that almost any language can be used as a shell, as long as its REPL is as rich and featureful enough. Since you can use Python as a shell, which as a language is not exactly the epitome of terseness and expressiveness, you could definitely make do with almost any other interpreted language, too. The problem is that very, very few languages have REPLs that are anywhere near IPython. It's so bad sometimes that you're advised to use `rlwrap` just to get basic line editing and history!

I've been working on a new shell based on GNU Smalltalk[1]. I really like the syntax - or lack of thereof - and being able to dump an image (ie. full state of the VM) at any time (and load it later) seemed like a good idea. The only change I needed was to add the `|>` pseudo-operator, which puts what's on the left into parens. Being able to introspect the running session was my primary motivation: I wanted to make the shell and the whole environment as discoverable as possible. I wrote some code for that and then realized that the default REPL uses readline from C, so it freezes the entire VM when waiting for input (including all background threads). My workaround was to set up a socket server and connect to it via rlwrapped telnet...

Anyway, I think "do we need a new shell" is the wrong question; instead, we should focus on improving REPLs to the point where a separate shell becomes unnecessary.

[1] https://github.com/piotrklibert/stshell

Re: Hush, a modern shell scripting language

#130

Post by 16bytes »

charles_f wrote: post #50

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 And then keep pictures for page 6.

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?

Post reply on HN