Furple has asked for the wisdom of the Perl Monks concerning the following question:

So, I'm hoping that perl has an easy way to do this. Essentially I need to see if a file exists on a remote server. here's the context - I'm throwing an email at our servers, assuming the email makes it all the way through this will trigger a post which is caught and logged into a file on a remote server I have access to. Within the context of my script I need to 1) check to see if the file I'm looking for exists on that remote server and delete it if it does, 2) send the email (got that part covered), 3) check to make sure it's come back into existence. The real part I'm getting stuck on is determining if that file exists or not. Anyone have any thoughts for checking for the existence of a file on a remote server?

turns out using backticks and cating the file works out alright. my code looks like:
@lines = `ssh REMOTE_SERVER cat /tmp/somefile.log`; my $flag; $flag = 1 if scalar @lines > 1;

Replies are listed 'Best First'.
Re: check for a remote file
by afoken (Chancellor) on Nov 02, 2010 at 18:22 UTC

    Now imagine a GPRS link running at 9.600 bit/s and a 5 GByte file. The first line will run for days, fill your local memory and your swap, just to give you the information that the logfile existed when you started the cat command and had at least two lines.

    To fix the two-lines problem, first compare with 0, not 1. This will give you a true value if the file exists and is not empty.

    To really fix the problem, don't transfer the file at all. Use the remote shell:

    my $flag=`ssh REMOTE_SERVER [ -f /tmp/somefile.log ] && echo 1`; chomp $flag; # not really needed

    This will download at most two bytes, independant from the file size.

    What happens here?

    1. ssh opens a shell to REMOTE_SERVER, then passes all remaining arguments to the shell.
    2. [ ] is a shortcut for the test command, the -f argument tells test to check if the next argument is the name of an existing file, and to return either success or failure. test is completely silent, it does not generate any output.
    3. && tells the shell to execute the right-hand-side command (echo) only if the left-hand-side command (test) returned success.
    4. echo 1 writes the digit 1 and a newline character to STDOUT.
    5. The backticks (``) collect what is written to STDOUT, dropping what is written to STDERR.
    6. Depending on the existence of a file named /tmp/somefile.log, $flag contains either "" (false) or "1\n" (true).
    7. chomp strips that final "\n".

    Some notes:

    • Some really old systems may not have the [ shortcut for test, so you need to use test -f /tmp/somefile.log && echo 1 instead.
    • [, test and echo are both shell build-in commands (on most systems) and separate programs. If you don't use a fully qualified name for those commands, most shells prefer the build-in commands over the external ones. Most shells can be configured to behave in the opposite way, but that is rather unusual, because it slows shell scripts down except on historic or embedded hardware.
    • Many, but not all implementations of echo support the -n parameter to suppress the final newline, so chomp is no longer needed.
    • Some shells on newer systems support the [[ ]] notation to indicate that you really, absolutely want the build-in and not the standalone test command. This avoids a lot of work (fork, exec, wait) for the shell. If the shell supports it, better use that notation: [[ -f /tmp/somefile.log ]] && echo 1
    • On most modern systems, you can combine the two previous points: [[ -f /tmp/somefile.log ]] && echo -n 1
    • Don't forget to quote the remote filename if it contains special characters.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)