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.
Related
How do you go about debugging a non-responsive python/PyQt application in PyCharm?
I am an experienced programmer, but new to all thing python. I have been given a large application (36,000 lines), which works under Windows, to port to Linux.
Having made just a handful of changes for OS-specific stuff, when I run the application it comes up with its main window. But then after a few seconds it becomes dimmed, and when I close the window I am asked to confirm to end "the window is not responding".
(Aside: On a whim I decided to try running the app via sudo, and surprisingly it works fine. I have tried doing strace running as root versus non-root, but I'm fairly sure there is nothing obvious in the way of file accesses/permissions etc. that differs. This may be a clue, but just as likely to be a red-herring, e.g. if it's an "uninitialized variable".)
If I debug it inside PyCharm, at that point I expect to click the "Pause Program" button, so that I can get a trace back and begin to see where it is in the code, and start stepping or whatever. However, that button does nothing at this stage? Maybe it only "works" when on "a python instruction"?
If I force a core dump (from the keyboard) and examine with gdb, I can see that the stack frame shows it is way down inside libQtCore/libQtGui, in processEvents on a call to read.
So how do I begin to go about debugging why it is (presumably) busy doing something at this point, or at least not responding? Any tips would be welcome. I do hope this question will not fall foul of SO's "too general" policy, any tips to get someone going on debugging a "non-responsive" program would be welcome.
To answer my own question, since no responses seem to be forthcoming.
In this case, the problem turned out to lie in a file which is imported into other files, named pyperclip.py. That had code outside of any function, and in a path through the source executed under Linux but I think not under Windows, which included:
app = PyQt4.QtGui.QApplication([])
cb = PyQt4.QtGui.QApplication.clipboard()
Clearly some attempt to gain a clipboard object. For whatever reason, this appears to work when run as su, but when run as the logged on user it causes the whole application to "hang". Removing those two lines solved the unresponsiveness.
In terms of what I learnt from this for debugging unresponsive applications: you need to debug not from the entry point of the program, as I would have expected, but rather right from the start of each file, and actually step into each import line just in case it is executing some initial code. Horrible!
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?
I'm new to Linux.Yesterday I wrote some Python codes,now I'm using Linux to execute my codes,it may take a few hours. As my Linux is not native,it's a remote server,I use putty to connect to it.
Now ,I want to close putty and go to sleep.But I don't know how to find my process again and reenter it after I wake up and start putty.And also,I wrote some code to print progress rate，next time when I find the process,can I see the print info again?
Run screen, start your programm and close the connection. After logging in again, use screen -r to resume your session.
Alternatively nohup will do the trick.
screen is the best built-in tool that's always available for that, although it gets a bit weird around keyboard shortcuts, some of which sometimes don't work the way you want exactly.
I've found tmux to be much better in terms of usability.
Alternatively. take a look at mosh, which is trying to replace ssh. It's a mobile shell tool from MIT that supports intermittent connectivity, lots of praise there.
I am using node.js to write a command line interface that generates unit test files. I have been using inquirer to get user input, however there is one field in which the user will very likely want to copy-paste and/or edit, large multi-line chunks of JSON data. Therefore, my goal is to:
open vim # certain point in CLI -> allow input-> close vim -> write out to tmp file -> process the result.
The problem is that input to vim is also going to the parent stdin, and when the return key is hit, the program continues on top of vim (mayhem). I'm fairly certain that stdio/in/out/err are not set up properly, but i cant seem to find the exact solution anywhere. Every iteration of my manipulating the streams seems closer, but i know that there is a small missing link.
i have tried a lot of things along the lines of:
var vim = child_process.spawn('vim', [path], {stdin: 'pipe', stdout: 'pipe', stderr: 'pipe'});
var vim = child_process.spawn('vim', [path], {stdio: 'inherit'}); //{stdio: ['pipe','pipe','pipe']}
Finally, i have followed a lot of the stdio manipulation from this example, How do I open a terminal application from node.js?, but there still remains some small missing link that i need help with
Notes:
I am 99% certain that my async promises are in order.
it doesn't necessarily have to be vim, as I am checking the ENV for
an editor first
I liken this to git commit, where an editor pops up and allows input
before closing
in a small test program, i can get perfect functionality, but when
trying to do this over another process, it doesnt go well
tl;dr : i want to ignore the parent process while input goes only to vim (child_process), but i cannot keep them separated, and because of this, the program goes haywire
If there is anything i can clarify, please let me know.
Thanks!
I know this is old, but anyway 6 days ago they released a function with 2015.02.06 Version 0.12.0 (Stable) that makes this very easy.
var spawnSync=require("child_process").spawnSync;
spawnSync("vim",[__filename],{stdio:"inherit"});
It will of course block the event loop, but in such a situation you likely want to wait for the user. Otherwise, you may end up with node writing to stdout and reading stdin while you are editing, which is obviously very confusing, and is the issue you were running into.
If you really still need asynchronous stuff while you are editing, it's probably easier to require("child_process").fork so you don't confuse the stdin/stdout. I imagine you could do some fancy stuff to remove all the listeners and add them back later, but it's probably not worth the effort.
I'm trying to add some details to a terminal application that I'm creating with ncurses.
The application is something like a quiz with timeout... if the user wastes too much time, timeout happens and cleans the screen.
Now the problem: how can I show the text that the user had inserted before timeout and edit/reedit if he wants?
Example:
Q:Do you feel happy? (correct answer Yes, I feel happy)
A:Yes, I fe (TIMEOUT, clean the screen, question is printed again but no "Yes, I fe" is printed).
I don't know if there is any possibility to add this to the stdin buffer or line buffer...
Ideas...
Thanks a lot
You could do it like that:
disable blocking keyboard reads by calling nodelay(stdscr, TRUE);
in a loop, check if a key was pressed using getch() and checking if it returns a value>0
if yes, process the key as usual
else sleep a few microseconds(no busy waiting!) using usleep() and check for timeout; if the timeout happened, process it