chet@cwns1.CWRU.EDU (Chet Ramey) (11/14/89)
In article <127462@sun.Eng.Sun.COM> bitbug (James Buster) writes: >I believe it would be useful to add the following construct to bash shell >functions, similar in spirit to 'builtin': 'external'. >The syntax is just like builtin, i.e: > >function ls () { > external ls -FC $* >} I still don't see what's wrong with this: ls() { /bin/ls -FC "$@" } Jeez, a couple of extra characters when typing in the function... Seriously, I can see a need for some mechanism that will let people who insist on writing functions like this use the $PATH. I'm not sure a new keyword is the way to go, though. Maybe something like "only non-quoted words are scanned as possible function names", which is the way aliases are expanded. However, I'm not sure I like that any better. (I just took a few minutes, put it into bash, made sure it works, and then took it out again. It's pretty easy to do.) Anyone else have ideas? >I would also like to report what I consider a bug in bash: aliases >are expanded when a shell function is defined. I believe the correct >behavior is to expand aliases when the shell function is executed, >rather than when it is defined. Well, bash does aliases the way ksh does aliases, and this is the way that ksh aliases are defined to behave. When you think about it, it makes some sense, and it's wrong to do it the other way. Function definitions are executable bash statements (a function definition installs the function and returns success or failure as appropriate), and aliases are expanded in executable statements. Chet -- Chet Ramey Network Services Group "Where's my froggie?" Case Western Reserve University chet@ins.CWRU.Edu
bfox@AUREL.CNS.CALTECH.EDU (Brian Fox) (11/15/89)
Date: 14 Nov 89 15:32:32 GMT From: samsung!rex!ukma!cwjcc!cwns1!chet@uakari.primate.wisc.edu (Chet Ramey) >I believe it would be useful to add the following construct to bash shell >functions, similar in spirit to 'builtin': 'external'. >The syntax is just like builtin, i.e: > >function ls () { > external ls -FC $* >} Bash will have a "command" builtin in 1.05. "command" is useful for builtins or disk commands. It means to ignore aliases and functions when searching for the command. Brian
jbw@bucsf.bu.edu (Joe Wells) (11/15/89)
In article <8911142325.AA01114@aurel.cns.caltech.edu.> bfox@AUREL.CNS.CALTECH.EDU (Brian Fox) writes:
Bash will have a "command" builtin in 1.05. "command" is useful for
builtins or disk commands. It means to ignore aliases and functions
when searching for the command.
How about a "command" builtin that only executes programs in your path,
since "builtin" already exists for running builtin commands.
Thus, "builtin command foo" would always run program "foo".
--
Joe Wells <jbw@bucsf.bu.edu>
jbw%bucsf.bu.edu@bu-it.bu.edu
...!harvard!bu-cs!bucsf!jbwbfox@AUREL.CNS.CALTECH.EDU (Brian Fox) (11/16/89)
Date: 15 Nov 89 03:40:54 GMT
From: bucsb!bucsf!jbw@cs.bu.edu (Joe Wells)
Organization: Boston University Computer Science Department
References: <891@cwjcc.CWRU.Edu>, <8911142325.AA01114@aurel.cns.caltech.edu.>
Sender: bug-bash-request@prep.ai.mit.edu
In article <8911142325.AA01114@aurel.cns.caltech.edu.> bfox@AUREL.CNS.CALTECH.EDU (Brian Fox) writes:
Bash will have a "command" builtin in 1.05. "command" is useful for
builtins or disk commands. It means to ignore aliases and functions
when searching for the command.
How about a "command" builtin that only executes programs in your path,
since "builtin" already exists for running builtin commands.
Thus, "builtin command foo" would always run program "foo".
For the most part, shell scripts do not care if the command that they
are executing is a builtin or on disk, they only care that it isn't a
functin or alias.
If you want to use disk commands, you can disable all of the shell
builtins that you don't want to use with the "enable -n" command.
Brianjbw@bucsf.bu.edu (Joe Wells) (11/19/89)
In article <8911142325.AA01114@aurel.cns.caltech.edu.> (Brian Fox) writes: Bash will have a "command" builtin in 1.05. "command" is useful for builtins or disk commands. It means to ignore aliases and functions when searching for the command. In article <JBW.89Nov14224054@bucsf.bu.edu> (Joe Wells) writes: How about a "command" builtin that only executes programs in your path, since "builtin" already exists for running builtin commands. Thus, "builtin command foo" would always run program "foo". In article <8911151705.AA03733@aurel.cns.caltech.edu.> (Brian Fox) writes: If you want to use disk commands, you can disable all of the shell builtins that you don't want to use with the "enable -n" command. Unfortunately, this is hard when the name of the executable file is not known beforehand, but is instead taken from the input or the environment. After thinking about this, I realized that a more useful command would be one like "type -path foo", except that it would return the full pathname of the executable file named "foo" that would be executed, *if there were no builtins, aliases, or functions named "foo"*, and would return nothing if there were no such executable file in the user's path. This is a cross between the current semantics of "type -path foo" and "type -all -path foo". -- Joe Wells <jbw@bucsf.bu.edu> jbw%bucsf.bu.edu@bu-it.bu.edu ...!harvard!bu-cs!bucsf!jbw