I know that one can close stdin when executing a command from a Linux CLI using logic such as:
0<&- <command>
This simulates/emulates running an application unattended, or within a CI/CD system such as Jenkins/Gitlab that has stdin closed.
Why do I care? Because we have an application that has a "Press any key to continue..." prompt.
When run under Jenkins/Gitlab or anything that doesn't have stdin open, it just moves on..... when run on Linux.
How would I do this, and is this possible to do this from the Windows CMD Window CLI?
I've tried 0<&- and that results in the message
0<& was unexpected at this time.
Google search gives many hits for stdin but all the documentation is on redirection. I haven't found anything for windows for closing.
You can try
command <nul
which basically means "take any input from the NUL device (as an infinite source of "CRLF"'s). This works as long as command takes its input from STDIN (like the pause command) and doesn't flush the input buffer (like the choice command)
If you need textual input (like the set /p command), you need another approach:
echo inputtext|command
Related
I've been learning batch scripting so I came across pipes and I/O redirection.
If this works:
tasklist | find "winword"
Why does this not:
cd | explorer
I expect this command to open explorer at current working directory as cd without any parameters outputs current directory and:
explorer %directory%
opens explorer at %directory%.
Is there something I am doing wrong here?
Open a Command Prompt window, type find "blah" and press Enter; you'll see it awaits user/keyboard/console input, which STDIN points to (press Ctrl+Z and Enter to end the prompt). Then type echo blah and press Enter; you'll notice the text blah is printed, so there is display/console output; this is pointed to by STDOUT. A pipe | takes the data at STDOUT from the left-side command and redirects it into STDIN for the right-side command.
Now type explorer into the Command Prompt window; of course an Explorer Window pops up, but what happens in the Command Prompt? right, nothing, it does not await any input at STDIN. So you can pipe to it but it will not care as it does not read at STDIN. In fact, GUI applications do generally not use STDIN and STDOUT, because these things are intended for command line applications.
Yet another example: in a Command Prompt window, type echo C:\Windows; quite obvious what will happen; then type echo C:\Windows| dir; what happens? dir returns the contents of the current directory but not of C:\Windows. Why? well, let's type dir first and see what happens: yes, dir shows the contents of the current directory, and it does not await console input; so at the right side of the pipe it receives data at STDIN but it simply doesn't care. You can try using dir "C:\some\other\folder", without and with the pipe, the output is just the same, STDIN is ignored here.
The echo/dir example also demonstrates the difference between console input (STDIN) and command line arguments or parameters: the path in the command line dir "C:\some\other\folder" is such an argument, and you cannot replace it by data from STDIN. To understand why, you need to distinguish between parse time (when the command is read and parsed by the interpreter) and run time (when the command is actually executed): arguments already have to be present at parse time, whilst STDIN is only relevant during run time, which is later. So we can say they just never meet.
This also reflects the situation with your attempt cd | explorer: the latter accepts command line arguments (which anyway need to be available before execution, so at parse time), but it doesn't care about STDIN. Also the STDOUT data from cd isn't available before execution (but only during run time), so it would arrive too late anyway...
I was writing a self-referencing Windows 10 (home ed.) batch script to locate a string in a large number of log files, create a results file and, when finished, open the log file in notepad++. This process sometimes takes a few minutes hence the self-referencing part which allows me to return control to the original command window until the log file is opened (and takes focus).
However, when the second command window, started with the "start" command and the "/b" switch, includes at least one "echo" command it won't exit cleanly and requires me to press the Enter key to fully exit that "nested" command window.
I've distilled the code down to nine lines so you can hopefully see what I mean. To see it in action, save the following as "test.bat" and run it from a command prompt:
#echo off
if "%1" EQU "" call :noArgs & goto :done
echo There was at least one argument.
:done
exit /b
:noArgs
echo There were no arguments.
start "" /b cmd /c test.bat arg1
goto :eof
It will print "There were no arguments." below the prompt followed by "There was at least one argument." at the prompt and then hang, waiting for the Enter key before returning control back to the prompt.
If you remove the line:
echo There was at least one argument.
the Enter key is no longer needed for the second command shell to exit. Similarly, if the output from the echo command is redirected to a file the issue goes away. This problem also occurs without echo commands but if output is generated from EG the type command so it seems it is due to there being some form of console output. This can be easily demonstrated by commenting out both the "echo" line as well as the first line "#echo off" - with commands now being echoed to the console it again hangs before exiting.
I could get around this issue by changing the "start" call to this:
start "" /min cmd /c test.bat arg1
however any output is no longer easily visible in the minimized window so it's a poor solution.
I'd love to know why the code I posted behaves the way it does, why it won't exit cleanly without requiring the Enter key to be pressed. The only clue I have is from the "remarks" column in the matrix on this page Close and exit batch files that states, "Make sure no text is displayed in the console window to make it close automatically at the end of the batch file". However that seems to refer only to Windows 9.x versions of command.com - not EG Windows 10 nor cmd.exe.
Thanks for any input/thoughts.
-s1m0n-
You're misinterpreting the output. If I've understood you rightly, it looks like this:
C:\working\test>test
There were no arguments.
C:\working\test>There was at least one argument.
That happened like this:
C:\working\test> <---- output from first shell
test <---- input
There were no arguments. <---- output from first shell
<---- output from first shell
C:\working\test> <---- output from first shell
There was at least one argument. <---- output from second shell
<---- cursor is here
The second shell is running asynchronously - that's what start does - so the first shell has already finished the batch job and printed the next prompt by the time the second shell gets around to printing its output.
At this point, the second shell has exited, and the first shell is waiting for you to enter a command. It doesn't know that the second shell has printed anything, so it has no reason to think that it needs to reprint the prompt. But if you enter a command, it will work.
If I create a process from a cmd prompt using the start command (opening a new cmd) is it possible to redirect the stdout and stderr from that process back to the calling cmd?
If you want the output of the STARTed process to appear in the parent command console, then simply use the START /B option.
If you want to process the output of your command, then you should use FOR /F ... in ('someCommand') DO ... instead.
OK. I have yet to find a straightforward answer to this question. I didn't want to bog down my question with what I thought unnecessary detail but seeing as I'm being criticized for the lack of this I'll expand a bit here.
I want to automate the updating of FWs on our production line, so I've a python app that gets the FWs from ftp and then uses the processors flash tool via python subprocess command to upload it to the board's flash. OK for all but one of the tools.
The one tool seems to have a problem when it's not running in its own terminal, so I provide a start to the subprocess command string which allows it to run OK in its own terminal. However, I need the output from this other terminal for logging reasons.
A possible solution was to log stdout and stderr to file using >> or wintee and then poll this file via a thread in my original app (perhaps a rather convoluted solution to the question). However the tool also has a separate problem where it doesn't like any std redirection, so this doesn't work for me.
I am trying to implement a terminal emulator in Java. It is supposed to be able to host both cmd.exe on Windows and bash on Unix-like systems (I would like to support at least Linux and Mac OS X). The problem I have is that both cmd.exe and bash repeat on their standard output whatever I send to their standard input.
For example, in bash, I type "ls", hit enter, at which point the terminal emulator sends the input line to bash's stdin and flushes the stream. The process then outputs the input line again "ls\n" and then the output of the ls command.
This is a problem, because other programs apart from bash and cmd.exe don't do that. If I run, inside either bash, or cmd.exe, the command "python -i", the python interactive shell does not repeat the input in the way bash and cmd.exe does. This means a workaround would have to know what process the actual output came from. I doubt that's what actual terminal emulators do.
Running "bash -i" doesn't change this behaviour. As far as I know, cmd.exe doesn't have distinct "interactive" and "noninteractive" modes.
EDIT: I am creating the host process using the ProcessBuilder class. I am reading the stdout and stderr and writing to the stdin of the process using a technique similar to the stream gobbler. I don't set any environment variables before I start the host process. The exact commands I use to start the processes are bash -i for bash and cmd for cmd.exe. I'll try to post minimal code example as soon as I manage to create one.
On Unix, run stty -echo to disable "local echo" (i.e. the shell repeating everything that you type). This is usually enabled so a user can edit what she types.
In your case, BASH must somehow allocate a pseudo TTY; otherwise, it would not echo every command. set +x would have a similar effect but then, you'd see + ls instead of ls in the output.
With cmd.exe the command #ECHO OFF should achieve the same effect.
Just execute those after the process has been created and it should work.
Is there a way, to send commands to another command-line program?
'Cause i have a special command-line program, but I can't send commands to it using syntax like program.exe something_to_do
the program executes something like this: ("here syntax" is where i want to input text to and also enter to start)
TheWhateverCommandLineProgram
Version 1.1
Give an option: "here syntax"
the program in code looks something like this:
echo TheWhateverCommandLineProgram
echo Version 1.1
Set opt=
set /p opt=Give an option:
if %opt%==command1 goto com1
if %opt%==command2 goto com2
...
Well, i guess so cause it wasnt me who made it (btw: off course its not called TheWhateverCommandLineProgram)
If you just want to give keyboard input to a commandline program you can just use echo and pipe it:
echo some text | program.exe
If you need more lines, then write them to a file and use input redirection:
echo one line > file
echo second line >> file
program.exe < file
I'm not 100% sure I understand what you're looking for. Here's two options:
You have two windows, each running a batch program. Let's say they are called myscript1.bat and myscript2.bat. You want to send a set of commands from myscript1.bat to be executed by myscript2.bat
You have a single batch script named myscript.bat, which executes a single program named program.exe. You want program.exe to execute some commands, or do some something.
Are either of these what you're looking for? Here's some idea:
Make myscript1.bat create a third file, mycommands.bat. Once myscript2.bat sees the file mycommands.bat exists, it will execute it and delete it. (Wow. Lame.)
Use Windows Scripting Host command (it's built in to Windows since Win2K) or Powershell (usually on most computers nowadays, if they have been updated). Either of these can send keystrokes to another program. Using those keystrokes, you can control the other program.
In what form does the other program take input? From the command prompt?
If the latter then I recommend Autohotkey: http://www.autohotkey.com/
You can use Autohotkey as a bridge and it will send the command as keypresses to the window of the other batch file.
You can ask for help in their forum. They are quite helpful.