Hacker News Reader

Comment by shimst3r | Hacker News Reader

While I see the benefit of this approach, I’m often baffled why people want to go either 100 % POSIX builtins or 100 % scripting language.

The biggest benefit of the shell is its clearly defined input and output (and error) interfaces. Most programming languages can read from and write to stdin, stdout, and stderr.

Why not use it and stick to KISS, replacing one cumbersome POSIX utility at a time, suites for the task? Then you don’t need to chain methods using less idiomatic code. But then you wouldn’t need these kind of libraries either.

View on HN

I agree in principle, but mastering the syntactic quirk-fest of bash and other shells is really a bit weird, in that surprises arise at runtime.

maybe that's the compelling use of scripting with a statically typed, thus compile-time at least partially low-hanging-fruit-error-checked, language?

We really need a 'Bash: The Good Parts' book like Doug Crockford did for Javascript. IMHO bash and the shell are in a state that Javascript was ~2005--an old language/tool full of complexities but that can be sharpened and honed down to something beautiful.

IMHO writing procedural style code with lots of if, loops, etc. in the shell can quickly turn into an anti-pattern. Try to stick to simple functions that are chained together in pipelines. The only loop is typically one that processes arguments and that's it.

> We really need a 'Bash: The Good Parts' book like Doug Crockford did for Javascript.

Bash is incredibly less complex than Javascript and there is such a resource: the "Bash guide" [1] and "Bash pitfalls" [2] are both excellent resources that teach you how to use Bash properly.

[1] http://mywiki.wooledge.org/BashGuide

[2] http://mywiki.wooledge.org/BashPitfalls

I have a coworker who uses make for tasks that do not fit comfortably in a few lines of shell script, and it can make for very elegant and readable solutions. Without giving in to the procedural constructs that are so awkward in shell scripting languages.

That opened my mind… 30 years after I started using make. D’oh!

i do that too...folks seem surprised, but it's handy

Bash really just should die already. I really don’t see it being more available than python is, and the fact that basically every 3+ line bash script is logically faulty should be enough of a reason. Add that they are basically unreadable after writing.

> I really don’t see it being more available than python is

Oh, but which version, 2 or 3?

Bash availability may not be guaranteed, but a POSIX shell of some variety is.

People talk about Bash quirks as if Python and Go don't have plenty of quirks that you also find out by trial and error. The difference is, most people hardly ever use Bash. If it were the reverse and people hardly ever used Python or Go or JavaScript, they'd be talking about how quirky those languages are. (They already do, in relation to other languages)

Shellcheck has dramatically increased the ease by which you can write decent scripts before ever running them. But I also have never seen any language that anyone could master without a year or more of constant use.

I think it boils down to the friction of starting and stopping external processes.

For example, you could in your scripting language use `find` to search for files in a folder and do something with them, but why do that when your language of choice almost certainly has globbing capabilities? You could grep a file for a line, but why do that when you can use your language's inbuilt regex system?

At least from the scripting side, the reason I tend to push more towards using the language and less towards using external processes is because most scripting languages can do what those external processes do in one go.

Perhaps it would make more sense if I were better at defining scope :)

Cross-platform deployment is why I switched from script plus utilities to a go binary.

I did manage to make a Windows batch file that replicated the functionality of a linux/mac bash script, but configuring it was no fun for customers on any platform, and then there were the utilities themselves to deploy.

The replacement binary has a very small platform-dependent aspect, and I am not held back by the limits of batch files when trying to achieve feature parity.

It might be doable to deploy a powershell script, but then there's installation work to do on the unix side instead.

Im facing the inverse of this right now. We have some internal tools that are written in go and are triggered from our scm's equivalent of hooks. Unfortunately these are now failing on non Windows platforms (where we primarily develop) because I can't call a windows go binary on Linux or vice versa. So now I'm back to writing python scripts that wrap golang binaries...

I completely agree.

This is the approach that I took with murex. It comes with a stack of builtins for json, jsonlines, yaml, toml, csv, sqlite3, and others. So you have all the power of data types and intelligent management of structured data but also works with regular POSIX CLI commands without any additional boilerplate code when swapping between murex code and coreutils (et al). So one could say I’ve spent a fair amount of time studying this point you’ve raised :)

Is murex open source? A quick search of murex shell presented me with beautiful seashells.

A quick Google for murex cli -sea yields: https://murex.rocks and https://github.com/lmorg/murex, looks like a promising tool

Not to mention the URL in @hnlmorg’s HN profile!

https://github.com/lmorg/murex

(Don't be afraid to self promote!)

One obvious benefit over what's suggested in the article is that you can use it interactively first, with autocomplete and such goodies, and transition smoothly to a script later.

GP has promoted murex a few times on HN recently, which doesn't bother me, but if I were them I'd be sensitive to not wanting to overdo it as well.

Is fish style autosuggestion possible or planned in murex? Thanks!

Let one-liners be one-liners, and bring in Go/etc when it ceases to be a one-liner. But not before.

Reply on news.ycombinator.com