4 ms·

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

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.

hnlmorg 5y ago
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 :)
- cyberge99 5y ago
  Is murex open source? A quick search of murex shell presented me with beautiful seashells.
  - zto 5y ago
    A quick Google for murex cli -sea yields: https://murex.rocks https://murex.rocks and https://github.com/lmorg/murex https://github.com/lmorg/murex, looks like a promising tool
    - darrenf 5y ago
      Not to mention the URL in @hnlmorg’s HN profile!
- klabb3 5y ago
  https://github.com/lmorg/murex 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.
  - freedomben 5y ago
    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.
- arunix 5y ago
  Is fish style autosuggestion possible or planned in murex? Thanks!
jjtheblunt 5y ago
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?
- qbasic_forever 5y ago
  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.
  - b215826 5y ago
    > 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 http://mywiki.wooledge.org/BashGuide [2] http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls
  - jimbokun 5y ago
    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.
    - tomcam 5y ago
      That opened my mind… 30 years after I started using make. D’oh!
    - 5y ago
cogman10 5y ago
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 :)
pphysch 5y ago
Let one-liners be one-liners, and bring in Go/etc when it ceases to be a one-liner. But not before.
unfocussed_mike 5y ago
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.
- maccard 5y ago
  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...

hnlmorg 5y ago

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 :)

cyberge99 5y ago
Is murex open source? A quick search of murex shell presented me with beautiful seashells.
- zto 5y ago
  A quick Google for murex cli -sea yields: https://murex.rocks https://murex.rocks and https://github.com/lmorg/murex https://github.com/lmorg/murex, looks like a promising tool
  - darrenf 5y ago
    Not to mention the URL in @hnlmorg’s HN profile!
klabb3 5y ago
https://github.com/lmorg/murex 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.
- freedomben 5y ago
  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.
arunix 5y ago
Is fish style autosuggestion possible or planned in murex? Thanks!

jjtheblunt 5y ago

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?

qbasic_forever 5y ago
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.
- b215826 5y ago
  > 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 http://mywiki.wooledge.org/BashGuide [2] http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls
- jimbokun 5y ago
  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.
  - tomcam 5y ago
    That opened my mind… 30 years after I started using make. D’oh!
  - 5y ago

cogman10 5y ago

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 :)

pphysch 5y ago

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

unfocussed_mike 5y ago

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.

maccard 5y ago
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...