Hacker News Reader

Comment by dataflow | Hacker News Reader

It's still relevant if you use -a, -o, or parentheses (which I guess is reason to avoid them):

  $ a=1; b=1; c='!'; d='!'
  $ [ "$a" = "$b" -a "$c" = "$d" ]
  -bash: [: too many arguments
  $ [ '!' '(' "$c" = "$d" ')' ]
  -bash: [: `)' expected, found !
  $ echo "${BASH_VERSION}"
  5.1.4(1)-release

Note that it's not even a bug here; it's necessary for disambiguation.

View on HN

Alternatively you can use the newer (and highly recommended) bash syntax that is also quote safe:

     $ a=1; b=1; c='!'; d='!'
     $ [[ $a = $b && $c = $d ]] && echo true
     true

For anyone writing bash scripts today I would avoid the old test/[ functions entirely.

It's always fun to assume everyone is running Bash until your Mac's zsh or your Ubuntu's dash (or whatever) choke on your script a few times. When this happens enough times you eventually reconsider...

That's what shebangs are for:

  #!/usr/bin/env bash

If it's not there, it will fail.

I expect every script with `#!/bin/sh` as shebang to be POSIX shell only.

> If it's not there, it will fail.

Until your users/colleagues source it into another shell, or copy-paste some part of it into their shell/Makefile/Bazel/other script... and then either you feel sorry for them, or you laugh at them and blame them for burning themselves and trashing their system. (Hopefully your choice didn't cause their files to get wiped. Unless you think they deserved it for daring to paste your code somewhere else, I guess.)

The world isn't perfect.

This problem is not exclusive to bash, try copy-pasting python 2 code into python 3.

Or ES2020 code in a browser.

Or ASM z80 into an x86 program.

When you're copy-pasting, you should be aware of what you're copying, and where you're pasting it.

Surely, no domain in IT is idiot-proof.

> This problem is not exclusive to bash, try copy-pasting python 2 code into python 3.

No, it is highly exclusive to Bash actually. In Bash, even one-character mistakes have a high potential to cause catastrophic damage. Just splitting or globbing on the wrong character can wipe your filesystem. As well as issues like these, where your string being '!' suddenly causes the command to be interpreted entirely differently. And Bash has modes that keep going when there is an error so it's not like you'll even know you've encountered an error or get any kind of visible crash + stack trace necessarily. It just keeps trashing everything further and further. These are extremely wildly different from Python.

> Surely, no domain in IT is idiot-proof.

I would love to know what happens when you say this to a user who pastes your Bash in zsh. Do you tell them your code isn't idiot-proof? Is everyone who ends up running Bash in zsh for some reason or another an idiot?

If you're not doing `set -euo` and if you run your scripts as root before testing them, you're asking for something wrong to happen.

EDIT in response to your EDIT:

My users get either:

  - a tar.gz archive
  - a binary
  - a docker image
  - an helm chart
  - a POSIX shell script (very rare)

Then they can use any method they want to deploy it.

You want your software to be portable? You have to put in the work to do it.

If you expect your users to know better (assume they ARE idiots), again, you're asking for something wrong to happen.

No, if you're using a language that requires you to perform some obscure incantation like "set -euo" before running your scripts, you're asking for something wrong to happen.

Blame the disease, not the symptom.

if your pedantic enough to use "set -euo", you're going to add it to the script and not make a user set it first.

> If you're not doing `set -euo` and if you run your scripts as root before testing them, you're asking for something wrong to happen.

...because you can't delete important files unless you're root, right? Subfolders in your home directory are totally OK being deleted? You store your documents so that only root can modify them?

And do you know set -e has a ton of its own pitfalls and doesn't save you from this? It's a half-broken mitigation. I don't have energy to keep arguing here, but I would suggest go learning about the pitfalls of Bash and set -e and such.

You mean "set -euo pipefail", don't you?

You should use more copy/paste. ;)

If people copy-and-paste complex shell scripts without testing, you’re going to have a bad day no matter what you do. The solution is to work on better practice, use of shellcheck, rewriting complex logic in Python, etc. since that’ll pay dividends in so many other ways.

> Until your users/colleagues source it into another shell

The intersection of people knowing the "source" command and not knowing what is a she-bang or the difference between sh and bash is quite small.

So what is your point here? I'm hallucinating when I see people do this?

Are you suggesting that leaving off the shebang line makes these types of mistakes less likely? That makes no sense.

If I copy Python 2 code into Python 3 it’s not gonna work right either. What’s your point?

I've been seeing this argument for decades and yet I've never run into any issues like you describe.

When I write a bash script it is for my use or in my production system. In either case I call bash explicitly (/usr/bin/env bash) so the script will work correctly or not at all.

Rarely do I have a project where there is a requirement to write a "run anywhere" script but if it were I would stick to posix.

There are more people in the world than you. You might do everything perfectly; other people won't. Especially users who have yet to learn about these pitfalls. If you haven't run into this, either you're lucky enough that it doesn't apply to your situation, or you haven't become aware of it or tried to pay attention to it. I know I've seen people try to run Bash in their Mac's zsh (not necessarily deliberately either; some programs just run the default shell) and watched it crash and burn. I'm not condoning it, I'm saying it happens whether you and I like it or not, and you can either blame the victim (which I guess wouldn't be the first time I see this happen), or you can do something about it.

Am I understanding correctly that your point is that we shouldn't write modern bash scripts because some number of untrained people will have problems by accidentally misusing the scripts (wrong interpreter, blind copy/paste, etc). Is that a correct summary?

To me this sounds like saying we shouldn't have powerful tools like chainsaws because every year some people without safety training use them wrong and hurt themselves.

No, that's just an exaggerated caricature of what I'm saying.

I'm only saying you should avoid using modern things needlessly. This means, don't do it when the POSIX-compliant syntax also serves your needs. e.g., don't do [[ -f "$foo" ]] when you could just as easily do [ -f "$foo" ]. And if you do need to use Bash-specific features, make sure it's safe enough that foreseeable misuses will fail safely. Or when that's not possible, try to mitigate it somehow (maybe with a comment, or by putting in some extra dynamic checks, or other solutions you can think of).

And this goes for other things too, not just Bash. Probably outside programming too.

> I'm only saying you should avoid using modern things needlessly.

I agree with that idea.

However, I don't think it applies in this case. The point of using modern bash syntax is that it fixed the brittleness and pitfalls of posix sh. This is significant. This is what I need in production. This is why our style guides insist on modern bash syntax for bash scripting.

I'd say the rest of your suggestions apply to shell scripts no matter what syntax is used.

Also, bash on Mac is shitty. I've run into problems with it before (can't remember exactly what it was) so we've reversed it: our shell scripts are written in zsh, and we just ensure that zsh installed everywhere.

