Bash/Sh is an objectively awful programming language. You could likely fill an entire book with all of the design fails that is Bash script syntax. Only in a shell script would you ever need eight backslash characters in a row in order to accomplish something...and "space as delimiter" is awful in so many ways.
But especially Sh runs everywhere, so it's good to know. This seems to be the article's point.
Honestly, though? The right answer is to transpile a better language to Sh.
Looking around, there have been several half-hearted, abandoned attempts. But apparently everyone is happy to just fall back on the "accidental syntax" of Bash that really doesn't make sense when compared to ... any other language.
I put up with Bash because there's no better alternative. That doesn't mean we should put up with Bash; just that we must put up with it at least to the point where it can run code written in a real language.
Bash is a user interface. The fact that you can string together words and symbols and make logic happen is basically just back-porting advanced user functionality into an existing interface.
Having said that, Bash is my favorite programming language, because it is so limiting, and simultaneously not limiting, because it wasn't designed to fulfill what A Real Programmer(TM) thinks a programming language should be.
A computer is supposed to serve a human. Not the other way around. But modern programmers, being wildly unimaginative creatures of habit, think the user is supposed to serve the computer. That the more you type, and the more hoops you jump through, the more "clever" you are with the "way" you tell the machine to do something, that this is superior. Never mind that the end result of all this incantation and tom-foolery doesn't actually result in a good outcome half the time. That the user is often unhappy with the result, if they even factor into the programmer's thinking at all. No, the true purpose of programming is to gratify the programmer and make the machine happy, not to make a human's life easier.
Programming is a mistake. It's a half-measure. A stutter in the evolution of digital computing. We weren't meant to program, we were meant to make a synthetic invention that relieved us of our labor. And what do we have to show for spending 1/3 of our life, and decades of work, for it? A metal and plastic box that can do pretty much exactly the same real work as 30 years ago, but with better graphics, because the hardware people gave us better screens.
There's almost nothing that computers do that isn't easier than the pre-computer way.
Look at it from an average user's perspective. They're thinking "Wow, this spreadsheet would have taken hours to do with a calculator and a pencil".
Most users are not programmers. Programming IS the act of making a synthetic invention that relieves us of our labor. It's no different from what a plumber does. If we had to connect pipes in a custom arrangement every time we wanted to do the dishes we would argue all day about the best pipes and threads and tapes.
But we don't. We use premade fixtures and we don't have to think about plumbing.
Those hoops you have to jump through are like the building codes. They make everything consistent. And more importantly, they make things inspectable. There are a million and one ways to plumb or frame a wall or something that would probably be fine. But that would be Real Engineering to do that and show that it's safe.
Wheras the codes are designed to not allow for "interesting" stuff that only an engineer would understand. The programming conventions developed over time based on programmers experience of what works and what doesn't when writing software that is so complicated not one person on earth could ever understand it.
The difference with programmers is they use programs to make programs. There's no user/designer distinction, and they all want to be creative and clever engineers, not just skilled tradespeople, so they don't see the benefits as much. If most of what you do is coding, you might thing nothing has advanced in the last 30 years, because you used text then and now you have more complicated text.
But from a user perspective, we went from drafting tables to CAD. We have Google Keep. We have voice assistants. We have 4k editing for consumers!
Bash pretty much just makes it explicit right in the language that there's no user/coder distinction and kind of keeps that mindset around.
Newer languages are designed to help people make user facing black boxes, and they do a great job of it it seems.
Meh. That part is irrelevant in the extreme to the discussion.
Fact is that people write `.sh` and `.bash` scripts to get things done. They use conditional logic and loops and everything.
Functionally, it's a programming language with a (useful) REPL.
And this discussion is 100% about how bash is as a programming language.
> Having said that, Bash is my favorite programming language, because it is so limiting, and simultaneously not limiting, because it wasn't designed to fulfill what A Real Programmer(TM) thinks a programming language should be.
Umm... Then, yeah, I have to agree with your self-assessment of not being a "real programmer."
Sorry, but it's obviously true.
You're a scripter. I've known and worked with many scripters. They can do a lot of valuable work and contribute in a lot of ways to various projects. But they're not programmers.
Which is fine. Script away.
> But modern programmers, being wildly unimaginative creatures of habit, think the user is supposed to serve the computer.
After admitting you're not a programmer, you then go on to demonstrate that you don't really understand how programming works. Which I guess follows?
That's so far from the reality, that it's Not Even Wrong.
> That the more you type, and the more hoops you jump through, the more "clever" you are with the "way" you tell the machine to do something, that this is superior.
Programming languages are exactly the level of complexity needed to, with the least effort and most reliability, craft the code that, literally, civilization relies on.
It can't be made simpler. The complexity is inherent in the domain.
> Programming is a mistake. It's a half-measure. A stutter in the evolution of digital computing. We weren't meant to program, ...
YOU weren't meant to program. You admitted that above. Don't speak for the rest of us.
Everything significant in software that has been and will be accomplished moving forward will be created by programmers using programming languages. Your rant against programmers and programming is based on a lack of understanding of what programming really is and how programmers really think.
It's not even slightly about being clever. It's about the act of primal creation. We're effectively wizards of the modern world. We don't care at all about making a machine happy; we care about building things that work. That the things embody complexity isn't the goal, but it is a thing of beauty when it all works together elegantly.
Bash is a shell. A bad shell. Korn is a good shell.
It's not meant to be a real language. It's meant to be a shell. Here, let me back that up and reverse it for you.
<JAVA>
public Set<String> listFilesUsingJavaIO(String dir) {
return Stream.of(new File(dir).listFiles())
.filter(file -> !file.isDirectory())
.map(File::getName)
.collect(Collectors.toSet());
} //I'm not handling errors, and this doesn't actually print anything, it just lets me try to.
<SHELL>
ls
Shell is meant to be a common way to do common tasks on commandline, and make a little script if you want to save that and run it again. I can do little things in a shell one-liner quick, that would take a page of python or perl.
I put up with my sports car because there's no better alternative. It doesn't mean I should put up with a sports car for transporting my piano, just that I must put up with it at least to the point where the sports car can transport me to the car that transports a piano.
And it's an objectively awful programming language. Sh is even worse.
Korn isn't installed absolutely everywhere like Sh is. It's not even installed in 1/100 of the locations that Bash is installed. So it being better is irrelevant to the discussion of Bash as a programming language.
Because Bash is so awful, the only real justification for using it as a programming language is that it's already installed. Since Korn isn't already installed, that means you'd need to install it. If you're going to be installing something, there are far better choices.
So your comment doesn't at all contribute to the discussion of alternatives to using Bash as a programming language.
And the verbosity of using Java to list a folder contents is equally irrelevant. No one would argue that Java is better ... for listing directory contents.
If you do want to write a script that calls a bunch of shell commands, or even that operates on folders and files, there are far better languages and tools.
The main use case of a shell is interactive use. There is no reason to invoke a teanspiler when you type a command to be immediately executed. Often its syntax is a bit awkward because in needs to be compact and quick to type.
If you want a better language for complex scripts, use Python, or even Perl, they are now ubiquitous, or bring someting self-contained like Lua or Janet with you.
It would be great to have a different ubiquitous shell language on Unix machines, but it's unrealistic now.
There are two places a new shell language needs to be ubiquitous for success. One is installed on systems, which is pretty easy. With today's connectedness, new software is just an apt install, pacman, or curl | bash away. The other, much harder problem is that the people using the system need to know this new shell language. If I have to debug your shell script using Zsh, Csh, or Fish, I'm not going to be happy about it.
Shell is an interactive, concatenative string language with transparent file system access and binary execution capabilities. It doesn't need to be a general purpose programming language, because it's great at what it does. When I need something lower level, I can write that in low level and integrate into the shell language seamlessly.
>Bash is great, but when it comes to writing more complex scripts, many people prefer a more convenient programming language. JavaScript is a perfect choice, but the Node.js standard library requires additional hassle before using. The zx package provides useful wrappers around child_process, escapes arguments and gives sensible defaults.
> Honestly, though? The right answer is to transpile a better language to Sh.
I like this, but I think it's even better to just escape sh entirely. If you are on a system that supports sh, it almost certainly has a c99 compatible compiler which can be used to install lua(JIT)? or another better scripting language. I wrote a little script idempotently installs lua 5.4 (that I tried to include but HN formatting messed up) and then runs a luascript embedded in a heredoc. The first time I ran it, it took 5.4 seconds to print "Hello, world!" including downloading the lua source code from their website and compiling the whole thing. The second time it took 11ms. I really see no great reason to continue using sh for anything new except for the purpose of installing something else.
- Embedded devices that may or may not have an internet connection
- Government classified networks that aren't allowed to grab ANY random software off of the internet
- Simply not wanting to add another dependency to an operation.
I'm a former Lua fan. I've ... written it off at this point. [1]
Honestly if I were to take the approach you describe, I'd likely instead have the shell script only look at the architecture and then choose one of 2-3 precompiled Go binaries. Talk about simple and fast...and the binaries could be hosted behind a firewall somewhere.
Or maybe I was thinking of it wrong. Just embed the various Go binaries into a tar file embedded right in the shell script[2], and choose the right one based on architecture. Done. :)
Bash and most alternatives are full of footguns. However, they are really convenient to glue together different components, e.g. a data preprocessing system.
Personally, the way I avoid footguns is to use a functional style. Filter instead of conditions and map instead of loops. GNU Parallel makes this straightforward, including distributed commands across machines! Aside, it is easy to emulate relational algebra with grep, sed, and awk.
There are lots of better alternatives in almost all cases, just not super weird niche stuff.
A lot of things that one would use bash for involve servers, and there's Ansible for that, no need to use bash directly most of the time. If it were up to me, distros would include Ansible out of the box.
IMHO doing anything at all that's not programmatically repeatable isn't the best practice, so it's not like I want to be logging onto something and writing a quick script in Nano.
Outside of servers.... nobody uses Linux except embedded systems and FOSS enthusiasts. Nobody is paying me to do FOSS work, so I can just pretend that Pythonless systems don't exist.
Python does have some version compatibility issues, but for the most part it's stable, and at least it will crash with a traceback not a cryptic error code because you used some utility that had some nonstandard syntax for the flags.
On embedded, most of what you're doing is probably simple enough that if you do need to use sh you won't absolutely scream.
If running everywhere is actually a constraint (likely it’s not) and transpiling is a consideration, you could use Golang, that statically links and produces standalone binaries that run more or less anywhere. Though if you have a CD pipeline to transpile and deploy such, you likely have enough control over your environment already to have a less constrained choice to begin with.
Normally I’m not very fond of Gos verbosity, especially compared to bash, but i take anything over bash, it is just so filled with footguns, every single line has to be super carefully scrutinized. Note that I say this as someone actually quite good at it, not because I don’t understand it. In fact the more you learn, the more scared you get.
Yes, yet 'set -x' in Bash is more useful than in any other languages I know.
Because Bash is used to call utils so you see the partial trace of your script that you want to see, not the inside of the tools/utils that you don't want to see.
In contrast in gdb for C++ you 'step' inside the STL implementation that most of the time you don't care about..
I'm not very knowledgeable in this area as I don't do much shell scripting, but isn't zsh supposed to be some kind of enhancement over bash? Does it suffer from the same issues?
Regardless, the idea of a language that transpiles to bash is kinda interesting.
ZSH is basically the same thing. For all intents and purposes it is basically the same thing. The best attempt I’ve seen to truly make a better shell is Nushell.
Shell is an objectively _difficult_ programming language. But difficult != awful. Pointy and ready to bite you if you make a tiny mistake? Yes. Ubiquitous and not going anywhere? Also yes.
But given that *nix tooling output defaults to text, it's hard to argue against a universal language that talks to all of it.
This article is not specifically about Bash, but about the shell command language sh. The POSIX Shell is a standardized subset of Bash which has even better portability. I would recommend learning and using sh unless you really need Bash.
Your script will use sh if it starts with #!/bin/sh (instead of #!/bin/bash).
I can also recommend ShellCheck which is a shell script analysis tool (implemented in Haskell) which can find errors and potential problems in your scripts. On a Debian system, installing ShellScheck is as simple as `sudo apt install shellcheck'.
>I would recommend learning and using sh unless you really need Bash.
I don't buy this argument. Ok, it's a standard, but sometimes it's a pain-in-the-hole standard. Bash augmentations lessen some of the pains, and it's just nicer. The only situation is if you're using busybox in a very limited system or you reeeeeally need your script to run on many difference unices, which let's be honest, is not that common nowadays.
All of this was covered in great detail in the 2000s, when Debian and Ubuntu switched /bin/sh to the Debian Almquist shell, which was basically POSIX-only with some 3 things that Debian people simply couldn't live without, and encouraged system scripts to use it. If you weren't around then, go and read the discussions. They're mostly still available, and they cover some important stuff that straw man counterarguments regularly miss.
The Debian people were concerned, for starters, with how much time the Bourne Again shell spent, at process initialization, setting up things for extensions and interactive features that were never employed in non-interactive "sh" mode; a significant cause for concern given how much of the system was executable shell scripts.
I do small embedded systems with busybox, even that I can squeeze in bash when I need that, it's about 1MB in size and gives a lot more than busybox's sh. Another option is Lua which is also great.
> Bash augmentations lessen some of the pains, and it's just nicer
Both sh and bash are terrible, ugly hacks. Anything that requires more than 3 lines of them (including the #! line) should be written in a proper scripting language.
Though I do agree that cross-platformity to that level is rarely meaningful, and so things like python are just as likely available/can be made available.
If you wish require some users to install an interpreter, you might as well go for Korn or a real programming language. If you want to use something that's portable and installed everywhere, that's POSIX sh (or at most dash-like level). Bash is in the poor middle which isn't good enough for either side, unless you really know what's your target and don't care about elsewhere.
I usually target BASHv3 in my scripts, but then I know the environment that will be using those scripts. My biggest issue with POSIX is the use of the backtick which is difficult to read and parse.
ShellCheck is absolutely the most important thing to use when writing scripts. Each time that you get a warning that you don't recognise is a learning opportunity - just follow the link provided in the warning. Also, take the time to add the "# shellcheck disable=" comments so that scripts don't issue any warnings from shellcheck.
> My biggest issue with POSIX is the use of the backtick which is difficult to read and parse.
POSIX also has $(command) for command substitution. It can certainly be annoying when it's not used, though. I think shellcheck will recommend it over backticks.
> The POSIX Shell is a standardized subset of Bash which has even better portability.
It would be much more correct to say that bash's features are a superset of the shell features standardised by the POSIX standard, as is the case for several other shells (each adding their own parts on top of the standard) too.
Not only is it not more portable, POSIX doesn't even require that it exists at all.
Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.
I don't know how this trend started but now it's been cargo-culted to death. Same with the /usr/bin/env thing in shebangs.
"If bash is invoked with the name sh, it tries to mimic the
startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well"
BASH is like Obi Wan. It isn’t the most powerful or flashiest, but it survived a long time, where others didn’t, for very good reasons. Bash runs basically everywhere. It has many modern features you wouldn’t expect. Its syntax is literally what you would type on the command line if you were diagnosing or fixing systems so you don’t need to transpile to another language. Its reliance on other programs means it is glue and can easily incorporate highly cohesive functionality/tools others write and maintain. Also, it’s been around and is everywhere so you don’t worry about trying to incorporate the current latest and greatest declarative tool (which will blow over in 5 years) into your other workflows. Basically, don’t disparage a Jedi/tool that has survived where others didn’t. There is a reason.
Also, use shellcheck. Incorporate it into you editor. Fix all warning and don’t ignore them. This will push you deep into bash syntax rabbit holes but you come out better the other side.
A lot of bash errors are not understanding possible cases due to white space.. which shellcheck catches. After using it for a while, I don’t even really worry about white space because of the good habits I’ve learned/(been forced to use).
The only real advantage of bash (or other shells) is the ability to build up to it from the command line; to use it as a REPL then embed the stuff you've just done into a script.
The massive disadvantage of bash is that it uses a legal filename character " " as a delimiter ("$IFS"). That means it's very easy to write scripts which work fine on your test case but blow up in a different context. And the worst case of that is accidentally deleting the user's file system.
So many of the cute little bash examples you'll see, including I think the awk one on this page, will go wrong if you have a space in the wrong place in your filesystem. Or, god help you, a newline. Or a file named "*". Or "--".
Getting the 10% of the cases that have whitespace or metacharacters in variable values and filenames to work ... takes the other 90% of the time. (-:
I habitually quote variable expansions, even when I know that the variables are never going to contain whitespace. Because long experience has taught me that one day they will.
Just like I've learned never to assume that ${PATH} is always non-blank and so assume that PATH="${PATH}:/something" won't accidentally add the current directory to my search path. (-:
I guess the URL path in the Nginx log would be URL-encoded and have a %20 instead of a space. And otherwise, it would actually also a problem of that text based log format that uses spaces as field delimiters itself.
Anyway: When I can "build up from the command line", then apparently whatever I'm building up can be easily and intuitively done in the command line.
So, stuffing it into a bash script is fast and easy and should be easy to understand as well.
I just have real-world applications for small scripts that aren't much bigger than those "cute little bash examples". When you work with embedded systems, you do a lot of repeatable stuff via SSH. I once ported an Installer to Python and now I hate it because it has so much unhelpful noise between the actual relevant commands being executed.
Yes, Bash has it's issues and requires some discipline, but so do most other languages.
Having to completely change the naming scheme you use for human-authored and human-read artifacts entirely to route around shitting, confusing escaping in a programming language is not a convincing selling point for that language.
If you have a file whose contents are Shakespeare's "As You Like It", you should be able to name that file "As You Like It" without having to worry that the computer will vomit and die on it. We deserve better tools.
I too often avoid spaces in filenames, but when writing scripts it's far better to ensure that you cope with them properly. The trick is to always quote your variables by default and then run shellcheck on your script so that it can flag up the corner cases where quoting acts to unquote the string. Of course, it'll also flag up a host of other possible issues which are well worth fixing or at least understanding why it's a possible issue.
Another common footgun is not including a double dash ('--') at the end of command options so that the following filename won't be interpreted as an option when it begins with a dash.
Hm, I write bash scripts routinely and never do it that way. Always develop and run my scripts as files, starting with ‘set -x’ if I need debug info. I keep interactive mode solely for command line work, not development of scripts I plan to from files.
I have a counterpoint for many comments here. If you are writing some Python for example, and most of your code is executing commands such as tail, cat, wc, etc. and then doing something with their output, you are better off writing a shell script instead .
I'm a computer scientist/software engineer that has used primarily Unix or Linux systems since the 80's. I write shell scripts occasionally, but I just find them error prone enough that I'd rather use python than sh for complex scripts. Python has some packages that make working with files, directories, and processes tolerable and at least I can understand the string quoting rules in python.
Generally my order of preference for shell scripting tasks is: python > bash > pearl > tcl > sh > anything > AppleTalk.
This argument isn't very compelling. Shell scripts are great at tricking you into believing you've got something 100% working when in fact you've only accounted for the happy path and maybe two or three failure cases. This is the primary reason shell scripts are so often broken. There are tons of assumptions baked in which are easily violated.
If your shell script keeps breaking, and you keep fixing it by writing more shell, then you're in an abusive relationship with your programming environment.
"Shell scripts are great at tricking you into believing you've got something 100% working"
Exactly. Shell scripting is basically a non-hygenic macro language, with very complex semantics around its primary data type, the string. It also lacks pretty much all of the affordances we use to write reliable programs. I have no doubt someone has written a typechecker or unit test framework for bash, but I've never seen one used. I'll take the ugly code with the straightforward semantics, thanks.
I feel like zsh is for pros maybe. I use Linux daily and write python and shellscripts. Zsh has been defaulted all over the place but all that meant for me is I have to figure out how to get it to do things the bash way once in a while.
I see no reason why distros like ubuntu or kali would default to zsh.I use the shell for sysadmin stuff, anything complex or app specific gets at least a python treatment.
The whole thing reminds me of python 2->3 or sysv init to systemd. There must be people somewhere deeply invested in these changes and their voice is certainly much more valuable than the average opensource joe user. Defaults matter and the time I and millions had to spend learning to transition for no direct benefit to us has value. The whole distro model of everyone getting a distro they like falls apart when not enough people can fork.
Overall, this devalues opensource as an investment. Because of unpredictable hidden costs like this.
Readit News
But especially Sh runs everywhere, so it's good to know. This seems to be the article's point.
Honestly, though? The right answer is to transpile a better language to Sh.
Looking around, there have been several half-hearted, abandoned attempts. But apparently everyone is happy to just fall back on the "accidental syntax" of Bash that really doesn't make sense when compared to ... any other language.
I put up with Bash because there's no better alternative. That doesn't mean we should put up with Bash; just that we must put up with it at least to the point where it can run code written in a real language.
Having said that, Bash is my favorite programming language, because it is so limiting, and simultaneously not limiting, because it wasn't designed to fulfill what A Real Programmer(TM) thinks a programming language should be.
A computer is supposed to serve a human. Not the other way around. But modern programmers, being wildly unimaginative creatures of habit, think the user is supposed to serve the computer. That the more you type, and the more hoops you jump through, the more "clever" you are with the "way" you tell the machine to do something, that this is superior. Never mind that the end result of all this incantation and tom-foolery doesn't actually result in a good outcome half the time. That the user is often unhappy with the result, if they even factor into the programmer's thinking at all. No, the true purpose of programming is to gratify the programmer and make the machine happy, not to make a human's life easier.
Programming is a mistake. It's a half-measure. A stutter in the evolution of digital computing. We weren't meant to program, we were meant to make a synthetic invention that relieved us of our labor. And what do we have to show for spending 1/3 of our life, and decades of work, for it? A metal and plastic box that can do pretty much exactly the same real work as 30 years ago, but with better graphics, because the hardware people gave us better screens.
Look at it from an average user's perspective. They're thinking "Wow, this spreadsheet would have taken hours to do with a calculator and a pencil".
Most users are not programmers. Programming IS the act of making a synthetic invention that relieves us of our labor. It's no different from what a plumber does. If we had to connect pipes in a custom arrangement every time we wanted to do the dishes we would argue all day about the best pipes and threads and tapes.
But we don't. We use premade fixtures and we don't have to think about plumbing.
Those hoops you have to jump through are like the building codes. They make everything consistent. And more importantly, they make things inspectable. There are a million and one ways to plumb or frame a wall or something that would probably be fine. But that would be Real Engineering to do that and show that it's safe.
Wheras the codes are designed to not allow for "interesting" stuff that only an engineer would understand. The programming conventions developed over time based on programmers experience of what works and what doesn't when writing software that is so complicated not one person on earth could ever understand it.
The difference with programmers is they use programs to make programs. There's no user/designer distinction, and they all want to be creative and clever engineers, not just skilled tradespeople, so they don't see the benefits as much. If most of what you do is coding, you might thing nothing has advanced in the last 30 years, because you used text then and now you have more complicated text.
But from a user perspective, we went from drafting tables to CAD. We have Google Keep. We have voice assistants. We have 4k editing for consumers!
Bash pretty much just makes it explicit right in the language that there's no user/coder distinction and kind of keeps that mindset around.
Newer languages are designed to help people make user facing black boxes, and they do a great job of it it seems.
Meh. That part is irrelevant in the extreme to the discussion.
Fact is that people write `.sh` and `.bash` scripts to get things done. They use conditional logic and loops and everything.
Functionally, it's a programming language with a (useful) REPL.
And this discussion is 100% about how bash is as a programming language.
> Having said that, Bash is my favorite programming language, because it is so limiting, and simultaneously not limiting, because it wasn't designed to fulfill what A Real Programmer(TM) thinks a programming language should be.
Umm... Then, yeah, I have to agree with your self-assessment of not being a "real programmer."
Sorry, but it's obviously true.
You're a scripter. I've known and worked with many scripters. They can do a lot of valuable work and contribute in a lot of ways to various projects. But they're not programmers.
Which is fine. Script away.
> But modern programmers, being wildly unimaginative creatures of habit, think the user is supposed to serve the computer.
After admitting you're not a programmer, you then go on to demonstrate that you don't really understand how programming works. Which I guess follows?
That's so far from the reality, that it's Not Even Wrong.
> That the more you type, and the more hoops you jump through, the more "clever" you are with the "way" you tell the machine to do something, that this is superior.
Programming languages are exactly the level of complexity needed to, with the least effort and most reliability, craft the code that, literally, civilization relies on.
It can't be made simpler. The complexity is inherent in the domain.
> Programming is a mistake. It's a half-measure. A stutter in the evolution of digital computing. We weren't meant to program, ...
YOU weren't meant to program. You admitted that above. Don't speak for the rest of us.
Everything significant in software that has been and will be accomplished moving forward will be created by programmers using programming languages. Your rant against programmers and programming is based on a lack of understanding of what programming really is and how programmers really think.
It's not even slightly about being clever. It's about the act of primal creation. We're effectively wizards of the modern world. We don't care at all about making a machine happy; we care about building things that work. That the things embody complexity isn't the goal, but it is a thing of beauty when it all works together elegantly.
It's not meant to be a real language. It's meant to be a shell. Here, let me back that up and reverse it for you.
<JAVA> public Set<String> listFilesUsingJavaIO(String dir) { return Stream.of(new File(dir).listFiles()) .filter(file -> !file.isDirectory()) .map(File::getName) .collect(Collectors.toSet()); } //I'm not handling errors, and this doesn't actually print anything, it just lets me try to.
<SHELL> ls
Shell is meant to be a common way to do common tasks on commandline, and make a little script if you want to save that and run it again. I can do little things in a shell one-liner quick, that would take a page of python or perl.
I put up with my sports car because there's no better alternative. It doesn't mean I should put up with a sports car for transporting my piano, just that I must put up with it at least to the point where the sports car can transport me to the car that transports a piano.
And it's an objectively awful programming language. Sh is even worse.
Korn isn't installed absolutely everywhere like Sh is. It's not even installed in 1/100 of the locations that Bash is installed. So it being better is irrelevant to the discussion of Bash as a programming language.
Because Bash is so awful, the only real justification for using it as a programming language is that it's already installed. Since Korn isn't already installed, that means you'd need to install it. If you're going to be installing something, there are far better choices.
So your comment doesn't at all contribute to the discussion of alternatives to using Bash as a programming language.
And the verbosity of using Java to list a folder contents is equally irrelevant. No one would argue that Java is better ... for listing directory contents.
If you do want to write a script that calls a bunch of shell commands, or even that operates on folders and files, there are far better languages and tools.
See, for example, https://www.npmjs.com/package/tish
Or just Node/TypeScript in general.
Yes. But it's also absolutely great in so many ways.
Yoo-nee-kode
Deleted Comment
If you want a better language for complex scripts, use Python, or even Perl, they are now ubiquitous, or bring someting self-contained like Lua or Janet with you.
It would be great to have a different ubiquitous shell language on Unix machines, but it's unrealistic now.
Cloudflare uses Go similarly as a scripting language. [2]
[1]: https://go.dev/solutions/google/sitereliability [2]: https://blog.cloudflare.com/using-go-as-a-scripting-language...
Not an official Google product of course but ...
https://github.com/google/zx
>Bash is great, but when it comes to writing more complex scripts, many people prefer a more convenient programming language. JavaScript is a perfect choice, but the Node.js standard library requires additional hassle before using. The zx package provides useful wrappers around child_process, escapes arguments and gives sensible defaults.
I like this, but I think it's even better to just escape sh entirely. If you are on a system that supports sh, it almost certainly has a c99 compatible compiler which can be used to install lua(JIT)? or another better scripting language. I wrote a little script idempotently installs lua 5.4 (that I tried to include but HN formatting messed up) and then runs a luascript embedded in a heredoc. The first time I ran it, it took 5.4 seconds to print "Hello, world!" including downloading the lua source code from their website and compiling the whole thing. The second time it took 11ms. I really see no great reason to continue using sh for anything new except for the purpose of installing something else.
But it's simply not realistic.
Examples:
- Embedded devices that may or may not have an internet connection
- Government classified networks that aren't allowed to grab ANY random software off of the internet
- Simply not wanting to add another dependency to an operation.
I'm a former Lua fan. I've ... written it off at this point. [1]
Honestly if I were to take the approach you describe, I'd likely instead have the shell script only look at the architecture and then choose one of 2-3 precompiled Go binaries. Talk about simple and fast...and the binaries could be hosted behind a firewall somewhere.
Or maybe I was thinking of it wrong. Just embed the various Go binaries into a tar file embedded right in the shell script[2], and choose the right one based on architecture. Done. :)
[1] https://realmensch.org/2016/05/28/goodbye-lua/
[2] https://www.xmodulo.com/embed-binary-file-bash-script.html
Personally, the way I avoid footguns is to use a functional style. Filter instead of conditions and map instead of loops. GNU Parallel makes this straightforward, including distributed commands across machines! Aside, it is easy to emulate relational algebra with grep, sed, and awk.
A good essay describing some of the advantages of this approach is: http://widgetsandshit.com/teddziuba/2010/10/taco-bell-progra...
A lot of things that one would use bash for involve servers, and there's Ansible for that, no need to use bash directly most of the time. If it were up to me, distros would include Ansible out of the box.
IMHO doing anything at all that's not programmatically repeatable isn't the best practice, so it's not like I want to be logging onto something and writing a quick script in Nano.
Outside of servers.... nobody uses Linux except embedded systems and FOSS enthusiasts. Nobody is paying me to do FOSS work, so I can just pretend that Pythonless systems don't exist.
Python does have some version compatibility issues, but for the most part it's stable, and at least it will crash with a traceback not a cryptic error code because you used some utility that had some nonstandard syntax for the flags.
On embedded, most of what you're doing is probably simple enough that if you do need to use sh you won't absolutely scream.
Normally I’m not very fond of Gos verbosity, especially compared to bash, but i take anything over bash, it is just so filled with footguns, every single line has to be super carefully scrutinized. Note that I say this as someone actually quite good at it, not because I don’t understand it. In fact the more you learn, the more scared you get.
Lisp and Scheme would like to have a word . . .
I hate Lisp.
'nough said.
Deleted Comment
So, no, it's not "objectively" awful. At most it's "subjectively" awful for some people.
A debugger won't "step in" unless you..."step in" instead of "step over."
STL is also no longer a thing. There's only the C++ standard library. So I think you're dating your usage of C++ by ... a decade or more?
Regardless, the idea of a language that transpiles to bash is kinda interesting.
And it's not installed by default on all systems. It's especially not installed on systems like Alpine.
The point was never to "find a better shell." It was to run install (or other) scripts with some level of logic absolutely anywhere.
https://www.nushell.sh/
Subjectively, not objectively.
If I'm going to install a language/shell, I'll likely choose Node, Bun, or Go, depending.
Python isn't actually a much better language from a language design standpoint.
But given that *nix tooling output defaults to text, it's hard to argue against a universal language that talks to all of it.
¹I have manipulated arrays in Bash, proving this statement.
You sus out what you need to do by hand and then convert your history into a script.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
Your script will use sh if it starts with #!/bin/sh (instead of #!/bin/bash).
I can also recommend ShellCheck which is a shell script analysis tool (implemented in Haskell) which can find errors and potential problems in your scripts. On a Debian system, installing ShellScheck is as simple as `sudo apt install shellcheck'.
I don't buy this argument. Ok, it's a standard, but sometimes it's a pain-in-the-hole standard. Bash augmentations lessen some of the pains, and it's just nicer. The only situation is if you're using busybox in a very limited system or you reeeeeally need your script to run on many difference unices, which let's be honest, is not that common nowadays.
The Debian people were concerned, for starters, with how much time the Bourne Again shell spent, at process initialization, setting up things for extensions and interactive features that were never employed in non-interactive "sh" mode; a significant cause for concern given how much of the system was executable shell scripts.
Due to docker, minimalistic Linux'es have been more common, including trimmed-down versions of distros that would otherwise feature bash.
Both sh and bash are terrible, ugly hacks. Anything that requires more than 3 lines of them (including the #! line) should be written in a proper scripting language.
Though I do agree that cross-platformity to that level is rarely meaningful, and so things like python are just as likely available/can be made available.
ShellCheck is absolutely the most important thing to use when writing scripts. Each time that you get a warning that you don't recognise is a learning opportunity - just follow the link provided in the warning. Also, take the time to add the "# shellcheck disable=" comments so that scripts don't issue any warnings from shellcheck.
I also recommend visiting https://mywiki.wooledge.org/BashFAQ for avoiding the many footguns, especially with filename parsing.
I always use $(...) or rather "$(...)" instead of backticks.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...POSIX also has $(command) for command substitution. It can certainly be annoying when it's not used, though. I think shellcheck will recommend it over backticks.
Nah I like using bash features and all the systems that I care about have /bin/bash so it doesn't matter.
It would be much more correct to say that bash's features are a superset of the shell features standardised by the POSIX standard, as is the case for several other shells (each adding their own parts on top of the standard) too.
or as I've taken to calling it, Ba + sh
Meaning /bin/sh is not more portable because you can’t be sure which shell will be used.
Exactly. The title is just plain wrong. Furthermore, TFA does not argue a "case", it simply tries to specify the language.
https://github.com/bash-lsp/bash-language-server/
Is Bash just surviving because no one knows about it or has remembers it while its been hiding in your system for 20 years?
The massive disadvantage of bash is that it uses a legal filename character " " as a delimiter ("$IFS"). That means it's very easy to write scripts which work fine on your test case but blow up in a different context. And the worst case of that is accidentally deleting the user's file system.
So many of the cute little bash examples you'll see, including I think the awk one on this page, will go wrong if you have a space in the wrong place in your filesystem. Or, god help you, a newline. Or a file named "*". Or "--".
Getting the 10% of the cases that have whitespace or metacharacters in variable values and filenames to work ... takes the other 90% of the time. (-:
I habitually quote variable expansions, even when I know that the variables are never going to contain whitespace. Because long experience has taught me that one day they will.
Just like I've learned never to assume that ${PATH} is always non-blank and so assume that PATH="${PATH}:/something" won't accidentally add the current directory to my search path. (-:
Anyway: When I can "build up from the command line", then apparently whatever I'm building up can be easily and intuitively done in the command line. So, stuffing it into a bash script is fast and easy and should be easy to understand as well.
I just have real-world applications for small scripts that aren't much bigger than those "cute little bash examples". When you work with embedded systems, you do a lot of repeatable stuff via SSH. I once ported an Installer to Python and now I hate it because it has so much unhelpful noise between the actual relevant commands being executed.
Yes, Bash has it's issues and requires some discipline, but so do most other languages.
It looks like a use-case for fabric https://docs.fabfile.org/en/stable/getting-started.html#adde... It is the best of both worlds: shell pipeline for one-liners, Python — for complex logic.
Or if more declarative approach works in you case then something like ansible could help https://docs.ansible.com/ansible/latest/getting_started/inde...
Just don't write bugs, what's so hard about shell programming?
On the very rare occasions I'm using an external dataset that includes them I'll make a copy with renamed files using underscores.
If more junior team members produce files with spaces in their paths I quickly educate them in how problematic it can be.
It's pretty rare this is a problem for me or my team, perhaps we're lucky in what we work on though.
Thankfully I have never seen a file named "*" or "--".
If you have a file whose contents are Shakespeare's "As You Like It", you should be able to name that file "As You Like It" without having to worry that the computer will vomit and die on it. We deserve better tools.
Another common footgun is not including a double dash ('--') at the end of command options so that the following filename won't be interpreted as an option when it begins with a dash.
Generally my order of preference for shell scripting tasks is: python > bash > pearl > tcl > sh > anything > AppleTalk.
If your shell script keeps breaking, and you keep fixing it by writing more shell, then you're in an abusive relationship with your programming environment.
Exactly. Shell scripting is basically a non-hygenic macro language, with very complex semantics around its primary data type, the string. It also lacks pretty much all of the affordances we use to write reliable programs. I have no doubt someone has written a typechecker or unit test framework for bash, but I've never seen one used. I'll take the ugly code with the straightforward semantics, thanks.
I see no reason why distros like ubuntu or kali would default to zsh.I use the shell for sysadmin stuff, anything complex or app specific gets at least a python treatment.
The whole thing reminds me of python 2->3 or sysv init to systemd. There must be people somewhere deeply invested in these changes and their voice is certainly much more valuable than the average opensource joe user. Defaults matter and the time I and millions had to spend learning to transition for no direct benefit to us has value. The whole distro model of everyone getting a distro they like falls apart when not enough people can fork.
Overall, this devalues opensource as an investment. Because of unpredictable hidden costs like this.