Re: nocaseglob
> It's worth noting here that bash's globbing of '[A-Z]*' etc is
> definitely different from the system collation sequence (i.e. using
> fnmatch() or glob() functions). There is an open bug report about this
> here:
On the contrary, the bash globbing of [A-Z] is using exactly the system's
collating sequence. Bash uses strcoll; glibc/python probably use character
value comparisons for old-style bracket range expressions.
Running the attached program like
asort -v {a..z} {A..Z}
will give you the current locale and show how the arguments sort. I get
$ ./asort -v {a..z} {A..Z}
default locale = en_US.UTF-8
a A b B c C d D e E f F g G h H i I j J k K l L m M n N o O p P q Q r R s S t T
u U v V w W x X y Y z Z
$ LC_ALL=en_US ./asort {a..z} {A..Z}
a A b B c C d D e E f F g G h H i I j J k K l L m M n N o O p P q Q r R s S t T
u U v V w W x X y Y z Z
This shows the collating sequence for alphabetics in the en_US locale. (Since
I don't set LC_ALL anywhere in my startup files, my system's default locale is
apparently en_US.UTF-8.)
Chet
#include
#include
#include
#include
#include
static int
qsort_strcmp(s1, s2)
char**s1, **s2;
{
return (strcoll(*s1, *s2));
}
static void
usage()
{
fprintf(stderr, "asort: usage: asort [-v] args\n");
}
int
main(c, v)
int c;
char**v;
{
int i, verbose;
char*dlocale;
verbose = 0;
while ((i = getopt(c, v, "v")) != -1) {
switch (i) {
case 'v':
verbose = 1; break;
case '?':
default:
usage();
exit(2);
}
}
c -= optind;
v += optind;
dlocale = setlocale(LC_ALL, "");
if (verbose)
printf("default locale = %s\n", dlocale ? dlocale : "''");
qsort(v, c, sizeof(char *), qsort_strcmp);
for (i = 0; i < c; i++) {
printf("%s ", v[i]);
}
printf("\n");
exit(0);
}
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
Chet Ramey wrote: > This shows the collating sequence for alphabetics in the en_US locale. (Since > I don't set LC_ALL anywhere in my startup files, my system's default locale is > apparently en_US.UTF-8.) Is _that_ the deal, then? There is such a thing as a "system default locale" that does not show up in my environment variables? If so, then that is what I want to change. Having ``[a-z]*'' match _any_ capitalized names is, in my completely unhumble opinion, nuts. It is really cute and spiffy dazzling keeno for looking at ls output, but it makes selecting file names an utter drag. That's far more important to me. So, I'll go Googling for "system default locale" and see if I can't fix this issue. Thanks - Bruce ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
[EMAIL PROTECTED] wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
> uname output: Linux kansas 2.4.18-26.7.x #1 Mon Feb 24 10:15:02 EST 2003 i686
> unknown
> Machine Type: i686-pc-linux-gnu
>
> Bash Version: 3.2
> Patch Level: 0
> Release Status: release
>
> Description:
> A simple regexp match using =~ inside [[ ]] works on 3.0.16
> and 3.1 versions of bash, but doesn't in 3.2.
>
> In pre-3.2 versions, the script in "Repeat-By" (below)
> produces one line of output: "Dog 01 is Wiggles". In 3.2, the
> regexp no longer matches, so it produces nothing.
>
> Repeat-By:
> # run this, eh?
> DOG="Dog name - 01 - Wiggles"
> if [[ $DOG =~ "([[:alpha:][:blank:]]*)- ([[:digit:]]*) - (.*)$" ]]
> then
> echo Dog ${BASH_REMATCH[2]} is ${BASH_REMATCH[3]}
> fi
One of the changes between bash-3.1 and bash-3.2 was to unify the handling
of the pattern in the `==' and `=~' conditional command operators. Pattern
characters on the rhs are quoted to represent themselves (remove their
special pattern meaning). This is how == has always worked. If you remove
the double quotes and use backslashes to escape the spaces in the pattern,
you will get the match you want.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
Bruce Korb wrote: Chet Ramey wrote: This shows the collating sequence for alphabetics in the en_US locale. (Since I don't set LC_ALL anywhere in my startup files, my system's default locale is apparently en_US.UTF-8.) Is _that_ the deal, then? There is such a thing as a "system default locale" that does not show up in my environment variables? ...while I agree that having the default locale be other than 'C' or 'POSIX' (whichever is appropriate) seems idiotic... If so, then that is what I want to change. Having ``[a-z]*'' match _any_ capitalized names is, in my completely unhumble opinion, nuts. ...you do know about using '[[:lower:]]' instead of '[a-z]', right? -- Matthew Don't read this. What did I just tell you? Why are you still reading? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
Chet Ramey <[EMAIL PROTECTED]> writes: > On the contrary, the bash globbing of [A-Z] is using exactly the system's > collating sequence. Bash uses strcoll; glibc/python probably use character > value comparisons for old-style bracket range expressions. glibc definitely uses strcoll as well. Most likely python has its own implementation which gets it wrong. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
On Tue, 23 Jan 2007, Chet Ramey wrote:
[EMAIL PROTECTED] wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux kansas 2.4.18-26.7.x #1 Mon Feb 24 10:15:02 EST 2003 i686
unknown
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 0
Release Status: release
Description:
A simple regexp match using =~ inside [[ ]] works on 3.0.16
and 3.1 versions of bash, but doesn't in 3.2.
In pre-3.2 versions, the script in "Repeat-By" (below)
produces one line of output: "Dog 01 is Wiggles". In 3.2, the
regexp no longer matches, so it produces nothing.
Repeat-By:
# run this, eh?
DOG="Dog name - 01 - Wiggles"
if [[ $DOG =~ "([[:alpha:][:blank:]]*)- ([[:digit:]]*) - (.*)$" ]]
then
echo Dog ${BASH_REMATCH[2]} is ${BASH_REMATCH[3]}
fi
One of the changes between bash-3.1 and bash-3.2 was to unify the handling
of the pattern in the `==' and `=~' conditional command operators. Pattern
characters on the rhs are quoted to represent themselves (remove their
special pattern meaning). This is how == has always worked. If you remove
the double quotes and use backslashes to escape the spaces in the pattern,
you will get the match you want.
Hi, Chet. Thanks for the explanation. I see the value in making ==
and =~ behave the same. However, we seem to have lost the ability to
use groupings to store results in BASH_REMATCH.
Escaping the spaces in the pattern doesn't work (though it does change
the error). I had actually tried that (in fact, I had tried every way
of escaping that pattern that I could think of) before sending in the
bashbug.
Using this pattern (spaces backslashed, double quotes removed):
if [[ $DOG =~ ([[:alpha:][:blank:]]*)-\ ([[:digit:]]*)\ -\ (.*)$ ]]
Yields this;
D:/tmp $ ~/src/bash-3.2/bash ./reduce.sh
Dog 01 is Wiggles
./reduce.sh: line 8: unexpected argument `(' to conditional binary
operator
./reduce.sh: line 8: syntax error near `(['
./reduce.sh: line 8: `if [[ $DOG =~ ([[:alpha:][:blank:]]*)-\
([[:digit:]]*)\ -\ (.*)$ ]]'
If I remove the grouping parens and leave the spaces escaped, like so:
if [[ $DOG =~ [[:alpha:][:blank:]]*-\ [[:digit:]]*\ -\ .*$ ]]
then I get a match, but $BASH_REMATCH is empty (since no groupings
were stored away):
D:/tmp $ ~/src/bash-3.2/bash ./reduce.sh
Dog 01 is Wiggles
Matched, anyway
Dog is
If I then also backslash-escape the parens, like so:
if [[ $DOG =~ \([[:alpha:][:blank:]]*\)-\ \([[:digit:]]*\)\ -\ \(.*\)$ ]]
then I no longer get the error, but the pattern doesn't match any more
at all.
D:/tmp $ ~/src/bash-3.2/bash ./reduce.sh
Dog 01 is Wiggles
So I still can't see how to get not just a match, but a match with
grouping, to work in 3.2 without putting the pattern into an
intermediate variable.
--
Ryan Waldron||| http://www.erebor.com|||[EMAIL PROTECTED]
"The web goes ever, ever on, down from the site where it began..."
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
On Tue, 2007-01-23 at 17:17 +0100, Andreas Schwab wrote: > glibc definitely uses strcoll as well. Most likely python has its own > implementation which gets it wrong. No, really, this is going through glibc's __collseq_table_lookup function. The Python example is just an easy-to-run distilled test case. Try a little C program using glob() or regex matching. Tim. */ signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
On Tue, 23 Jan 2007 11:04:58 -0500 Chet Ramey <[EMAIL PROTECTED]> wrote: > One of the changes between bash-3.1 and bash-3.2 was to unify the > handling of the pattern in the `==' and `=~' conditional command > operators. Pattern characters on the rhs are quoted to represent > themselves (remove their special pattern meaning). This is how == > has always worked. I don't get this; I must be missing something. If I do, in bash-3.1: $ V="alphabet" $ [[ $V == alphabet ]] && echo yes yes $ [[ $V == "alphabet" ]] && echo yes yes $ [[ $V == 'alphabet' ]] && echo yes yes $ [[ $V =~ alphabet ]] && echo yes yes $ [[ $V =~ "alphabet" ]] && echo yes yes $ [[ $V =~ 'alphabet' ]] && echo yes yes $ yet if I try the same in 3.2: $ V="alphabet" $ [[ $V == alphabet ]] && echo yes yes $ [[ $V == "alphabet" ]] && echo yes yes $ [[ $V == 'alphabet' ]] && echo yes yes $ [[ $V =~ alphabet ]] && echo yes yes $ [[ $V =~ "alphabet" ]] && echo yes $ [[ $V =~ 'alphabet' ]] && echo yes $ which to me looks like the two operators are not treating quotes the same way. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
Tim Waugh wrote:
> On Tue, 2007-01-23 at 17:17 +0100, Andreas Schwab wrote:
>> glibc definitely uses strcoll as well. Most likely python has its own
>> implementation which gets it wrong.
>
> No, really, this is going through glibc's __collseq_table_lookup
> function. The Python example is just an easy-to-run distilled test
> case.
But it doesn't matter what undocumented internal function glibc is using.
The portable, standard way to perform character comparison using the
current locale is strcoll(). If I can't get the same results using
strcoll(), glibc is clearly doing something different internally. (And
there is no portable standard way to obtain the current collating sequence.
The best you can do is sort sets of characters like I did.)
Try running the attached program. Run it like
rangecmp -v start test end
e.g.,
rangecmp -v A h Z
Here are the results I get:
$ LC_ALL=C ./rangecmp -v A h Z
default locale = C
strcoll (h, A) -> 1
strcoll (h, Z) -> 1
$ ./rangecmp -v A h Z
default locale = en_US.UTF-8
strcoll (h, A) -> 7
strcoll (h, Z) -> -18
$ LC_ALL=en_US ./rangecmp -v A h Z
default locale = en_US
strcoll (h, A) -> 7
strcoll (h, Z) -> -18
strcoll indicates that, in the "en_US" locale, `h' sorts between `A' and
`Z'. In the "C" locale, it does not. This is consistent with the
collating sequences I posted earlier.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
#include
#include
#include
#include
#include
static void
usage()
{
fprintf(stderr, "rangecmp: usage: rangecmp [-v] start test end\n");
}
int
main(c, v)
int c;
char**v;
{
int i, verbose, r1, r2;
char*dlocale;
verbose = 0;
while ((i = getopt(c, v, "v")) != -1) {
switch (i) {
case 'v':
verbose = 1; break;
case '?':
default:
usage();
exit(2);
}
}
c -= optind;
v += optind;
dlocale = setlocale(LC_ALL, "");
if (verbose)
printf("default locale = %s\n", dlocale ? dlocale : "''");
r1 = strcoll (v[1], v[0]);
printf("strcoll (%s, %s) -> %d\n", v[1], v[0], r1);
r2 = strcoll (v[1], v[2]);
printf("strcoll (%s, %s) -> %d\n", v[1], v[2], r2);
exit(0);
}
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
SIGWINCH getting lost
Hello,
since some time I have the problem that on some machines that programs
(f.i. irssi) do not resize when I change the terminal size. At first I had
the idea that this has something to do with the shopt checkwinsize but
if I understood the manpage correctly this is only to set COLUMNS and
LINES if necessary. I don't know wether the problem only exists over ssh
because this host has no X so I cannot try locally. It already occoured
on debian sarge on this maschine and it disappeard after upgrading to
etch. But not it's the same as before (still etch).
Here is a small perl script which I wrote to see wether the application
receives a SIGWINCH.
andariel [~]> cat /tmp/sigw.pl
#!/usr/bin/perl -w
sub got_sig {
print "Got a signal!\n";
}
$SIG{WINCH} = \&got_sig;
while (1) {
sleep (1);
}
The result is rather confusing for me. As I expected sigw.pl does not get
a WINCH signal but only with bash. When executing a csh it works and also
after executing a bash again.
andariel [~]> /tmp/sigw.pl
<<< Resizing terminal, nothing happens >>>
andariel [~]> exec csh
andariel:~> /tmp/sigw.pl
<<< Resizing terminal with csh>>>
Got a signal!
andariel:~> exec bash
andariel [~]> /tmp/sigw.pl
<<< Resizing terminal with bash again >>>
Got a signal!
andariel [~]>
Can anyone give me a hint why it behaves like that? These are the things
I already tried but none of them did help:
- trying another terminal (xterm, Eterm instead of aterm)
- using a friends pc (and account) to make sure that the problem is not
on my local environment.
- logging in with a new user account with default settings
- compiling the latest bash from http://www.gnu.org/software/bash/
- downgrading the bash to the debian package which was installed right
after the etch update.
- setting checkwinsize by hand in all involved shells
The same problem occures on another box with debian sarge.
Here some details of my currently installed bash (official debian
package):
andariel [~]> echo $BASH_VERSION
3.1.17(1)-release
andariel [~]> cat /etc/debian_version
4.0
andariel [~]> apt-cache policy bash
bash:
Installed: 3.1dfsg-8
Candidate: 3.1dfsg-8
Version table:
*** 3.1dfsg-8 0
500 http://debian.informatik.uni-erlangen.de etch/main Packages
100 /var/lib/dpkg/status
andariel [~]>
If you have any ideas what causes this behavior or if you just need some
more information concering my system or environment which might help to
solve this problem please let my know.
Thanks in advance,
Rainer
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
man page "-c" explanation clarity
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 uname output: Linux pc.austin.ibm.com 2.6.9-34.EL #1 Fri Feb 24 16:44:51 EST 2006 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.0 Patch Level: 15 Release Status: release Description: The man page states, for the "-c" option: -c string If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0. I think the phrase "arguments after the string" is confusing in that the "arguments" here are really still within "the string", not after. Repeat-By: $ man bash Fix: I'd suggest slightly different wording, such as: "... If argments follow the respective commands within the string, they are..." -- Regards, Paul Clarke ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
Chet Ramey wrote: > (Since I don't set LC_ALL anywhere in my startup files, my system's > default locale is apparently en_US.UTF-8.) Even if you don't actively set the LANG, LC_COLLATE, LC_ALL locale variables in your shell startup files they may be getting set in your environment through PAM's /etc/environment or through /etc/profile. The recent trend seems to be to use /etc/environment for this. This can cause confusion because interactive shell processes started through PAM get settings upon login from /etc/environment while system processes such as those started from /etc/init.d/* at boot time do not spawn through PAM and so do not get any settings from /etc/environment. There is no one single place to configure a value globally for all processes on the system. Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: man page "-c" explanation clarity
Paul A. Clarke wrote: The man page states, for the "-c" option: -c string If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0. I think the phrase "arguments after the string" is confusing in that the "arguments" here are really still within "the string", not after. I'd suggest slightly different wording, such as: "... If argments follow the respective commands within the string, they are..." No, that's wrong, because it is talking about positional parameters as seen by /the shell/, not anything that is subsequently executed. For example, 'bash -c echo foo' does not do what you might expect. It runs the built-in "echo" in the modified environment '0=foo'. Try e.g. "bash -c 'echo 0=$0 @=$@' foo bar". This is not the same as subsequently passing arguments to a program, which must be done within the *single* argument to '-c'. -- Matthew Don't read this. What did I just tell you? Why are you still reading? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: man page "-c" explanation clarity
"Paul A. Clarke" <[EMAIL PROTECTED]> wrote: > The man page states, for the "-c" option: >-c string If the -c option is present, then commands are read from > string. If there are arguments after the string, they are > assigned to the positional parameters, starting with $0. > I think the phrase "arguments after the string" is confusing in that the > "arguments" here are really still within "the string", not after. bash -c 'printf %s\\n "$0" "$@"' arg0 arg1 arg2 arg3 "The string" refers to the part which, in this example, is single-quoted, and the arguments are indeed after that, not within it. > I'd suggest slightly different wording, such as: > "... If argments follow the respective commands within the string, they > are..." That would suggest to me that arguments in the place of %s\\n in my example are assigned to the positional parameters, which is not true. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
> >> Bash Version: 3.2
> >> Patch Level: 0
> >> Release Status: release
Install the patches. One (patch 3) deals with this issue. The following
transcript shows the difference between the patched and unpatched versions
of bash-3.2.
$ cat x16
DOG="Dog name - 01 - Wiggles"
if [[ $DOG =~ ([[:alpha:][:blank:]]*)-\ ([[:digit:]]*)\ -\ (.*)$ ]]
then
echo Dog ${BASH_REMATCH[2]} is ${BASH_REMATCH[3]}
fi
$ ../bash-3.2-patched/bash --version
GNU bash, version 3.2.9(7)-release (powerpc-apple-darwin8.7.0)
Copyright (C) 2005 Free Software Foundation, Inc.
$ ../bash-3.2-patched/bash ./x16
Dog 01 is Wiggles
$ ../bash-3.2/bash ./x16
./x16: line 2: unexpected argument `(' to conditional binary operator
./x16: line 2: syntax error near `(['
./x16: line 2: `if [[ $DOG =~ ([[:alpha:][:blank:]]*)-\ ([[:digit:]]*)\ -\
(.*)$ ]]'
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
> I don't get this; I must be missing something. If I do, in bash-3.1: I get identical results with fully-patched versions of bash-3.1 and bash-3.2: $ cat x17 V="alphabet" [[ $V == alphabet ]] && echo yes 1 [[ $V == "alphabet" ]] && echo yes 2 [[ $V == 'alphabet' ]] && echo yes 3 [[ $V =~ alphabet ]] && echo yes 4 [[ $V =~ "alphabet" ]] && echo yes 5 [[ $V =~ 'alphabet' ]] && echo yes 6 $ ../bash-3.2-patched/bash ./x17 yes 1 yes 2 yes 3 yes 4 yes 5 yes 6 $ ../bash-3.1-patched/bash ./x17 yes 1 yes 2 yes 3 yes 4 yes 5 yes 6 $ ../bash-3.2-patched/bash --version GNU bash, version 3.2.9(7)-release (powerpc-apple-darwin8.7.0) Copyright (C) 2005 Free Software Foundation, Inc. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
> Chet Ramey wrote: > > (Since I don't set LC_ALL anywhere in my startup files, my system's > > default locale is apparently en_US.UTF-8.) > > Even if you don't actively set the LANG, LC_COLLATE, LC_ALL locale > variables in your shell startup files they may be getting set in your > environment through PAM's /etc/environment or through /etc/profile. > The recent trend seems to be to use /etc/environment for this. /etc/environment does not appear on my system and the variable is not set in /etc/profile. Be that as it may, from a user's perspective, it's the same thing: something set outside his control is effectively the "system-default locale". Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Quoting near =~ is inconsistent
Tim Waugh wrote: > Further to this, I am having trouble porting existing scripts to > bash-3.2's new style of regex matching. > > Here is one example that is problematic: I want to use a character class > in my regex, but bash seems to get confused by the ':]]' closing the > class, and apparently takes it as a ']]' closing the conditional > expression. > > Here is a distilled test case: > > [[ $line =~ [[:space:]]*(a)?b ]] && echo match || echo no match > > I used single quotes around the RHS in bash-3.1, which worked very well. > How should this be written so as to work with bash-3.2 -- and, of > course, still with bash-3.1? It cannot; the level of backwards compatibility is not that great. I will have to think about a solution. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
Chet Ramey wrote: >> Chet Ramey wrote: >>> (Since I don't set LC_ALL anywhere in my startup files, my system's >>> default locale is apparently en_US.UTF-8.) >> Even if you don't actively set the LANG, LC_COLLATE, LC_ALL locale >> variables in your shell startup files they may be getting set in your >> environment through PAM's /etc/environment or through /etc/profile. >> The recent trend seems to be to use /etc/environment for this. > > /etc/environment does not appear on my system and the variable is not > set in /etc/profile. Be that as it may, from a user's perspective, it's > the same thing: something set outside his control is effectively the > "system-default locale". Exactly. And I want to learn how to shoot that dang thing down. Dead. If I've cleared my environment of LC_* and LANG values, then by gum ``echo [a-z]*'' should work the way it has for the past 35 years, and not some newfangled thing that somebody thought would be "helpful". Down with "system default locale". Thanks - Bruce ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
On Tue, 23 Jan 2007 16:55:02 -0500 Chet Ramey <[EMAIL PROTECTED]> wrote: > > I don't get this; I must be missing something. If I do, in > > bash-3.1: > > I get identical results with fully-patched versions of bash-3.1 and > bash-3.2: $ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/bash -version GNU bash, version 3.2.9(1)-release (i686-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. $ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/bash ~/x17 yes 1 yes 2 yes 3 yes 4 That's with bash-3.2 built with only the 001 through 009 patches applied (we have a few other local patches for various reasons, but I've built without them to be sure they're not affecting this). What's the (7) in the release number - does that refer to difference I might be missing? -- Kevin F. Quinn signature.asc Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
On Tue, 23 Jan 2007, Chet Ramey wrote: Bash Version: 3.2 Patch Level: 0 Release Status: release Install the patches. One (patch 3) deals with this issue. The following transcript shows the difference between the patched and unpatched versions of bash-3.2. That was it. Sorry about missing the patches. It's been a long time since I compiled bash directly, and I didn't realize that the 3.2.tgz version I downloaded wasn't fully patched already. Thanks! -- Ryan Waldron||| http://www.erebor.com|||[EMAIL PROTECTED] "The web goes ever, ever on, down from the site where it began..." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
Bruce Korb wrote: > Exactly. And I want to learn how to shoot that dang thing down. Dead. > If I've cleared my environment of LC_* and LANG values, then by gum > ``echo [a-z]*'' should work the way it has for the past 35 years, and > not some newfangled thing that somebody thought would be "helpful". > Down with "system default locale". You need to force the issue. Add export LC_COLLATE=C to your startup files. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional Regexp matching problem in 3.2
Kevin F. Quinn wrote: > On Tue, 23 Jan 2007 16:55:02 -0500 > Chet Ramey <[EMAIL PROTECTED]> wrote: > >>> I don't get this; I must be missing something. If I do, in >>> bash-3.1: >> I get identical results with fully-patched versions of bash-3.1 and >> bash-3.2: > > $ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/bash -version > GNU bash, version 3.2.9(1)-release (i686-pc-linux-gnu) > Copyright (C) 2005 Free Software Foundation, Inc. > > $ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/bash ~/x17 > yes 1 > yes 2 > yes 3 > yes 4 > > That's with bash-3.2 built with only the 001 through 009 patches > applied (we have a few other local patches for various reasons, but I've > built without them to be sure they're not affecting this). What's the > (7) in the release number - does that refer to difference I might be > missing? Strange. It succeeds on Mac OS X, Solaris, FreeBSD, and BSD/OS. Linux fails (Red Hat, FWIW). I'll have to look into it further. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
