On Sat, 25 Nov 1995, Ian Jackson wrote:
> > Run-parts does not run scripts not beginning with #!/... This may not be
> > a bug, but it should be documented. run-parts --test, however, displays
> > _all_ scripts, which is rather confusing, and not a test at all.
> It does run them - or try to, anyway. It invokes `system' in Perl.
> Unfortunately Perl does the wrong thing when you say
> $foo='./t'; system($foo './u');
What it does is documented: It calls execvp, which in turn executes only
script _with_ #!/interpreter (or binaries of course).
If we want run-parts to execute scripts without #!/interpreter, then the
following should work:
--- /bin/run-parts Sat Nov 4 21:12:17 1995
+++ /home/hs/bin/run-parts Sun Nov 26 11:27:31 1995
@@ -43,7 +43,7 @@
} elsif ($test) {
print("$cmd would run $path\n") || &quit("$cmd: output error: $!");
} else {
- $!=0; system($path $f);
+ $!=0; system($path);
if ($? && $!) {
warn "$cmd: running $path gave exit status $?, error $!\n";
$exitstatus= 1;
system() with a single argument is also executed (after word splitting)
by execvp, but if it returns ENOEXEC, then perl runs /bin/sh -c $cmd.
If on the other hand we want run-parts to run only #!/-scripts, then the
--test argument and the manpage should be changed. (It took me some time
to find out, why my setserial script did not run, although it was shown
with run-parts --test)
> if ./t isn't a proper executable script. IMO it should produce a
> message to stderr, but it doesn't.
perl -w produces a warning in that case. perl without -w is silent.
> Instead $? is set to 62580 and no
> message is produced.
I did not find which error should be returned if system cannot execvp. I
agree, I would expect -1, and $! should be set (which it isn't). Maybe
this is a bug in perl? Anyway, it has nothing to do with the
inconsistency between run-parts and it's documentation.
Harald Schueler
Universitaet Essen Tel +49-201-1832456
Fachbereich 7 Fax +49-201-1832120
45117 Essen Email [EMAIL PROTECTED]
