I want to resume script execution immediately after any key is pressed kind of like C's getch() but I can't find a way. I also need to know the input so I can either call the function or not.
I considered calling cmd.exe /c pause but that doesn't return the input and WScript.StdIn.Read(1) doesn't resume execution after pressing a key. Instead, you can type as much as you want and, when enter is pressed, it only reads the first character. Is this possible? Thank you!
Related
We are making a program write to a file on my computer and there is basically just one part that I can't figure out how it works.
Before the program opens the file the program allows me to press the Return key to go ahead to open the file and thus erasing the content. Or I can press ctrl+C to interrupt my program. I'm thankful for any kind of input here since I really can't seem to find anything about this specific function.
filename = ARGV.first
puts "We're going to erase #{filename}"
# This is the part I can't find out how it works.
puts "If you dont want that press ctrl-c (^C)."
puts "If you do want that press RETURN."
$stdin.gets
Ruby gets reads a line of text. When called on a file - it reads a line of this file. When called on $stdin as in your case, it reads a line from the standard input (a console).
If you press Enter, the program will read an empty line and continue execution. If you press Ctrl+C a signal is sent to the program and this signal make program to stop execution. You can press Ctrl+C in any moment of program execution and it will be stopped (unless the signal is handled in the program, but it's not the case here).
See also:
gets docs
question about Ctrl-C
!start seems the only way to avoid taskbar blinking on Windows?
I know we can use system() to retrieve the return value, but I want to avoid the blinking.
So Is there any method including certain workarounds to get the return value from !start?
psudocode
let g:return_value = !start /b program.exe
Small trick
:enew
:r! start /b program.exe
:let g:return_value=join(getline(1, '$'), "\n")
Info there : http://vim.wikia.com/wiki/Append_output_of_an_external_command
:!start starts external programs into the background. At best it could tell you that the program you expect to start cannot start. As usual, with external program execution, this is stored into v:shell_error. However it seems that the /b flag prevents it to be filled. That's odd.
Any way, you cannot obtain the exit code of your program this way. Indeed, this makes no sense in such a scenario.
If you really want to start the program in the background, you'll get more information with job_start() & co: you'll know whether it could be started, you'll obtain what it prints, and you'll eventually obtain its exit code.
Otherwise, I'm afraid you'll only have system() that waits for the external program to end.
I am making it so that it stops asking for input upon CTRL-C.
What I have currently is that a separate go-routine, upon receiving a CTRL-C, changes the value of a variable so it won't ask for another line. However, I can't seem to find a way around the current line.
i.e. I still have to press enter once, to get out of the current iteration of reading for \n.
Is there perhaps a way to push a "\n" into stdin for the reader.ReadString to read. Or a way to stop its execution altogether.
The only decent mechanism that Go gives you to proceed when either of two things happens is select, and select only selects on channel reads, so your only option is to change your signal-handler goroutine to write to a channel, and add another goroutine that handles stdin and passes lines of input to a channel, then select on the two channels.
However, that still leaves your question half-unanswered: your main program can stop waiting for input on a Ctrl-C, but the goroutine that's reading input will still be waiting for input. In some cases that might be okay... if you will never need stdin again, or if you will go right back to processing lines in the same exact way. But if you want to do something other than ReadString from that reader, you're stuck... literally. The only solution I see would be to write your own state machine around Read or ReadByte that is capable of changing its behavior in response to external conditions, but that can easily get horribly complicated.
Basically, this looks like a case where Go simplifies things compared to the underlying system (not exposing anything like EINTR, not allowing select on filehandles), but ends up providing less power to the programmer.
What command/keyword is used to check for keyboard input without stopping execution? I want to build a loop that will run continuously, and at every iteration of the loop, I want to check for keyboard input. If the user presses the right key, my program will act on it; if not, it will continue to run.
EDIT
I want it to work with out pressing the enter key. Like when a game runs it checks if the user presses the arrow key then acts on the key press or continues if nothing is pressed.
From what I could find and some hacking around, I managed to put together something that will immediately echo the keys you press when running in command line.
require 'io/console'
loop do
p STDIN.getch
end
But as the referenced answer mentions, you'll want to capture SIGTERMs so you don't get trapped in the program: Signal.trap("INT") { exit }
So the meat of your program and all of its processing lives in that main loop, and each go around of that loop it will grab a character from the STDIN.
You cannot do that with a simple method. The most common way to do that is to use the curses gem.
I have bash script I am running from powershell in windows that does a for loop. Every once in a while, one of the loop iteration hangs until I hit enter on the keyboard.
This doesn't happen all the time, in fact, it happens pretty rarely, but it still does.
The interesting thing is that my loop innards is basically time _command_ and so after I hit enter, it'll tell me how long the command took to run. The command actually takes way less time to execute than the loop iteration takes - because it's waiting for keyboard input for some odd reason.
It's pretty annoying to leave a script running overnight and come back in the morning to see that it didn't get very far.
Does someone knows WHY this happens and WHAT to do to get around it?
Thanks,
jbu
I have encountered the same problem several times. Now I guess I have found the reason!
If you ever press the mouse within the powershell, it might get stuck and need user to press "enter" to continue. So the get-around-way is to make sure that you didn't accidentally press your mouse within the shell window while you are already running some program...
Goto the powershell properties and unselect 'Quick Edit'/'Insert' check boxes. If these are selected, the console pauses output and resumes only when an Enter key is pressed ( You can identify this by monitoring the console title bar- it will switch from "Administrator:Windows PowerShell" to "Select Administrator:Windows Powershell"
Until you post the script, there's little we can do to help.
However, in general, one of your commands probably returns a null once in a while as input to stdin of another command which, upon seeing null looks to the terminal as stdin. Or something along those lines.