Jakub Sadowski wrote:
> Machine: i586
>
> OS: linux-gnu
>
> Compiler: gcc
>
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-mandriva-linux-gnu'
> -DCONF_VENDOR='mandriva' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -O2 -pipe
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fomit-frame-pointer -march=i586
> -mtune=pentiumpro -fasynchronous-unwind-tables
> uname output: Linux localhost 2.6.18.8.tex5 #1 SMP Thu May 10 11:36:58 WST
> 2007 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux
> Machine Type: i586-mandriva-linux-gnu
>
> Bash Version: 3.1
>
> Patch Level: 17
>
> Release Status: release
>
>
> Description:
> The bash shell restricts the wait builtin to operating on child processes of
> the current shell or script. This is an excessive restriction as it should
> be
> restricted to processes owned by the same user as that of the current shell
> or
> script.
In general, there's no good way for a shell, or any process, to be
notified about status changes in an arbitrary process. The underlying
standard system calls (wait, waitid, and waitpid) only work on children
of the calling process.
The status polling loop you describe as crude is just as well implemented
outside the shell as internally, with the obvious caveat that by your
definition root can "own" any process.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
