Is this a bug? "+=" works like "=" for the first element of an array when it is not indexed and when some other conditions are met.

Here is the output I get when I run those commands:

1 members found this post helpful.

Thank you, good to know.

Indeed this unlogical (buggy?) behavior exists in older bash versions; I verified with bash-3.2 and bash-4.1.

1 members found this post helpful.

So the moral of this story is that 'c' is equivalent to 'c[0]'?

I wonder if this behavior is actually mentioned in the nearly 6000 lines of the bash manpage.

Personally, I'd always include the index when referring to the array; I hate having to remember quirks like this.

There might be 6000 lines of manpage, but the Array section is not even 6000 bytes, so it was fairly easy to find this sentence:
Which makes it an officially documented feature (and clarifies that it's not limited to += operator).

Wouldn't surprise me if it was accidental behaviour that later got documented, rather than something deliberately implemented.

Well, references to arrays are scattered amongst about 5000 of those ~6000 lines. Most folks may not run across that one line---searching for it isn't trivial (it can depend on what size terminal window you're using, for example). But then manpages aren't really created as comprehensive reference manuals on Unix/Linux topics. The GNU tutorial on bash arrays is much more useful and I didn't see that quirk mentioned in there. (Doesn't mean it isn't in there; it's just not mentioned very prominently.) Still think it's a poor practice to follow documented or not. "[0]" just leaps out at ya and says "this is an array reference even though you may have forgotten about that 'declare' statement 200 lines above".

Slight Aside: Years ago, a co-worker discovered -- probably by accident (we were unable to find anything in Big Blues docs that said this was valid) -- that the IBM Fortran compiler would accept a statement like "DO100I=1,1000" instead of the "DO 100 I = 1, 1000" that would normally be used. He considered it a triumph of disk space savings ("Hey! Saved five bytes of disk space!") and went on to crank out a ton of code that had to be re-edited in case it was ever re-hosted on another vendor's system -- it eventually was, of course -- and thank $DIETY I had a student intern I could count on to help make those edits). Omitting "[0]" from bash arrays seems like the same pointless exercise in disk space or keystroke savings.

So what other interesting oddities are hiding in bash's syntax? :^)

Note: these two are both valid, but do different things:

Am I misreading or did you mistype something, because that seems to be saying that over 80% of the Bash manual refers to arrays?!

On an 80 column terminal I get 144 instances in 6175 lines (using man bash | wc -l and man bash | grep -io array | wc -l)


Well the HTML manual has a table of contents, which means searching is <ctrl-f> "arrays" <click> rather than the "/arrays nnnnnnnn" it takes to get to the section in the man page, but the latter is not that bad, and even on a claustrophobic 80x24 terminal I'd still say it is trivial to find the reference.

The point you should be making is more that most people don't tend to go looking, at least not until they notice oddness, (and even then I find myself in a minority of people who actually check the documentation).

Languages should aim to follow the principle of least surprise just as much as other areas of computing, and this clearly violates that.


I'd condemn it with something stronger than "poor practice" - I only meant to suggest a bug report would probably be a waste of effort, not that it should ever be used.