So what is the difference between your child process's environment and your shell process's environment? Are you running this script via your shell prompt, or as, say, a CGI script? If the latter, there are tons of different things we can look at, like your PATH, user/ownerships, permissions, etc. If it's something like this:
$ cat script.pl
system("rcp file host:/tmp");
$ rcp file host:/tmp
$ perl script.pl
$
(i.e. both *appeared* to work from this point of view, but in reality, the first rcp command succeeded in producing a file but the second did not), then we probably have a problem.
If your script does not look as simple as the one above, consider reducing it to its simplest components that still reproduce your problem, then give us as much detail about the differences in the way you're running each script and your environment. | [reply]
[d/l] |
hey, Fastolfe... the script isn't as simple as that, but it might as well be... the script itself is made to remotely log on to dozens of machines, read the permsissions of a dir. of files and change the ones that aren't set correctly... sometimes this means hundreds of files per machine... doing a remsh from the master machine for each file is time and resource heavy... copying a file/script to the machine and excuting it is much quicker and easier for the system... but rcp isn't working, hence my question... OS for all systems involved is HP-UX 10.20... if i simplify the script down to just enough to reproduce the problem, it looks like just what you wrote about... the rest is simply work on the permssions and logging... the script runs perfect except for this one problem... the script has the perl path in it and i run it direct from the command line... ultimately it will be run from crontab (where, i've tried, it still doesn't get rcp to work... sigh... any other way to copy a file remotely in perl?)... thanks for all the help... magnus
| [reply] |
$ cat script.pl
system("rcp file host:/tmp");
$ rcp file host:/tmp
$ perl script.pl
$
and the first manual rcp succeeded normally while the second one (via the Perl script) did not, something is seriously wrong with your environment.
If your code varies in ANY way from that simplistic example above, investigate EACH assumption you're making about each item, and be absolutely certain each is behaving as you expect it. If you're using variables in the Perl side of things instead of static text (like I am above), be 100% certain that those variables are set correctly. If you are modifying your environment in any way (your $ENV{PATH} for example), check assumptions there.
Finally, the whole problem itself that you are describing is very fishy! The fact that 'rsh' would create a file but fail to put any data in it tells me that it had a problem reading data from the original file, or writing anything to the destination file. If your script's Perl environment is unchanged (not changing uid's or gid's or something), perhaps the destination system's filesystem ran out of space? It's equally weird that rsh is not giving you any errors. Try running, say, 'perl -e "system('rcp file host:/tmp')"' in lieu of running a script at all. If that succeeds normally, then you clearly have something in your script that is messing things up. Is it prompting for a password? Should it? Does rcp have any debugging options or a 'verbose' setting? Anything out of the ordinary there?
If you've still exhausted all options, and have tried my example above and still get a normal file when running it by hand but get a zero-length file the other way, I am out of options. Perhaps it's some strange bug with Perl or rsh. Something certainly smells like you're not telling me everything, or you're assuming something that seems benign enough to you so as not to mention it wouldn't be causing any problems, when in fact it is. It's impossible for me to tell. | [reply]
[d/l]
[select] |