Chet Ramey <chet.ra...@case.edu> writes: > So I assume that you want to change the kernel's idea of the process > arguments as seen and displayed by `ps'. If so, I'm not really interested > in adding that as a feature. It doesn't seem to add anything for shell > users.
Well, I am a shell user :).
I would really love to have such a feature because I have two use-cases
for it.
1. I would use it as a super minimalist progress indicator for one-shot
scrips written with little consideration.
For example, I sometimes find myself writing something like:
`while true; do try_something_slow && exit 0 ; sleep 1 ; done &`
With a setproctitle I would write something like:
`I=0 ; while true; do try_something_slow && exit 0 ; I=$((I + 1)) ;
setproctitle "trier_$I-times" sleep 1 ; done &`
And this leaves no lingering files, does not require finding a PID to
look at `/proc/$pid/environ`, et cetera. I can just query the progress
using `ps`.
2. I would use it to distinguish subshells from the current script in
`ps`.
By default a subshell has the same name as the parent shell.
So when I run `ps/pgrep`, I often get processes with the same name, and
I'd have to parse the output of `pstree` to find out which is which.
And running exec -a "${BASH_ARGV0}_child" while true ; do sleep 1 ; done &
is not a valid syntax.
I think this would greatly simplify debugging shell scripts, but maybe
it's just me.
>I think this is appropriate for a loadable builtin. This one is Linux-
>specific.
I am not experienced enough to have an opinion on whether a loadable
built-in is better than a feature of "exec".
--
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)
signature.asc
Description: PGP signature
