Don't get me wrong, I am a full time bash script programmer and I do know how
man pages (and their syntax) look like. I use this syntax myself in every
usage() I write...
Still I think it is misleading.
I simply cannot see how a newb can tell the difference between a bracket that's
part of the syntax:
[...]Any element of an array may be referenced using ${name[subscript]}.[...]
.. and one that's not:
[...]Constants with a leading 0 are interpreted as octal numbers. A leading
0x or 0X denotes hexadecimal. Otherwise, numbers take the form [base#]n,
where base is a decimal number between 2 and 64 representing the arithmetic
base, and n is a number in that base. If base# is omitted, then base 10 is
used.[...]
Granted, it states that base# can be omitted, but I still cannot tell why it is
an "optional" indicator here and "part of the syntax" with the array
explanation. (where it basically can be left out as well to get just the first
element, so it isn't mandatory). It could be part of the syntax here equally
well in my understanding..
But things get even more complicated with array assignments:
[...]Arrays are assigned to using compound assignments of the form name=(value1
... valuen), where each value is of the form [subscript]=string. Indexed array
assignments do not require the bracket and subscript. When assigning to indexed
arrays, if the optional brackets and subscript are supplied, that index is
assigned to[...]
If everything in brackets is optional it should be [subscript=]string or the
value will be a literal "=string" if the optional [subscript] gets left out...
Please don't get me wrong. I have no problem in understanding the man page this
way, but I do think it is inconsistent. And I absolutely understand why, as
there are multiple meanings for a poor little bracket ;->
On Mon, 03/29, 2010 02:51:18PM, Greg Wooledge wrote:
> On Mon, Mar 29, 2010 at 02:22:35PM +0200, Thomas Bartosik wrote:
> > Well OK, I understand. Still I think there should be a difference in the
> man
> > page when it comes to brackets. When talking about arrays, the brackets
> are
> > NOT an option but mandatory.
>
> That's correct. Referencing a specific element of an array by index
> uses square brackets as part of the syntax.
>
> > (and it might be me being uneducated, but how to you print out the
> decimal equivalent of binary 11 without using brackets? I can only produce the
> correct value "3" by
> > echo $[2#11]
>
> The $((...)) notation is preferred and documented.
>
> echo $((2#11))
>
> > The "optional" refers to being able to not use it when operating on a
> normal
> > decimal number as I understand this now. Then where can I find that I
> have to
> > use brackets like I use them -- which only is a side effect of the
> brackets I
> > have seen in the man page and seems unrelated on the whole!)
>
> You are confusing literal square brackets which are part of the syntax
> of a command (as in array indexing) with the brackets used in man pages
> and other documents to indicate that something is optional.
>
> We're not saying that literal square brackets are optional when doing
> array indexing. We're saying that the things INSIDE brackets in a man
> page are optional -- and that the brackets themselves are NOT part of
> the command at all, but rather, part of the documentation.
>
> I understand how it's easy to get confused by that, but eventually
> you'll have to get used to it.
>
> Look at ls(1) from Debian as an example:
>
> SYNOPSIS
> ls [OPTION]... [FILE]...
>
> Or from HP-UX:
>
> SYNOPSIS
> ls [-abcdefgilmnopqrstuxACFLR1] [names]
>
> Or from OpenBSD:
>
> SYNOPSIS
> ls [-1AaCcdFfghikLlmnopqRrSsTtux] [file ...]
>
> See the brackets there? They indicate that the options and filenames
> are optional. They don't mean that you type literal square brackets
> around the options and filenames.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
