I use Bash as my interactive shell and I was wondering if there was an easy way to get Bash to run a system command instead of a shell builtin command in the case where they both share the same name.
For example, use the system kill (from util-linux) to print the process id (pid) of the named process(es) instead of sending a signal:
$ /bin/kill -p httpd 2617 ...
Without specifying the full path of the system command, the Bash builtin is used instead of the system command. The kill builtin doesn’t have the -p option so the command fails:
$ kill -p httpd bash: kill: p: invalid signal specification
I tried the answers listed in Make bash use external `time` command rather than shell built-in but most of them only work because time is actually a shell keyword – not a shell builtin.
Other than temporarily disabling the Bash builtin with enable -n kill, the best solution I’ve seen so far is to use:
$(which kill) -p httpd
Are there other easier (involve less typing) ways to execute an external command instead of a shell builtin?
Note that kill is just an example and I’d like a generalised solution similar to the way that prefixing with the command builtin prevents functions which have the same name as an external command from being run. In most cases, I usually prefer to use the builtin version as it saves forking a new process and some times the builtin has features that the external command doesn’t.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Assuming env is in your path:
env kill -p http
env runs the executable file named by its first argument in a (possibly) modified environment; as such, it does not know about or work with shell built-in commands.
This produces some shell job control cruft, but doesn’t rely on an external command:
exec kill -p bash &
exec requires an executable to replace the current shell, so doesn’t use any built-ins. The job is run in the background so that you replace the forked background shell, not your current shell.
Method 2
The simplest way to do what you want might be to put the line
alias kill="/bin/kill"
into your ~/.bashrc file. After that, each new login/invocation of bash will interpret “kill” as /bin/kill.
Method 3
If you know a solution that requires some typing and you want a solution that requries less typing, build it:
runFile() { local cmd="$1"; shift; cmd="$(which "$cmd")" && "$cmd" "<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="3a1e7a">[email protected]</a>"; }
Abbreviating stuff that normally takes some effort is what computers excel at.
Method 4
In this very specific case, the command pgrep is an exact match for the need.
In a general sense, a function works. From “file command”:
fcmd(){ local a=$1; shift; $(which "$a") "<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="614521">[email protected]</a>"; }
call as
fcmd kill -p httpd
But if you need less typing, there is no shorter way than a good alias.
From the concept “list pid” (lp):
alias lp='/bin/kill -p'
then, just type:
lp httpd
Method 5
(In zsh) You can prefix any command name with an = sign to get the system version instead of a builtin. This is also a handy way to dodge any aliases that mess up a specific scenario.
$ =kill -p httpd
Method 6
You could send a bugreport against your kill manpage and ask why this includes non-standard options that are taken from pkill and use pkill whenever you like to get the features from pkill.
If you call:
pkill httpd
you avoid the problems you describe.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0