New answers tagged


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.


You can use env your-command to avoid interference from the shell. Example: $ env kill -L 1 HUP 2 INT 3 QUIT 4 ILL 5 TRAP 6 ABRT 7 BUS 8 FPE 9 KILL 10 USR1 11 SEGV 12 USR2 13 PIPE 14 ALRM 15 TERM 16 STKFLT 17 CHLD 18 CONT 19 STOP 20 TSTP 21 TTIN 22 TTOU 23 URG 24 XCPU 25 XFSZ 26 ...


Because time is a shell builtin, it writes to the shell's stderr, rather than the command's stderr. Using parentheses forces the whole command into a child shell whose stderr can be redirected. using curly brackets produces a similar result without actually starting a subshell { time who ; } > /tmp/timwho >& /tmp/xx (yes, you need the ...


In ksh, bash and zsh, time is not a command (builtin or not), it's a reserved word in the language like for or while. It's used to time a pipeline1. In: time for i in 1 2; do cmd1 "$i"; done | cmd2 > redir You have special syntax that tells the shell to run that pipe line: for i in 1 2; do cmd1 "$i"; done | cmd2 > redir And report timing ...


There's no command named time wc, time and wc are separated word in shell. Now, there're often two separate program named time, the one is shell keyword, another one is external command. In shells which time is a shell keyword, when you type time wc ..., the shell used its keyword time instead of the external time utility. When the shell uses time keyword, ...


It is not time that writes the time information. The builtin time makes the shell write this after the command has completed. But redirection affects only the command. In the (time ...) case the redirection is applied to the whole subshell.


Because time you're executing is bash builtin. Bash processes it in such special way. If you will use real time binary, it will act exactly in the way you expect it: /usr/bin/time wc file > wc.out 2>&1 Though the output of this time is a bit different: $ /usr/bin/time wc file > wc.out 0.00user 0.00system 0:00.00elapsed ?%CPU ...


It is a matter of which shell we are talking about. On this shell, I get: $ times 0m9.805s 0m3.372s 39m29.072s 0m15.537s Because it has been running for a while. However, a sub-shell will report zero: $ ( times ) 0m0.000s 0m0.000s 0m0.000s 0m0.000s And, as a pipeline is executed in a sub-shell for each part of it: $ sleep 10 | times 0m0.000s 0m0.000s ...


Within a pipeline, all commands are run in a subshell. times reports time spent by the shell and its subshells, but not its parent shell. You can try process substitution instead: times > >( head -n1 ) times > >( read user sys ; echo $user )

Top 50 recent answers are included