Symbol for "not" within []

  • Follow


I've been using something like this:

    [[ a/bc == [^/]*/*[^/] ]] && echo match

(the "a/bc" is an example value)

to test whether a variable contains a file name having a relative path,
and it worked fine with bash.  But then I started using the Interix ksh
and it failed.  So I had to read the man pages again ...

Seems bash is liberal about the meaning of "not" here.  Bash interprets
^ or ! as "not", but Interix ksh treats ^ literally, and only recognizes
! as "not"

I had always preferred ^ since that's what grep uses within [] to mean
"not", but I guess I will change that habit for shell purposes so I can
run my scripts on Interix ksh.


-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
0
Reply jak (362) 8/8/2010 9:08:13 PM

On Sun, 08 Aug 2010 21:08:13 +0000
John Kelly <jak@isp2dial.com> wrote:

> 
> I've been using something like this:
> 
>     [[ a/bc == [^/]*/*[^/] ]] && echo match
> 
> (the "a/bc" is an example value)
> 
> to test whether a variable contains a file name having a relative path,
> and it worked fine with bash.  But then I started using the Interix ksh
> and it failed.  So I had to read the man pages again ...
> 
> Seems bash is liberal about the meaning of "not" here.  Bash interprets
> ^ or ! as "not", but Interix ksh treats ^ literally, and only recognizes
> ! as "not"
> 
> I had always preferred ^ since that's what grep uses within [] to mean
> "not", but I guess I will change that habit for shell purposes so I can
> run my scripts on Interix ksh.

The standard negation in a character class (per POSIX) is indeed "!". Bash
accepts "^" as an extension. 


0
Reply pk 8/8/2010 9:09:35 PM


On 2010-08-08, John Kelly wrote:
>
> I've been using something like this:
>
>     [[ a/bc == [^/]*/*[^/] ]] && echo match
>
> (the "a/bc" is an example value)
>
> to test whether a variable contains a file name having a relative path,
> and it worked fine with bash.  But then I started using the Interix ksh
> and it failed. 

   If you used standard syntax instead of [[ ... ]], you wouldn't have
   to worry about portability.


-- 
   Chris F.A. Johnson, author           <http://shell.cfajohnson.com/>
   ===================================================================
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)

0
Reply Chris 8/8/2010 9:18:17 PM

On Sun, 8 Aug 2010 21:18:17 +0000 (UTC), "Chris F.A. Johnson"
<cfajohnson@gmail.com> wrote:

>On 2010-08-08, John Kelly wrote:
>>
>> I've been using something like this:
>>
>>     [[ a/bc == [^/]*/*[^/] ]] && echo match
>>
>> (the "a/bc" is an example value)
>>
>> to test whether a variable contains a file name having a relative path,
>> and it worked fine with bash.  But then I started using the Interix ksh
>> and it failed. 
>
>   If you used standard syntax instead of [[ ... ]], you wouldn't have
>   to worry about portability.

I thought [[ ... ]] was portable.


-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
0
Reply John 8/8/2010 9:22:00 PM

John Kelly <jak@isp2dial.com> wrote:
> On Sun, 8 Aug 2010 21:18:17 +0000 (UTC), "Chris F.A. Johnson"
> <cfajohnson@gmail.com> wrote:

> >On 2010-08-08, John Kelly wrote:
> >>
> >> I've been using something like this:
> >>
> >>     [[ a/bc == [^/]*/*[^/] ]] && echo match
> >>
> >> (the "a/bc" is an example value)
> >>
> >> to test whether a variable contains a file name having a relative path,
> >> and it worked fine with bash.  But then I started using the Interix ksh
> >> and it failed. 
> >
> >   If you used standard syntax instead of [[ ... ]], you wouldn't have
> >   to worry about portability.

> I thought [[ ... ]] was portable.

Not really. Portability is a fuzzy term, but what POSIX specifies is so
minimal it's as good a baseline as any. POSIX reserves "[[" but leaves its
use unspecified. See POSIX.1-2008, Shell & Utilities volume, section
2.4.

	http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04

Note that the OpenGroup requires assent to their terms for accessing the
document. If you haven't already agreed follow thru here

	https://www.opengroup.org/online-pubs-short?DOC=9699919799&FORM=HTML

The spec is so relatively short it's not much of a hassle to read it through
once. That way you can likely exclude as portable anything not well defined
according to POSIX. Of course, it still might not be de facto portable even
if well defined.
0
Reply William 8/10/2010 8:33:16 AM

On Tue, 10 Aug 2010 01:33:16 -0700, William Ahern
<william@wilbur.25thandClement.com> wrote:

>> I thought [[ ... ]] was portable.

>Not really. Portability is a fuzzy term, but what POSIX specifies is so
>minimal it's as good a baseline as any. POSIX reserves "[[" but leaves its
>use unspecified. See POSIX.1-2008, Shell & Utilities volume, section
>2.4.

>	http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04

>The spec is so relatively short it's not much of a hassle to read it through
>once. That way you can likely exclude as portable anything not well defined
>according to POSIX. Of course, it still might not be de facto portable even
>if well defined.

OK.

I wonder what shells don't provide [[ ... ]]

Hopefully I will never use them ...



-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
0
Reply John 8/10/2010 9:19:10 AM

John Kelly <jak@isp2dial.com> writes:

> I've been using something like this:
>
>     [[ a/bc == [^/]*/*[^/] ]] && echo match
>
> (the "a/bc" is an example value)
>
> to test whether a variable contains a file name having a relative path,
> and it worked fine with bash.

