Version: 3.5.1 (using KDE 3.5.1, Debian Package 4:3.5.1-2 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.12-1-k7 When a user has a shell script that is marked as executable and they click on it in Konqueror, it executes. However it does not open a console window, so if the script requires command line user interaction it simple dies and the user does not know why. What should happen is when a user clicks an executable file in Konqueror that from the mimetype information can be determined to be of a type that normally runs in a terminal window to open and run it in the user's preferred console as determined by their control center settings.
How does the MIME type say that it should open in a terminal window? Not all shell scripts are Terminal-based. You cannot generalise.
If that generalization is not acceptable then the solution is to allow it to execute and have the parent thread monitor the output and wait for it to read from stdin, and then if ether occurs to open a terminal and display the output that was produced or to allow the user to type the input. This is of course a lot more complicated than simply always opening a terminal for all scripts. Never the less simply killing the process (or worse, letting it go into an infinite loop) with no user feedback to indicate that it is running or was launched, or that there was a problem is not a solution.
Once the child process has started, you can't change it. I can't be reparented either. So there's no way to transfer it to a terminal after it has started without one. There's no solution to this problem that I can see.
Created attachment 15464 [details] Proof of concept This script launches the IO of the program specified on the command line in a konsole after it has started executing but only if it produces some output. A similar script could be used for input as the command `echo -n ""` will block on output to be available but not write anything to it.
Created attachment 15465 [details] Helper Script
If you can do that using terminals (not FIFOs), it's something to reconsider. It has to be a terminal because many programs may try isatty(3) to determine whether they are running in a terminal or if input has been redirected.
Sure that is not a problem, it's not that different then what I did in the script. Have an application that opens a /dev/pts/# entry launch the program using these as it's input and output. Then have two treads one which blocks on trying to write the other on trying to read if ether of them unblock, then spawn a terminal and execute the following in it: cat /dev/pts/# & cat >> /dev/pts/# where # is the number you used. Then that process will "take over" the /dev/pts/# and make it look as though this input and output came from one terminal when it came from the other. You can test this by opening 2 terminals and finding the tty number of each, then run the two cat commands on the other, and you get all the io for the other terminal. This of course is not useful as you cannot run anyting on the other terminal for this to work, and as soon as you type input the forground cat will take over the display and you won't see anymore output until you switch back to the other cat. However if you connected a process up to each of these (and wrote it in some language other than bash so you did not have to wait for a return for data to be sent) this could be a useful mechanism.
Sounds doable.
Closing old bugs