Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!ucsd!usc!samsung!uunet!bu-cs!bucsb!bucsf!jbw From: jbw@bucsf.bu.edu (Joe Wells) Newsgroups: gnu.bash.bug Subject: Re: Request for enhancement Message-ID: Date: 18 Nov 89 23:46:27 GMT References: <8911151705.AA03733@aurel.cns.caltech.edu.> Distribution: gnu Organization: Boston University Computer Science Department Lines: 29 In-reply-to: bfox@AUREL.CNS.CALTECH.EDU's message of 15 Nov 89 17:05:07 GMT 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 (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@bu-it.bu.edu ...!harvard!bu-cs!bucsf!jbw