Some people like to claim that using a pretty esoteric language with lots of weird footguns, lack of basic features and data types, and spawning subprocesses for everything, is somehow keeping it simple.
Weird footguns don't matter if you stick to using shell for control flow, composition, and interpolation, and don't use all the weird things you have to look up every time. It's also very easy to do something in the commandline then just
tail -n 8 $HISTFILE > script.sh
and very little to no editing is needed to make that useful. Shell is not a programming language, it's an interface to the OS, and thinking about it like a programming language is just asking for frustration.
Shell exists to give users a way to run programs. It was the user interface for UNIX, C was the programming interface. Yes, it's technically a programming language by any reasonable definition, but it's not meant to be used in the same way at all so that's not helpful.
I honestly think that's the contrary: it's the laziest choice possible when you want something to work immediately without thinking too much about it. Till like 7 years ago I made literally every script to do "personal" stuff in bash, because I wasn't quite good with any programming language and bash... was just there in my Linux machine, and I was already familiar with it because I was a long time Linux user.
Sometimes you end up committing it on github and people start issuing feature requests, and at the beginning you are just happy that your work fits the need of other people and you don't want to rewrite it from scratch with a better programming language and end up over-scripting it.
That's basically the story of a little program I made years ago. Now I don't log in on github anymore because I'm afraid people is still requesting new features...
It probably started as a helper script and grew from there. The script seems quite focused and doesn't grow, so a rewrite might not be warranted.
It also has no other dependency, which is also good. I have written helper script to run coding agents in a container. And you guessed it, it's in bash. For the reasons I just wrote down. Should it have to grow I would rewrite it, but not currently.
Known system dependency that's (almost) always on the system you're on.
I remember somebody once telling me that they had learned vi because "it was always installed". Well, no, technically, the only editor you can be sure is there is ed. So, you know, learn that. I was surprised that they actually did.
Bash is syntactically not perfect, I agree. However it's a well known, mature, stable environment. LLMs can write it well if you need them to. If it was perfect, we'd never have had Perl, and as a result we'd never have had Ruby, Python and other scripting languages.
But I like it's a tool that doesn't require me to go reach for a package manager and some build tools I don't always have on every system.
I’ve been down this path (it was a script for scraping and extracting text). You write your text utility in bash. It works. Then you need a regex so you use sed.
Then you wonder why it doesn’t work in your other environment. Then you find that GNU vs BSD sed have different syntax.
Better to start with Python once you’re doing more than coordinating well known other tools.
I'd presume it's quite common with NixOS. At least I don't have python linked to my environment. It might be different would I use the REPL, but I do not, so for me python is a program (or script) dependency, not something I need to carry around. It's actually quite common for many setup scripts to fail when python is not installed, but not all of them list python as a dependency either.
To be fair, qualifying bash as on (almost) every system and then poo-pooing vi as being also on (almost) every system seems odd. Had you said sh instead of bash the analogy would have worked better.
Some people like to claim that using a pretty esoteric language with lots of weird footguns, lack of basic features and data types, and spawning subprocesses for everything, is somehow keeping it simple.
I do not understand them.
Weird footguns don't matter if you stick to using shell for control flow, composition, and interpolation, and don't use all the weird things you have to look up every time. It's also very easy to do something in the commandline then just
and very little to no editing is needed to make that useful. Shell is not a programming language, it's an interface to the OS, and thinking about it like a programming language is just asking for frustration.> Shell is not a programming language, it's an interface to the OS, and thinking about it like a programming language is just asking for frustration.
I guess this just isn’t obvious to me. Where do you see the boundary between “interface to the os” and “programming language”?
Shell exists to give users a way to run programs. It was the user interface for UNIX, C was the programming interface. Yes, it's technically a programming language by any reasonable definition, but it's not meant to be used in the same way at all so that's not helpful.
I honestly think that's the contrary: it's the laziest choice possible when you want something to work immediately without thinking too much about it. Till like 7 years ago I made literally every script to do "personal" stuff in bash, because I wasn't quite good with any programming language and bash... was just there in my Linux machine, and I was already familiar with it because I was a long time Linux user. Sometimes you end up committing it on github and people start issuing feature requests, and at the beginning you are just happy that your work fits the need of other people and you don't want to rewrite it from scratch with a better programming language and end up over-scripting it. That's basically the story of a little program I made years ago. Now I don't log in on github anymore because I'm afraid people is still requesting new features...
It probably started as a helper script and grew from there. The script seems quite focused and doesn't grow, so a rewrite might not be warranted.
It also has no other dependency, which is also good. I have written helper script to run coding agents in a container. And you guessed it, it's in bash. For the reasons I just wrote down. Should it have to grow I would rewrite it, but not currently.
Known system dependency that's (almost) always on the system you're on.
I remember somebody once telling me that they had learned vi because "it was always installed". Well, no, technically, the only editor you can be sure is there is ed. So, you know, learn that. I was surprised that they actually did.
Bash is syntactically not perfect, I agree. However it's a well known, mature, stable environment. LLMs can write it well if you need them to. If it was perfect, we'd never have had Perl, and as a result we'd never have had Ruby, Python and other scripting languages.
But I like it's a tool that doesn't require me to go reach for a package manager and some build tools I don't always have on every system.
I’ve been down this path (it was a script for scraping and extracting text). You write your text utility in bash. It works. Then you need a regex so you use sed.
Then you wonder why it doesn’t work in your other environment. Then you find that GNU vs BSD sed have different syntax.
Better to start with Python once you’re doing more than coordinating well known other tools.
> technically... you can be sure there's ed
Unfortunately, ed has been omitted from the default installation of recent debians, at least. I had to install it manually.
WTF?! RIP Debian.
If I wanted an OS without a text editor, I'd use emacs.
Who's updating their blog from a random machine without Python on it, though?
It's not python that's the dependency that needs managing. It's pip and the keystone cops it brings along.
I'd presume it's quite common with NixOS. At least I don't have python linked to my environment. It might be different would I use the REPL, but I do not, so for me python is a program (or script) dependency, not something I need to carry around. It's actually quite common for many setup scripts to fail when python is not installed, but not all of them list python as a dependency either.
To be fair, qualifying bash as on (almost) every system and then poo-pooing vi as being also on (almost) every system seems odd. Had you said sh instead of bash the analogy would have worked better.
Really? I think there's a nice niche for tools like nb that Just Work. Ubiquity is a feature!
https://xwmx.github.io/nb/
...for fun!
Works for me!