Extending Bash brace expansion
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 integers
and single letters.
Unix utilities such as split generate files with multiple
letter suffixes. It
would be useful to be able to respresent these with beace
expansions. Moreover,
there are many other useful applications of extended
sequences. Extending
sequences to arbitrary strings is not difficult.
Incrementing Arbitrary Strings
Consider the process of incrementing an integer. The last
digit is incremented
until it reaches 9. At that point it wraps around to 0
and we carry the 1: if
there is only one digit in the integer, we prefix a 1;
otherwise we increment
the next digit to the left, following the same procedure
until there are no more
carries left to perform.
Letters of the alphabet have a definite sequence just as
digits do. So we can
increment them in much the same way: we increment the last
letter until we reach
"z", then we wrap around to "a" and carry the 1. The
difference is that letters
have no equivalent to zero, so when we perform a carry by
prefixing a letter, we
prefix the first letter ("a") instead of the second ("b"),
whereas with digits
we would skip the first digit (0) and prefix the second
(1) since leading zeros
have no value.
I choose to distinguish between uppercase and lowercase
letters, since brace
expansions are often used to generate file names and Unix
distinguishes between
case in file names. But uppercase letters are incremented
in the same way as
lowercase letters.
Characters other than letters and digits have no unique
ordering. So we just
don't increment them. Instead, we always carry the 1. If
we need to prefix a
character, we just copy the current character. So "-"
would be followed by
"--", and so on.
When we expand a range, the lower and upper bounds are
specified. Normally, the
upper bound will be a string as long as, or longer than,
the lower bound. So
when we need to perform a carry by prefixing a character,
we determine what
position it is in (how many columns from the right it is),
and then look at the
upper bound and see what character it has in that
position. If the upper bound
has a digit in that position we prefix a 1, if the upper
bound has a letter in
that position we prefix an "a", and if neither case is
true we copy the
character from the upper bound. But if the upper bound
has no character in that
position, we look at the leftmost character in the current
value instead.
For example, suppose that we want to expand {8..b-5}. We
generate "8" and "9",
and then we have to carry. Since there is only one
character in our current
value, we have to prefix a character, which will be placed
in the second column
from the right. Looking at the upper bound, we see that
it has a "-" in that
position. This is neither a digit nor a letter, so we
copy it and continue on,
generating "-0", "-1", "-2", "-3", "-4", "-5", "-6", "-7",
"-8", and "-9". Now
we have to prefix another character, this time in the
third column from the
right. The upper bound has a "b" in this position, which
is a letter, so we
prefix an "a". We generate "a-0", "a-1", "a-2", "a-3",
"a-4", "a-5", "a-6",
"a-7", "a-8", and "a-9". This time, when we carry we can
increment the leftmost
character. So we generate "b-0", "b-1", "b-2", "b-3",
"b-4", and "b-5". Now
we've hit the upper bound, so we're finished.
Comparing Strings
Leading zeros have no value. So when we compare two
strings we start out by
scanning past any leading zeros, then compare the
remaining strings. That way,
numeric sequences will work as expected, e.g. "00" is less
than "9" even though
"00" is a longer string.
If one string is longer than another it is deemed to be
greater. But if the two
strings are of equal length, we compare them lexically,
e.g. via strcmp(),
strcoll(), or some other such.
Examples
{0.1..2.3} generates the sequence
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 1.2 1.3 1.4
1.5 1.6 1.7 1.8 1.9 2.0 2.1 2.2 2.3
{q..af} generates the sequence
q r s t u v w x y z aa ab ac ad ae af
/usr/{ucb/{ex,edit},lib/{ex?.?*,how_ex}} still generates
the expected result:
/usr/ucb/ex /usr/ucb/edit /usr/lib/ex?.?*
/usr/lib/how_ex
data.{4,7..10,22,23,35..37} generates the sequence
data.4 data.7 data.8 data.9 data.10 data.22 data.23
data.35 data.36 data.37
--- Brian
#include
#include
#include "brace_expander.h"
#include "errors.h"
#include "expansion_data.h"
#include "stack.h"
#include "symbols.h"
// #define DEBUG
#ifdef DEBUG
#include
#define REPORT(...) printf(__VA_ARGS__)
#else
#define REPORT(...)
#endif
/*--
Expand brace expressions withi
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 really a simple regular file test existing? > 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 often used to examine the status of a file. There are string operators and numeric comparison operators as well. The behavior of test depends on the number of arguments. Read the bash manual page for the complete specification.
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 often used to examine the status of a file. There are string operators and numeric comparison operators as well. The behavior of test depends on the number of arguments. Read the bash manual page for the complete specification. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 to a regular file?
> (bash) Bash Conditional Expressions::
Unless otherwise specified, primaries that operate on files follow
symbolic links and operate on the target of the link, rather than the
link itself.
> Andreas.
Then the builtin test help need a documentation fix, right?
For some purpose, I need to make sure the file is regular (like for creating
archives); will have to do something like this?
[ -f tmp/sym-link ] && {
[ -h tmp/sym-link ] && echo do something to break the symlink
}
do something to break link
Re: Does [ -f FILE ] have a bug on testing 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 tmp/sym-link ] && echo true > true > The manual has this in addition: «Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself.» http://www.gnu.org/software/bash/manual/bashref.html#Bash-Conditional-Expressions Probably wouldn't hurt to include that in the help text for the test builtin as well. -- Geir Hauge
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 Expressions:: Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 target location. If you want to determine whether something is a symlink, you need to test that explicitly with -L or -h. imadev:~$ ln -s /etc/passwd linktopasswd imadev:~$ [ -f linktopasswd ] && echo true true imadev:~$ [ -L linktopasswd ] && echo true true Similarly, to test for a dangling symlink, you need to apply at least two separate tests: imadev:~$ ln -s nosuchthing dangling imadev:~$ [ -f dangling ] && echo true imadev:~$ [ -L dangling ] && echo true true
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 true > true Symlinks originated in BSD. GNU is implementing previously existing behavior. It is a BSD feature that migrated to System V and then to GNU and elsewhere. The behavior is now standardized by POSIX so that it will always be the same everywhere and it is possible to write portable scripts that behavior the same everywhere. The idea is that symlinks should be completely transparent and invisible to most applications. The idea is that when normal things are run they don't realize they are using a symlink. Behavior would be exactly the same as if it were a regular file system link. That is what is happening in your test case. The symlink references an existing file, is a regular file and exists, therefore the status is true. If you have an application that needs to know if something is a symlink then then you will need to test for that case explicitly. Since this is a question and not a bug in bash it would be better discussed in the help-b...@gnu.org mailing list instead. Please send future use discussion there. Thanks. Bob
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 symlink to a regular file? Read the rest of the docs: Unless otherwise specified, primaries that operate on files follow sym‐ bolic links and operate on the target of the link, rather than the link itself. > > $ [ -f tmp/sym-link ] && echo true > true which means tmp/sym-link resolved to a regular file. You need test -h to determine if you have a symlink. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 true on a symlink to a regular file? > > $ [ -f tmp/sym-link ] && echo true > true Symlinks are transparent for most purposes, and in your case the test is against the file pointed to by the symlink. If you want to test the symlink itself you can use the -h or -L test operators.
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 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 > true >
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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 symlink to a regular file? > > $ [ -f tmp/sym-link ] && echo true > true This is fundamental to how symbolic links work. Unless you test specially for a symlink and use system calls like lstat and readlink to obtain values, system calls that operate on filenames follow symbolic links (open, stat, etc.). The bash man page notes this: "Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself." -- ``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/
Does [ -f FILE ] have a bug on testing a symlink ?
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 true
Re: messy bash.git history
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. > > Yeah, when I wrote the script that constructs the snapshots, I wasn't that > proficient with git. I've pretty much left it alone since then. I'll > look at cleaning that up this week. Thanks. While at it, add autom4te.cache/ to the list of files (well, in this case, directories) not worth tracking in git (you haven't been removing that in your stray files cleanup patches). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: readline 6.3 violates POSIX by doing #undef setjmp
-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 to do the same thing for longjmp as you did for setjmp (that's > another situation where #undef longjmp puts you in portability hot water). Thanks for the report. There's a change that does this in the devel branch. - -- ``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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAlTY280ACgkQu1hp8GTqdKu0SQCfQNHWc1DGGWlfMqNa/Xqqr8d5 /PAAnRewVaP2yNfRbhBhwYfg/RSUHSvy =+xwB -END PGP SIGNATURE-
Re: messy bash.git history
-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. Yeah, when I wrote the script that constructs the snapshots, I wasn't that proficient with git. I've pretty much left it alone since then. I'll look at cleaning that up this week. Chet - -- ``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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAlTY0AYACgkQu1hp8GTqdKvYXwCgnniVagL46+ab69SrpQOWwe1q xbMAn1MAEx1/ThPa3QS4KlkVNw9Y8KTL =QQeN -END PGP SIGNATURE-
