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:~$
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 va
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 =~ b
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
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
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
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
>
> /bi
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 dif
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 str
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 m
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.
>
>
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:
c
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 f
13 matches
Mail list logo
