I am working on a Tcl project where a certain procedure will run continuously. user can abort that procedure anytime using some Key-Combination. So basically, I need to trap the signal within Tcl code. So far, everything is done except one problem.
I am using Ctrl+Z i.e. SIGSUSP signal (SIGTSTP in case of Tcl) which technically does the job.
signal trap sigtstp onAbort
But, pressing Ctrl+Z immediately returns the Shell prompt, rest of the output from the program comes after that and when output comes to an end, no shell prompt returned (as it is already returned before). I need to press Enter again to get the prompt.
Following is the case I am refering to. You can see the prompt (polaris#ubuntu:~$) is returned in between output of the main program.
Also as output of pressing Ctrl+Z, it returned [40]+ Stopped, which is bit annoying. Can I avoid this ?
Can I avoid this whole problem using some other key-combination i.e. signal ? Or can I avoid this with Ctrl+Z also by tweking something ?
NOTE: I have tried using Ctrl+C. I got the exactly expected behavior with that. Unfortunately I can't use Ctrl+C as it is used for some other functionality.
Cz causes the shell to send the current foreground process a SIGSTOP(19). This signal cannot be caught or ignored and so your program will receive it and run the default handler. This is not killing the process as your question suggests you're trying to do. This only suspends it and you can bring it back into the foreground using fg on most modern shells.
Looks like you're out of luck. However, you might be able to rebind the keychord at the level of the shell. This is outside your program though and your end users don't have control over it. (Cf. https://superuser.com/questions/378018/how-can-i-do-ctrl-z-and-bg-in-one-keypress-to-make-process-continue-in-backgroun)
Also, if your program relies on user inputs for various actions (since you suggest that C-c does something else), perhaps you should make it a full fledged CUI application using curses or something?
Related
I do process.stdin.setRawMode(true) and I get data on every keypress. Then I do process.kill(process.pid, 'SIGSTOP') and put the process into the background. When I resume the process with linux $ fg I no longer get data on every keypress but only after a carriage return. Calling setRawMode(true) again has no effect. I think this must be a bug?
Probably not very many people want to use nodejs for its raw mode processing but I posted the issue on the nodejs github and they said a work around is to setRawMode(false) and then setRawMode(true) since it will not work just setting it to true again.
I would like to enter a password into the IDLE terminal in Windows without an echo.
Normally entering passwords is possible with python using the function getpass.getpass(), but in IDLE there comes up the following warning message:
GetPassWarning: Can not control echo on the terminal.
Warning: Password input may be echoed.
I found out, this is because IDLE replaces the sys.stdin with a different object:
if sys.stdin is not sys.__stdin__:
return fallback_getpass(prompt, stream)
However, I could not find a solution. Does anybody have an answer or another way to enter a password into the IDLE terminal without an echo?
As an IDLE maintainer with some familiarity with IDLE internals, I do not believe that it is possible to suppress character display but not otherwise change behavior in response to input('prompt') without major changes to IDLE code.
But even that would be insufficient for getpass.getpass since it calls one of unix_getpass, win_getpass, or default_getpass, and the first two use system_specific low-level functions that bypass stdin.
In terms of design intent: IDLE is, as its name says, a program development environment. Developed programs normally, and sometimes must be, executed by Python directly, without going through IDLE. Python normally runs attached to a terminal window. IDLE's Shell is based on a tkinter Text widget, which is a multiline editor, not a terminal. This is why one can enter, recall, and edit complete multiline statements rather than only a single line at a time.
In IDLE, there's no clear screen, and after reading the forums the best method is plainly to print a ton of "\n"s. However, after playing with IDLE, I made a discovery. When my game was waiting for an input after printing out instructions using print statements, instead of inputting any useful character, I entered 'control-z,' and IDLE began to remove the text that was display by the print statements, one by one.
My main question is, how do I manually in the code itself enter 'control-z', so I can utilize this functionality?
If you're confused by my story, here's some example code and try it yourself by hitting control-z.
print("Some Text")
print("More Text")
input("The Input (Hit Control - Z Here):")
^Z is a bit of a mess. The ascii control char ^D is usually interpreted as EOT, end of transmission, which on Unix and many other systems means end of file, close the application. Ascii ^Z is meant to be interpreted as SUB, substitute, whatever that means. Editors ofter use it as UNDO (meaning undo a ^X cut). Microsoft (and a few other old systems) at least sometimes interprets ^Z as end of file, with the same effect as ^D on *nix.
The Windows console closes a text app after ^Z . ^D is passes on to the app. IDLE, as a cross-platform app, closes on ^D. IDLE used to close on ^Z on Windows, but now, for me, it only erases the prompt. (I don't know if this alternative is intended.) I do not see the progressive deletion you report. What OS and what Python version are you running?
To answer your main question: you can't. input is usually used in assignment statements: string = input('prompt'). The way to imitate input statements is to directly assign 'user input': s = 'simulated user input'. However, this does not work for characters that get intercepted by the programs managing the input window and never sent to the python program.
IDLE's Shell generally imitates Python's interactive console. The latter (at least on Windows) makes everything, except the current input, read-only. Shell follows suite. Imitation is especially strict as regards executing user code. It is intended that user code tested in IDLE should run in Python without IDLE. It would be wrong for IDLE to clear the interactive shell in response to user code when Python cannot.
For editor and output windows, ^A (select all) followed by Backspace (delete), Delete, or ^X (cut) do clear the window.
Shell does, however, has more editing commands than many (most? all?) consoles and a menu system. These additions are allowed since they are interactive only and not accessible from user code. There have been various proposals and patches to enable clearing part or all of the shell window. https://bugs.python.org/issue6143 has some of the discussions and proposals.
I have this node.js server which, once spawned, expects some input from stdin. The inputs shouldn't be given straight away: I need to wait for some event before giving them (e.g. a connection from somebody). If I give the commands and close the shell, the server shuts itself down. I would like to give the input to the server and close my shell (effectively leaving the server running).
I know that to run a process in background I need to do for example node my_server.js &, but this prevents the input from the command line. I would like to give this input AND then put it in background. Modules like forever puts it in the background automatically without letting me giving the inputs through stdin.
Moreover putting the script in background kills anyways the server when closing the shell.
Any suggestion?
Thanks
I did a quick test just using gedit in Ubuntu 12.04, and it worked.
Start your node app like so "node app.js arg1 arg2" however you want to and hit enter to start the program. Then hit CTRL-z once your program has started running. This gives you the terminal back but stops the process in the background. To let it run in the background now, simply "bg" and hit enter. This will let the process keep running now but in the background.
You can confirm you are still up with the command "ps -ef | grep node" which should show your program still running.
However, this does still leave the node process attached to the terminal window so when you close the terminal window it will close the process. But I think this will get you most of what you seem to be looking for quick and easy.
You asked for any suggestion, so here it is: make your server able to start without user interaction. The simplest way to do it is probably to create a file containing exactly the input needed by the server, then starting it like this:
node my_server.js < my_input.txt &
If the input needed depends on what the server outputs (ouch), use expect(1). If possible, subvert the whole thing and use a module like commander to get your inputs from the command line instead of stdin.
I have a recurrent problem when using R with a Linux console. I sometimes suspend it with [Ctrl+Z], then put it to the background with bg, (execute some other commands), then put it to the foreground again with fg.
R resumes correctly with all the workspace intact, but when I type, the characters are invisible (just like when we type passwords).
I still can execute commands though, and I see the response. Moreover, when I type [enter], the prompt doesn't go to the next line, but does something like this: > > >.
Then I need to quit R using q(), in order that everything returns to normal. I didn't manage to find any reference to this problem on internet.
Would you have an idea? Thanks a lot for your help.
No direct answer but via
"Doctor, doctor, it hurts when I do this."
"Then just don't do this."
I would suggest that if you must have an R console open, place it inside screen --- or if you have it, byobu a fancier extensions, or even tmux.
Or even inside the One True Editor (TM) using ESS. For what it is worth, I always run emacs --daemon and then connect to the same R session either via emacsclient -nw on the terminal or under X11 via emacsclient -c (both of which I aliased to emt and emx). I also run byobu sessions for command-line work where I often use littler for command-line tasks and tests.
Unix is a multitasking system. There is no need to limit yourself to one prompt, especially if you suffer side-effects as a consequence.