Please note that VisualCron support is not actively monitoring this community forum. Please use our contact page for contacting the VisualCron support directly.


mnchitnis
2008-02-25T22:01:13Z
Hi,

I seem to run into an issue launching a perl script with arguments.

The command is the perl executable: 'C:\perl\bin\perl.exe'.

The arguments are the perl script itself in quotation marks as recommended (though various combinations have been tested) followed by the arguments to the perl script itself.
e.g.: Arguments: "Test.pl" -arg1 -arg2

Visual Cron records the task as completing successfully (however there is no output and no errors) However, as one of the first things the script does is create a logfile, the lack of said file suggests that the script has not been launched.

The script runs perfectly from the command-line.

Has anyone else encountered this?
Sponsor
Forum information
Support
2008-02-25T22:05:27Z
In VisualCron, the working directory is automatically set to the same directory as where the command is located - if you not specify anything else. Currently, perl.exe is looking for test.pl in c:\perl\bin\.

There are 2 options.

1. Specify the full path to test.pl in the argument

or

2. Set the working directory to the folder where test.pl resides
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
mnchitnis
2008-02-26T00:06:05Z
I have tried both options.

The quirky thing is that if it couldnt actually find the file, the job will fail. However, it returns as success with no output or error.

ErikC
2008-02-26T08:41:46Z
I have some perl scripts running as wel. Don't have any troubles with it.

Here is my setup:
The Command is the full path to the perl.exe and all the argument are in the Arguments field.
The working directory is the full path to the perl script file (script.pl). And I'm running it in a hidden window.
It is running under a different user (credentials setup).

I can create files and I have output in the result of Visualcron.

Uses Visualcron since 2006.
Support
2008-02-26T12:50:05Z
Yes, the Credential might be it. Perl may require access to some environment variable.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
mnchitnis
2008-02-28T19:50:04Z
I suspect credentials has something to do with it as well. I do access files on a network drive. Other similar perl scripts that I have run fine.

I have tried running it using both profile and network credentials only mode. I run the process in the background, run it both with hidden window checked and unchecked.

I do use the UNC name both in the working directory (however I have tried both UNC and drive labels) and in the argument passed (the perl file name). Tried it with and without quotes in the argument.

As I mentioned, I get no indication that the script file even gets launched, yet the command returns as success with no output.

Oddly enough, as mentioned before, when I run the command from the command line in the directory specified, the script runs perfectly.

Is there a difference in the way VisualCron launched a command (in terms of loading up environment) vs a command-line?

Support
2008-02-28T20:16:32Z
A Windows limitation is that logical network drives are not shared across users. VisualCron is running as the SYSTEM account. Even though you use a Credential there is no API that tells us what network drives where mapped or not and impersonating a user with a Credential does not automatically load any network drives.

Generally, network drives should be avoided as network drives can changed, deleted etc. Instead you should use UNC paths. A UNC path looks like this \\server\path\file. Even though a logical drive is removed this will always work. And the good news is also that once you use a Credential, you have access to UNC paths.

There are 3 options for you:

1. Change to UNC paths and keep Credential - recommended
2. Map the drives in the VisualCron drive mapping tool and remove the Credential after that as you don't need it then - not as stable as 1. as you are still dependant on network drives
3. Change the username of the VisualCron 4 service and remove Credential - not recommended as you may give the Service more access than you want + in the end you don't know who your tasks are really running as
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Scroll to Top