If I call Python/Bash script from CMake using execute_process and this script uses input/output, it doesn't work - can't get any input or display output when script executes. Is there any way to do it? I need to continue building my project differently depending on user input.
Example CMakeLists.txt
execute_process(
COMMAND python ${MY_BUILD_DIR}/test_input.py
)
Example test_input.py
result = raw_input("Enter something + [ENTER]: ")
print(result)
Edit:
Actually, if this script is called as only COMMAND in execute_process (as in my example) then Python waits for input normally except that no output is printed ("Enter something + [ENTER]: "). If I use another COMMAND and similar Python (or Bash) script then raw_input will return output ("Enter something + [ENTER]: " + result) from first script (which is as described in execute_process) but subsequent raw_input calls would fail "EOFError: EOF when reading a line" as if input was read from file and EOF is received but I expected to read next line from standard input.
So I have two problems:
Can't display anything during execution of script through execute_process.
Can't read standard input normally in subsequent scripts.
Related
In Pick BASIC source code I see lines such as
CALL SOMEPROGRAM (PARAM1, PARAM2)
How can I invoke that same line from the TCL command prompt? I've tried variations of the following but nothing seems to work.
SOMEPROGRAM ('1','2')
The only way I've found is to write and compile a program with the single line command and then run that program.
If this was your routine:
SUBROUTINE REALPROG(A,B)
PRINT "A is ":A
PRINT "B is ":B
END
To call it from command line, you'd build this routine:
PROGRAM WRAPPERPROG
COMMAND.RECEIVED = SENTENCE()
VAR1 = FIELD(COMMAND.RECEIVED,' ',2)
VAR2 = FIELD(COMMAND.RECEIVED,' ',3)
CALL REALPROG(VAR1, VAR2)
END
Assuming you typed this from the TCL/ECL command line:
WRAPPERPROG DOG CAT
VAR1 would be DOG and VAR2 would be CAT
...and would call REALPROG with those parameters and you should see
A is DOG
B is CAT
Tcl can invoke your overall program file as a subprocess using exec, but it is up to your program to turn that into a call to the program and processing of correct arguments.
The Tcl code to run the program will probably look something like this:
exec {*}[auto_execok CALLERPROGRAM]
If you were passing the arguments 1 and 2 over, you'd do this:
exec {*}[auto_execok CALLERPROGRAM] 1 2
Again, that does not say how those values get from the command line into the Pick Basic subprogram. You'll need to consult the Pick documentation for how to do that. But I know (and have tested) that Tcl will definitely have correctly provided them…
In Pick BASIC CALL statements are used to call subroutines and they can't be directly executed from TCL. Subroutines are denoted by setting the first word on the first line of the program to SUBROUTINE.
You can execute "programs" from TCL. These don't include the SUBROUTINE at the top of the source code. In some Pick BASIC variants you may need to include PROGRAM but I think most don't require that (I know D3 doesn't). These programs can be run from TCL but they don't get the command line parameters passed in automatically like subroutines do. I think you can use SENTENCE() in pretty much any Pick BASIC variant to get the command line parameters.
Here's an example program that will print the command line arguments:
PRINT SENTENCE()
END
You could use this to create a program that will take the command line arguments and pass them into a subroutine to do something for you.
I was literally typing out some elaborate answer, but your question has been answered. You cant directly call a subroutine, you need to call a program that calls the subroutine. Also subroutines are a good way to separate code from the main program to reduce clutter, but they arent always necessary. Other methods you can use are functions, or GOSUBS/GOTOS. This is an example of a GOTO below..
VAR = 'HELLO'
GOTO 10:
10:
CRT VAR
from the TCL you will call the name of your program and all of this code will be executed without calling another program.
The output will be the string hello.
I wrote a utility 30+ years ago to address this. Other Basics (QB, VB, Dartmouth) have a single command line. You are either writing lines into a program or processing single line requests. Pick did not.
I created an MD item called PRINT. It then runs a program called BP PRINT that takes the whole TCLREAD line, writes it out to another program space called BP PPRINT, compiles it and then runs it.
Incredibly useful. Thus at TCL these commands would work:
PRINT ; X=1 ; Y=2 ; CALL SOMESUB(X,Y)
PRINT ; FOR I=1 TO 12 ; PRINT (I*28)"DMA" ; NEXT I
PRINT ; OPEN "CUST" THEN READV NAME FROM "1234", 1 THEN PRINT NAME
PRINT OCONV("12345678","MD2Z,$")
PRINT DATE()
Basically anything that can be programmed within a single line of code can be typed at TCL this way. Any IF or ELSE statements must be completed in the same one line. Great for testing.
Should be part of every Pick implementation out of the box.
Mark Johnson
I am trying to prompt the user of my .jl file to enter user entered multiple destinations.
Basically I need the user to give an input & an output. I know in java you would use a scanner, or accept arguments when it is compiled in the command line. I am fine with either option. From what I have found looking through the Julia Documentation I think I could accomplish the first way of assigning a variable to the readline function.
(String)in = (String)Readline(STDIN)
From my understanding the variable 'in' should now contain a String of the user's input. I am encountering an error, in that when I compile my .jl code, because my command prompt does not stop to read user input, and just finishes reading the .jl code.
The first item to note in the code in your question is:
(String)in = (String)Readline(STDIN)
Julia 1.0.0 now uses stdin instead of STDIN.
Next, the (String) typecasting is not something you need or want to do in Julia.
Thus your code could read (though we get an error):
julia> in = readline(stdin)
This is a test.
ERROR: cannot assign variable Base.in from module Main
So variable in is in conflict with a Julia Base.in variable. Just use a another variable name.
julia> response = readline(stdin)
This is a test.
"This is a test"
This code is now working, but it has no prompt. Your answer provides an example input function with a prompt which you defined like this:
julia> function input(prompt::AbstractString="")
print(prompt)
return chomp(readline())
end
input (generic function with 2 methods)
The chomp function removes a single trailing \n newline character from the input string. Docs here.
Example use of the function here:
julia> input_file = input("Please enter input file name: ")
Please enter input file name: Data.txt
"Data.txt"
julia> output_file = input("Please enter output file name: ")
Please enter output file name: Output.txt
"Output.txt"
Command Line Args Method
As the docs point out, to just print out the arguments given to a script, you can do something like this:
println("Arguments passed to ", PROGRAM_FILE, ":")
for arg in ARGS
println(arg)
end
Here is an example of above code running on the Windows command line:
c:\OS_Prompt>julia PrintArgs.jl Data.txt Output1.txt Output2.txt Output3.txt
Arguments passed to PrintArgs.jl:
Data.txt
Output1.txt
Output2.txt
Output3.txt
You can also print out the script file name as shown, PrintArgs.jl.
After searching & testing I found one solution and decided to reply to it here. I had to declare my own function to be able to get the program to accept user input.
function input(prompt::AbstractString="")
print(prompt)
return chomp(readline())
end
I am not sure what the chomp function does, but I know it works for what I was asking. I am still curious if you can do something in Julia similar to java and C String args[], in which you pass extra information while you are telling your command to run. Something like the following.
Julia testFile.jl goHere.txt lookHere.txt
I workin' with Torch7 and Lua programming languages. I need a command that redirects the output of my console to a file, instead of printing it into my shell.
For example, in Linux, when you type:
$ ls > dir.txt
The system will print the output of the command "ls" to the file dir.txt, instead of printing it to the default output console.
I need a similar command for Lua. Does anyone know it?
[EDIT] An user suggests to me that this operation is called piping. So, the question should be: "How to make piping in Lua?"
[EDIT2] I would use this # command to do:
$ torch 'my_program' # printed_output.txt
Have a look here -> http://www.lua.org/pil/21.1.html
io.write seems to be what you are looking for.
Lua has no default function to create a file from the console output.
If your applications logs its output -which you're probably trying to do-, it will only be possible to do this by modifying the Lua C++ source code.
If your internal system has access to the output of the console, you could do something similar to this (and set it on a timer, so it runs every 25ms or so):
dumpoutput = function()
local file = io.write([path to file dump here], "w+")
for i, line in ipairs ([console output function]) do
file:write("\n"..line);
end
end
Note that the console output function has to store the output of the console in a table.
To clear the console at the end, just do os.execute( "cls" ).
I have a script which interacts with user (prints some questions to stderr and gets input from stdin) and then prints some data to stdin. I want to put the output of the script to a variable in vimscript. It probably should look like this:
let a = system("./script")
The supposed behavior is that script runs, interacts with user, and after all a is assigned with its output to stdout. But instead a is assigned both with outputs to stdout and stderr, so user seed no prompts.
Could you help me fixing it?
Interactive commands are best avoided from within Vim; especially with GVIM (on Windows), a new console window pops up; you may not have a fully functional terminal, ...
Better query any needed arguments in Vimscript itself (with input(); or pass them on from a custom Vim :command), and just use the external script non-interactively, feeding it everything it needs.
What gets captured by system() (as well as :!) is controlled by the 'shellredir' option. Its usual value, >%s 2>&1 captures stdout as well as stderr. Your script needs to choose one (e.g. stdout) for its output, and the other for user interaction, and the Vimscript wrapper that invokes it must (temporarily) change the option.
:let save_shellredir = &shellredir
:set shellredir=>
:let a = system('./script') " The script should interact via stderr.
:let &shellredir = save_shellredir
Call the script within the other as,
. ./script.sh
I think this is what you meant.
I was originally trying to run an executable (tftpd32.exe) from Expect with the following command, but for some unknown reason it would hanged the entire script:
exec c:/tftpd32.351/tftpd32.exe
So, decided to call a batch file that will start the executable.
I tried to call the batch file with the following command, but get an error message stating windows cannot find the file.
exec c:/tftpd32.351/start_tftp.bat
I also tried the following, but it does not start the executable:
spwan cmd.exe /c c:/tftpd32.351/start_tftp.bat
The batch file contains this and it run ok when I double click on it:
start tftpd32.exe
Any help would be very much appreciated.
Thanks
The right way to run that program from Tcl is to do:
set tftpd "c:/tftpd32.351/tftpd32.exe"
exec {*}[auto_execok start] "" [file nativename $tftpd]
Note that you should always have that extra empty argument when using start (due to the weird way that start works; it has an optional string in quotes that specifies the window title to create, but it tends to misinterpret the first quoted string as that even if that leaves it with no mandatory arguments) and you need to use the native system name of the executable to run, hence the file nativename.
If you've got an older version of Tcl inside your expect program (8.4 or before) you'd do this instead:
set tftpd "c:/tftpd32.351/tftpd32.exe"
eval exec [auto_execok start] [list "" [file nativename $tftpd]]
The list command in that weird eval exec construction adds some necessary quoting that you'd have trouble generating otherwise. Use it exactly as above or you'll get very strange errors. (Or upgrade to something where you don't need nearly as much code gymnastics; the {*} syntax was added for a good reason!)