This obviously suits your usage, but a string with no slashes is a file
name having a relative path but it fails your test.

<snip>
-- 
Ben.
0
Reply Ben 8/10/2010 2:55:44 PM

On Tue, 10 Aug 2010 15:55:44 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk>
wrote:

>John Kelly <jak@isp2dial.com> writes:
>
>> I've been using something like this:
>>
>>     [[ a/bc == [^/]*/*[^/] ]] && echo match
>>
>> (the "a/bc" is an example value)
>>
>> to test whether a variable contains a file name having a relative path,
>> and it worked fine with bash.
>
>This obviously suits your usage, but a string with no slashes is a file
>name having a relative path but it fails your test.

Right.

I poorly worded its intended usage.  This is the actual code:

        [[ $this == [^/]*/*[^/] ]] && mkdir -p .diff/${this%/*}
        diff -Nru a b > .diff/$this || test 2 -gt $? ||
            quit "failure diffing $REPLY"
  
a and b are symlinks pointing to two directory tress, so that diff
always produces a consistent header, for use with patch -p1.

The result of diff goes into the .diff directory tree.  If there's only
one path component in $this, the diff goes into the base .diff directory
and I don't need to create any subdirectories.  But if there's more than
one path component in $this, I need to create a subdirectory structure
within .diff for all but the last one.

So it's not really a "file name" I'm talking about.

Sorry for poor documentation, but that's sometimes what you get from
programmers, especially when they try to write "standards."  Just look
at how much trouble three lines of code can be.  ;-)


-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
0
Reply John 8/10/2010 3:54:12 PM

John Kelly wrote:

> I wonder what shells don't provide [[ ... ]]

traditional Bourne shells
Almquist shells
posh

while these shells for example (at least later releases) know it:

bash (since -2)
ksh88 (since 88a, == is not recognized until 88g)
ksh93
mksh
pdksh
zsh


> Hopefully I will never use them ...

"ymmv"
-- 
http://www.in-ulm.de/~mascheck/various/shells/
0
Reply Sven 8/10/2010 6:40:24 PM

On Tue, 10 Aug 2010 18:40:24 +0000 (UTC), Sven Mascheck
<mascheck@email.invalid> wrote:

>John Kelly wrote:

>> I wonder what shells don't provide [[ ... ]]

>while these shells for example (at least later releases) know it:

>bash (since -2)
>ksh88 (since 88a, == is not recognized until 88g)
>ksh93
>mksh
>pdksh
>zsh

>-- 
>http://www.in-ulm.de/~mascheck/various/shells/

Nice web page, thanks.



-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
0
Reply John 8/10/2010 6:57:37 PM

Sven Mascheck <mascheck@email.invalid> writes:

> John Kelly wrote:
>
> > I wonder what shells don't provide [[ ... ]]
>
> traditional Bourne shells
> Almquist shells
> posh

Including the Debian Almquist Shell (‘dash’), which is now used for
‘/bin/sh’ on Debian systems and derivatives by default.

> > Hopefully I will never use them ...

If that's what you hope, then I advise you to never declare a shell of
‘/bin/sh’ in the shebang line.

-- 
 \     “I am the product of millions of generations of individuals who |
  `\      each fought against a hostile universe and won, and I aim to |
_o__)              maintain the tradition.” —Paul Z. Myers, 2009-09-12 |
Ben Finney
0
Reply Ben 8/10/2010 11:10:08 PM

On Wed, 11 Aug 2010 09:10:08 +1000, Ben Finney
<ben+unix@benfinney.id.au> wrote:

>Sven Mascheck <mascheck@email.invalid> writes:
>
>> John Kelly wrote:
>>
>> > I wonder what shells don't provide [[ ... ]]
>>
>> traditional Bourne shells
>> Almquist shells
>> posh
>
>Including the Debian Almquist Shell (�dash�), which is now used for
>�/bin/sh� on Debian systems and derivatives by default.
>
>> > Hopefully I will never use them ...
>
>If that's what you hope, then I advise you to never declare a shell of
>�/bin/sh� in the shebang line.

I've never liked Debian or Ubuntu.  Now I have a another reason.



-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
0
Reply John 8/11/2010 12:00:08 AM

On 2010-08-11, John Kelly <jak@isp2dial.com> wrote:
> I've never liked Debian or Ubuntu.  Now I have a another reason.

For those who missed it, his reason to dislike them is debhelper
used the name "dh", and ten years later Kelly came along and wrote
a mediocre daemon(8)-type program (runs its command line arguments as
a daemon), grabbed that name for it because he believed it would be
a "universal" utility, and then when he found out that a few million
people had already taken the name for something else, announced that
he liked to hear them squeal.

A real charmer.  And marginally relevant, because it turns out you
can daemonize things quite nicely in shell:

	( "$@" ) >/dev/null 2>&1 </dev/null &

(This could probably use some tweaking, but the idea is sound.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
Reply Seebs 8/11/2010 12:40:05 AM

Ben Finney wrote:

> Sven Mascheck <mascheck@email.invalid> writes:
> 
>> John Kelly wrote:
>>
>> > I wonder what shells don't provide [[ ... ]]
>>
>> traditional Bourne shells
>> Almquist shells
>> posh
> 
> Including the Debian Almquist Shell (‘dash’), which is now used for
> ‘/bin/sh’ on Debian systems and derivatives by default.

Yes, he said "Almquist shells".

0
Reply pk 8/11/2010 10:55:04 AM

pk <pk@pk.invalid> writes:

> Yes, he said "Almquist shells".

Indeed. My point was to make clear that “I've never heard of Almquist
shells so it can't be too widespread” is, despite its superficial
attractiveness, not a safe conclusion. Almquist shells are going to be
much more prevalent now, since ‘dash’ is the default ‘/bin/sh’ in new
Debian installations as of the upcoming Squeeze release.

-- 
 \     “To save the world requires faith and courage: faith in reason, |
  `\            and courage to proclaim what reason shows to be true.” |
_o__)                                                —Bertrand Russell |
Ben Finney
0
Reply Ben 8/11/2010 1:42:39 PM

On Wed, 11 Aug 2010 23:42:39 +1000, Ben Finney
<ben+unix@benfinney.id.au> wrote:

>pk <pk@pk.invalid> writes:
>
>> Yes, he said "Almquist shells".
>
>Indeed. My point was to make clear that �I've never heard of Almquist
>shells so it can't be too widespread� is, despite its superficial
>attractiveness, not a safe conclusion. Almquist shells are going to be
>much more prevalent now, since �dash� is the default �/bin/sh� in new
>Debian installations as of the upcoming Squeeze release.

I don't plan to suffer Debian's bad decisions.  They do too many things
wrong.


-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 
0
Reply John 8/11/2010 3:17:57 PM

Ben Finney wrote:

> Almquist shells are going to be much more prevalent now, since
> dash is the default /bin/sh in new Debian installations as of
> the upcoming Squeeze release.

....and don't forget about those, which are not explicitly labeled
as almquist shells, in particular /bin/sh on Net- and FreeBSD.
And slackware and busybox also come to mind.

-- 
http://www.in-ulm.de/~mascheck/various/shells/
0
Reply Sven 8/11/2010 4:23:41 PM

On 2010-08-11, Sven Mascheck <mascheck@email.invalid> wrote:
> ...and don't forget about those, which are not explicitly labeled
> as almquist shells, in particular /bin/sh on Net- and FreeBSD.
> And slackware and busybox also come to mind.

Yes.

Someone trying to write programs which were going to be usable by other
people would want to either:

1.  Write for POSIX sh, these days, or...
2.  Use #!/bin/bash and hope that people installed it there.

That may not apply to all readers here; sometimes just knowing that your
program won't run on a ton of other peoples' systems is enough to make you
feel special and important.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
Reply Seebs 8/11/2010 6:34:24 PM

17 Replies
291 Views

(page loaded in 0.475 seconds)

Similiar Articles:


















7/28/2012 12:21:36 AM


Reply: