Can I use AutoIT, running as a service on a server, using the send function - service

I'm trying to trigger Illustrator javascripts through the use of AutoIT and its send function. AutoIT is invoked via a Perl script and it works when I have Illustrator open and I run the Perl script from the command line. (The Perl script runs in a continuous loop, triggered by files arriving in a hot folder.) It runs on a server when I have an active connection. However, when I disconnect, keeping the session alive, the autoIT process does not work. (I'm guessing it is because I'm using the send function which requires an active window.)
This is running on a Windows 2003 server.
Is this possible to do or am I farting in the wind.
Thanks in advance.
CODE:
Run("C:\Program Files\Adobe\Adobe Illustrator CS6\Support Files\Contents\Windows\Illustrator.exe")
WinActivate("Adobe Illustrator CS6")
sleep (3000)
Send("!f")
Send("{DOWN 17}")
Send("{RIGHT 2}")
Send("{ENTER}")

Here is some documentation on the Send() function in AutoIT. Also if you look near the bottom of the page after the key examples you can see that it also recommends trying to use ControlSend: http://www.autoitscript.com/autoit3/docs/functions/Send.htm

Related

Pausing a perl script while SFTP transfers files

FYI, I'm a complete newbie with Perl, as in I can spell it and only a little more so I'm trying to learn. What I'm trying to accomplish is using SFTP to transfer files from a Windows machine to a Linux machine.
I've noticed that Perl issues the SFTP get command, but doesn't wait for the transfer to finish so when the Perl script tries to use a file it can't find it. I know there is the sleep command, but the number and size of files will vary on a weekly basis so using sleep(600) seems a little silly.
Is there a standard way to pause a Perl script until SFTP finishes transferring all necessary files?
TIA.
Using Net::SFTP might have solved this dilemma, but my workplace won't allow me to download and install stuff, especially in production. So rather than waiting on the typical bureaucracy I did some more digging around and discovered this:
By calling SFTP in batch mode using a separate file that contains the SFTP commands, the Perl script has to wait for SFTP to finish executing the commands in the separate "command" file. So by using the batch mode option, the Perl script is paused as long as it takes for SFTP to finish its work of file transfer.

Executing a commandline from JConsole

I've recently discovered the joy of going through JConsole.exe instead of J.exe to run various scripts. There's generally a noticeable performance gain.
However, sometimes I need to use wd winexec (calling ad-hoc programs for example) and in the console, 11!:0 (wd) support is not available.
Is there a way to send a command from JConsole.exe to the regular Windows command line interpreter? Or maybe a workaround?
You might try the task script. See the script itself for documentation.
J6: ~system/packages/misc/task.ijs',
J7: ~system/main/task.ijs
It contains utilities such as fork_jtask_, spawn_jtask_, shell_jtask_
You can load the script in both versions using: require 'task'

Start a remote Matlab process within Emacs matlab-mode?

I use Matlab remotely via ssh, and would like to execute regions of code from an m-file in Emacs without having to cut and paste. How do I configure Emacs to do this?
I tried to follow the solution offered here: I wrote a script that connects to the server and opens Matlab. The script works when I run it in a terminal. I edited matlab.el as explained on that page. Now, if I'm editing my m-file in Emacs and try to start Matlab, I get a message that it can't execute my remoteMatlab.sh file, and that M-shell exited abnormally with code 1.
Thanks in advance for any help.
You can achieve this running a shell from within emacs, starting up your ssh and matlab session in it, and renaming the shell buffer from *term* or whatever to *MATLAB*. You can then use matlab-mode on a script file and run the code.
This is not exactly what you asked for but may achieve the same thing. You can use function dbstop, which allows you to set debug break points through code.
http://www.mathworks.com/help/techdoc/ref/dbstop.html#inputarg_location

How can I communicate with an application that does not return to the command prompt?

