I am writing a script that can execute a batch file, which needs to open a file in the same folder first. My current code is:
from subprocess import Popen
p = Popen("Mad8dl.bat <RUNTHISTO.txt>", cwd=r"C:\...\test")
stdout, stderr = p.communicate()
where the ... is just the path to the folder. However, everytime I run it I get the syntax error:
The syntax of the command is incorrect
Any help regarding the syntax would be greatly appreciated.
First, you should probably remove the < and > angle brackets from your code; just pass the filename, without any brackets, to your batch file. (Unless your filename really does contain < and > characters, in which case I really want to know how you managed it since those characters are forbidden in filenames in Windows).
Second, your code should look like:
from subprocess import Popen, PIPE
p = Popen(["Mad8dl.bat", "RUNTHISTOO.txt"], cwd=r"C:\...\test", stdout=PIPE, stderr=PIPE)
stdout, stderr = p.communicate()
Note the list containing the components of the call, rather than a single string. Also note that you need to specify stdout=PIPE and stderr=PIPE in your Popen() call if you want to use communicate() later on.
Related
I wrote a Perl script to convert from TEX format to JSON format.
Calling in the batch file:
perl -w C:\test\support.pl TestingSample.tex
This is working fine now.
Perl script having two types of input from another program (might be any platform/technology) one is file (*TEX) or else content (*TEX file) either this or that option.
How can I receive the full content as the input to the Perl script?
Now my Perl script is:
my $texfile = $ARGV[0]; my $texcnt = "";
readFileinString($texfile, \$texcnt);
I am trying to update:
perl -w C:/test/support.pl --input $texcnt" #Content is Input
I am receiving error message:
The command line is too long.
Could someone please advice?
First of all regarding the error you're getting:
Perl (or your shell) is complaining that your input argument is too long.
Parsing entire files as arguments to scripts is generally a bad idea anyway, for example quotation mark escaping etc. might not be handled and thus leave a wide open vulnarbility to your entire system!
So the solution to this is to modify your script so that it can take the file as an argument (if that isn't already the case) and if you really need to have an entire file's content parsed as an argument I'd really advise you to create a temporary file in /tmp/ (if on Linux) or in your %TEMP% directory on Windows and parse the file the content into the file and after that give your support.pl script the new temp file as an argument.
There is a line in a library that I can't take out:
put oResults format "x(80)" skip.
I have a program that is calling the library that doesn't have a default output so this line errors out.
I know I can just send output in my program somewhere but I want to fix it so you don't have to have a output. Seek function maybe?
EDIT: 10.2b
I only get an error in unix.
In a unix environment this line:
put oResults format "x(80)" skip.
errors out.
but if you put a:
if seek(output) <> ? then
put oResults format "x(80)" skip.
it doesn't error.
in a unix environment line:
put oResults format "x(80)" skip.
errors out.
but if you put a:
if seek(output) <> ? then
put oResults format "x(80)" skip.
it doesn't error.
You are running in batch mode. You should always be redirecting your output at the OS level when you run in batch mode. Something like this:
bpro -p test.p > errors.out 2>&1
Not redirecting output will pretty much always lead to the error that you are seeing.
If you are embedding the bpro, mbpro or _progres -b or whatever command in a script that needs to show that output or otherwise work with it you would typically use "cat" or "tail -f" on the output file.
I am trying to use the system() function to pipe the output of the gdalinfo (version 1.10 x64) utility directly to Matlab/Octave. The function consistently returns status=0, but does not return any output. For example:
[status output] = system('"C:\Program Files\GDAL\gdalinfo.exe" "E:\DATA\image.tif"')
will only return:
status =
0
output =
''
Any idea why no output is returned?
It appears there is something strange about `gdalinfo.exe'. Several people have reported difficulty piping the output of the program to a textfile - see for example http://osgeo-org.1560.x6.nabble.com/GDALINFO-cannot-pipe-to-text-file-td3747928.html
So the first test would be - can you do something like this:
"C:\Program Files\GDAL\gdalinfo.exe" "E:\DATA\image.tif" > myFile.txt
and see whether the file is created and has any content? If it doesn't, it may be that the program is using a different way to produce output (for example, using stderr instead of stdout). If it is possible to get data into a text file but not directly to matlab, I suppose a workaround would be to write to file, then read that file in separately:
tempFile = tempname; % handy built in function to create temporary file name
execCmd = '"C:\Program Files\GDAL\gdalinfo.exe ';
targetFile = '"E:\DATA\image.tif"';
status = system([execCmd targetFile ' > ' tempFile]);
output = textread( tempFile, '%s' );
system(['del ' tempFile);
Now the output variable will be a cell array with one cell per line in the input file.
This works on my Windows machine if I am in the Octave directory:
[status output] = system('ls bin')
I was having the same issue trying to pipe the output from within C#. It turns out that the ECW plugin breaks the capability (I don't know how). If this plugin is not crucial to you, go into the plugins directory and delete gdal_ECWJP2ECW.dll. You should be able to use '>' and other stuff to dump your output to a file.
I'm trying to solve the bilateral problem on Spotify's Tech Puzzles. http://www.spotify.com/us/jobs/tech/bilateral-projects/ I have something that is working on my computer that reads input from a file input.txt, and it outputs to ouput.txt. My problem is that I cannot figure out how to make my code work when I submit it where it must read from stdin. I have looked at several other posts and I don't see anything that makes sense to me. I see some people just use raw_input - but this produces a user prompt?? Not sure what to do. Here is the protion of my code that is suposed to read the input, and write the output. Any suggestions on how this might need changed? Also how would I test the code once it is changed to read from stdin? How can I put test data in stdin? The error i get back from spotify says Run Time Error - NameError.
import sys
# Read input
Input = []
for line in sys.stdin.readlines():
if len(line) <9:
teamCount = int(line)
if len(line) > 8:
subList = []
a = line[0:4]
b = line[5:9]
subList.append(a)
subList.append(b)
Input.append(subList)
##### algorithm here
#write output
print listLength
for empWin in win:
print empWin
You are actually doing ok.
for line in sys.stdin.readlines():
will read lines from stdin. It can however be shortened to:
for line in sys.stdin:
I don't use Windows, but to test your solution from a command line, you should run it like this:
python bilateral.py < input.txt > output.txt
If I run your code above like that, I see the error message
Traceback (most recent call last):
File "bilateral.py", line 20, in <module>
print listLength
NameError: name 'listLength' is not defined
which by accident (because I guess you didn't send in that) was the error the Spotify puzzle checker discovered. You have probably just misspelled a variable somewhere.
i have a command line executable program that accepts a configuration file as it's one argument for launch. the configuration file contains only 2 lines of code:
#ConfigFile.cfg
name=geoffrey
city=montreal
currently, the wrapper program that i'm building for this command line executable program writes the configuration file to disk and than sends that written file as the argument to launch the program on the command line.
> myProgram.exe configFile.cfg
is it possible to cast these configuration file entries as the configuration file, allowing me to bypass having to write the configuration file to disk but still allow the program to run as if it's reading from a configuration file?
perhaps something like the following:
> myProgram.exe configFile.cfg(name=geoffrey) configFile.cfg(city=montreal)
If you don't control the source for the program you're wrapping, and it doesn't already provide a facility to receive input in another way, you're going to find it difficult at best.
One possibility would be to intercept the file open and access calls used by the program though this is a horrible way to do it.
It would probably involve injecting your own runtime libraries containing (for C) fopen, fclose, fread and so on, between the program and the real libraries (such as using LD_LIBRARY_PATH or something similar), and that's assuming it's not statically linked. Not something for the faint of heart.
If you're worried about people being able to see your file, there's plenty of ways to avoid that, such as by creating it with rwx------ permissions in a similarly protected directory (assuming UNIX-like OS). That's probably safer than using command line arguments which any joker logged in could find out with a ps command.
If you just don't want the hassle of creating a file, I think you'll find the hassle of avoiding it is going to be so much more.
Depending on what you're really after, it wouldn't take much to put together a program that accepted arguments, wrote them to a temporary file, called the real program with that temporary file name, then deleted the file.
It would still be being written to disk, but that would no longer be the responsibility of your wrapper program. Something along the lines of (a bit rough, but you should get the idea):
#include <stdio.h>
#define PROG "myProgram"
int main (int argCount, char *argVal[]) {
char *tmpFSpec;
FILE *fHndl;
int i;
char *cmdBuff;
tmpFSpec = getTempFSpec(); // need to provide this.
cmdBuff = malloc (sizeof(PROG) + 1 + strlen (tmpFSpec) + 1);
if (cmdBuff == NULL) {
// handle error.
return 1;
}
fHndl = fopen (tmpFSpec, "w");
if (fHndl == NULL) {
// handle error.
free (cmdBuff);
return 1;
}
for (i = 1; i < argCount; i++)
fprintf (fHndl, "%s\n", argVal[i]);
sprintf (cmdBuff, "%s %s", PROG, tmpFSpec);
system (cmdBuff);
return 0;
}