Is there a way run a compiled (with PAR) perl script with the RUNSCRIPT command without having the to compile the required .dll files with it or putting the needed files in the /windows/sys32 directory (the result is a core dump)? If not, can that ability be added to the new version of NC_Net?
Kyle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you should be able to do this by constructing a command line that launches pearl with the script name as a input argument. Using Absolute path names to the files.
put the command into a BAT file
Test the bat from a User whos Path is limited to make sure that the Absolute path names are working as expected.
If all worked then put it into the script folder of NC_NEt
check the startup.cfg is properly configured.
(if modifying the config restart NC_NEt)
then test the script via Check_nc_net
The runscript command was limited to the script folder and purges relative paths from the script name that use .. in order to reduce security risks.
Things like setworking directory were also restricted for the same purpose.
Command arguments are ignored by default (but can be enabled in the startup.cfg)
Some scripts do not properly run in the asyncronouse enviroment, thus there is a second runscript command for syncronouse that usually resolves this.
Hopefully this is clear,
Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tony,
Is there a way run a compiled (with PAR) perl script with the RUNSCRIPT command without having the to compile the required .dll files with it or putting the needed files in the /windows/sys32 directory (the result is a core dump)? If not, can that ability be added to the new version of NC_Net?
Kyle
Glad you asked,
you should be able to do this by constructing a command line that launches pearl with the script name as a input argument. Using Absolute path names to the files.
put the command into a BAT file
Test the bat from a User whos Path is limited to make sure that the Absolute path names are working as expected.
If all worked then put it into the script folder of NC_NEt
check the startup.cfg is properly configured.
(if modifying the config restart NC_NEt)
then test the script via Check_nc_net
The runscript command was limited to the script folder and purges relative paths from the script name that use .. in order to reduce security risks.
Things like setworking directory were also restricted for the same purpose.
Command arguments are ignored by default (but can be enabled in the startup.cfg)
Some scripts do not properly run in the asyncronouse enviroment, thus there is a second runscript command for syncronouse that usually resolves this.
Hopefully this is clear,
Tony