Oh yeah that too, that's another whole can of worms I forgot to bring up, thanks for mentioning it.

Besides that bash has its problems with array variables. Unless I switch to one of the "real" scripting languages, I use zsh too and start my scripts with

  if [[ -n "$BASH" ]] ; then
    echo $0: use zsh, not bash
    exit 1
  fi

Earlier on I used the more compact

  [[ -n "$BASH" ]] && { echo $0: use zsh, not bash;  exit 1 }

But bash chokes on that with a syntax error

The syntax error is on a required semicolon. Put one after the "exit 1":

  [[ -n "$BASH" ]] && { echo $0: use zsh, not bash;  exit 1; }

As always my take on this is that if you don't care about portability, why even bother with bash?

My rule of thumb is that if your script becomes too complicated that you find POSIX sh limiting, it's probably a good hint that you should rewrite it in a proper programming language. Bash scripting is an anti-pattern in my opinion, it's the worst of both worlds since it's neither portable nor that much better than POSIX.

> it's the worst of both worlds since it's neither portable nor that much better than POSIX

Writing modern bash using the updated syntax, it is easy to make robust scripts and the syntax around things like quoting is simple and consistent.

It seems odd to me to suggest that one should either stick to the old brittle /bin/sh syntax or not use bash at all. It has it's place in the world and it should be done the modern way.

You'll find 10s of thousands of lines of bash in the kubernetes repo and all the files I checked are written using modern bash syntax. There must be a reason they choose bash for these parts.

Of course, in any case everyone should use the tools they like and find most suited to the task at hand.

"there must be a reason" hahahahahaha

> There must be a reason they choose bash for these parts.

Kubernetes is a Google creation. Google mandates bash for shell scripts: https://google.github.io/styleguide/shellguide.html#s1.1-whi...

