pkill -l
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use case I can think of
is did I kill the right process? which is literally the kind of shoot
first, ask questions later behavior we should maybe not encourage.
Related: linux pkill doesn't support -l either.
Index: pkill.1
===
RCS file: /cvs/src/usr.bin/pkill/pkill.1,v
retrieving revision 1.20
diff -u -p -r1.20 pkill.1
--- pkill.1 21 Aug 2012 09:45:50 - 1.20
+++ pkill.1 24 Sep 2013 02:17:59 -
@@ -49,7 +49,7 @@
.Op Ar pattern ...
.Nm pkill
.Op Fl Ar signal
-.Op Fl flnoqvx
+.Op Fl fnoqvx
.Op Fl G Ar gid
.Op Fl g Ar pgrp
.Op Fl P Ar ppid
@@ -101,9 +101,10 @@ Print the process name in addition to th
process.
If used in conjunction with
.Fl f ,
-print the process ID and the full argument list for each matching process
-.Pf ( Nm pgrep
-only).
+print the process ID and the full argument list for each matching process.
+This option can only be used with the
+.Nm pgrep
+command.
.It Fl n
Match only the most recently created (newest) process, if any.
Cannot be used in conjunction with
Index: pkill.c
===
RCS file: /cvs/src/usr.bin/pkill/pkill.c,v
retrieving revision 1.31
diff -u -p -r1.31 pkill.c
--- pkill.c 12 Dec 2012 22:25:21 - 1.31
+++ pkill.c 24 Sep 2013 02:16:37 -
@@ -184,6 +184,8 @@ main(int argc, char **argv)
criteria = 1;
break;
case 'l':
+ if (!pgrep)
+ usage();
longfmt = 1;
break;
case 'n':
@@ -446,7 +448,7 @@ usage(void)
if (pgrep)
ustr = [-flnoqvx] [-d delim];
else
- ustr = [-signal] [-flnoqvx];
+ ustr = [-signal] [-fnoqvx];
fprintf(stderr, usage: %s %s [-G gid] [-g pgrp] [-P ppid] [-s sid]
\n\t[-T rtable] [-t tty] [-U uid] [-u euid] [pattern ...]\n,
@@ -458,9 +460,6 @@ usage(void)
int
killact(struct kinfo_proc *kp, int dummy)
{
- if (longfmt !quiet)
- printf(%d %s\n, (int)kp-p_pid, kp-p_comm);
-
if (kill(kp-p_pid, signum) == -1) {
if (errno == ESRCH)
return (STATUS_NOMATCH);
Re: pkill -l
On 10/22/13 02:09, Ted Unangst wrote:
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use case I can think of
is did I kill the right process? which is literally the kind of shoot
first, ask questions later behavior we should maybe not encourage.
I tend to pgrep -fl for a process to kill, and then I always have to
think about which switch to remove. Being as tightly coupled as they
are, I think allowing -l for both is helpful.
I agree the output is inconstistant, but I'd rather have that fixed (if
possible) than it being removed.
$ sleep 50
[1] 2673
$ pgrep -fl sleep
25664 sleep 5
2673 sleep 50
$ pgrep -fl 'sleep 50'
2673 sleep 50
$ pkill -l 'sleep 50'
$ pgrep -fl 'sleep 50'
2673 sleep 50
$ #fuck
$ pkill -f 'sleep 50'
[1] + Terminated sleep 50
Related: linux pkill doesn't support -l either.
Indeed, which annoys me almost every day at work. ;-)
/Alexander
Index: pkill.1
===
RCS file: /cvs/src/usr.bin/pkill/pkill.1,v
retrieving revision 1.20
diff -u -p -r1.20 pkill.1
--- pkill.1 21 Aug 2012 09:45:50 - 1.20
+++ pkill.1 24 Sep 2013 02:17:59 -
@@ -49,7 +49,7 @@
.Op Ar pattern ...
.Nm pkill
.Op Fl Ar signal
-.Op Fl flnoqvx
+.Op Fl fnoqvx
.Op Fl G Ar gid
.Op Fl g Ar pgrp
.Op Fl P Ar ppid
@@ -101,9 +101,10 @@ Print the process name in addition to th
process.
If used in conjunction with
.Fl f ,
-print the process ID and the full argument list for each matching process
-.Pf ( Nm pgrep
-only).
+print the process ID and the full argument list for each matching process.
+This option can only be used with the
+.Nm pgrep
+command.
.It Fl n
Match only the most recently created (newest) process, if any.
Cannot be used in conjunction with
Index: pkill.c
===
RCS file: /cvs/src/usr.bin/pkill/pkill.c,v
retrieving revision 1.31
diff -u -p -r1.31 pkill.c
--- pkill.c 12 Dec 2012 22:25:21 - 1.31
+++ pkill.c 24 Sep 2013 02:16:37 -
@@ -184,6 +184,8 @@ main(int argc, char **argv)
criteria = 1;
break;
case 'l':
+ if (!pgrep)
+ usage();
longfmt = 1;
break;
case 'n':
@@ -446,7 +448,7 @@ usage(void)
if (pgrep)
ustr = [-flnoqvx] [-d delim];
else
- ustr = [-signal] [-flnoqvx];
+ ustr = [-signal] [-fnoqvx];
fprintf(stderr, usage: %s %s [-G gid] [-g pgrp] [-P ppid] [-s sid]
\n\t[-T rtable] [-t tty] [-U uid] [-u euid] [pattern ...]\n,
@@ -458,9 +460,6 @@ usage(void)
int
killact(struct kinfo_proc *kp, int dummy)
{
- if (longfmt !quiet)
- printf(%d %s\n, (int)kp-p_pid, kp-p_comm);
-
if (kill(kp-p_pid, signum) == -1) {
if (errno == ESRCH)
return (STATUS_NOMATCH);
Re: pkill -l
On Tue, Oct 22, 2013 at 02:34, Alexander Hall wrote: On 10/22/13 02:09, Ted Unangst wrote: I don't think the -l flag to pkill is useful. It's behavior is oddly different from pgrep -l (and more different with pgrep/pkill -f). Or rather, it's not just long output, but also turns on verbose mode when otherwise nothing would be printed. The only use case I can think of is did I kill the right process? which is literally the kind of shoot first, ask questions later behavior we should maybe not encourage. I tend to pgrep -fl for a process to kill, and then I always have to think about which switch to remove. Being as tightly coupled as they are, I think allowing -l for both is helpful. I agree the output is inconstistant, but I'd rather have that fixed (if possible) than it being removed. $ sleep 50 [1] 2673 $ pgrep -fl sleep 25664 sleep 5 2673 sleep 50 $ pgrep -fl 'sleep 50' 2673 sleep 50 $ pkill -l 'sleep 50' $ pgrep -fl 'sleep 50' 2673 sleep 50 $ #fuck $ pkill -f 'sleep 50' [1] + Terminated sleep 50 This is exactly the problem I experience. I didn't want to rely solely on I can't remember which flag to use, but yes, that is the root of the problem. Removing support for -l causes it to be a hard error, that one will notice, as opposed to a silent failure.
