Re: manpage error-Arithmetic Evaluation of numbers with explicit base
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. (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 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!) On 03/2310 03:05 AM, chet.ra...@case.edu wrote: On 3/22/10 9:13 AM, tbart...@gmx-topmail.de wrote: Bash Version: 4.0 Patch Level: 35 Release Status: release Description: The man page seems to be wrong regarding the handling of numbers with different bases. It states one has to use [base#]n although it seems to be [base#n] that needs to be used... The meta-notation [x] means that x is optional. This usage is fairly common, especially in Unix man pages. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern E-Mail, SMS mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail
Re: manpage error-Arithmetic Evaluation of numbers with explicit base
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.
Re: manpage error-Arithmetic Evaluation of numbers with explicit base
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
Re: manpage error-Arithmetic Evaluation of numbers with explicit base
Le 29/03/2010 14:50, Thomas Bartosik a écrit : Please don't get me wrong. I have no problem in understanding the man page this way, but I do think it is inconsistent. It's a pity that square brackets are used both in the language itself and in its syntactic definitions but this is bound to happen when there is a fairly limited number of characters available. So what do you suggest? Removing brackets from POSIX is going to be quite challenging. Getting rid of them in syntactic definitions is probably even less realistic considering how they are universally used to describe optional elements (even in EBNF). So I do not think you can do any better than trying to make sure the context makes things obvious enough on a case by case basis. What are your suggestions to make the Arithmetic Evaluation page more obvious? By the way I do not think the Bash manual is meant for newbies. It is a reference manual and there are tons and tons of other, free resources better suited to newbies. Cheers, Marc
Re: Built-in test -x fails for root on FreeBSD
On 03/29/2010 10:36 AM, Johan Hattne wrote: It also states for faccessat (eaccess is a non-portable interface comparable to the standardized faccessat): But faccessat() does not really have anything to do with test? test(1) should be implemented using faccessat(2) or equivalent, in order to properly honor ACLs. On systems that lack faccessat, then eaccess() is a good fallback. Therefore, it is perfectly acceptable for the root user to claim that a file is executable, as reported by eaccess, even if none of the file permission bits grant such permission. Yes, but test should still return false if the file isn't executable by anybody on the system. If eaccess() lies and returns true even though the file is not executable by anybody on the system (including the superuser), then that is a bug in eaccess(), not in test(1). This patch fails to take into account ACLs, which is one of the reasons that faccessat was standardized. But faccessat() is equivalent to access() except in the case where the path is relative? faccessat(AT_FDCWD, name, mode, 0) is equivalent to access(name, mode), regardless of whether name is relatived (it differs from access only when the first argument is not AT_FDCWD and when name is relative). faccessat(AT_FDCWD, name, mode, AT_EACCESS) is equivalent to eaccess (name, mode). test(1) should use faccessat(AT_FDCWD, name, mode, AT_EACCESS). Regarding ACLs, I'm not sure they're checked on any other operating system either. YES THEY ARE. Cygwin is proof of a system that has _properly_ implemented faccessat() in the face of ACLs. It is _entirely_ possible for stat() to claim that a file cannot be accessed by the owner, group, or world, but where ACLs show that the current effective id _can_ execute it, and that is the case that faccessat is designed to detect, which must then be fed into test -x. As far as I can see from bash's sh_stataccess function, test -x ANDs the st_mode bits with S_IXGUO. That's because bash's sh_stataccess is a workaround for systems that lack POSIX 2008 compliance - no one ever claimed that the workaround is as good as the real thing. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Built-in test -x fails for root on FreeBSD
On 03/29/10 11:42, Eric Blake wrote: Therefore, it is perfectly acceptable for the root user to claim that a file is executable, as reported by eaccess, even if none of the file permission bits grant such permission. Yes, but test should still return false if the file isn't executable by anybody on the system. If eaccess() lies and returns true even though the file is not executable by anybody on the system (including the superuser), then that is a bug in eaccess(), not in test(1). The way I read the specifications, it can be OK for eaccess(2) and friends to say something's executable when it really isn't, while it's not OK for test(1) to return false positives. I still believe this is a bash bug. Regarding ACLs, I'm not sure they're checked on any other operating system either. YES THEY ARE. Cygwin is proof of a system that has _properly_ implemented faccessat() in the face of ACLs. It is _entirely_ possible for stat() to claim that a file cannot be accessed by the owner, group, or world, but where ACLs show that the current effective id _can_ execute it, and that is the case that faccessat is designed to detect, which must then be fed into test -x. What I meant was that I don't think there's any consideration of ACLs in bash's built-in test. I don't seem to have any calls to faccessat() in my bash source tree. As far as I can see from bash's sh_stataccess function, test -x ANDs the st_mode bits with S_IXGUO. That's because bash's sh_stataccess is a workaround for systems that lack POSIX 2008 compliance - no one ever claimed that the workaround is as good as the real thing. To me it looks like whenever one does test -x in bash one will end up calling either eaccess(2) or stat(2). // Best wishes; Johan
Re: Completion List color
On 3/29/10 4:40 PM, MJ wrote: Hi, I was wondering if there is a way to set the color used for the completion listing? I would like it to stand out somewhat compared to my default prompt color. There is currently no way to do that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
