Paul Jarc wrote:
Linda Walsh <[EMAIL PROTECTED]> wrote:
p="-e -p 60 -x"
---
That's why I wanted the capture -- to pick out the 60 -- where 60 represents
a positive integer. The space between the -p and the number is optional.
It sounds like you're looking for getopt.
---
I knew about
Linda Walsh <[EMAIL PROTECTED]> wrote:
> p="-e -p 60 -x"
> ---
> That's why I wanted the capture -- to pick out the 60 -- where 60 represents
> a positive integer. The space between the -p and the number is optional.
It sounds like you're looking for getopt.
paul
Paul Jarc wrote:
Linda Walsh <[EMAIL PROTECTED]> wrote:
In my copy of the man pages, Pattern matching is indented an extra
level making it look like it's under Pathname Expansion and only
applies there
Pattern matching applies primarily to pathname expansion; other uses
explicitly refer to
Stepan Koltsov wrote:
BTW, my use case for "(false)" is:
===
set -e
( cd some-dir && make )
( cd other-dir && ./build.sh )
( cd third-dir && ant )
===
Most readers (and writers) expect script to fail if "make" failed. So
I think that outer bash should exit with error on "(false)" :-)
Linda Walsh <[EMAIL PROTECTED]> wrote:
> The longest matching substring (because you use "/" to start the pattern,
> yes?)
No, !() normally uses the longest match, just like *, *(), and +().
>s="thomas rich george"
>
> Manpage says "!()" will match anything except one of the patterns.
>
> "
Paul Jarc wrote:
It looks for substrings in both cases - specifically, the longest
matching substring, which might happen to be the entire string. With
!(), that is often the case.
x=12ab34; echo ${x//+([0-9])/X}# prints XabX
x=12ab34; echo ${x//!(+([0-9]))/X} # prints X
-
Paul Jarc schrieb:
Bernd Eggink <[EMAIL PROTECTED]> wrote:
My impression is that the pattern lookup depends on whether or not a
!' is involved. If the pattern does not contain a '!', the shell looks
for matching substrings, from left to right. If it contains a '!', the
value as a whole is matche
Bernd Eggink <[EMAIL PROTECTED]> wrote:
> My impression is that the pattern lookup depends on whether or not a
> !' is involved. If the pattern does not contain a '!', the shell looks
> for matching substrings, from left to right. If it contains a '!', the
> value as a whole is matched.
It looks f
On 1/30/08, Bob Proulx <[EMAIL PROTECTED]> wrote:
> Stepan Koltsov wrote:
> > set -e
> > ( cd some-dir && ./build.sh )
> > ...
> > Most readers (and writers) expect script to fail if "./build.sh" failed. So
> > I think that outer bash should exit with error on "(false)" :-)
> > Of course, script ca
Pierre Gaston schrieb:
On Jan 28, 2008 4:00 AM, Linda Walsh <[EMAIL PROTECTED]> wrote:
I was wondering -- in the bash substitute commands ${..%%|##|//} etc,
is there a way to "capture" a subexpression, so that I can
use the subexpression in the replacement string so I can
end up 'only' with the
Stepan Koltsov wrote:
> set -e
> ( cd some-dir && make )
> ...
> Most readers (and writers) expect script to fail if "make" failed. So
> I think that outer bash should exit with error on "(false)" :-)
> Of course, script can be rewritten as
> ( cd some-dir && make ) || false
Of course the script c
BTW, my use case for "(false)" is:
===
set -e
( cd some-dir && make )
( cd other-dir && ./build.sh )
( cd third-dir && ant )
===
Most readers (and writers) expect script to fail if "make" failed. So
I think that outer bash should exit with error on "(false)" :-)
Of course, script can be rewritte
Lea Wiemann wrote:
> Repeat-By:
>
> IFS=$'\n'
> a=(A B C D)
> b=("[EMAIL PROTECTED]")
> echo "[EMAIL PROTECTED]", "[EMAIL PROTECTED]" # 4, A B C D -- OK
> b=("[EMAIL PROTECTED]:2}")
> echo "[EMAIL PROTECTED]", "[EMAIL PROTECTED]" # 1, C D -- bug, should be 2,
> C D
I have to correct myself, i
Lea Wiemann wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/
On Jan 29, 2008 8:09 PM, Stepan Koltsov <[EMAIL PROTECTED]> wrote:
> What is "simple command"?
>
> Is
>
> ===
> ( false ) || false
> ===
>
> simple? Seems like it is not, however
>
> ===
> set -e
>
> ( false ) || false
>
> echo "end"
> ===
>
> Prints nothing and exits with error.
Indeed according
Linda Walsh <[EMAIL PROTECTED]> wrote:
> In my copy of the man pages, Pattern matching is indented an extra
> level making it look like it's under Pathname Expansion and only
> applies there
Pattern matching applies primarily to pathname expansion; other uses
explicitly refer to its use there:
Chen(é) Jun(å) wrote:
sh -c "pwd"
It outputs:
/bin
Oouups, what I expect was E:/msys/1.0/bin .
Suprised? You now know what the weird sh.exe does. It checks whether some
token starts with / , if so, it considers that toke a path and applies
trasformation. This is utterly rude. So this sh.exe ca
Bernd Eggink wrote:
Linda Walsh schrieb:
I keep confusing the path-matching regular expressions with
string-matching expressions and keep getting disappointed when I'm
re-reminded of the limitation...:-(
There should be no difference between path-matching and string-matching
expressions. No
Paul Jarc wrote:
Linda Walsh <[EMAIL PROTECTED]> wrote:
# *1 - using "-e" stops your script immediately on any error
Not any error - only those from simple commands. The subtleties are
subtle enough that I avoid -e, and use "&&" between all commands
instead.
paul
Yeah...it doesn't catc
What is "simple command"?
Is
===
( false ) || false
===
simple? Seems like it is not, however
===
set -e
( false ) || false
echo "end"
===
Prints nothing and exits with error.
S.
On 1/29/08, Pierre Gaston <[EMAIL PROTECTED]> wrote:
> On Jan 29, 2008 10:04 AM, Stepan Koltsov <[EMAIL PROTECT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paolo Bonzini on 1/29/2008 7:19 AM:
|> | I didn't know source used the path. Actually I thought the contrary...
|>
|> . has always used PATH; but in older shells, it also implicitly tacked .
|> onto its path search. Since this was a sec
On Jan 29, 2008 10:04 AM, Stepan Koltsov <[EMAIL PROTECTED]> wrote:
>
> Bash must exit the shell too. Because
>
> $ bash -ce '(false); echo $?'
> 1
>
> S.
>
(false) is a compound command, the bash exits with set -e only if a
simple command exits with false
> $ bash -ce '(false;echo foo);echo bar'
> bar
could i ask what the command line option '-e' mean?
i did not find any explanation in bash's manual.
PS:
[EMAIL PROTECTED] ~]# bash --version
GNU bash, version 3.1.17(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, I
On 1/29/08, Pierre Gaston <[EMAIL PROTECTED]> wrote:
> On Jan 28, 2008 11:36 PM, <[EMAIL PROTECTED]> wrote:
> > Configuration Information [Automatically generated, do not change]:
> > Machine: i486
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> It has the same effect as set -e, you can pass the options of set to
> bash directly bash -x etc...
>
got it. thanks
> The manual says:
> "In addition to the single-character shell options documented in the
> description of the set builtin command, bash interprets the following
> options when
25 matches
Mail list logo
