Re: -e does not work with subscript
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
Re: -e does not work with subscript
> $ 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, Inc. > >
Re: -e does not work with subscript
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' > > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' > > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > > -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 > > uname output: Linux hilbert 2.6.18-openvz-amd64 #1 SMP Tue Apr 10 19:34:07 > > MSD 2007 i686 GNU/Linux > > Machine Type: i486-pc-linux-gnu > > > > Bash Version: 3.1 > > Patch Level: 17 > > Release Status: release > > > > Description: > > failed subscript does not cause script to exit, while -e is set > > > > Repeat-By: > > > > % cat aa.sh > > set -e > > > > ( > > false > > ) > > > > echo "unreachable" > > > > % bash ./aa.sh > > unreachable > > % zsh ./aa.sh > > zsh: exit 1 zsh ./aa.sh > > > > Script aa.sh is expected to exit with error and print nothing. In > > bash it prints "unreachable". > > > > > bash exits the subshell you create with ( ) and not the shell: > > $ bash -ce '(false;echo foo);echo bar' > bar Bash must exit the shell too. Because $ bash -ce '(false); echo $?' 1 S.
Re: -e does not work with subscript
> 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 it is invoked:" > > (and don't worry for not finding it, I know it is easier to find what > you want when you already know what you are looking for.)
Re: testsuite -C dir
-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 security hole for trojan files, |> POSIX forbids implicit `.'. Thus, the only safe way to source a file in |> the current directory is with anchored notation, since you can't rely on |> `.' being in the user's PATH. | | Uhm, I have: | | bonzinip$ echo echo foo > bar | bonzinip$ . bar | foo | | And . is not in the PATH: | | bonzinip$ chmod +x bar | bonzinip$ bar | -bash: bar: command not found | | Then I try within scripts and behavior is the same: | | bonzinip$ echo . bar > baz | bonzinip$ chmod +x baz | bonzinip$ sh --version | GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0) | bonzinip$ ./baz | foo | bonzinip$ POSIXLY_CORRECT=1 sh baz | foo | | Even with bash 3.2: | | bonzinip$ /sw/bin/bash --version | GNU bash, version 3.2.9(1)-release (powerpc-apple-darwin8.10.0) | Copyright (C) 2005 Free Software Foundation, Inc. | bonzinip$ /sw/bin/bash baz | foo | bonzinip$ POSIXLY_CORRECT=1 /sw/bin/bash baz | foo | | /me is confused... Hmm. Bash explicitly documents that it behaves differently depending on whether it is in POSIX mode - from bash-3.2/POSIX: ~ 28. The `.' and `source' builtins do not search the current directory ~ for the filename argument if it is not found by searching `PATH'. It looks like we've discovered a bash bug. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHnzjH84KuGfSFAYARAiEUAJ9daSG5G7xXlPGyW0i88zu02zznqwCfdOMP nKPxBGFPgh33k14nVZT8Kbg= =KoSc -END PGP SIGNATURE-
Re: -e does not work with subscript
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 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 >
Re: Exit application with two function calls
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 catch everything -- probably not best for a production script, but I always use it as "-ue". That catches many more -- mispelled or unset vars also cause an errexit. It depends on how you program -- if you use && and || alot, it will "hide" a failure status, but presumably, if you are using || or ||, you are catching the error condition yourself...? I'll often use (cd dir && do-something-I-only-want-done-in-dir) Using a pathological example: cd /temp; rm -fr * # not likely intended if one meant # /tmp instead of /temp... :-), but cd /tmp && rm -fr * is slightly safer... I thought && and || were specifically listed as ways to avoid a command failure (so -e wouldn't trigger an exit)... Maybe that was in some other shell reference I read.
Re: capturing sub-expressions?
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. Normally even nested extended patterns work with string
matching. But, in fact, !(...) appears to not work like one would
expect. The only case that looked correct to me is the trivial one
${x//!(*)}, which leaves $x unchanged.
I'm not sure whether this is a bug or I (we) miss something.
Interestingly, ksh behaves the same way. Can anybody clarify this?
---
Perhaps due to other failures, I haven't always had luck in the
with the *() !() ops due to quirk in the way they work...
Reading in the manpage, the section ordering is minorly
confusing at first glance...
Parameter Expansion
Command Substitution
Arithmetic Expansion
Process Substitution
Word Splitting
Pathname Expansion
Pattern Matching
Quote Removal
-
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 therebut if people say it works outside of Paths...
well...must be so! :-)...darn manpages!
You are right about the !() not working as one would expect...
I thought:
p="myswitch1 myswitch2 myswitch3"
then
p=${p/!(myswitch2)}
I _hoped_ would match every thing in "p" except "myswitch2",
i.e. "myswitch1 myswitch3", which (guess I didn't think this
through too well) I wanted to leave "myswitch2" as the only
thing left in $p; A bit too creative with my pattern matching.
Hey...whatever happened to the "Do what I want" operator???
Re: -e does not work with subscript
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 can also be written as: make -C some-dir :-) Bob
Re: capturing sub-expressions?
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 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
>
> If the same algorithm had been applied in the 2nd case, the first
> substring matching the pattern "not a sequence of at least one digit"
> would have been 'a' (or maybe 'ab'), and the output would have been
> 12Xb34' (or '12X34').
"12ab34" is also "not a sequence of at least one digit", so as the
longest match, it is preferred.
Note how "not a sequence of at least one digit" differs from "a
sequence of at least one nondigit"; the latter is specified as
+([!0-9]) and has the behavior you expect !(+([0-9])) to have.
> IMHO (please correct me if I'm wrong) this contradicts the usual
> meaning of the '!' operator
Negation is negation, but it has different effects on the overall
result depending on where you place it in the pattern.
paul
Re: -e does not work with subscript
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 rewritten as === ( cd some-dir && make ) || false === S. On 1/29/08, Pierre Gaston <[EMAIL PROTECTED]> wrote: > 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 to man bash, this is a list It is perhaps possible to > consider that the last false is executed as a simple > command but I think the documentation of set -e could perhaps be made > more clear about what happens when > the last command of a list exits with non 0. > > I understand why it is implemented this way, so that any non processed > error exits the shell. > > The shells seems to disagree on what (false) should do (ksh and zsh > exit the shell, dash and bash only the subshell. > They also seems to disagree on what ! true should do ( zsh exits, bash > dash and ksh don't) >
Re: Sub-arrays do not work with non-blank IFS
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, in the normal case "[EMAIL PROTECTED]:2}" will expand
indeed word-wise. So it's a bug.
Sorry,
Jan
Re: Is there a Windows native port of Bash or Bourne Shell(no cygwin)?
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 cannot cooperate with many existing Windows programs. --- It was deliberately designed that way by Bill Gates!!! "/" was used by CP/M on microcomputers -- I think they copied the idea from early versions (Bell Labs) of Unix. Bill Gates made the path separator "\" to make DOS distinctively different from CP/M, to try to avoid accusations of copying CP/M's interface. Dunno if he told DOS's creator to write it that way or if he changed it in the code after he purchased it and before he licensed it to IBM, but either way -- "\" has been an albatross around DOS's / Window's neck ever since. At the time, it wasn't so much of an issue. "C" wasn't ported to DOS at the time and neither were the unix utils, so the fact that "\" is almost universally a "quote-next-char-as-literal" wasn't so much an issue. But now...programming anything in Windows is a "drag" due to Bill Gates trying to hide Dos's similarities from CP/M. Idiot. At least with Cygwin, you can somewhat control unix or dos path conversion with "cygpath" which can convert paths either way. I just wish cygwin's "system" features would integrate better with windows...(things like being able to use kill to kill windows processes, or kill -SIGSTOP" to suspend them, for example...). I use bash as a windows scripting language -- if I need to pass something as a Windows path, I can use cygpath or single quotes to literallize the string... I call bash scripts from the task-scheduler, nightly, to do Windows maintenance...
Re: capturing sub-expressions?
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:
${parameter/pattern/string}
The pattern is expanded to produce a pattern just as in
pathname expansion. Parameter is expanded and the
longest match of pattern against its value is replaced
with string. [...]
> I wanted to leave "myswitch2" as the only thing left in $p;
p=" $p "
p=${p/* myswitch2 */myswitch}
p=${p/ */}
paul
Re: Sub-arrays do not work with non-blank IFS
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='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
> -g -O2
> uname output: Linux fly 2.6.22-3-686 #1 SMP Mon Nov 12 08:32:57 UTC 2007
> i686 GNU/Linux
> Machine Type: i486-pc-linux-gnu
>
> Bash Version: 3.1
> Patch Level: 17
> Release Status: release
>
> Description:
>
> If the IFS does not contain a blank, copying an array using
> ("[EMAIL PROTECTED]") works, but creating a sub-array using
> ("[EMAIL PROTECTED]:offset:length}") does not work.
>
> 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 assume:
"[EMAIL PROTECTED]" is defined (see manual) to expand as separate words.
"[EMAIL PROTECTED]:x:y}" will "just expand"
>From my understanding this is the correct behaviour.
J.
Re: -e does not work with subscript
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 to man bash, this is a list It is perhaps possible to consider that the last false is executed as a simple command but I think the documentation of set -e could perhaps be made more clear about what happens when the last command of a list exits with non 0. I understand why it is implemented this way, so that any non processed error exits the shell. The shells seems to disagree on what (false) should do (ksh and zsh exit the shell, dash and bash only the subshell. They also seems to disagree on what ! true should do ( zsh exits, bash dash and ksh don't)
Re: capturing sub-expressions?
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 the subexpression?
I don't think so, you can only use =~ and BASE_REMATCH
If the full expression was in a shellvar "Options", I thought about
using something like:
${Option//!(expr)}
which I hoped would have "!(expr) match anything but my desired
expression, and the double "/" would say allow it to match multiple
times, but it appears the "!()" construct is limited to pathname
expansion? Presuming that is true (limited to pathname expansion),
is there anyway to do it on Shell vars?
!( ) is indeed not very intuitive, it is not limited to pathname
expansion but it is not as interesting as it might seem.
!(expr) will match anything that is not expr, for instance !(foo) will
match f and bar, but it also match "fooa",
the only thing that is not match is exactly "foo", which is useful if
you do: "echo !(foo)" to list all the files except
the one named "foo".
Now if you use parameter expansion :
var=fooa;echo ${var//!(foo)/b} # prints "b" because !(foo) matches "fooa"
var=foo; echo ${var/!(foo)/b} # prints "bo" because !(foo) matches "fo"
var=foo; echo ${var/!(foo)/b} # prints "bb" because !(foo) matches "fo" and "o"
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.
Example:
x=12ab34; echo ${x//+([0-9])/X}# prints XabX
x=12ab34; echo ${x//!(+([0-9]))/X} # prints X
If the same algorithm had been applied in the 2nd case, the first
substring matching the pattern "not a sequence of at least one digit"
would have been 'a' (or maybe 'ab'), and the output would have been
'12Xb34' (or '12X34').
IMHO (please correct me if I'm wrong) this contradicts the usual meaning
of the '!' operator and makes it nearly useless - except in the simple
"echo !(foo)" case you mentioned.
Bernd
--
Bernd Eggink
[EMAIL PROTECTED]
http://sudrala.de
Re: -e does not work with subscript
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 can be rewritten as > > ( cd some-dir && ./build.sh ) || false > > Of course the script can also be written as: > > make -C some-dir -C flag of make is the reason while such strange behavior of bash is not well known ;-) S.
Re: capturing sub-expressions?
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 matched.
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
If the same algorithm had been applied in the 2nd case, the first
substring matching the pattern "not a sequence of at least one digit"
would have been 'a' (or maybe 'ab'), and the output would have been
12Xb34' (or '12X34').
"12ab34" is also "not a sequence of at least one digit", so as the
longest match, it is preferred.
Thanks, that made it clear. The crucial point, that the longest match is
preferred in any case, had slipped out of my mind (though I have been
using this for decades...).
Regards,
Bernd
--
Bernd Eggink
[EMAIL PROTECTED]
http://sudrala.de
Re: matching !(patterns)
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.
>
> "$s" is 1 pattern, no? (no alternation); 1 pattern containing
> "thomas rich george", yes?
Right.
> Then if I use !($s) as the replacement pattern within in the substitute
> operator, ( ${s//!($s)/X} ) the !($s) should match any string
> except what is in "$s" ("thomas rich george").
It will match the longest substring of $s that is not $s itself -
which is the first N-1 characters of s. With //, it will replace
every match, so the final character will also be replaced, since it is
not the same as all of $s.
> So in the substitute, the string to replace (the "!($s) part) should
> match nothing in my variable "$s", so I'd think no replacement would
> be done.
You're right that $s as a whole does not match !($s). But that isn't
the only candidate for matching. Every substring is a candidate. The
first position where a match is found is used, with the longest match
starting at that position.
To check whether a string as a whole matches a pattern, instead of
checking for a matching substring, you can use case. (Or, if the
pattern is a literal string with no special characters, you can use
test.)
>> echo \"${s//!($s)/X}\"
> "XX" # why two X's? if I use 1 "/" instead of double:
>> echo \"${s/!($s)/X}\"
> "Xe" # why an "e" afterwards?
With / instead of //, only the first match is replaced.
paul
matching !(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
---
The longest matching substring (because you use "/" to start the pattern,
yes?) I'm not sure I fully understand this behavior though. Let's have
s="thomas rich george"
Manpage says "!()" will match anything except one of the patterns.
"$s" is 1 pattern, no? (no alternation); 1 pattern containing
"thomas rich george", yes?
Then if I use !($s) as the replacement pattern within in the substitute
operator, ( ${s//!($s)/X} ) the !($s) should match any string
except what is in "$s" ("thomas rich george").
So in the substitute, the string to replace (the "!($s) part) should
match nothing in my variable "$s", so I'd think no replacement would
be done. I.e. the output would be unchanged. But when I
try it that's not what I get:
echo \"${s//!($s)/X}\"
"XX" # why two X's? if I use 1 "/" instead of double:
echo \"${s/!($s)/X}\"
"Xe" # why an "e" afterwards?
-
The converse works as expected:
echo \"${s//+($s)/X}\"
"X"
echo \"${s/+($s)/X}\"
"X"
Re: -e does not work with subscript
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)" :-)
I wouldn't, since you are placing the ops in a subshell --
only the subshell has the "error", but the top level shell wouldn't
have an error just because a subshell exited. If you want the
shell to exit, use braces:
{ cd some-dir &* make ; }
# braces don't parse as end-of-line delimiters
# like parens do, so the semicolon is needed after make
Re: capturing sub-expressions?
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 its use there:
${parameter/pattern/string}
The pattern is expanded to produce a pattern just as in
pathname expansion. Parameter is expanded and the
longest match of pattern against its value is replaced
with string. [...]
I wanted to leave "myswitch2" as the only thing left in $p;
p=" $p "
p=${p/* myswitch2 */myswitch}
p=${p/ */}
-
I simplified my example a bit too much...
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.
I can get at the 60 using multiple "nibbles" off the front and end of
the string, but no [easy] way I can think of to get at it directly.
I figured with "capture", I could substitute it in as the replacement
string. with nibbling, it makes for convoluted code that doesn't
feel "robust" (and I can easily come up with specific (though unlikely
to be used in practice) examples to cause failure).
Harder targets included more "switches" (-b, -v and -t which all take
arguments which may or may not be separated from the switch by a space.
Switches (and their values) are space separated. I'm not worrying
about supporting embedded spaces in filenames.
p="-e -p60 -b 1m -v string -tfile"
Switch -b has some decimal value with an optional suffix in the set
"kmgtpesb". But the above target isn't really needed AFAIK in the near
future.
Re: capturing sub-expressions?
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 getopt -- was just wanting a string-manipulation mechanism to do it, but am maybe getting too used to string manipulations in perl? Would still love to use perl's full RE's in bash expressions, such is life... (am not sure I want it enough to try implementing/merging them...:-)) Linda
Re: capturing sub-expressions?
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