I need to build a test bench by sending appropriate inputs to an application. However,
once I launch the application, it takes control and does not return to the command
prompt (unless an exit command is executed from the application). In that case
is there any technique by which I can send a command to that application from the Perl
script and interpret the output from that application?
My operating system is Windows.
If it's a GUI application, take a look at the Win32::GuiTest module. It sends events to GUI applications - simulating user input.
For a command line application, I would normally recommend the Expect module. Unfortunately, Expect doesn't work under Windows.
If there is anyway to write or redirect the application output to a file, you can always open that file to process/interpret the output. If you are talking about a command-line application, it should be easy to redirect the terminal output to a file using the '>' and '>>' characters. It may not be as easy with a GUI app, though.

How can I pause Perl processing without hard-coding the duration?

I have a Perl script that contains this code snippet, which calls the system shell to get some files by SFTP and unzip them with WinZip:
# Run script to get files from remote server
system "exec_SFTP.vbs";
# Unzip any files that were retrieved
foreach $zipFile (<*.zip>) {
system "wzunzip $zipFile";
}
Even if some files are retrieved, they are never unzipped, because by the time the files are retrieved and the SFTP connection is closed, the Perl script has already completed the unzip step, with the result that it doesn't find anything to unzip.
My short-term fix is to insert
sleep(60);
before the unzip step, but that assumes that the SFTP connection will finish within 60 seconds, which may sometimes be a gross over-estimate, and other times an under-estimate.
Is there a more sound way to cause Perl to pause until the SFTP connection is closed before proceeding with the unzip step?
Edit: Responders have questioned (and reasonably so) the use of a VB script rather than having Perl do the file transfer. It has to do with security -- the VB script is maintained by others and is authorized to do the SFTP.
Check the code in your *.vbs file. The system function waits for the child process to finish before execution continues. It appears that your *.vbs file is forking a background task to do the FTP and returning immediately.
In a perfect world your script would be rewritten to use Net::SFTP::Foreign and Archive::Extract..
An ugly quick-hackish kind of way might be to create a touch-file before your first system call, alter your sftp-fetching script to delete the file once it is done and have a while like so
while(-e 'touch.file') {
sleep 5;
}
# foreach [...]
Of course, you would need to take care if your .vbs fails and leaves the touchfile undeleted and many other bad side effects. This would be for a quick solution (if none of the other suggestions work) until you get the time to rewrite without system() calls.
You need a way for Perl to wait until the SFTP transfer is done, but as your script is currently written, Perl has no way of knowing this. (It looks like you're combining at least two scripting languages and a (GUI?) SFTP client; this can work, but it's not exactly reliable or robust. Why use VBscript to start the SFTP transfer?)
I can think of four options:
Your Perl script could do the SFTP transfer itself, using something like CPAN's Net::SFTP module, rather than spawning an external job whose status it cannot track.
Your Perl script could spawn a command-line SFTP utility (like PSFTP) that doesn't return until the transfer is done.
Or change exec_SFTP.vbs script to not return until the transfer is done.
If you're currently using a graphical SFTP client and can't switch for whatever reason, I'd recommend using a scripting language like AutoIt instead of Perl. AutoIt has features to wait for windows to change state and so on, so it could more easily monitor for an activity's completion.
Options 1 or 2 would be the most robust and reliable.
The best I can suggest is modifying exec_SFTP.vbs to exit only after the file transfer is complete. system waits for the program it called to complete, so that should solve your problem:
system LIST
system PROGRAM LIST
Does exactly the same thing as "exec LIST", except
that a fork is done first, and the parent process
waits for the child process to complete.
If you can't modify the vbs script to stay alive until it terminates, you may be able to track subprocess creation. If you get subprocess ids, you can monitor them thereby know when the vbs' various offspring terminate.
Win32::Process::Info lets you get a subprocess ids from a running process.
Maybe this is a dumb question, but why not just use the Net::SFTP and Archive::Extract Perl modules to download and unzip the files?
system will not return until the shell it's running the command in has returned; this may be wrong for launching graphical programs and file associations.
See if any of the following help?
system('cscript exec_SFTP.vbs');
use Win32::Process;
use Win32;
Win32::Process::Create(my $proc, 'wscript.exe',
'wscript exec_SFTP.vbs', 0, NORMAL_PRIORITY_CLASS, '.');
$proc->Wait(INFINITE);
Have a look at IPC::Open3
IPC::Open3 - open a process for reading, writing, and error handling using open3()