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
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
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
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
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
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
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
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
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
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
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
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
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
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.
-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
-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.
16 matches
Mail list logo