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

Monks,

I've come across a strange phenomenon I'm hoping someone can shed some light on. It appears that some logical "or"s in my code behave differently if run from the command line, than if called from the scheduler or from a scheduler service I built.

The code works fine when run on the command line (this is 5.6.1 on Win2K). I've seen it in a couple of different places. The problem statements are part of a script I inherited which parses output from some fax software, reformats it then dumps out a text file. I've also seen it in another simpler script. A snippet should serve to illusatrate. Based on the varying circumstances in which I've observed this, the rest of the code is irrelevant. Anyway here goes: 

$logfile = "C:\\somepath\\somefile";
open (LOGFILE, "$logfile) || die "Can't open $logfile: $!";
do something with the file
close (LOGFILE);

[download]
When executed on the command line, it opens the logfile and continues to execute. When called via "at" or the simple scheduler I wrote, it opens the logfile AND dies. Similarly: 
$cmd = "G:\\somepath\\bin\\vfxolog -U vsifax";
$return = `$cmd` or die "Can't execute $cmd: $!";

[download]
alternate form fails as well: 
$cmd = "G:\\somepath\\bin\\vfxolog -U vsifax";
system ( $cmd ) || die "Can't execute $cmd: $!";

[download]
Same behavior as the filehandle operation above. From the command line this dumps the Vsi-Fax log file as directed, and continues processing. But, from "at" or my scheduler, it executes the command AND dies.

I could sort of understand how precedence might change based on context, but I can't figure out how an "or" becomes an "and". What am I missing?

Replies are listed 'Best First'.
Re: When is a logical or not logical
by BrowserUk (Patriarch) on May 10, 2003 at 03:27 UTC

    As far as the system "failures" are concerned, the problem is that you cannot use or die...; to test these calls for failure. For a better explanation than I can give see sauoq's explanation at Re: Re: vanishing system call. (Notice also that he was replying to my bad use of this 'meme':)

    As for the `backticks`, in essence, if the `cmd` returns no output, then the die will be triggered, but it doesn't mean that the cmd didn't execute, only that it didn't produce any output.

    As for the open case working from the command line but not under the auspices of AT, the problem is probably that when it runs under the scheduler, it runs under a different account to when you are running it from the command line and that account doesn't have permission to access the file? It's a guess, but it's a problem that has come up here before.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
[reply]
[d/l]
      I like the system explaination - makes sense. Thanks for the link.

      The backtick case may have been when I was still battling permissions problems. In that case I believe you are right on the mark, because without correct permissions, the command runs, but gives no output. I'll need to re-examine that now that I have those resolved.

      Unfortunately that still leaves the "open" case. This one is not permissions. The curious thing is that it does create a 0 byte file, then dies. I actually had two typos in my OP. Should have been: 

      open (LOGFILE, ">$logfile") or die "Can't open $logfile: $!";

      [download]
[reply]
[d/l]
        Ah - well - the correction to your typo presents an explatnation not addressed yet, for the apparently anamolos behaviour. The "greater-than" symbol in the OPEN statement will be treated as an output redirect by the command prompt, even if it is inside quotes. To avoid that, it needs to be preceded by the caret (^). So, to run the open statement at the command line the way you want, you will need to enter it as: 
           open (LOGFILE, "^>$logfile") or die "Can't open $logfile: $!";

        [download]
        (Notice the tiny little "^" symbol after the first quote mark)
[reply]
[d/l]
Re: When is a logical or not logical
by eduardo (Curate) on May 10, 2003 at 02:53 UTC
    I'm going to work under the assumption that you have a copy/paste error in the code you posted, but...
    open (LOGFILE, "$logfile) || die "Can't open $logfile: $!";

    [download]
    you desperately need a " to finish off the logfile name in the open statement...
[reply]
[d/l]
Re: When is a logical or not logical
by dws (Chancellor) on May 10, 2003 at 06:29 UTC
    When called via "at" or the simple scheduler I wrote, it opens the logfile AND dies.

    How do you know that the logfile gets opened, and what does $! hold at the point the script dies? It seems to me that you're inadvertantly withholding some clues.

[reply]
Re: When is a logical or not logical
by bobn (Chaplain) on May 10, 2003 at 03:09 UTC
    What happens if you actually change the 'or' to an 'and'?

    Unfortunately, your working on the Win platform. I've had serious hair loss trying to make stuff act right under 'at'.

    Bob Niederman, http://bob-n.com
[reply]

Back to Seekers of Perl Wisdom