Version: unspecified (using KDE 4.3.5) OS: Linux Processes trying to read standard input wait forever waste system resources when started from the desktop manager. Reproducible: Didn't try Steps to Reproduce: 1. Tell plasma to run {cat}. 2. Tell plasma to show processes. Actual Results: 2. The process for cat is running (waiting forever for user input). The only way to make it quit is to kill it. Expected Results: 2. cat should fail immediately because stdin would be closed. Note: Microsoft Windows does not have this problem (almost). A GUI process has its input closed and a console process gets its console window to run from. This information is stored in executable meta-data. I suppose Linux executables do not have such meta-data, so we can choose either of the two behaviours to be the default. Any choice would be better than the current behaviour, which is unreasonable. The choice of closing standard input is simpler.
(In reply to comment #0) > Reproducible: Didn't try Reproducible: Always. My bad.
you cannot simply close stdin, as this is a fairly safe way to wreak havoc. you want to redirect it to /dev/null instead. and guess what? kdm does that, as the second thing, right after setting the umask. so the problem is somewhere in the actual desktop environment. i think that's because KRun uses KProcess' stardard i/o settings, which is forwarded stdout/stderr and stdin from a pipe. it should use setStandardInputFile("/dev/null") ("NUL" on windows) somewhere.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Workaround: tell KRunner to run it in terminal!
(In reply to Oswald Buddenhagen from comment #2) > i think that's because KRun uses KProcess' stardard i/o settings, which is > forwarded stdout/stderr and stdin from a pipe. it should use > setStandardInputFile("/dev/null") ("NUL" on windows) somewhere. We can just forward the standard input channel now.
Workaround: { kquitapp5 krunner; }
(In reply to Oswald Buddenhagen from comment #2) > i think that's because KRun uses KProcess' stardard i/o settings, which is > forwarded stdout/stderr and stdin from a pipe. it should use > setStandardInputFile("/dev/null") ("NUL" on windows) somewhere. We could also close the write channel; this is not the same as closing the standard input of the subprocess because it closes the input end of the input pipe. This is a normal action, to be expected from the calling process. This is not what the shell does — but the shell, unlike us, forwards its own standard input to the subprocess.
> because stdin would be closed It's not; if you run `cat` in a terminal window it also keeps stdin open forever. There isn't a bug here; just don't run `cat` in KRunner since it doesn't make any sense to do so.
(In reply to Nate Graham from comment #11) > > because stdin would be closed > It's not; if you run `cat` in a terminal window it also keeps stdin open > forever. > > There isn't a bug here; just don't run `cat` in KRunner since it doesn't > make any sense to do so. No, it does not ; when I run { cat; } in a terminal, its input stream stays open until I close it. But when { cat; } is run by KRunner, I cannot close it because I cannot access its input handle. While running { cat; } from KRunner does not make sense indeed, there are programs that present a graphical widget when their input stream is closed. These programs get confused by KRunner. I do not think we gain anything by allowing this behaviour.
>While running { cat; } from KRunner does not make sense indeed, there are programs that present a graphical widget when their input stream is closed. These programs get confused by KRunner. Can you give an example? From looking at the code, it seems that there is nothing this runner can do to get the desired behavior you described. In the KIO KProcessRunner one could close the read channel. Though, I am not sure about the implications of this.