On 8/4/10 8:31 AM, Greg Wooledge wrote:
> In fact, putting the ERE-pattern you want to match against into a variable
> and then using =~ $variable *is* the recommended practice, if you need to
> use =~ at all. It is the only way to get consistent results among all
> the different releases of bash
On 8/4/10 10:38 AM, Clark J. Wang wrote:
> Function definitions are not simple commands. Actually, func definition
> syntax is listed under the *Compound Commands* section in bash2.05b's man
> page and in bash3+ it's been moved to a separate section.
While technically true, that doesn't enter int
On 8/3/10 5:23 PM, Eric Blake wrote:
> But why not teach the matcher the difference between a fixed-length
> pattern, vs. one that has * or other extended globbing that would cause
> a variable length match? That is, since you know that [^;] can match at
> most one character, there is no need to
Am 04.08.2010 16:38, schrieb Clark J. Wang:
On Wed, Aug 4, 2010 at 8:27 PM, Bernd Eggink wrote:
Am 04.08.2010 12:39, schrieb Clark J. Wang:
I was testing the precedence between functions and aliases so I tried like
this (with bash 4.1.5):
$ cat rc
alias foo='echo this is the alias'
foo()
Andreas Schwab wrote:
> Bob Proulx writes:
> > Neither of those produce any output.
> >
> > $ printf '%d\n' ""
> > 0
>
> Since the command substitution is not quoted the result of the expansion
> is subject to field splitting, thus expands to nothing at all instead of
> a single empty argument
Bob Proulx writes:
> Neither of those produce any output.
>
> $ printf '%d\n' ""
> 0
Since the command substitution is not quoted the result of the expansion
is subject to field splitting, thus expands to nothing at all instead of
a single empty argument.
Andreas.
--
Andreas Schwab, sch..
Peng Yu wrote:
> I have the following script and output. The man page says "Return a
> status of 0 or 1 depending on the evaluation of the conditional
> expression expression." Therefore, I thought that the two printf
> statements should print 1 and 0 respectively. But both of them print
> 0. I'
On Wednesday 04 Aug 2010 16:03:25 Peng Yu wrote:
> I have the following script and output. The man page says "Return a
> status of 0 or 1 depending on the evaluation of the conditional
> expression expression." Therefore, I thought that the two printf
> statements should print 1 and 0 respecti
Hello All,
I have the following script and output. The man page says "Return a
status of 0 or 1 depending on the evaluation of the conditional
expression expression." Therefore, I thought that the two printf
statements should print 1 and 0 respectively. But both of them print
0. I'm wondering w
On Wed, Aug 4, 2010 at 8:27 PM, Bernd Eggink wrote:
> Am 04.08.2010 12:39, schrieb Clark J. Wang:
>
> I was testing the precedence between functions and aliases so I tried like
>> this (with bash 4.1.5):
>>
>> $ cat rc
>> alias foo='echo this is the alias'
>>
>> foo()
>> {
>> builtin echo 't
On Wed, Aug 4, 2010 at 7:03 PM, Marc Herbert wrote:
> Le 04/08/2010 11:39, Clark J. Wang a écrit :
>
> > Seems like I must explicitly use the `function' keyword to define foo()
> for
> > this scenario. Is that the correct behavior?
>
> The correct behaviour is simply not to use aliases, since the
Am 04.08.2010 15:13, schrieb Eric Blake:
On 08/04/2010 05:03 AM, Marc Herbert wrote:
Le 04/08/2010 11:39, Clark J. Wang a écrit :
Seems like I must explicitly use the `function' keyword to define foo() for
this scenario. Is that the correct behavior?
The correct behaviour is simply not to us
On 08/04/2010 05:03 AM, Marc Herbert wrote:
> Le 04/08/2010 11:39, Clark J. Wang a écrit :
>
>> Seems like I must explicitly use the `function' keyword to define foo() for
>> this scenario. Is that the correct behavior?
>
> The correct behaviour is simply not to use aliases, since they bring noth
On Wed, Aug 04, 2010 at 02:02:39AM -0700, Linda Walsh wrote:
> Other string operators? What other ones operate this way?
>
> This is what I'm referring to:
>
> a="hi"
> if [[ "hi" == "$a" ]]; then echo "this matches"; fi
> if [[ 'hi' == '$a' ]] then echo "this doesn't"; fi
You are misunderstand
Am 04.08.2010 12:39, schrieb Clark J. Wang:
I was testing the precedence between functions and aliases so I tried like
this (with bash 4.1.5):
$ cat rc
alias foo='echo this is the alias'
foo()
{
builtin echo 'this is the function'
}
foo
$ source rc
bash: confusing-aliases-2.sh: line 4: sy
Le 04/08/2010 11:39, Clark J. Wang a écrit :
> Seems like I must explicitly use the `function' keyword to define foo() for
> this scenario. Is that the correct behavior?
The correct behaviour is simply not to use aliases, since they bring nothing
to the table compared to functions. Have a look at
Le 04/08/2010 09:27, Davide Brini a écrit :
> From the Changelog:
>
> This document details the changes between this version, bash-3.2-alpha,
> and the previous version, bash-3.1-release.
> ...
> 3. New Features in Bash
> ...
> f. Quoting the string argument to the [[ command's =~ operator now
I was testing the precedence between functions and aliases so I tried like
this (with bash 4.1.5):
$ cat rc
alias foo='echo this is the alias'
foo()
{
builtin echo 'this is the function'
}
foo
$ source rc
bash: confusing-aliases-2.sh: line 4: syntax error near unexpected token `('
bash: conf
Linda Walsh writes:
> I would prefer this work:
>
> a="h."
>
> if [[ "hi" =~ "$a" ]];
This works (both with and without compat31):
[[ "hi" =~ $a ]] && echo matches
(It doesn't matter how you quote the lhs, anyway.)
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint =
Oi vey.
Is that the only thing that will be affected by shopt -s compat31?
Or perhaps that shopt needs to be a bit more specific.
> So your example would have worked with "shopt -s compat31".
>
>From the file COMPAT:
33. Bash-3.2 adopts the convention used by other string and pattern matchi
On Wednesday 04 Aug 2010 09:06:16 Linda Walsh wrote:
> On 8/1/2010 8:11 PM, Chris F.A. Johnson wrote:
> > On Sun, 1 Aug 2010, Linda Walsh wrote:
> >> I have:
> >>
> >> w="/home/law/bin/package: line 5: type: xx: not found"
> >>
> >> The =~ operator is suppose to use the RH Expr as a ext.-regex.
>
On 8/1/2010 8:11 PM, Chris F.A. Johnson wrote:
> On Sun, 1 Aug 2010, Linda Walsh wrote:
>
>> I have:
>>
>> w="/home/law/bin/package: line 5: type: xx: not found"
>>
>> The =~ operator is suppose to use the RH Expr as a ext.-regex.
>>
>> So why doesn't this match and print "not found"?
>>
>> if [
22 matches
Mail list logo
