On Thu, Jul 07, 2005 at 09:24:07PM -0600, Bob Proulx wrote: > Roberto C. Sanchez wrote: > > I was reading the kill man page today looking for some information for a > > script I am writing. The man page mentioned that some shells have a > > kill built-in command. On further investigation, I noticed that bash > > has this as a built-in. > > > > My questions are: > > > > * should I explicitly call /bin/kill? > > No. Just call it 'kill' as you would normally. In general you should > avoid hard coding paths like this unless you have a specific reason. > And even then you should not use hard coded paths. :-) > > > * is there any advantage to avoiding the built-in? > > No. The man page is pointing this out because when people go to > report a bug in 'kill' they read man page and report it to procps or > coreutils or wherever. The maintainer there says you are not using > the standalone kill but rather the one in bash (or ash or ...) and so > then you back up and report the bug to bug-bash. > > Now that you know there is a shell built-in version by reading it in > the man page you can isolate the bug to the right package before > submitting an inquiry on it to the wrong one. (This is usually my > experience with kill, sleep, nice, test, etc. in coreutils. It is now > one of the FAQs in coreutils[1].) > > > * why the different implementations? > > It is there for BSD job control functionality. That way you can say > 'kill %1' and kill the background jobs by job control number. The > standalone version does not know about the shell's list of jobs. > > Bob > > [1] http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#I-am-having-a-problem-with-kill Thanks. That was very enlightening. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr
Attachment:
pgp3Bqytyo5wq.pgp
Description: PGP signature