Extending Bash brace expansion

2015-02-09 Thread McGuinness, Brian
Extended Brace Expansions The enclosed code implements an extended version of the Bash brace expansion. The main objectives are: * Allow plain text and sequences to be used together in a brace expression, e.g. file.{7,14,22..30,56,80..84} * Generalize sequences so they are not limited to

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Cheng Rk
On Monday, February 9, 2015 3:13 PM, Andreas Schwab wrote: Cheng Rk writes: >> Then the builtin test help need a documentation fix, right? You're addressing different lines but I am saying this line is inaccurate, right? -f FILETrue if file exists and is a regular file. Is there

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Andreas Schwab
Cheng Rk writes: > Then the builtin test help need a documentation fix, right? test: test [expr] Evaluate conditional expression. Exits with a status of 0 (true) or 1 (false) depending on the evaluation of EXPR. Expressions may be unary or binary. Unary expressions are oft

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Cheng Rk
On Monday, February 9, 2015 1:59 PM, Andreas Schwab wrote: >> According this documentation `help test`, I am expecting it should return >> false on anything other than a regular file, >> >> -f FILETrue if file exists and is a regular file. >> >> >> but why it returned true on a symlink

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Geir Hauge
2015-02-09 22:00 GMT+01:00 Cheng Rk : > According this documentation `help test`, I am expecting it should return > false on anything other than a regular file, > > -f FILETrue if file exists and is a regular file. > > > but why it returned true on a symlink to a regular file? > > $ [ -f t

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Andreas Schwab
Cheng Rk writes: > According this documentation `help test`, I am expecting it should return > false on anything other than a regular file, > > -f FILETrue if file exists and is a regular file. > > > but why it returned true on a symlink to a regular file? (bash) Bash Conditional Expres

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Greg Wooledge
On Mon, Feb 09, 2015 at 09:00:12PM +, Cheng Rk wrote: > -f FILETrue if file exists and is a regular file. > > but why it returned true on a symlink to a regular file? > > $ [ -f tmp/sym-link ] && echo true > true It's supposed to work this way. -f resolves symlinks and tests the tar

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Bob Proulx
Cheng Rk wrote: > According this documentation `help test`, I am expecting it should > return false on anything other than a regular file, > > -f FILETrue if file exists and is a regular file. > > but why it returned true on a symlink to a regular file? > > $ [ -f tmp/sym-link ] && echo

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Eric Blake
On 02/09/2015 02:00 PM, Cheng Rk wrote: > > > To bug-bash@gnu.org: > > > According this documentation `help test`, I am expecting it should return > false on anything other than a regular file, > > -f FILETrue if file exists and is a regular file. > > > but why it returned true on a

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Ken Irving
On Mon, Feb 09, 2015 at 09:00:12PM +, Cheng Rk wrote: > > To bug-bash@gnu.org: > > According this documentation `help test`, I am expecting it should > return false on anything other than a regular file, > > -f FILETrue if file exists and is a regular file. > > but why it returned t

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Evan Gates
from bash(1): Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself. On Mon, Feb 9, 2015 at 1:00 PM, Cheng Rk wrote: > > > To bug-bash@gnu.org: > > > According this documentation `help test`, I am expe

Re: Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Chet Ramey
On 2/9/15 4:00 PM, Cheng Rk wrote: > > > To bug-bash@gnu.org: > > > According this documentation `help test`, I am expecting it should return > false on anything other than a regular file, > > -f FILETrue if file exists and is a regular file. > > > but why it returned true on a syml

Does [ -f FILE ] have a bug on testing a symlink ?

2015-02-09 Thread Cheng Rk
To bug-bash@gnu.org: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? $ [ -f tmp/sym-link ] && echo true

Re: messy bash.git history

2015-02-09 Thread Eric Blake
On 02/09/2015 08:19 AM, Chet Ramey wrote: > On 2/6/15 4:13 PM, Eric Blake wrote: >> Chet, > >> I've noticed that your 'devel' branch in bash.git is rather messy; >> basically lots of commits that snapshot the state of a directory, then >> a followup commit that removes leftovers and stray files.

Re: readline 6.3 violates POSIX by doing #undef setjmp

2015-02-09 Thread Chet Ramey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/6/15 4:50 PM, Eric Blake wrote: > ./lib/readline/libreadline.a(util.o): In function `rl_abort_internal': > /home/eblake/bash/lib/readline/util.c:115: undefined reference to > `siglongjmp' > collect2: error: ld returned 1 exit status > > You need

Re: messy bash.git history

2015-02-09 Thread Chet Ramey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/6/15 4:13 PM, Eric Blake wrote: > Chet, > > I've noticed that your 'devel' branch in bash.git is rather messy; > basically lots of commits that snapshot the state of a directory, then > a followup commit that removes leftovers and stray files.