Re: regex confusion -- not matching; think it should?

[Dan Douglas]

On Thu, Jun 20, 2013 at 7:09 AM, Greg Wooledge  wrote:
> On Wed, Jun 19, 2013 at 06:12:57PM -0500, Dan Douglas wrote:
>> Thanks to mksh, posh, etc not supporting POSIX character classes at all, I'm
>> not so sure it's actually better in practice. (talking about standard shell
>> pattern matching of course)
>
> I'm fairly sure nobody on the entire planet uses those shells except
> their authors and you.

I'm talking about the entire family of pdksh-derived shells. mksh
ships with Android. oksh on openbsd. pdksh on SUA / interix. I'm sure
some use posh for testing. Collectively I'd say they're at least as
significant as dash, probably more.

> Now, since this is a bash mailing list, it's reasonable to talk about
> bash.  If you're writing a script in bash, you MUST NOT use the [a-z]
> or [A-Z] ranges, or any other alphabetic ranges, unless you are
> working in the POSIX locale.  If you use an alphabetic range in any
> other locale, you invite disaster.

I can't reproduce this on a GNU system using en_US.UTF-8

Are you saying this because certain implementations tend to behave
this way, or because it's implied by the spec? I'd assume this has
more to do with your C library than to do with Bash specifically.
According to POSIX the character ranges look just as bad as the
character classes. There's even text which says implementations may
offer extensions that do not even include those characters required
for the C locale, and I don't see anything that says what should occur
for non-POSIX locales.

Re: regex confusion -- not matching; think it should?

[Greg Wooledge]

On Fri, Jun 21, 2013 at 02:39:14AM -0500, Dan Douglas wrote:
> > If you're writing a script in bash, you MUST NOT use the [a-z]
> > or [A-Z] ranges, or any other alphabetic ranges, unless you are
> > working in the POSIX locale.  If you use an alphabetic range in any
> > other locale, you invite disaster.
> 
> I can't reproduce this on a GNU system using en_US.UTF-8

Yes, *some* implementations go out of their way to try to make [a-z]
work in the "intuitive" way.  But if you want your script to be portable,
you can't rely on that.

> Are you saying this because certain implementations tend to behave
> this way, or because it's implied by the spec?

Because real computers behave in the way I demonstrated.  "imadev"
is the workstation sitting under my desk.  It's what I'm typing this
email on right now.  It runs HP-UX 10.20.

There are a very large number of old HP-UX 10.20 and 11.11 machines
in the world.

> I'd assume this has
> more to do with your C library than to do with Bash specifically.

True.

How to test if a link exists

[Mark Young]

Hi,

I stumbled into discovering that the -e test for a file does not report the 
file as existing if the file is a dead symbolic link. This seems wrong to me.

Here's some test code:-
(WARNING it includes rm -f a b)

#!/bin/bash

bash --version
echo ""

rm -f a b
ln -s b a
[ -a a ] && echo "1. (test -a) File a exists, it's a dead link"
[ -e a ] && echo "1. (test -e) File a exists, it's a dead link"
[ -f a ] && echo "1. (test -f) File a exists, it's a dead link"

touch b
[ -a a ] && echo "2. (test -a) File a exists, it points to b"
[ -e a ] && echo "2. (test -e) File a exists, it points to b"
[ -f a ] && echo "2. (test -f) File a exists, it points to b"


When run on my CentOS v5.9 system I get the following 

$ ./test
GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

2. (test -a) File a exists, it points to b
2. (test -e) File a exists, it points to b
2. (test -f) File a exists, it points to b


When run on Cygwin I also get basically the same

$ ./test
GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

2. (test -a) File a exists, it points to b
2. (test -e) File a exists, it points to b
2. (test -f) File a exists, it points to b


My feeling is that this is wrong and that I should be told that a exists even 
though b doesn't. File 'a' does exist it is a dead symbolic link. So it 
prevents me for instance creating a symbolic link:-

E.g.

$ ln -s c a
$ ls -l a b c 
ls: b: No such file or directory
ls: c: No such file or directory
lrwxrwxrwx 1 marky tools 1 Jun 21 14:41 a -> b


Is this an error in bash?
What test should I use to decide if a file exists (including dead symbolic 
links)?

Cheers,
Mark

Aw: How to test if a link exists

[John Kearney]

   check out
   help test
   if you want to test fot both you can do

   [ -e file -o -h file ] || echo file not present.

   AFAIK the current behaviour is intentional and is the most useful.

   cheers


   Gesendet: Freitag, 21. Juni 2013 um 15:43 Uhr
   Von: "Mark Young" 
   An: bug-bash@gnu.org
   Betreff: How to test if a link exists
   Hi,
   I stumbled into discovering that the -e test for a file does not report
   the file as existing if the file is a dead symbolic link. This seems
   wrong to me.
   Here's some test code:-
   (WARNING it includes rm -f a b)
   #!/bin/bash
   bash --version
   echo ""
   rm -f a b
   ln -s b a
   [ -a a ] && echo "1. (test -a) File a exists, it's a dead link"
   [ -e a ] && echo "1. (test -e) File a exists, it's a dead link"
   [ -f a ] && echo "1. (test -f) File a exists, it's a dead link"
   touch b
   [ -a a ] && echo "2. (test -a) File a exists, it points to b"
   [ -e a ] && echo "2. (test -e) File a exists, it points to b"
   [ -f a ] && echo "2. (test -f) File a exists, it points to b"
   When run on my CentOS v5.9 system I get the following
   $ ./test
   GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
   Copyright (C) 2005 Free Software Foundation, Inc.
   2. (test -a) File a exists, it points to b
   2. (test -e) File a exists, it points to b
   2. (test -f) File a exists, it points to b
   When run on Cygwin I also get basically the same
   $ ./test
   GNU bash, version 4.1.10(4)-release (i686-pc-cygwin)
   Copyright (C) 2009 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or later
   <[1]http://gnu.org/licenses/gpl.html>
   This is free software; you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.
   2. (test -a) File a exists, it points to b
   2. (test -e) File a exists, it points to b
   2. (test -f) File a exists, it points to b
   My feeling is that this is wrong and that I should be told that a
   exists even though b doesn't. File 'a' does exist it is a dead symbolic
   link. So it prevents me for instance creating a symbolic link:-
   E.g.
   $ ln -s c a
   $ ls -l a b c
   ls: b: No such file or directory
   ls: c: No such file or directory
   lrwxrwxrwx 1 marky tools 1 Jun 21 14:41 a -> b
   Is this an error in bash?
   What test should I use to decide if a file exists (including dead
   symbolic links)?
   Cheers,
   Mark

References

   1. http://gnu.org/licenses/gpl.html