Re: 'test' builtin of bash returns wrong value for '! -a FILE' operation

tags 426990 - moreinfo tags 426990 + upstream # documentation bug severity 426990 minor retitle 426990 bash: "help test" gives no hint of complicated precedence rules quit OZAKI Masanobu wrote: > On Fri, 2010-11-05 at 03:17:13 -0500, Jonathan Nieder > wrote: >>> P

Re: cd --help should output the complete man page

Hi Faheem, Faheem Mitha wrote: > $ cd --help > bash: cd: --: invalid option > cd: usage: cd [-L|-P] [dir] > > I'm don't even know how to get the usage output without > inducing an error. Does "help cd" do the trick? > I think a man page might also be a good idea. You may > als

Re: bash: $() doesn't preserve new lines

Hi again, Dmitry Baryshev wrote: > 2011/4/14 Jonathan Nieder >> ? Note that 'echo' is an ordinary built-in utility, which will behave >> in most respects like an external utility. So the expansion gets >> passed to it as a sequence of arguments. As "help

Re: bug on [A-Z] and [a-z]

Hi, ri...@inf.ufpr.br wrote: > When running "echo [A-Z]*" , it shows all files/dirs of current > directory, not only those starting with capital letters. I tried > different locales such as: POSIX, C, en_US, pt_BR > > Repeat-By: > $ mkdir a && cd a > $ touch a b c; mkdir D

Re: eval

Hi Rafael, Rafael Fernandez wrote: > set -- a b c d e f g h i j k l m n o p q r s t u v w x y z > i=1 > eval echo '$'$i # outputs an expected 'a' > i=10 > eval echo '$'$i # outputs 'a0'; expected 'j' > i=11 > eval echo '$'$i

Re: eval

Rafael Fernandez wrote: > Thanks, I wasn't aware that positional parameters greater than nine have to > be enclosed in brackets. No prob. The manpage says When a positional parameter consisting of more than a single digit is expanded, it must be enclosed in braces (see E

[PATCH/RFC] bash.1: "shopt -s checkwinsize" has no effect in non-interactive shells

Explain that COLUMNS and LINES are not set automatically in non-interactive shells, and recommend direct use of the tput utility from ncurses as a replacement. Fixes: http://bugs.debian.org/628638 Reported-by: Leslie A Rhorer Helped-by: Leslie A Rhorer --- Hi Chet et al, Here's a quick document

Re: printf treats arguments of "%c" not as expected

Hi, Yunfeng Wang wrote: > $ printf %c 65 66 67 > 666 > > The expected output is ABC, i.e. characters with ASCII code of 65 66 67 I believe the current behavior is correct. POSIX (XCU.4.printf) sayeth[*]: 11. The argument to the 'c' conversion specifier can be a string

License details for bash-4.2

Hi, Adrian Bunk wrote: > /usr/share/doc/bash/copyright says: [...] > the terms of the GNU General Public License as published by the Free > Software Foundation; either version 2, or (at your option) any later [...] > The source files say: [...] >it under the terms of the GNU General Public Li

License of bash manpage (Re: License details for bash-4.2)

Hi Chet et al, Jonathan Nieder wrote: [concerning licensing] > Looking over bash 4.2, I have a few questions: After investigating a little more and testing with files removed, I'm down to one question (though it would still be nice to clarify the licenses of the other files mentioned):

Re: License of bash manpage (Re: License details for bash-4.2)

Chet Ramey wrote: > The man page copyright belongs to me -- I don't know that I ever > assigned it to the FSF. I don't have a problem with others modifying the > man page, and expect it under certain circumstances. For instance, if a > distribution modifies the startup files bash reads (e.g., to

Re: License of bash manpage (Re: License details for bash-4.2)

Chet Ramey wrote: > I wrote the entire test suite except for the one file from Glen Fowler. > It is (or should be) copyright GPL3 just like the rest of the distribution. Just wanted to say thanks for the clear and quick responses. They helped. Jonathan

Re: integer addition crash

Hi Cédric, Cédric Martínez Campos wrote: > $ echo $((08+1)) > bash: 08: too big element for the base (the error element is "08") > [translated from spanish] Strings of digits starting with a '0' in an arithmetic expansion are octal numbers. The bash FAQ[*] has some details. Hope th

Re: pwd as first command changes script behavior

Hi Sam, Quiring, Sam wrote: > #! /bin/bash > pwd > echo $_ > > #! /bin/bash > echo $_ > pwd > > The first one displays: > /home/windriver/changes/NexS-235r1/with-camera > pwd > > The second one displays: > ./apply.sh > /home/windriver/changes/NexS-235r1/with-camera That's what $_ is advertised t

Re: Execution strange when get lines of the console in script with command substitution and the rediretion of the stderr.

(+cc: help-bash, -cc: bug-bash, bcc: bug-bash) Hi, QGZ wrote: > $ cat abc.sh > #!/bin/bash > tput lines > echo $(tput lines) [...] > $ ./abc.sh 2>/dev/null > > We will get : > 50 > 24 This is an ncurses question, not a "bash" questi

Re: Restricted Bash - Not so restrictive (in 4.2 as well)

Hi, Sarnath K - ERS, HCLTech wrote: > I see this problem in the latest Bash 4.2 as well. Say, I invoke > "rbash" or "bash -r". This leaves me in a restrictive shell. > However, this restrictive shell allows me to run "bash" or any other > shell (without execing - just simply run) which leaves me

Re: Restricted Bash - Not so restrictive (in 4.2 as well)

Sarnath K - ERS, HCLTech wrote: > Apart from this, BASH Documentation says "When a command that is > found to be a shell script is executed (see COMMAND EXECUTION > above), rbash turns off any restrictions in the shell spawned to > execute the script.". > > Does this mean that a guy with restric

Re: Bash scripting and large files: input with the read builtin from a redirection gives unexpected result with files larger than 2GB.

Hi Chet, Chet Ramey wrote: > Compile and run the attached program. If it prints out `4', which it does > on all of the Debian systems I've tried, file offsets are limited to 32 > bits, and accessing files greater than 2 GB is going to be unreliable. off_t is typedef'd to off64_t if you compile

Re: Bug/limitation in 'time'

-bug-bash, +help-bash Bruce Dawson wrote: > Chris Down pointed that out. My loop now looks like this -- portable (I > believe) and fast: > > BashCount() { > for (( i = $1 ; i > 0 ; i-- )); do Not actually portable to non ksh-based shells. See for hints. Hope

Re: [bash] wait: specify that you can only wait for child PIDs

Hi, Török Edwin wrote[1]: > $ wait 1 > bash: wait: pid 1 is not a child of this shell > > The manpage of bash, dash and wait should mention that the PID has to be a > child of the shell. How about this patch? (Should be applicable to the "devel" branch by saving this message in mbox format and