When is a logical or not logical

[rah]

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);

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: $!";

alternate form fails as well:

$cmd = "G:\\somepath\\bin\\vfxolog -U vsifax";
system ( $cmd ) || die "Can't execute $cmd: $!";

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?

[BrowserUk]

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

[rah]

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: $!";

[NetWallah]

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: $!";

(Notice the tiny little "^" symbol after the first quote mark)

[eduardo]

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: $!";

you desperately need a " to finish off the logfile name in the open statement...

[dws]

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.

[bobn]

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