Re: Sourcing a script renders getopts impotent (or is it just me?)
On Thu, Sep 16, 2010 at 02:06:11PM -0700, Mun wrote: > I have a script which uses getopts that I need to source in my > interactive shell. The problem is that if I source it, getops behaves > as if no arguments were passed into the script. What are you actually doing? It works for me: imadev:~$ cat ~/bin/args #! /bin/sh printf "%d args:" $# printf " <%s>" "$@" echo imadev:~$ set -- one two three imadev:~$ source args 3 args:
Re: Sourcing a script renders getopts impotent (or is it just me?)
Hi Dennis, On Thu, Sep 16, 2010 at 05:18 PM PDT, Dennis Williamson wrote: DW> Use return instead of exit when you have an error and you're sourcing DW> the script. You can make it conditional. DW> DW> Try setting OPTIND=1 to make your script work when it's sourced. DW> Initialize your script's variables since they will be carried over DW> between runs when you source the script. That was in fact the problem. Once I set OPTIND in the script, it worked correctly :) DW> #!/bin/bash DW> invoked=$_ # needs to be first thing in the script Setting 'invoked' is a great idea. Thanks for the quick and very helpful reply! Regards, -- Mun DW> OPTIND=1# also remember to initialize your flags and other variables DW> DW> . . .# do some stuff DW> DW> if some error condition DW> then DW> if [[ $invoked != $0 ]] DW> then DW> return 1# the script was sourced DW> else DW> exit 1# the script was executed DW> fi DW> fi DW> DW> DW> DW> On Thu, Sep 16, 2010 at 4:06 PM, Mun wrote: DW> > Hi, DW> > DW> > Platform : Red Hat Enterprise Linux v5.5 DW> > Bash : GNU bash, version 4.1.0(1)-release (x86_64-unknown-linux-gnu) DW> > DW> > I have a script which uses getopts that I need to source in my DW> > interactive shell. The problem is that if I source it, getops behaves DW> > as if no arguments were passed into the script. Although, if I simply DW> > run the script in a sub-process, getopts works correctly. DW> > DW> > As an experiment, I echo'd all args prior to the getopts statement in DW> > the script, and when the script was sourced all args were correctly DW> > displayed. So I'm at a loss as to why getopts doesn't seem to work when DW> > the script is sourced. DW> > DW> > On a side note, there is some error checking being done within the DW> > script. I would like the script execution to terminate but leave the DW> > interactive shell running upon error detection (i.e., don't exit out of DW> > the terminal sessioni). Is there any way to accomplish that objective DW> > in bash? DW> > DW> > Regards, DW> > DW> > -- DW> > Mun DW> > DW> > DW>
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Jan Schampera wrote: == is the same as =, my suggestion is to NOT touch that. === Nothing I am suggesting would touch =/==. They behave exactly as one would expect. Single quotes do not allow expansion of variables, double quotes do expansion of variables. I.e. I'm asking that =~ behave consistently with respect to quotes as '==' does. There is no reason to have the =~ be disabled with double quotes: the == doesn't disable double-quote functionality -- it would be like *changing* double quotes, when used with "=/==", to NOT expand variables. Single quotes do not allow expansion of variables, double quotes do expansion of variables. I.e. A. t='one two three' a='two' 1) if [[ $t == 'one $a three']]; then echo 'no match expected'; fi 2) if [[ $t == "one $a three"]]; then echo 'Matches'; fi 3) if [[ $t == one\ $a\ three ]]; then echo 'Matches'; fi So for =/==, double quotes allows *grouping* and is equivalent to 3. But for the =~, it is broken: B. t='one two three' a='t..' 1) if [[ $t =~ 'one $a three' ]]; then echo 'no match expected'; fi 2) if [[ $t =~ "one $a three" ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes disable match'; fi 3) if [[ $t =~ one\ $a\ three ]]; then echo 'Matches'; fi -- but even more of the badness, single quotes disable matching entirely: 4) if [[ $t =~ one\ t..\ three ]]; then echo 'Matches'; fi 5) if [[ $t =~ 'one t.. three' ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes disable match'; fi Or another disparity: C. t='one two three' c='one two three' 1) if [[ $t == $a ]]; then echo 'Matches'; fi 2) if [[ $t == "$a" ]]; then echo 'Matches'; fi So, the expressions match whether or not $a is in double quotes or not (single quotes would not match, as the $a would be taken literally). But, with the operator that says 'take right hand expression as 'RE', do we get consistent behavior?: t='one two three' a='one t.. three' 3) if [[ $t =~ $a ]]; then echo 'Matches'; fi 4) if [[ $t =~ "$a" ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes disable match'; fi Now, double quotes Don't behave consistently -- AGAIN This is what I am talking about. Quoting should not disable RE matching. Period. If the user doesn't want RE' matching then they should use '=/=='. The =~ operator shouldn't be overloaded with inconsistent or broken operations. It's bad grammar. I can't see how this could ever be considered a good thing. It breaks semantic compatibility and expectations of how single and double quotes function. It is NOT the same as double quotes not allowing *file glob expansion*. There is no *expansion* going on. The right hand is a static pattern. But it's still a pattern. It doesn't 'expand' like "*" does outside of quotes in filename expansion. The equivalent idea of: i) ls * vs. ii) ls "*" where, double (or single) quotes disable the file globbing operator from expanding, would be to quote the =~ operator (which would often result in a syntax error, BUT, you could do the following: iii) if [[ "$t =~ anything" ]]; then echo 'Matches'; fi That will match -- because the expression is non-zero and not-null. But quotes only disable operators normal function when they are around the operator -- not when they are around the operands. Does that make sense? There is no suggestion on the table to change the operation of '=/==', just to make quotes function the same with =~ as they do with ==. Right now, the meaning of double quotes is broken and has been overloaded with a special case that makes no sense. If someone needs the broken semantics. then make it clear and add a switch shopt -o 'quotes-disable-regex-matching', but that shouldn't be the default behavior as the above examples show it being incompatible with how quotes have historically been handled. Linda
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Linda Walsh writes: > Or another disparity: C. > t='one two three' > c='one two three' > 1) if [[ $t == $a ]]; then echo 'Matches'; fi > 2) if [[ $t == "$a" ]]; then echo 'Matches'; fi > So, the expressions match whether or not $a is in double quotes or not > (single quotes would not match, as the $a would be taken literally). Set a='one * three' and try again. > Quoting should not disable RE matching. Yes it should. Just like quoting disables glob matching. There must be a way to remove the special meaning of a character. > It is NOT the same as double quotes not allowing *file glob > expansion*. Globbing is not only about expansion, it is also about matching. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Andreas Schwab wrote:
Linda Walsh writes:
Or another disparity: C.
t='one two three'
c='one two three'
1) if [[ $t == $a ]]; then echo 'Matches'; fi
2) if [[ $t == "$a" ]]; then echo 'Matches'; fi
So, the expressions match whether or not $a is in double quotes or not
(single quotes would not match, as the $a would be taken literally).
Set a='one * three' and try again.
Why? How would that be any different than case B4 & B5 that I already
showed?
If you don't understand my examples, I don't think you fully understand the
problem.
Quoting should not disable RE matching.
Yes it should. Just like quoting disables glob matching.
---
Care to show me how it disables matching and NOT expansion?
Note, using "*" and "?" aren't allowed -- since you are quoting the operators!
Now show me a case where it disables matching where the operators are not
quoted.
With =~, the operator is NOT quoted.
If you quote the operator, it will be disabled. That is expected. But not if
you
quote the "operands".
Here's another example, though it could be argued that it is broken as
implemented
1) a='2'+'3'
echo $a
5
The quotes don't disable addition.
However, it is the case that quoting the operator doesn't disable the addition:
This arguably could be considered a bug:
let b=2'+'3 #works
let b='2+'3 #works
let b=2\+3 # also works
In the above case, no application of quotes will disable the '+' operator from
functioning
in a let statement.
So if operators don't disable arithmetic evaluation, why should it disable
pattern-matching evaluation.
Pattern matching is not an operation of expansion the part between quotes.
That's where you are confused. The operation is not happening inside the quotes.
When you have
"one two three" =~ "one t.. three", there is no change made to the right hand
operand.
You are claiming that the double quotes on the right side should disable the
operator that
is NOT inside the quotes --- like this:
if [[ 'abc' =~ a"b". ]]; then echo you-claim-shouldn't-match, but does; fi
The double quotes don't disable the operator. The =~ is the operator, not the
"."
That's not the case with globbing. ;) In globbing, the operators are * and ?.
They expand (or not) to match a pattern.
That's the difference.
Pattern matching isn't controlled by the pattern -- it's controlled by the
operator --
that's one way in which regex's are different from globbing. That difference
should be
preserved.
It is a difference that makes regex's usable in different ways than globbing,
and vice-versa.
If you just wanted to make regex = globbing, that's different, but look at any
implementation
of pattern matching. Look at other utils that have posix style pattern
matching -- they don't
disable the pattern match when the right hand side is quoted:
Ex. Perl:
1) > perl -e '$a="one two three"; $b="one t.. three";
>> if ( $a =~ $b ) { print "unquoted matches\n"; } '
unquoted matches
2) > perl -e '$a="one two three"; $b="one t.. three";
>> if ( $a =~ "$b" ) { print "quoted matches TOO\n"; } '
quoted matches TOO
So tell me under what circumstances, algorithms can't be written in perl because
double quotes don't disable pattern matching.
How about grep?
1) echo 'one two three'|grep t..
one two three
2) echo 'one two three'|grep "t.."
one two three
Again, quotes don't turn off matching. Can you explain how grep is broken
because
of this?
Please demonstrate with actual examples.
There must be
a way to remove the special meaning of a character.
Which character are you trying to disable? The standard way to get
characters in a regex to lose their normal meanings is to ESCAPE them. That's
STANDARD in how regex's work in unix/linux/posix. Why should BASH be
incompatible?
Globbing is not only about expansion, it is also about matching.
---
I claim there is no case where the globbing characters are
not expanded to zero or more matching characters in order to perform a
match. Show me a case where this isn't the case and where double quotes
change the sense of the answer. Notice how you makes claims in your
post, but provide no examples?
Regex's are not globbing -- the are conceptually different -- and that
seems to be where the confusion is. Regex's SHOULDN'T act like globbing because
they are not the same feature -- that was part of the point of adding them --
to add a new feature with *different functionality* from globbing. Bastardizing
regex's to make them a little more like globbing is not a supportable position.
There's no reason to do it and it makes it incompatible not only with other
posix and gnu utils in regex handling, but also makes Bash internally inconsistent
with itself. That's at least 2 strikes against this lameness. More if you
look at the number of inconsistencies that breaking quoting causes.
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Jan Schampera wrote: Linda Walsh wrote: Why do (or should) double quotes lose their normal meaning inside double brackets? After initialĺy introducing =~, Chet made it consistent with =/== in a second version, means: =/== doesn't do pattern matching for parts inside quotes, =~ doesn't du regexp matching for parts inside quotes. Except this isnt' true. Quoting example C: t='one two three' a='one two three' 1) if [[ $t == $a ]]; then echo 'Matches'; fi 2) if [[ $t == "$a" ]]; then echo 'Matches'; fi examples. The above does match. the pattern in $a matches the pattern in $t whether it is in quotes or not. But with =~ it is different: t='one two three' a='one t.. three' 3) if [[ $t =~ $a ]]; then echo 'Matches'; fi 4) if [[ $t =~ "$a" ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes disable match'; fi They don't behave the same. My personal opinion is: This makes sense. Can't speak for others. --- If you would show me an example where pattern matching is disabled with ==, I might be more inclined to agree. But as I showed above, the pattern in $a matches regardless of double quoting. That's also the reason you have 2 different =~ behaviours. Please, whatever the reasonable result of this discussion is, do not make up yet the next =~ variant that's incompatible with the others ;) No...I'm pushing back on the incompatibility introduced after 3.1. I would like to see double quotes and single quotes NOT disable RE functionality when used with =~. I would like to suggest that to disable RE functionality, that the user use '==', instead. == is the same as =, my suggestion is to NOT touch that. You are not understanding my examples or what is going on. No where is there a change being suggested for ==. What I suggest is how ==/= already works. That's the lunacy of breaking =~ --- apparently people arguing against =~ meaning RE, don't know that literal matching is what already happens with the == operator (subject to variable expansion with double quotes, and no variable expansion inside of single quotes). That's the way Bash has always operated. I'm not suggesting any change to that. But what's happening here is that quotes are having an effect on the =~ operator. That would be similar (if you were right) to quotes disabling matching with == as well -- but it doesn't. That's why I claim =~ shouldn't either. I'm not going to respond to the rest of your post, as it appears you are posting under some misunderstanding of how bash currently works, so it's not really useful to respond to a position that doesn't really exist (at least not how I understand you saying it! ;-)).
Re: trap 'echo "trap exit on ${LINENO}"' EXIT -> wrong linenumber
On 9/14/10 3:44 AM, Jochen Dekeyser wrote:
> Bash Version: 4.1
> Patch Level: 7
> Release Status: release
>
> Description:
> Run this script:
>
> #!/bin/bash
>
> trap 'echo "trap error on ${LINENO}"' ERR
> trap 'echo "trap exit on ${LINENO}"' EXIT
>
> /bin/false
>
> exit 0
>
> You should get (and this is also the result you get in Bash 3.2):
>
> trap error on 6
> trap exit on 8
>
> But you get:
>
> trap error on 6
> trap exit on 1
This was changed in bash-4.0 with the rationale that traps, except the
special bash traps, should be run in a semi-independent environment with
a private value of $LINENO. As a result, $LINENO gets reset before
running the trap.
I guess you could make a case to not reset $LINENO for the exit trap
due to this sentence in Posix (though $LINENO is not Posix):
"The environment in which the shell executes a trap on EXIT shall be
identical to the environment immediately after the last command executed
before the trap on EXIT was taken."
I'll have to think about it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Case (in)sensitivity of complete -X patterns?
On 9/16/10 2:19 PM, Ville Skyttä wrote: > Hello, > > I was looking for a way to make complete/compgen -X filter patterns case > insensitive, but it seems that the -X patterns are not affected by nocaseglob > nor nocasematch, is that correct? That's correct. Those variables are applied at a different place in the code. > If yes, would it be possible to add something that would accomplish that in > future bash releases? Sure, I'll take a look for a future release. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
On 9/17/10 6:50 PM, Linda Walsh wrote: > > > Jan Schampera wrote: >> == is the same as =, my suggestion is to NOT touch that. > === I'm not going to say too much on this. The behavior as it exists now is very consistent: for both == and =~, any part of the rhs that's quoted is matched as a string. Period. It was a mistake not to do it that way in the first place. Matching is different from word expansion. The word expansions that take place in double-quoted words on the rhs of == and =~ are the same. I really don't understand a lot of Ms. Walsh's argument. I appreciate the effort she's put into this, but none of the examples she presents demonstrate what I think she's trying to prove. > Single quotes do not allow expansion of > variables, double quotes do expansion of variables. I.e. > > A. t='one two three' > a='two' > 1) if [[ $t == 'one $a three']]; then echo 'no match expected'; fi > 2) if [[ $t == "one $a three"]]; then echo 'Matches'; fi > 3) if [[ $t == one\ $a\ three ]]; then echo 'Matches'; fi > > So for =/==, double quotes allows *grouping* and is equivalent to 3. > But for the =~, it is broken: > > B. > t='one two three' > a='t..' > 1) if [[ $t =~ 'one $a three' ]]; then echo 'no match expected'; fi > 2) if [[ $t =~ "one $a three" ]]; then echo 'SHOULD Match'; else echo 'BUG, > double quotes disable match'; fi > 3) if [[ $t =~ one\ $a\ three ]]; then echo 'Matches'; fi You realize these two cases are not equivalent, right? Why would you expect A2 and B2 to be treated the same when one's a string and one's a pattern? > > -- but even more of the badness, single quotes disable matching entirely: > 4) if [[ $t =~ one\ t..\ three ]]; then echo 'Matches'; fi > 5) if [[ $t =~ 'one t.. three' ]]; then echo 'SHOULD Match'; else echo > 'BUG, double quotes disable match'; fi More precisely, quoted characters are matched as strings, with any special matching significance removed. > Or another disparity: C. > t='one two three' > c='one two three' > 1) if [[ $t == $a ]]; then echo 'Matches'; fi > 2) if [[ $t == "$a" ]]; then echo 'Matches'; fi > So, the expressions match whether or not $a is in double quotes or not Of course they do. They're the same string (I'm assuming that the assignment to `c' was a typo). There's no pattern matching happening at all. > (single quotes would not match, as the $a would be taken literally). > > But, with the operator that says 'take right hand expression as 'RE', do we > get consistent behavior?: > t='one two three' > a='one t.. three' > 3) if [[ $t =~ $a ]]; then echo 'Matches'; fi > 4) if [[ $t =~ "$a" ]]; then echo 'SHOULD Match'; else echo 'BUG, double > quotes disable match'; fi > Now, double quotes Don't behave consistently -- AGAIN Again, the examples are not equivalent. Did you do this deliberately? You're not helping your argument any by using examples that can at best be considered disingenuous and at worst deliberately misleading. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
On 9/17/10 8:20 PM, Linda Walsh wrote: > > > Andreas Schwab wrote: >> Linda Walsh writes: >> >>> Or another disparity: C. >>> t='one two three' >>> c='one two three' >>> 1) if [[ $t == $a ]]; then echo 'Matches'; fi >>> 2) if [[ $t == "$a" ]]; then echo 'Matches'; fi >>> So, the expressions match whether or not $a is in double quotes or not >>> (single quotes would not match, as the $a would be taken literally). >> >> Set a='one * three' and try again. > > Why? How would that be any different than case B4 & B5 that I already > showed? I'm not sure you are understanding the difference between one case that does not include any special pattern characters (what you're using with ==) and one that does (what you're using with =~). Since the quoting disables the special meaning of pattern characters, how can you claim that your examples are equivalent? >>> Quoting should not disable RE matching. That's what you're asserting. You're certainly entitled to do so. Since quoting does also disable pattern matching when using ==, however, you can't use alleged inconsistency as an argument. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
On 9/17/10 8:36 PM, Linda Walsh wrote: > t='one two three' > a='one two three' > 1) if [[ $t == $a ]]; then echo 'Matches'; fi > 2) if [[ $t == "$a" ]]; then echo 'Matches'; fi examples. > > The above does match. the pattern in $a matches the pattern > in $t whether it is in quotes or not. > > But with =~ it is different: > t='one two three' > a='one t.. three' > 3) if [[ $t =~ $a ]]; then echo 'Matches'; fi > 4) if [[ $t =~ "$a" ]]; then echo 'SHOULD Match'; else echo 'BUG, double > quotes disable match'; fi > > They don't behave the same. I can't understand why you think the two values of `a' are equivalent. Since they're not equivalent, how can you claim the behaviors should be identical? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
On Sat, Sep 18, 2010 at 3:36 AM, Linda Walsh wrote: > > --- > If you would show me an example where pattern matching is > disabled with ==, I might be more inclined to agree. But as I > showed above, the pattern in $a matches regardless of double quoting. glob="f??" re="f.." echo case: case foo in $glob) echo matches without quotes;; *) echo do no match without quotes;; esac case foo in "$glob") echo matches with quotes;; *) echo do no match with quotes;; esac echo "= in [[ ]]" if [[ foo = $glob ]]; then echo matches without quotes else echo do no match without quotes fi if [[ foo = "$glob" ]]; then echo matches with quotes else echo do no match with quotes fi echo "=~ in [[ ]]" if [[ foo =~ $re ]]; then echo matches without quotes else echo do no match without quotes fi if [[ foo =~ "$re" ]]; then echo matches with quotes else echo do no match with quotes fi $ bash test/g case: matches without quotes do no match with quotes = in [[ ]] matches without quotes do no match with quotes =~ in [[ ]] matches without quotes do no match with quotes
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
I'm sorry to not answer a message directly, but I didn't get the mails of this list during the last day - no idea why. Quoting text from the pipermail archive. >> After initialÄy introducing =~, Chet made it consistent with =/== >> in a second version, means: =/== doesn't do pattern matching for parts >> inside quotes, =~ doesn't du regexp matching for parts inside quotes. > >Except this isnt' true. Quoting example C: > > t='one two three' > a='one two three' > 1) if [[ $t == $a ]]; then echo 'Matches'; fi > 2) if [[ $t == "$a" ]]; then echo 'Matches'; fi examples. > > The above does match. the pattern in $a matches the pattern > in $t whether it is in quotes or not. > > But with =~ it is different: > t='one two three' > a='one t.. three' > 3) if [[ $t =~ $a ]]; then echo 'Matches'; fi > 4) if [[ $t =~ "$a" ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes > disable match'; fi Test with a='one t?? three', i.e. use a pattern matching special character. Or for the regex case, use NO regex special character. Then both should behave the same: Patter matching: $ t="one two three" $ a="one t?? three" $ [[ $t = $a ]]; echo $? 0 $ [[ $t = "$a" ]]; echo $? 1 Regular expression matching: $ t="one two three" $ a="one t.. three" $ [[ $t =~ $a ]]; echo $? 0 $ [[ $t =~ "$a" ]]; echo $? 1 Regards, Jan
