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: Built-in "test -x" fails for root on FreeBSD
On 03/26/2010 11:47 PM, Johan Hattne wrote: > Description: > The bash built-in test command fails to correctly report executable > status for non-executable files when run by root on FreeBSD. Not a bug. POSIX states for test -x: True if pathname resolves to an existing directory entry for a file for which permission to execute the file (or search it, if it is a directory) will be granted, as defined in File Read, Write, and Creation. http://www.opengroup.org/onlinepubs/9699919799/utilities/test.html It further states: If a process has appropriate privileges: * If read, write, or directory search permission is requested, access shall be granted. * If execute permission is requested, access shall be granted if execute permission is granted to at least one user by the file permission bits or by an alternate access control mechanism; otherwise, access shall be denied. http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_04 It also states for faccessat (eaccess is a non-portable interface comparable to the standardized faccessat): If any access permissions are checked, each shall be checked individually, as described in XBD File Access Permissions , except that where that description refers to execute permission for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user. http://www.opengroup.org/onlinepubs/9699919799/functions/access.html 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. > #if defined (HAVE_EACCESS)/* FreeBSD */ > - return (eaccess (path, mode)); > + if (stat (path, &s) != 0) > +return (-1); > + ret = eaccess (path, mode); > + if (mode == X_OK && ret == 0 && !S_ISDIR(s.st_mode) && geteuid() == 0) > +return ((s.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) == 0 ? -1 : 0); > + return (ret); This patch fails to take into account ACLs, which is one of the reasons that faccessat was standardized. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: compiling BASH on windows without cygwin not possible
On 03/26/2010 09:59 PM, Jim Michaels wrote: > configure is a BASH script. Am I not correct in stating that BASH requires > BASH to install? No. Bash requires a quasi-POSIX-conformant shell to be built, but can be installed without the use of such a shell. Your complaint that bash cannot be bootstrapped on windows is not true. You can build it on another machine, using a cross-compiler, then copy the resulting executable over. And since bash is not the only shell that has been ported to windows, you could start your bash-on-windows build by installing another ported shell instead of bash. > > windows does not come with any such sh shell. and I need to be able to build > one from scratch. You can obtain bash pre-built for windows by going to cygwin.com. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
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/10 09:01, Eric Blake wrote: > On 03/26/2010 11:47 PM, Johan Hattne wrote: >> Description: >> The bash built-in test command fails to correctly report executable >> status for non-executable files when run by root on FreeBSD. > > Not a bug. POSIX states for test -x: > > True if pathname resolves to an existing directory entry for a file for > which permission to execute the file (or search it, if it is a > directory) will be granted, as defined in File Read, Write, and Creation. > http://www.opengroup.org/onlinepubs/9699919799/utilities/test.html But the last sentence in the paragraph quoted states "False if pathname cannot be resolved, or if pathname resolves to an existing directory entry for a file for which permission to execute (or search) the file will not be granted". >If a process has appropriate privileges: ... > * If execute permission is requested, access shall be granted if > execute permission is granted to at least one user by the file > permission bits or by an alternate access control mechanism; otherwise, > access shall be denied. > > http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_04 I'm OK with that--for root, "test -x" should return true as long as there exists at least one user who has execute permission. > 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? > If any access permissions are checked, each shall be checked > individually, as described in XBD File Access Permissions , except that > where that description refers to execute permission for a process with > appropriate privileges, an implementation may indicate success for X_OK > even if execute permission is not granted to any user. > http://www.opengroup.org/onlinepubs/9699919799/functions/access.html Yes, so the FreeBSD access functions don't break the Open Goup specification. > 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 defined (HAVE_EACCESS)/* FreeBSD */ >> - return (eaccess (path, mode)); >> + if (stat (path, &s) != 0) >> +return (-1); >> + ret = eaccess (path, mode); >> + if (mode == X_OK && ret == 0 && !S_ISDIR(s.st_mode) && geteuid() == 0) >> +return ((s.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) == 0 ? -1 : 0); >> + return (ret); > > 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? Regarding ACLs, I'm not sure they're checked on any other operating system either. As far as I can see from bash's sh_stataccess function, "test -x" ANDs the st_mode bits with S_IXGUO. // Best wishes; Johan
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
Completion List color
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. Regards, -- MJ
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/
Re: Bash sometimes cannot find aliases
Good news: I met this problem again a few minutes ago. Then I looked back to find out what I was doing. After some investigation I could stably reproduce this problem by following steps (tested with bash 3.1.17, 3.2.39 and 4.1.0): bash$ alias xx='echo 142857'### Make sure there isn't an external cmd named `xx' bash$ export EDITOR=vi bash$ set -o vi bash$### Press ESC to get out of vi's INSERT mode bash$### Press v to invoke vi to input a cmd like `ls', save and exit, the `ls' cmd runs. bash$ xx -bash: xx: command not found bash$ xx 142857 bash$ On Fri, Jan 29, 2010 at 9:29 AM, Clark J. Wang wrote: > On Thu, Jan 28, 2010 at 4:55 PM, Dan Zwell wrote: > >> Configuration Information [Automatically generated, do not change]: >> Machine: x86_64 >> OS: linux-gnu >> Compiler: gcc >> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' >> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' >> -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' >> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64 >> -mtune=generic -O2 -pipe >> uname output: Linux mordor 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 18 23:30:46 >> CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel >> GNU/Linux >> Machine Type: x86_64-unknown-linux-gnu >> >> Bash Version: 4.1 >> Patch Level: 2 >> Release Status: release >> >> Description: >>When I attempt to run an alias, Bash occasionally says the command >> is not found. Re-running the command generally succeeds. This also occurs >> with aliases that are named after existing programs. For example, running >> "ls", which is aliased to "ls --color", occasionally results in "ls" being >> run without the "--color" argument (the alias is bypassed). >> >> Repeat-By: >>This problem seems to occur once every few hundred aliased commands >> I run. It seems more frequent immediately after sourcing a .bashrc file. I >> cannot reproduce it with a loop that repeatedly runs an aliased command. >> >> Is this a known issue? I may be able to help debug this (perhaps by >> modifying my build to log state when a command is not found). >> >> I have the same problem. It's not 4.1 specific. I don't know how to > reproduce it either but I can see it from time to time. > >> Thanks >> -Dan >> >> >> >
Re: Bash sometimes cannot find aliases
Bash 2.05b also reproduces this problem. On Tue, Mar 30, 2010 at 2:36 PM, Clark J. Wang wrote: > Good news: > > I met this problem again a few minutes ago. Then I looked back to find out > what I was doing. After some investigation I could stably reproduce this > problem by following steps (tested with bash 3.1.17, 3.2.39 and 4.1.0): > > bash$ alias xx='echo 142857'### Make sure there isn't an external cmd > named `xx' > bash$ export EDITOR=vi > bash$ set -o vi > bash$### Press ESC to get out of vi's INSERT mode > bash$### Press v to invoke vi to input a cmd like `ls', save and exit, > the `ls' cmd runs. > bash$ xx > -bash: xx: command not found > bash$ xx > 142857 > bash$ > > > On Fri, Jan 29, 2010 at 9:29 AM, Clark J. Wang wrote: > >> On Thu, Jan 28, 2010 at 4:55 PM, Dan Zwell wrote: >> >>> Configuration Information [Automatically generated, do not change]: >>> Machine: x86_64 >>> OS: linux-gnu >>> Compiler: gcc >>> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' >>> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' >>> -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' >>> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64 >>> -mtune=generic -O2 -pipe >>> uname output: Linux mordor 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 18 23:30:46 >>> CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel >>> GNU/Linux >>> Machine Type: x86_64-unknown-linux-gnu >>> >>> Bash Version: 4.1 >>> Patch Level: 2 >>> Release Status: release >>> >>> Description: >>>When I attempt to run an alias, Bash occasionally says the command >>> is not found. Re-running the command generally succeeds. This also occurs >>> with aliases that are named after existing programs. For example, running >>> "ls", which is aliased to "ls --color", occasionally results in "ls" being >>> run without the "--color" argument (the alias is bypassed). >>> >>> Repeat-By: >>>This problem seems to occur once every few hundred aliased >>> commands I run. It seems more frequent immediately after sourcing a .bashrc >>> file. I cannot reproduce it with a loop that repeatedly runs an aliased >>> command. >>> >>> Is this a known issue? I may be able to help debug this (perhaps by >>> modifying my build to log state when a command is not found). >>> >>> I have the same problem. It's not 4.1 specific. I don't know how to >> reproduce it either but I can see it from time to time. >> >>> Thanks >>> -Dan >>> >>> >>> >> >
