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
Related
I want to make a some kind of alert to let me know when the charger has disconnected (the cable doesn't fit into the socket well).
I have this to detect the status of the charger:
cat /sys/class/power_supply/ADP1/online
it returns 1 when charging and 0 when on battery.
and this to request a pop-up window:
zenity --info --text="Charger unplugged!"
I figured some kind of if statement would do the job, having to run it infinitely every second or so.
Then I remembered my days of Arduino where you could program an interrupt, that could trigger the script to run, rather than having to run it all the time.
Not sure what the best way to achieve this is. Does anybody know?
Many thanks.
You could create a service, or you can do it in a more simple and primitive way: create a script that will create a fork, redirect it's own stdout and stderr to /dev/null and execute an infinite loop that will be constantly checking your /sys/class/power_supply/ADP1/online file. When the value is 0 it will redirect the stdout and stderr to the original, in order to show the prompt. To make this an autonomous script, you would have to execute it with crontab #reboot.
I think that in the CLI it should work, but I don't know if it would work in a Graphical Desktop Interface
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.
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 have an linux app that uses cups for printing, but I've noticed that if I print and then quit my app right away my printout never appears. So I assume that my app has to wait for it to actually come out of the printer before quitting, so does anyone know how to tell when it's finished printing??
I'm using libcups to print a postscript file that my app generates. So I use the command to print the file and it then returns back to my app. So my app thinks that the document is off to the printer queue when I guess it has not made it there yet. So rather than have all my users have to look on the screen for the printer icon in the system tray I would rather have a solution in code, so if they try and quit before it has really been sent off I can alert them to the fact. Also the file I generate is a temporary file so it would be nice to know when it is finished with so I can delete it.
As soon as your CUPS web interface (localhost:631) or some other thing to look at what CUPS sees shows you that CUPS received the job, you can quit the application.
How about using a print spool service like lpr & lpq?
You certainly do not need to wait till the paper is out of the printer. However, you need to wait until your temporary file is fully received by cupsd in its spooling aerea (usually /var/spool/cups/).
If you printed on the commandline (using one of the CUPS lp or lpr commands) you'd know the job is underway if the shell prompt returns (the command will even report the CUPS job ID for the job sent), and if the exit code ($?) is 0.
You do not indicate which part of libcups and which function call you are using to achieve what you want. If I'd have to do this, I'd use the IPP function cupsSendRequest and then cupsGetResponse to know the result.
Your app likely hadn't finished printing yet when you quit it. If you're using evince to print a PDF or other document, this is a known bug--there is no visual confirmation that the printing operation is underway. If the print job has been submitted, a printer icon will appear in your system tray until the actual printing has finished. You can click on the printer icon in the system tray and see what jobs are currently running and pending.