Thanks. Looks like a good patch. I'll test it out and upload a new version
soon. I hadn't tested randomplay with 'play' before.

Christopher Zimmermann wrote:
> Package: randomplay
> Version: 0.47
> Severity: normal
> Tags: patch
> 
> Hi, 
> randomplay failes to skip tracks played by the play command, which in
> turn runs sox. That's because the KillAll sub is limited to kill only
> the children of a process and not it's grandchildren. I modified it to
> recursively kill all descendants.
> 
> Christopher
> 
> 
> *** patch
> --- /usr/bin/randomplay       2005-09-04 13:57:39.000000000 +0200
> +++ randomplay        2005-10-24 22:28:43.000000000 +0200
> @@ -67,7 +67,7 @@
>    eval $regexp_if_statement;
>  }
>  
> -# KillAll kills the request process ID and all of its children
> +# KillAll recursively kills the request process ID and all of its children, 
> grandchildren...
>  # This is a bit of a hack--there should be a better way to do this, but I 
> haven't found one.
>  # Normally, kill HUP => -$$ should do the job, except this doesn't work when 
> randomplay itself
>  # is called from a shell script and all output from child processes is 
> redirected to null.
> @@ -79,7 +79,8 @@
>    local $SIG{HUP} = 'IGNORE';   # don't want to kill ourselves 
> here--shouldn't happen, but just in case.
>    if (open PS, "ps -o pid,ppid |") {
>       foreach my $line (<PS>) {
> -       kill HUP => $1 if ($line =~ /^\s*(\d+)\s*(\d+)\s*$/ and ($1 eq $pid 
> or $2 eq $pid));
> +       kill HUP => $pid;
> +       KillAll($1) if ($line =~ /^\s*(\d+)\s*(\d+)\s*$/ and ($2 eq $pid));
>       }
>       close PS;
>    } else {                      # if we can't read the process table, just 
> try killing the child process group
> 
> 
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: sparc (sparc64)
> Shell:  /bin/sh linked to /bin/dash
> Kernel: Linux 2.6.14-rc4-sparc
> Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
> 
> Versions of packages randomplay depends on:
> ii  libdate-calc-perl             5.4-4      Perl library for accessing dates
> ii  libmp3-info-perl              1.13-1     Perl MP3::Info - Manipulate / 
> fetc
> ii  libogg-vorbis-header-perl     0.03-1     perl interface to Ogg Vorbis 
> infor
> ii  libterm-readkey-perl          2.30-2     A perl module for simple 
> terminal 
> ii  perl                          5.8.7-6    Larry Wall's Practical 
> Extraction 
> 
> Versions of packages randomplay recommends:
> ii  mpg321                        0.2.10.3   A Free command-line mp3 player, 
> co
> ii  vorbis-tools                  1.0.1-1.4  Several Ogg Vorbis Tools
> 
> -- no debconf information
> 
> 
> ------------------------------------------------------------------------
> 
> --- /usr/bin/randomplay       2005-09-04 13:57:39.000000000 +0200
> +++ randomplay        2005-10-24 22:28:43.000000000 +0200
> @@ -67,7 +67,7 @@
>    eval $regexp_if_statement;
>  }
>  
> -# KillAll kills the request process ID and all of its children
> +# KillAll recursively kills the request process ID and all of its children, 
> grandchildren...
>  # This is a bit of a hack--there should be a better way to do this, but I 
> haven't found one.
>  # Normally, kill HUP => -$$ should do the job, except this doesn't work when 
> randomplay itself
>  # is called from a shell script and all output from child processes is 
> redirected to null.
> @@ -79,7 +79,8 @@
>    local $SIG{HUP} = 'IGNORE';   # don't want to kill ourselves 
> here--shouldn't happen, but just in case.
>    if (open PS, "ps -o pid,ppid |") {
>       foreach my $line (<PS>) {
> -       kill HUP => $1 if ($line =~ /^\s*(\d+)\s*(\d+)\s*$/ and ($1 eq $pid 
> or $2 eq $pid));
> +       kill HUP => $pid;
> +       KillAll($1) if ($line =~ /^\s*(\d+)\s*(\d+)\s*$/ and ($2 eq $pid));
>       }
>       close PS;
>    } else {                      # if we can't read the process table, just 
> try killing the child process group



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to