Pete,
We aren't windows-greeking the call='xyz/getrulebase.cmd' call on the
installer.
Do we want to do that on this next release? The XYNTService double quotes the
calls, so I'm not worried about that.... but if it failed for him, why wouldn't
it fail for others?
_A
----- Original Message -----
From: Pete McNeil
To: Message Sniffer Community
Sent: Monday, October 06, 2008 8:26 AM
Subject: [sniffer] Re: Update Script - Path apparently doesn't tolerate
embadded blanks
Hello Andy,
Sunday, October 5, 2008, 11:25:37 PM, you wrote:
>
Hi Pete,
Found a bug (I think):
<update-script on-off='on' call='D:/Program Files/SNF/getRulebase.cmd'
guard-time='180'/>
With THIS configuration, the script apparently gets never launched.
What's particularly disturbing is, that I didn't find any place where the
service reports/logs any errors about the update process?
http://www.armresearch.com/support/articles/software/snfServer/config/node/network/update-script.jsp
When the update launcher detects that a new rulebase file is ready it passes
the contents of call= to the system() function. The system() function _SHOULD_
exist on every platform, but it's implementation can be different on every one.
More importantly for this question - the result code returned by system() is
implementation specific, so there is no way to know what that result code will
be (what it means) without actually testing every case. Worse than that an
apparently successful call to system() might only indicate that the OS supports
syste(), or that the command interpreter didn't crash or didn't have a problem
with the command string even though the command string didn't necessarily do
anything.
When testing a new update script you need to install it and see if SNFServer
can launch it successfully by testing the result of the script -- did it do
what it was supposed to do?
We are considering some features for the next minor upgrade to help test this
feature such as the ability to trigger it and a log entry that returns whatever
system() returned (that will have to be interpreted by the user according to
their platform's documentation for that call).
For now you can trigger this feature by changing the timestamp of your .snf
file. If the .snf file's timestamp is earlier than the timestamp of the file
available from our system then the update-script feature will fire.
>
After spending some time, trying to narrow down the problem but not
finding any diagnostic info, I eventually decided to eliminate spaces from the
path:
<update-script on-off='on' call='D:/Progra~1/SNF/getRulebase.cmd'
guard-time='180'/>
and now it DOES seem to work.
Everything in call= is passed to system() as a string. No additional parsing
takes place.
In theory that means if you can type the contents of call= at the command
line and get your desired result then SNFServer will be able to do the same.
A couple of things can get in the way of that --
* Does SNFServer have the correct permissions to do what you have put into
call= ?
* Does the system() function on your platform interpret this string correctly
?
On Windows systems spaces can be a problem whenever one program is calling
another. Wherever possible it is usually best to use tilde to eliminate spaces
in file or directory names -- otherwise the spaces are likely to be interpreted
as breaks between command line parameters.
Best,
_M
--
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[email protected]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
