set function and special builtin set

[Clive Nicolson]

Is it posible to get a user function named set to be called in place of 
the special builtin set?


ie

set() { echo "My set $@" ;}

set params

Thanks
Clive


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash=~ bug or feature

[Jeff Chua]

On Thu, 17 May 2007, Bob Proulx wrote:


The behavior has been intentionally changed.

Please see Bash FAQ item E14.



Ok, thanks. I should have read the FAQ first.

Thanks,
Jeff.



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: set function and special builtin set

[Benno Schulenberg]

Clive Nicolson wrote:
> Is it posible to get a user function named set to be called in
> place of the special builtin set?
>
> ie
>
> set() { echo "My set $@" ;}
>
> set params

You haven't tried this?

$ set() { echo "My set $@" ;}
$ set params
My set params

It just works.

Also read the output of 'help builtin'.

Benno


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: set function and special builtin set

[Andreas Schwab]

Benno Schulenberg <[EMAIL PROTECTED]> writes:

> Clive Nicolson wrote:
>> Is it posible to get a user function named set to be called in
>> place of the special builtin set?
>>
>> ie
>>
>> set() { echo "My set $@" ;}
>>
>> set params
>
> You haven't tried this?
>
> $ set() { echo "My set $@" ;}
> $ set params
> My set params
>
> It just works.

It's not supposed to.  See
:

If a simple command results in a command name and an optional list
of arguments, the following actions shall be performed:
  1. If the command name does not contain any slashes, the first
  successful step in the following sequence shall occur:
a. If the command name matches the name of a special
built-in utility, that special built-in utility shall be
invoked.

(And set is a special built-in.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: set function and special builtin set

[Benno Schulenberg]

Andreas Schwab wrote:
> Benno Schulenberg <[EMAIL PROTECTED]> writes:
> > $ set() { echo "My set $@" ;}
> > $ set params
> > My set params
> >
> > It just works.
>
> It's not supposed to.  See
>:
>
> If a simple command results in a command name and an optional
> list of arguments, [...]

But set() is not a simple command, it is a function definition, no?

Benno


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: set function and special builtin set

[Paul Jarc]

Benno Schulenberg <[EMAIL PROTECTED]> wrote:
> Andreas Schwab wrote:
>>:
>>
>> If a simple command results in a command name and an optional
>> list of arguments, [...]
>
> But set() is not a simple command, it is a function definition, no?

Right, so defining the function should work, but calling it should
not.


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: set function and special builtin set

[Benno Schulenberg]

Paul Jarc wrote:
> Benno Schulenberg <[EMAIL PROTECTED]> wrote:
> > Andreas Schwab wrote:
> >> >>ap02.html#tag_02_09_01_01>:
> >>
> >> If a simple command results in a command name and an
> >> optional list of arguments, [...]
> >
> > But set() is not a simple command, it is a function definition,
> > no?
>
> Right, so defining the function should work, but calling it
> should not.

Ah!  Okay.

$ export POSIXLY_CORRECT=yes
$ set() { echo "My set $@" ;}
$ set params
$ unset POSIXLY_CORRECT
$ set params
My set params

Benno


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: variable assignments and parameter expansion in a single command

[Kevin F. Quinn]

Following a discussion we had earlier this year regarding the order of
evaluation of variables and variable assignments:

 $ A="moo" B="$A more" env |grep ^B
 B=moo more

(rather than showing just 'B= more')
the dash maintainer has highlighted the following:


 $ bash -c 'K=dvb0.net0 A=${K#dvb} eval echo \$A'

 $ bash -c 'a=/bin PATH=$a ls /dev/null'
 bash: line 1: ls: No such file or directory
 $ bash -c 'x=${K:=dvb0.net0} A=${K#dvb} echo $A'

 $


which he says is inconsistent.  I could see the third one is correct
(variable assignments are evaluated after expansion, according to the
spec), but can't see whether the first two are correct or not.

Is the bash behaviour correct in these cases?

Cheers,
Kev.


signature.asc
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

some more inline assignments / evaluation wrt POSIX

[Mike Frysinger]

testing with bash-3.2p17 here ...

looking at these statements:
K=dvb0.net A=${K#dvb} echo "$A"
K=dvb0.net A=${K#dvb} ; echo "$A"
K=dvb0.net A=${K#dvb} eval echo '$A'

shouldnt "0.net" always be displayed ?  looks like A is always set properly 
to "0.net", but in the first statement, $A gets expanded before the variable 
assignments are processed
-mike


signature.asc
Description: This is a digitally signed message part.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: some more inline assignments / evaluation wrt POSIX

[Andreas Schwab]

Mike Frysinger <[EMAIL PROTECTED]> writes:

> testing with bash-3.2p17 here ...
>
> looking at these statements:
> K=dvb0.net A=${K#dvb} echo "$A"
> K=dvb0.net A=${K#dvb} ; echo "$A"
> K=dvb0.net A=${K#dvb} eval echo '$A'
>
> shouldnt "0.net" always be displayed ?  looks like A is always set properly 
> to "0.net", but in the first statement, $A gets expanded before the variable 
> assignments are processed

See
.
The command is expanded before the assignments are evaluated.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash