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

171–180 of 192 posts

Re: Hush, a modern shell scripting language

#171

Post by blacksqr »

t43562 wrote: post #77

For 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 t…

You might love autosetup, a Tcl-based autoconf tool chain replacement.

Not just Tcl-based, but designed to work with a simple Tcl subset shell called Jim, which compiles from one source code file. So you can bootstrap your project in a mostly-platform-independent way with a standard C compiler as the only prerequisite.

https://msteveb.github.io/autosetup/

Re: Hush, a modern shell scripting language

#172

Post by chasil »

nine_k wrote: post #169
chasil wrote: post #166

Earlier quoted context omitted.

The requirement, as set by POSIX, was to run the shell in Xenix on an 80286, which only supported a 64k text segment. There are few tools that can meet this requirement, and the limit is as relevant now as the day it was first published. Any aspiring shell must run within this limit to fully pervade POSIX. Ignoring this requirement greatly reduces applicable scope. Korn '88 could do it, but the code was not pretty. A…

> the limit is as relevant now as the day it was first published Can't say if it's ironic or serious.

Guess.

"Indeed, in 2014 -- 42 years after Intel’s rollout of the 8008 -- the godfather of microcontrollers accounted for 39.7% of overall sales revenues in the MCU market... That’s more than 32-bit devices (38.5%) and 16-bitters (21.8%), which grabbed most of the headlines."

https://www.designnews.com/electronics-test/why-8-bit-microc...

Re: Hush, a modern shell scripting language

#173

Post by jiggawatts »

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?

If I wasn’t on mobile I would dig up some excellent articles on the topic, so please excuse the too brief summary:

The core concept of the UNIX philosophy is that each tool should do one thing, and then you can compose them.

In practice this doesn’t work because of the physical constraints of the small machines used back in the day when UNIX was developed.

The original shell concept used plain byte or char streams, which are too primitive.

The end result is that every tool has to do parsing and serialisation. Worse, they pretty print by default, losing the structure and making subsequent steps fragile.

So for example, Visual Studio crashes if your Git version is “wrong” because it’s trying and failing to parse the output text.

Similarly if you ask UNIX people to solve simple problems like “stop all processes run by ‘Ash’”, they’ll reach for grep and accidentally stop every bash process also.

In PowerShell the commands don’t parse. They don’t serialise. They don’t pretty print. They don’t sort, filter, group, export, or import.

Instead there are dedicated, single-purpose commands for those functions that compose elegantly.

This is the UNIX philosophy, and PowerShell does it more than bash.

Re: Hush, a modern shell scripting language

#174

Post by majkinetor »

jiggawatts wrote: post #173
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?

If I wasn’t on mobile I would dig up some excellent articles on the topic, so please excuse the too brief summary: The core concept of the UNIX philosophy is that each tool should do one thing, and then you can compose them. In practice this doesn’t work because of the physical constraints of the small machines used back in the day when UNIX was developed. The original shell concept used plain byte or char streams, w…

Amen to that!

Re: Hush, a modern shell scripting language

#175

Post by dahart »

sverhagen wrote: post #170
dahart wrote: post #127

Earlier quoted context omitted.

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…

Sure, but the conversation had already evolved to "scripting languages" as opposed to command lines.

Where did that happen? The comment you replied to emphasized “system level stuff”. The comment before that emphasized “shells”.

Re: Hush, a modern shell scripting language

#176

Post by patrck »

gorgoiler wrote: post #38
patrck wrote: post #35

Earlier quoted context omitted.

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.

Definitely. Debugging loves `duck-talking`.

Didn't mean to come across as REPLs consisted only items in the set of { programming , shells }.

Re: Hush, a modern shell scripting language

#177

Post by paskozdilar »

majkinetor wrote: post #138
paskozdilar wrote: post #126

Earlier quoted context omitted.

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

Yours is not even opinion. You need to put some logic behind it man :) As for me, I will keep my Decade-And-More-Old-And-Still-Shiny-Shell-With-Objects-And-Stuff to myself :)

I don't think I need to "put some logic behind" not liking .NET, same as I dont need to put some logic behind not liking Java. It just sux and we know better now :)

Also good luck with your emacs pinky. :) :) :) :D :D :D :) :) :^)

Re: Hush, a modern shell scripting language

#178

Post by pmontra »

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…

Agreed. The problem with bash & Co. (if that's a problem) is that it's the result of a process of adding clunk after clunk of stuff in the only few ways that wouldn't break the language. So we have things like i=$(( i + 1 )) and [ $? -eq 0 ] and [ "$?" = "0" ]. Add to it the differences between "$@" "$" and $ and a number of similar things. Apart from that it's very good at what it does. Hush seems to start from a normal language like Python or Ruby and add the pipelining / redirection stuff which is usually very verbose and error prone to do in those kind of languages.

Re: Hush, a modern shell scripting language

#179

Post by oblio »

chasil wrote: post #172
nine_k wrote: post #169

Earlier quoted context omitted.

> the limit is as relevant now as the day it was first published Can't say if it's ironic or serious.

Guess. "Indeed, in 2014 -- 42 years after Intel’s rollout of the 8008 -- the godfather of microcontrollers accounted for 39.7% of overall sales revenues in the MCU market... That’s more than 32-bit devices (38.5%) and 16-bitters (21.8%), which grabbed most of the headlines." https://www.designnews.com/electronics-test/why-8-bit-microc...

1. How many people connect to shells on those microcontrollers?

2. How many people actually develop for those microcontrollers?

The numbers of devices doesn't matter. Exaggerating a bit, if you have 100 folks developing for 50 billion devices and 10 million developing for 10 billion devices, we will always optimize for the development experience of the 10 million developers, not the 100.

I'm quite convinced (based on job board statistics) that embedded developers are a minority.

And that's not even counting sysadmins, devops, testers, etc, in which case the community outside of embedded completely dwarfs the embedded community.

Re: Hush, a modern shell scripting language

#180

Post by oblio »

usrbinbash wrote: post #87
majkinetor wrote: post #79

Earlier quoted context omitted.

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

> I have never seen good argument against PowerShell As long as I have to type `Get-Content` instead of `cat`, that's argument enough for me.

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.

Post reply on HN