strace ./backup
should shed some light on the problem.
Also, make sure the file is properly newline terminated (I've sometimes seen weird problems running shell scripts transferred from Windows that were terminated with \r\n).
| [reply] [d/l] |
... make sure the file is properly newline terminated ...
Very good point. I actually considered that, though, because I had had exactly such a problem at work about 3 or 4 days ago (a Linux tarball was unzipped on Windows, then put back together, and none of the scripts in it behaved correctly -- turned out they had all been converted to [dos] format). So I had already done a dos2unix on "hello.pl", with no change in the results.
As far as running strace, I hadn't think of that, and it's a very good suggestion too. Unfortunately, running it on the simple hello.pl program doesn't yield significant differences between the two. Most of the differences are memory locations, with the exception of a complaint about some invalid ioctl in /dev/urandom (but that happens with the strace on the version of hello in /var/www/html, which is the working one). Otherwise, they both indicate the same values for what was (supposedly) being output.
@ARGV=split//,"/:L";
map{print substr crypt($_,ord pop),2,3}qw"PerlyouC READPIPE provides"
| [reply] |
You might want to try invoking something other than perl from the #!, like
/bin/bash. If #! /bin/bash also does nothing, there's something wrong with your shell/os/something-other-than-perl. If you get a bunch of bash errors, that means bash did try to interpret it, so the problem is probably perl specific.
Also, erasing and re-writing the #! line will remove any of the line ending/other invisible character weirdness possibilities.
Did you copy the working script ( /var/www/html/hello.pl ) over the wierd one ( /var/www/bugs/hello.pl ) or did you write them separately? Make sure they're absolutely identical.
Last idea, this one is a TOTAL long shot. Is /var/www/bugs a different mount point with execution restrictions?
| [reply] |
| [reply] [d/l] |
Yes, it was one of the first things I did. I even have an alias for making any file executable (I'm more of a tcsh fan than bash, so I use the alias: alias cx chmod +x \!\*, and then cx <file>), but I went further and did a chmod 777 on both the original file backup and the test file hello.pl, and did a chown root.root on each. Still no success.
@ARGV=split//,"/:L";
map{print substr crypt($_,ord pop),2,3}qw"PerlyouC READPIPE provides"
| [reply] |
And just to make sure I wasn't omitting some important information, I ran the script command, and created the following blow-by-blow:
Script started on Sat 18 Feb 2006 11:37:23 PM EST
[root@localhost html]# pwd
/var/www/html
[root@localhost html]# ls -ltd .
drwxr-xr-x 3 root root 4096 Feb 18 23:15 .
[root@localhost html]# ls -lt ./hello.pl
-rwxr-xr-x 1 root root 39 Feb 18 23:14 ./hello.pl
[root@localhost html]# cat ./hello.pl
#!/usr/bin/perl -w
print "Hello!\n";
[root@localhost html]# ./hello.pl
Hello!
[root@localhost html]# perl ./hello.pl
Hello!
[root@localhost html]# cd bugs
[root@localhost bugs]# ls -ltd .
drwxrwxrwx 14 root root 4096 Feb 18 23:14 .
[root@localhost bugs]# ls -lt ./hello.pl
-rwxrwxrwx 1 root root 39 Feb 18 23:14 ./hello.pl
[root@localhost bugs]# cat ./hello.pl
#!/usr/bin/perl -w
print "Hello!\n";
[root@localhost bugs]# ./hello.pl
[root@localhost bugs]# which perl
/usr/bin/perl
[root@localhost bugs]# /usr/bin/perl ./hello.pl
Hello!
[root@localhost bugs]# exit
Script done on Sat 18 Feb 2006 11:38:53 PM EST
Note that it runs fine when I run it as root in /var/www/html, but then fails to print anything when, still as root, I run it in /var/www/html/bugs. What the heck am I missing???
@ARGV=split//,"/:L";
map{print substr crypt($_,ord pop),2,3}qw"PerlyouC READPIPE provides"
| [reply] [d/l] |
Others has mentioned the obvious pitfalls, but nobody has mentioned acl's. I've never used them, but it is a security enhancement which limits what different users can do in various directories. Is your Fedora a "security enhanced version"? See linux-acl Maybe there is a default settings directory in /etc, which may be set up to be very restrictive by default.
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
Just to echo some of the ideas and put some concrete behind them, I have had plenty of experience with scripts (shell, perl) not executing properly on a linux box due to the script originating on a windows platform.
perl -pi.bak -e 's/\r$//' scriptfile.pl
--chargrill
$/ = q#(\w)# ; sub sig { print scalar reverse join ' ', @_ }
+ sig
map { s$\$/\$/$\$2\$1$g && $_ } split( ' ', ",erckha rlPe erthnoa stJu
+" );
| [reply] [d/l] [select] |
Wow, so many good suggestions! And now I see my good friends chargrill and zentara have come to my aid as well ... thanks, guys!
First of all, to answer your questions, pileofrogs, I wrote a script to generate both hello.pl and do_df.pl, in each directory from a specified list. That way, I'm guaranteed the scripts have the exact same contents. I saved everything to a file using the script command, and here are the results:
Script started on Sun 19 Feb 2006 11:59:00 AM EST
[root@localhost ~]# cat sayhello
#!/usr/bin/perl -w
use strict;
use warnings;
use FileHandle;
use File::Basename;
my @dirs = qw(
/root
/root/subdir
/var
/var/www
/var/www/html
/var/www/html/bugs
);
my $iam = basename $0;
foreach my $dir (@dirs) {
trydir($dir);
}
sub tryfile {
my ($fname, $text) = @_;
my $fh = new FileHandle();
open($fh, ">", $fname) or die "$iam: can't write '$fname' ($!)\n"
+;
print $fh $text;
close $fh;
(chmod 0777, $fname) or die "$iam: can't chmod '$fname' ($!)\n";
print "Running '$fname' ...\n";
system($fname);
print "Running perl '$fname' ...\n";
system("perl $fname");
}
sub trydir {
my ($dir) = @_;
(chdir $dir) or die "$iam: can't change to '$dir' ($!)\n";
print "\e[102m[In directory '$dir']\e[m\n";
tryfile("./hello.pl", "#!/usr/bin/perl -w\nprint \"Hello!\n\";");
tryfile("./do_df.pl", "#!/bin/df");
}
[root@localhost ~]# ./sayhello
[In directory '/root']
Running './hello.pl' ...
Hello!
Running perl './hello.pl' ...
Hello!
Running './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573692 28666048 12% /
Running perl './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573692 28666048 12% /
[In directory '/root/subdir']
Running './hello.pl' ...
Hello!
Running perl './hello.pl' ...
Hello!
Running './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573692 28666048 12% /
Running perl './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573692 28666048 12% /
[In directory '/var']
Running './hello.pl' ...
Hello!
Running perl './hello.pl' ...
Hello!
Running './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573692 28666048 12% /
Running perl './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573692 28666048 12% /
[In directory '/var/www']
Running './hello.pl' ...
Running perl './hello.pl' ...
Hello!
Running './do_df.pl' ...
Running perl './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573696 28666044 12% /
[In directory '/var/www/html']
Running './hello.pl' ...
Running perl './hello.pl' ...
Hello!
Running './do_df.pl' ...
Running perl './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573696 28666044 12% /
[In directory '/var/www/html/bugs']
Running './hello.pl' ...
Running perl './hello.pl' ...
Hello!
Running './do_df.pl' ...
Running perl './do_df.pl' ...
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
33994464 3573700 28666040 12% /
[root@localhost ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
/dev/proc on /proc type proc (rw)
/dev/sys on /sys type sysfs (rw)
/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda3 on /boot type ext3 (rw)
/dev/shm on /dev/shm type tmpfs (rw)
/dev/sda2 on /dos type vfat (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid2318) on /misc type autofs (rw,fd=4,pgrp=2318,minproto=2,
+maxproto=4)
automount(pid2349) on /net type autofs (rw,fd=4,pgrp=2349,minproto=2,m
+axproto=4)
[root@localhost ~]# exit
Script done on Sun 19 Feb 2006 11:59:13 AM EST
As you can see, it's only a problem in certain directories; it works as expected in
/root
/root/subdir
/var
but fails in
/var/www
/var/www/html
/var/www/html/bugs
Furthermore it does NOT seem to be limited to perl, since, in the directories where perl fails to work, so does df.
chargrill, you brought up an excellent point; it's important to strip the dos \r character from scripts which were copied from a FAT/FAT32/NTFS system. I've been stung by that before, and it can be very hard to spot the problem. Clearly that's not the case here, though, since I'm creating the files directly under Linux.
zentara, your suggestion sounds promising, as I *did* select the "most secure" option during installation, which I believe was referring to the use of ACL's. I'm not very familiar with them, so I'll have to investigate further. I did include a mount in the script command above, and didn't see anything unusual. Also, at the suggestion of my manager, I used the LVM for the first time with this installation -- in the past I've always created the individual separate physical partitions. But that may not be relevant.
Much thanks again everyone for all the terrific ideas ...
Update: I should also point out that the strange behavior has changed a little; I see from what I wrote previously that it used to work in /var/www/html; this is not longer the case, as it now only works in /var, but not anything subordinate to that.
Update 2: The problem is solved! I showed it to my manager this morning, and he immediately knew what it was -- SELinux was imposing security restrictions on the file, depending on where it was being run from. So zentara, you win the prize for guessing where the problem was. All that was needed was to disable SELinux with system-config-security-level.
@ARGV=split//,"/:L";
map{print substr crypt($_,ord pop),2,3}qw"PerlyouC READPIPE provides"
| [reply] [d/l] [select] |
This is probably going to sound equally /(simple|silly)/, is /usr/bin part of {insert username here}'s $PATH variable?
Update: Nevermind, I answered my own question. Yes it is because otherwise which perl would not have returned with a valid path.
| [reply] |