Because it's everywhere anyone cares about and isn't some weird thing like zsh or Lord forgive us tcsh.

Also all of these modern are basically fancy wrappers around bash scripts. Even dockerfiles is just a way to run some shell commands at image build time and other shell commands at launch time. Much less puppet or ansible or user-data.sh ....

Sometimes you write POSIX shell (or very nearly POSIX) for portability. Sometimes you write in "a proper programming language" for more powerful/flexible features. And sometimes you write Bash to get both.

Bash is ported to basically every system, it's a small binary (by today's grotesque standards), and it gives you some added functionality that would be otherwise annoying to re-implement in POSIX sh (or Bourne sh). But it's also far less complex than Python. In today's world, if someone has any shell, it's a safe bet that they either already have Bash, or they can install it just like they'd have to install Python.

It's less painful in the long term to use Bash rather than Python. Python is more time-consuming and costly. It's a larger space requirement, you have to manage more runtime dependencies and a virtual environment, debugging is worse, and there's more opportunity for bugs because it's more complex. Bash scripts also rarely get bugs down the line due to dependencies changing, whereas this happens in Python so frequently we have to pin versions in a virtualenv. When's the last time you pinned the version of a Bash script dependency?

This used to be my take, but I'm not sure any more. Now, I don't think Python is ideal, and I am looking for something that maybe fits better than it in that gray zone of programming language vs "quick" script, but I can't see your point about debugging and bugs: bash is notoriously annoying to write bug free, and I can't see what's the issue with the Python debugger.

Also if we're in that gray zone of bash vs Python, you can pretty much stick to the stdlib.

python3 or python2.7???

I would go with the one that hasn't been out of support since Jan 1, 2020.

https://www.python.org/doc/sunset-python-2/

yet everything comes standard with stock install of 2.7. ???

No responsible distro still ships 2.7

hahahaha. I like your definition or responsible as AWS Linux 2 comes with 2.7 and macOS comes with 2.7

glad to know i'm such a hellion running such irresponsible OSes! down with the man!! I do what I want!

Or more likely, the world isn't as clear cut as you might think

> I['d] like your definition [f]or responsible

A distribution that removes Python 2.7 once upstream security support has been cut. Since Python is frequently used on network-facing services, it is unconscionable to allow its use past January 2020. Heck, one might even have setuid programs in Python and you don't really want to risk an unfixed local privilege escalation either.

> AWS Linux 2

A butchered version of CentOS

> and macOS

Not a distribution, and Apple doesn't exactly have a good track record with keeping things up to date or secure.

> Or more likely, the world isn't as clear cut as you might think

Given that the vast majority of the Python ecosystem is no longer compatible with 2.7, there isn't even a technical reason for kicking around 2.7 anymore.

Python 2.7 is trivial to build and run if you really, really want or need it, but since all the major upstream distributions have removed it, it sends a clear signal that you must take the risks into serious consideration before doing it.

I'm hopeful that Deno can be just that runtime. Since its a single binary, its trivial to install and script for. TBH, I don't have any technical reasons for JS/TS over python besides that I have coworkers that have never had to learn python and would prefer not to.

  /**
   * cat.ts
   */
  for (let i = 0; i < Deno.args.length; i++) {
    const filename = Deno.args[i];
    const file = await Deno.open(filename);
    await Deno.copy(file, Deno.stdout);
    file.close();
  }

Ruby!

In the space of shell programming, virtualenv and third-party Python libraries are irrelevant and unnecessary.

Huh? That's only true if you don't use any libraries, right?

What if you want to use something like delegator[0] to make running shell commands less toilsome?

[0] https://github.com/amitt001/delegator.py

Python with no libraries is still a much, much nicer programming environment than bash.

How say you? To even ask the system a question in python, you have to "import os". Is that not a library? I'm not a python-first type of person, but I have hacked enough scripts to be functional. My one take away is how python core is not very useful, and to even remotely do anything one must have a list of imports.

'os' is in the standard library, not a concern when discussing virtual-env and third party libraries.

then why must it be imported as a 3rd party? this is my question on python in general. i get needing to explicitly import things that are not part of the core/standard, but why are core/standard required to be imported? why can't the methods they provide not just immediately available.

*clearly, i've never taken a python CS style class, but it this importing core functions is just strange to me

"Third party" means a third party provided it: not yourself, and not the Python distribution, but someone else.

"os" is a second-party library. You didn't write it; it was included in the Python distribution for you.

What you're asking, I think is why the "os" functions are not, in Python terminology, "builtins." The builtins are functions that are available without any kind of import: like len(), max(), sorted(), etc.

https://docs.python.org/3/library/functions.html

Why do you have to "import os"? Python was designed that way, that's all. So were the majority of other languages that come with standard libraries. (JavaScript is one exception that comes to mind, but there aren't many such exceptions.)

