I am trying to start an IDL programme from the Windows command line.
Lets say I have the following programme:
PRO hello
print, "Hello, I am a IDL script!"
a=bytarr(100,200)
outname='g:\testimage.tif'
WRITE_TIFF, outname, a
END
I want to execute this programme using IDL -e .RUN from the command line as following:
C:\Users\lein_pa>idl -e ".RUN G:/05_Software/01_IDL/IDLWorkspace/Default/hello.pro"
IDL Version 8.2, Microsoft Windows (Win32 x86_64 m64). (c) 2012, Exelis Visual Information Solutions, Inc.
Installation number: xxxxx.
Licensed for use by: xxx
% Compiled module:HELLO.
C:\Users\lein_pa>
As you can see HELLO.pro will be compiled, but no message "Hello, I am a IDL script!" appears on the shell and also testimage.tif is not written to the disk. When I start this programme from the IDL IDE everything works fine.
Can please someone help me? What am I doing wrong?
You could keep the file with the same name, but change it to a batch-like file by commenting out the PRO hello and END since everything in your routine could just as easily be run from the command line.
Then to start everything, try:
C:\Users\lein_pa>idl -e G:/05_Software/01_IDL/IDLWorkspace/Default/hello.pro
On unix-based systems, this would start IDL and immediately run the batch file hello.pro. If you need the double quotes for a Windows based machine, then add those accordingly.
Keep in mind, if you make this routine more complicated but keep it as a batch file, then be careful with loops as you will need to use $ and & $ at the end of lines to include them in loops. I am quite certain that one could run actual programs/functions on startup, but it's just as easy to type in the function name after startup if it's necessary. Typically one wants to use a startup batch routine to set personal preferences/defaults that you wish to use or commonly use when in IDL.
Related
I have a Perl script on Win10 that uses the system() command to run a couple of different command line processes, including:
Start Windows Media Player with a specified .mp3 file.
my $cmd = "start call wmplayer.exe myRadoShow.mp3";
system($cmd);
Start another Perl program that does something else at the same time (specifically reads and broadcasts a set of timecodes and titles).
my $cmd2 = "secondScript.pl some_params";
system($cmd2);
All of this works correctly; the minor problem is that #1 above starts up a new command line window each time it executes the system($cmd) command. I have to later go back and close those windows.
If I don't use "start call" the Perl script doesn't continue to #2.
Is there a preferred way to execute #1 that doesn't leave these windows open?
I realize this question may be more about Windows commands than Perl.
Firstly, If youre using active perl versions, there is a wperl.exe you can call your script with instead of the default perl.exe. Not to sure if this will hide sub processes created by your script but you can give it a go.
If that doesnt work, then maybe you can use Win32::GUI:
use Win32::GUI;
my $hw = Win32::GUI::GetPerlWindow();
Win32::GUI::Hide($hw);
there are other modules that provide this functionality as well. Good luck!
I am trying to run the below perl code from Windows batch file but getting error The file name, directory name, or volume label syntax is incorrect.
The script ran fine in eclipse.My ultimate goal is to run this perl script periodically using windows task scheduler, hence running it from a batch file.
Is there any other ways with which we can achieve my goal of running perl script on windows periodically?
I want my script to be functional across platforms, coz I have plans to run it from a mac as well.
use strict;
use warnings;
use Data::Dumper;
use File::Find::Rule;
my $basedir="G:\/My_Workspaces";
my #exclude_dirs= qw(.foo);
#Fetching all the workspaces under base dir excluding the ones in #exclude_dirs
my #subdirs =
File::Find::Rule
->mindepth(1)
->maxdepth(1)
->not_name(#exclude_dirs)
->directory
->in($basedir);
#Formating list of workspaces by removing the full path
s{^\Q$basedir\E/}{} for #subdirs;
If that is exactly the contents of your file, then you're asking Windows' command interpreter to process Perl source code, which it can't do
If you really need to create a batch file that has your Perl code embedded in it, then take a look at the pl2bat utility, which will do exactly that
A command like
pl2bat myperl.pl
will create a file myperl.bat that will run on the Windows command line and has your Perl source code embedded inside it. But that file is non-portable because it uses Windows commands that aren't recognised on a Mac or Linux platform
Either something doesn't know how to execute your Perl script, or your Perl script is being interpreted by something other than perl.
This could due to a problem with your file associations (or a lack thereof). Determining the exact cause would require more information.
In any case, executing perl with your script as a parameter rather than executing the script directly should solve the problem.
In other words, execute
perl script.pl
instead of
script.pl
I'm trying to create a shell script via cygwin that will automatically build an executable and run it. It's a very simple format of
#!/bin/bash
gcc test.c -o hello
./hello.exe
When I enter the 2nd and 3rd lines separately, everything works normally. However, if I save those 3 lines into a .sh file, the resulting .exe built has some extra character added in that will always throw off the last line.
helloļ.exe
I can't even replicate the file name because no tool, including the character map/MS word/other ASCII tools online will give me any result. Some online tool gave me the ASCII result , but as far as I can tell that doesn't correspond to anything meaningful. How can I avoid this problem in my shell script?
Very likely you have Windows linefeeds in the .sh file. Make sure you have Unix linefeeds.
A small request: I read Stack Overflow's Perl questions every day, and answer/contribute where I can; today I need the community's help!
Perl setup: I'm running Active Perl 5.8.8 on Windows. The installation is on our department server's local drive, which is also shared to the network. All department users run Perl on their own PCs by pointing to this network-installed Perl. This has worked for years, and isn't causing a problem, but it's a piece of info needed to understand the problem.
The server in question is also our "cron" (Scheduled Task) server, handling a variety of automation tasks. Suddenly last week, system calls in Perl scripts (on the server) started failing (details below). At first, I suspected a corrupt Perl installation, but all of the client PCs can still run the same Perl scripts without any issues, leading me to think it's a server issue. I've rebooted the server twice, and the problem is persistent, thus I need help!
Here are some examples of the various way that system calls are failing, boiled down to Perl one-liners:
% perl -e "system('dir')"
That should print a "dir" listing, but instead it opens a sub-shell. If I type "exit", I can exit the sub-shell, and I'm back in the original shell (confirmed by examining the shell history using the UP arrow key).
% perl -e "print `dir`"
This actually hangs. Nothing happens at all. If I Ctrl-C to kill the process, I get the message "Terminating on signal SIGINT(2)" and the DOS prompt comes back. But, any future commands in the DOS prompt (even just hitting ENTER) cause the error "The process tried to write to a nonexistent pipe.". You have to exit the DOS prompt as it's effectively useless.
Last example:
% perl -e "system('Z:/Scripts/rebuild.pl')"
'ebuild.pl' is not recognized as an internal or external command,
operable program or batch file.
In this case, Perl switches the forward-slashes (/) to DOS/Windows back-slashes (), which it has done just fine for years. But, Perl is interpreting the "\r" at the beginning of the "rebuild.pl" filename as a carriage-return (I think) and looking for the remaining "ebuild.pl". Calls to other scriptnames whose characters can't be misinterpreted like that result in the above hangs (if you use backticks) of sub-shells being opened (for system() calls).
I'm not just puzzled by this - I'm desperate! Our department server's "cron" jobs are useless right now since we use a lot of system calls.
Again, I don't think this is a corrupt Perl install, since the network users can run fine. So, what could happen on an individual machine (not tied to the Perl install itself) that could cause Perl's system calls to fail like this?
Environment settings, as requested:
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\engmodem\Application Data
CDSROOT=Z:\Cadence\SPB_16.5
CDS_CONCEPT_NOSPLASH=TRUE
CDS_LIC_ONLY=1
CDS_SITE=Z:\Cadence\Sites\16.5
CHDL_LIB_INST_DIR=%CDSROOT%
CLIENTNAME=USENTUTTLJL3C
ClusterLog=C:\WINDOWS\Cluster\cluster.log
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=CORPUSAPP5
ComSpec=C:\WINDOWS\system32\cmd.exe
CONCEPT_INST_DIR=%CDSROOT%
FP_NO_HOST_CHECK=NO
HOMEDRIVE=H:
HOMEPATH=\
HOMESHARE=\\PF1\HOME
ICMHOME=Z:\Software\PTC\INTERC~1
INSTDIR=%CDSROOT%
LOGONSERVER=\\ENGMAHO5
LSF_BINDIR=Z:\Software\LSF\bin
LSF_ENVDIR=\\hwc151\LSF_6.2\etc
MESSAGE=BROADCAST
NUMBER_OF_PROCESSORS=2
OA_PLUGIN_PATH=%CDSROOT%\Share\oaPlugIns
OS=Windows_NT
Path=C:\Program Files\Legato\nsr\bin;Z:\oracle\ora92\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Windows Resource Kits\Tools\;Z:\Software\Perl\5.8.8\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\Program Files\Support Tools\;Z:\Software\LSF\bin;C:\Program Files\PHP\;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\EMC RepliStor;C:\GitStack\python;C:\GitStack\python\Scripts;C:\GitStack\git\cmd;Z:\Scripts;Z:\bin;Z:\Cadence\SPB_16.5\tools\bin;Z:\Cadence\SPB_16.5\tools\fet\bin;Z:\Cadence\SPB_16.5\tools\pcb\bin;Z:\Cadence\SPB_16.5\OpenAccess\bin\win32\opt
PATHEXT=.COM;.EXE;.BAT;.PL;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.VBS
PCB_LIBRARY=16
PERL5SHELL=cmd
PHPRC=C:\Program Files\PHP\
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 29 Stepping 1, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1d01
ProgramFiles=C:\Program Files
PROMPT=$P$G
PULLUP_DIFF_PAIRS=TRUE
SESSIONNAME=RDP-Tcp#1
SystemDrive=C:
SystemRoot=C:\WINDOWS
TZ=EST5EDT
VISUALSVN_SERVER=C:\Program Files\VisualSVN Server\
WF_RESOURCES=Z:\oracle\ora92\WF\RES\WFus.RES
windir=C:\WINDOWS
It turned out the reason of this weird behavior was incorrectly defined PERL5SHELL variable: cmd.exe (the shell interpreter in Windows) should be called with some parameters for proper processing - there parameters went missing after some updates. )
By the way, in The Doc it's said that Perl usually assumes the 'cmd.exe /x /c' line as a shell executable anyway if PERL5SHELL environment variable is not defined at all.
P.S. I really like this thread: it clearly shows the purpose of comments. )
I am trying to reverse engineer the build system of a commercial Windows based IDE, so I can use make to build my project.
A program is launched to perform a task, and I need to know what command line arguments are passed to this program when it is run. However the windows process viewer does not show the command line arguments.
Is there any way to see what command line arguments are being passed when the program is launched?
(Actually it just occurred to me that I should substitute a stub program to read the command line args. Still, I'd like to know if there's an easy way).
Sysinternals Process Explorer lets you do that.