The discussion above relates to "virtual environments", which are ways to manage third-party dependencies. My claim is that virtualenvs, while handy for general-purpose development, are basically pointless for replacing shell scripts. You don't need them -- the core language and its standard library are sufficient for most shell scripting purposes. I'm basing this opinion on my ~20 years of using Python for this kind of work.

python is indeed very painful for typical short shell script tasks

for example: anything with pipes

however once you start having to run multiple background jobs with custom wait logic it probably becomes worth it

Python is far easier for anything involving http and data parsing/manipulation. It's far worse at running seuqntial shell programs.

  from sh import wc, ls
  print(wc(ls("-1"), "-l"))

Try to do in Python something like:

Where size of data >> RAM (but less than free space in /tmp). It of course possible, but I suspect would require more effort and would work slower than a shell line above.

If you want to compare memory efficiency. The sort+uniq -c would likely be more optimal in a high level language as you would there keep only the count+value in a defaultdict or alike instead of sorting the entire dataset, which requires keeping it all in mem.

As for brevity, yeah, this particular example would require 5 lines instead of 1.

For small datasets something like defaultdict may be more efficient, but if it would not fit in RAM you have a problem.

There are two specific cases where you do not have BASH.

1. Ubuntu/Debian /bin/sh is the Debian variant of the Almquist shell, known as dash. The only non-POSIX element it includes is the "local" keyword (afaik).

2. Busybox, with the Almquist shell. Busybox also has a "bash" which offers a few cosmetic improvements to ash (an alias of [[ to [ is one that I can see in the source). I write POSIX shell scripts on Windows with busybox quite often.

The only other shell that omits everything outside of the POSIX specification is mrsh. I don't think mrsh is widely-deployed in any major distribution.

(You also aren't going to have bash in AIX/HP-UX and maybe a Solaris base load, but as the parent article says, we aren't talking about dinosaur herders.)

tcsh was the default shell in Mac OS X for a while…

For #1, you can just put #!/bin/bash at the top of the file to use Bash. Bash is still available, it’s just not the default for scripts that specify #!/bin/sh.

#2 is still currently tricky, but Rob Landley (former Busybox maintainer) is working on a full bug-for-bug compatible Bash clone called toysh which will be included in an upcoming release of Toybox[1]. Once that’s released, I’m looking forward to (hopefully) never writing a script for BusyBox ash again.

[1] http://landley.net/toybox/about.html

Bash is ugly and rife with pitfalls, but it can be incredibly productive for certain classes of problems if you know what you’re doing. Trying to use Python or Go to whack some external commands together feels very cumbersome to me.

For pure programming, “real” languages are absolulely preferable in almost every way, but all of them fail when it comes to running external programs and redirecting their output in a way that doesn’t make me pull my hair out. As a heavy user of both “real” programming languages and shell scripting languages, I’m left craving something that brings the best of both worlds.

There are a number of newer shell projects in this vein that are very exciting, like Oil [0], Elvish [1], and Xonsh [2]. I was also hopeful that Neugram [3] would go somewhere, but the project seems to have died out. While many people cite Bash’s lack of portability as a reason not to use it, I find Bash to be very portable for my use cases and avoid using these newer shells for their lack of portability. Maybe one day we can have nice things.

[0]: https://github.com/oilshell/oil

[1]: https://github.com/elves/elvish

[2]: https://github.com/xonsh/xonsh

[3]: https://github.com/neugram/ng

Sad that none of those projects took the easy route. If you want to replace Bash, do it the way Bash replaced Bourne: Make it backwards compatible.

Bash acts like 'historical versions of sh' if it was invoked as sh. So, a Bash replacement could act like Bash if it was invoked like bash. Then implement all the extra crazy shit if you invoke it as slash or something.

Assuming it was a small, fast, compiled binary, this would take off in all the distros pretty much immediately. And if you really want it to succeed, implement a spec first, and implementations second. Add a slash implementation to Busybox, and then it's on every embedded Linux system in the world.

It would certainly be nice, but I wouldn’t call that the easy route. Creating a new shell that’s fully backwards compatible with the monstrosity that is Bash sounds like a massive undertaking. POSIX or the Bourne shell is probably an easier target, and there are numerous alternative shells that are POSIX-compatible and add nice new features or optional alternate syntaxes. But I agree, to properly dethrone Bash would probably require backwards compatibility with it.

Personally I don't see the point dethroning bash. I mean Bash still hasn't completely dethroned the Bourne shell. And now there is a lot more competition in shells than there ever was.

Personally I think the better approach is to accept that bash/sh will always be about for legacy stuff and for alternative shells to carve out a niche elsewhere. Particularly because to some of bash/sh's pain points can't be addressed without break compatibility in the first place (like handling file names with spaces).

Literally the first in the GPs list, Oil shell, aims to do just that.

> Oil is a new Unix shell. It's our upgrade path from bash to a better language and runtime.

https://www.oilshell.org/blog/2021/01/why-a-new-shell.html

It's worth adding mine to the list too:

[4]: https://github.com/lmorg/murex

Superficially it's quite similar to elvish (purely by coincidence) but it's aimed around local machine use (eg by developers and devops engineers) so is as much inspired by IDEs as it is by shells.

> Trying to use Python or Go to whack some external commands together feels very cumbersome to me.

Try https://amoffat.github.io/sh/

  from sh.contrib import git
  git.reset(hard=True)

Wow that’s cool. Thanks for sharing.

How is this better than just using subprocess? Faster? More elegant?

The doc says: sh is a full-fledged subprocess replacement

It would be nice if that page had some sort of comparison. I guess the examples shown are sufficient if you're a regular user of subprocess?

Shellcheck specifically supports POSIX, BASH, and Korn. Each of these has an important role in scripting.

Development of the formal ksh93 was halted and rewound by AT&T after David Korn's departure, precisely because the user community remains extremely intolerant to changes in functionality and/or performance. Korn shell development that requires a "living" shell should likely target both ksh93 and the MirBSD Korn shell (the default shell in Android).

BASH has diverged from the Korn shell in a few (annoying) ways, but remains core to the GNU movement and rightly commands its own audience. It is much larger than the MirBSD Korn shell.

POSIX shells were developed to target truly minimal systems - POSIX rejected Korn likely due to (Microsoft) XENIX on 80286 systems that only allowed 64K text segments. Korn was able to run on such machines, but the code was not maintainable. Clean C source for a POSIX shell is far easier to achieve for XENIX, and remains a better fit for embedded environments. This is likely why POSIX is not Korn.

There’s portability and there’s portability.

I don’t really care about targeting, say, IRIX, or z/OS, or the early-2000s-era Windows POSIX Subsystem. But I do care about targeting Linux, macOS/iOS, all the modern living BSDs, and Android (where applicable.) I also maybe care about letting my software run under a Linux Busybox userland.

It’d be great to know what the lowest-common-demoninator standard is for just that set of targets. I don’t care about POSIX, but if that set of targets had a common formal named standard, I’d adhere to it rigorously.

Since it doesn’t, I just mostly adhere to POSIX — except where it gets to be too much (like having to write 1000-line Bourne Shell scripts.) When that happens, I look around to see if the set of targets I care about all do something the same way. If they do (such as all happening to ship some — perhaps ancient — version of Bash), then I break away from POSIX and take advantage of that commonality.

I don’t know enough about all the things these OSes do or do not have in common to truly code to the implicit standard 100% of the time. I wish I did. So, in most respects, wherever I haven’t done independent research, I have to hold myself to a much stricter standard — POSIX. But it’s only ignorance keeping me doing it!

>I don’t really care about targeting, say, IRIX, or z/OS, or the early-2000s-era Windows POSIX Subsystem.

Sure, those are very niche, but not all BSDs or every Linux distros have bash in the base distribution. And if you work with embedded system bash is very much a luxury. You mention busybox but this one is very much a crap shot because everything in busybox is opt-in. You want to use `seq`? Better make sure that it's configured. On the other hand you almost certainly won't have bash on these systems either.

At any rate if the alternative is between having to install python, ruby, perl or lua on my machine or having to maintain and hack on ginormous bash scripts I know what I'll chose.

But in general I like your approach, it's pragmatic. It's just pretty hard these days to find a system that ships bash but can't give you some decent scripting support, at least in my experience.

not just limited to embedded environments, some docker images used in cloud setups also don't have bash - alpine doesn't have it. The alpine image is used a lot, due to its small size; you can add bash easily, but bash is not part of the base image (there is a difference if you are in an ssh session to a container that doesn't have access to the net)

   docker run --rm -it alpine
   / # bash
   /bin/sh: bash: not found

Note that targeting bash on macOS means targeting bash v3, as Apple is not updating to bash v4+ (due to GPLv3) and has changed the default interactive shell to zsh in macOS 11.0+.

Using a "proper" programming language adds a dependency. If you're okay adding a dependency, then adding a dependency on bash should be fine.

The worst part of Linux development is the insistence on 'portability' when using the Unix tools. As a result bash, make, awk, have all stagnated.

With all the different shells that could be on a system like sh, zsh, ksh, csh, tcsh, ... I'm thinking that bash itself is a dependency.

Agreed. I think bash is a dependency. Even more, it's a dependency I'd want to avoid at all cost.

You can have other shells that are not bash, true. But you are guaranteed to find a bash shell in any Linux distribution (well, except minimal distros like OpenWRT or Alpine Linux that for saving space use busybox). Let's say that in any server or desktop Linux installation you find bash.

You would probably find also python, but what version? Python3? These days you are probably guaranteed to find them, except that there are old Red Hat servers still in production where is not installed. And Python3, what version? 3.7? Older? What features are safe to use and what are not? Do you have to research to find out? Or you are stuck with using Python 3.2 just to be safe? Well, in the time you wasted thinking about that, you would have finished writing the script in bash.

> Bash scripting is an anti-pattern in my opinion

Totally agree here. Shells are good for one thing: user interaction. For all the rest, use a programming language.

Except for perhaps C, Which "proper" programming language has been ported to more systems and architectures than bash?

What's a good environment that has:

1. interactive file listing and tab completion

2. the ability to run one-off lines

3. the ability to run parts of scripts and build up into a bigger script

Currently I write a lot of small-ish scripts using either bash or bash plus a text editor. I would like to use a less obtuse language than bash, but the interactive part is really important. I don't want a system where I have to run exploratory and test commands in bash and then translate them into a different language, because that means figuring out how to say it twice and doing extra debugging.

For small scripts, bash is still the easier way to go. Other programming languages are not that immediate to do simple things. How many lines of code take piping a command into another in python, for example?

Also bash is not portable, but you can assume to find a recent version of bash on any Linux system. And for BSD systems or macOS, you can install it with a command. And yes, there are other ancient UNIX systems, but who uses them? But what other programming language can you be sure to find on any system?

Finally, bash it's quite efficient. I mean that it doesn't have the weight that a full programming language like Python has, especially the time that it takes to activate the program interpreter. That could make a difference in scripts that are executed a lot of time from other script or other programs. Or even in wrapper scripts, since they doesn't add noticeable delay when executing a command.

There is still a reason to use and know bash to me. Of course implementing whole programs in bash doesn't make sense, but for simple scripts it does.

> How many lines of code take piping a command into another in python, for example?

None.

  from sh import sort, du
  from glob import glob
  print(sort(du(glob("*"), "-sb"), "-rn"))

Looks like three lines to me?

The [[ builtin is a ksh feature copied by bash. POSIX includes [[ and ]] in its list of reserved keywords but doesn't specify their behaviour.

> For anyone writing bash scripts today I would avoid the old test/[ functions entirely.

I think it's better said that anyone writing bash scripts today should always pass their script to shellcheck.net. It can even be installed locally in case sharing the script online is undesired.

Shellcheck will not only look for problems in the script but it will also usually provide some background about how the problem is a problem and a suggested workaround or solution.

You can also use shellcheck[1], which has saved me from pushing numerous potential bugs into production.

https://www.shellcheck.net/

This article appears to be discussing how to handle this case from within said shellcheck :)

> Alternatively you can use the newer (and highly recommended) bash syntax that is also quote safe

Well, mostly:

  $ a=1; b='*'; c='!'; d='*'
  $ [[ $a = $b && $c = $d ]] && echo true
  true
  $ [[ $a = "$b" && $c = "$d" ]] && echo true
  $

From the bash(1) manpage:

> When the == and != operators are used, the string to the right of the operator is considered a pattern and matched according to the rules described below under Pattern Matching, as if the extglob shell option were enabled.

POSIX syntax is more consistent and more portable:

  $ [ "$a" = "$b" ] && [ "$c" = "$d" ] && echo true
  $

I would avoid using bash for writing scripts (i.e., non-interactive use). There are better shells for scripting, like the one most Linux distributions are using, derived from the default shell in NetBSD, derived from the Almquist shell. The thing I miss most when using Linux is the default NetBSD shell. It has the speed of dash plus command line history.

> that is also quote safe

Depends on what you mean by quote safe. Quotes aren't redundant:

  $ d='*'
  $ [[ foo = $d ]]; echo $?
  0
  $ [[ foo = "$d" ]]; echo $?
  1

The post mentions the issue is fixed by POSIX, which… notably does not standarize -o -a and parens. I guess now we know why POSIX didn't standardize those.

POSIX did standardize those, but the functionality is marked XSI, so only XSI-conforming implementations are required to provide it.

There is never a reason to use them, though. They can be replaced by the shell's && and || operators, which nicely bypasses the parsing ambiguities at the same time.

> There is never a reason to use them, though. They can be replaced by the shell's && and || operators, which nicely bypasses the parsing ambiguities at the same time.

Not sure I agree. The equivalent of more complicated expressions like (a AND b) OR (c AND d) with && and || isn't always so "nice" IMO. e.g., try it for this:

  [ -f a -a -f b -o -f c -a -f d ]

I think the simplest syntax will require you to spawn subshells, which is neither particularly nice, nor particularly performant (especially on Windows).

Is this really so much worse:

   { test -f a && test -f b; } || { test -f c && test -f d; }

Yes, it's more verbose, but the original expression isn't particularly readable either, and if you'd want to evaluate something like (a OR b) AND (c OR d) you'd need to introduce parentheses anyway.

Note also that this does not need any subshells. I think dataflow was thinking of (test -f a && test -f b) || (test -f c && test -f d) instead, but { } isn't worse than that.

Yeah almost. I was thinking of

  ([ -f a ] && [ -f b ]) || ([ -f c ] && [ -f d ])

instead of

  (test -f a && test -f b) || (test -f c && test -f d)

Parentheses launch a subshell, so you probably want to use accolades instead:

{[ -f a ] && [ -f b ] ;} || { [ -f c ] && [ -f d ] ;}

With braces I'd prefer the test syntax actually, this is too many special characters to be comfortably readable for me.

And yes I know it creates subshells, that was precisely what I was saying in my comment where I said the simplest syntax I could think of (i.e. that very code) creates subshells.

It's not "so much" worse, it's just mildly worse. All I was saying here was the verbosity is a reason for using them. Obviously there are reasons not to use them too, which I said in my own top comment.

> Note that it's not even a bug here; it's necessary for disambiguation.

I would call it a bug when there's one valid way to read it, and [ fails to see it. I don't see the ambiguation. For example, zsh's [ doesn't have these errors:

  $ a=1; b=1; c='!'; d='!'
  $ [ "$a" = "$b" -a "$c" = "$d" ]; echo $?
  0
  $ [ '!' '(' "$c" = "$d" ')' ]; echo $?   
  1

Same result with FreeBSD's tcsh's [.

I think bash's [ is just lacking the ability to backtrack while parsing its arguments.

Curiously, GNU's [ fails to parse the arguments of the first, but not the second's:

  $ command [ "$a" = "$b" -a "$c" = "$d" ]; echo $? 
  [: extra argument ‘!’
  2
  $ command [ '!' '(' "$c" = "$d" ')' ]; echo $?   
  1

It seems its argument parsing works differently when using parentheses:

  $ command [ "$a" = "$b" -a '(' "$c" = "$d" ')' ]; echo $? 
  0

I was just being a little sloppy in what I wrote. I meant you can encounter ambiguities in the language when you start using -a/-o or (). I didn't mean those particular examples' parse trees are ambiguous.

Well, never seen any reason to use -a or -o. To me they are less clear and you are prone to error. I find things like: [ "$a" = "$b" ] && [ "$c" = "$d" ] much more clear.

TIL

Reply on news.ycombinator.com