SUMMARY STEPS TO REPRODUCE 1. Open In Dolphin or KRunner some console program OBSERVED RESULT There is no console spawn. EXPECTED RESULT KDE will detect it is console application and if so, suggest to ran terminal. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I created such tools. It uses some hacks and needs further love, but I asks for direction/suggestions. One key missing is full VT support. Currently, it detects if app is console or graphical (X11/Wayland), shows some early start messages (linker problems, for example), etc. It uses libgreattao, which is my library, but I can port my solution to Qt. After detecting app type (or earlier), user could select to open terminal window. To perform detection, we start the apps itself, so I need to have good implementation of VT. Currently virtual terminal implementation is only in early stage. Some other bugs should been addressed. Link to topic: https://forum.kde.org/viewtopic.php?f=304&t=171864 Link to sourceforge project's page: https://sourceforge.net/projects/wxconsolespawner/ Link to YouTube movie (outdated); https://www.youtube.com/watch?v=Ed6oAI3RsyE&t=10s
Can you attach a sample script that you think should be run in terminal when launched from Dolphin or KRunner? Note that it needs to begin with a shebang, e.g. `#!/bin/bash`
Created attachment 141791 [details] Simple Hello World script One think my tool do for checking if program is console was waiting for it tries to read data from stdin. It maybe not always worked, but as I said, my tool is not completed yet. I must decided, what to do in other cases. I can assume if we do not detect program opens window and exit that it is console program. I do not do this, because program could open window and exit very quickly after opening an window. But maybe this assumption is bad. If program exits fast (too fast, so user even cannot read message from window), should we show user console with the debug messages? I must think.
Is the script marked as executable? It gets launched as expected when I mark it as executable.
Yes. It is marked as executable. But, what means it gets launched as excepted? Many years ago, Novell support similar solution on SUSE, but remove it. My solution is in some way better, because it additionally checks program is not GUI. Do you compile my solution, run my script in terminal or use other way to launch the script. My solution detect if app is console or GUI program.
checks program is not GUI Should be: checks program is GUI, because we read list of opened unix sockets (it open Wayland socket) and checks loaded libraries by program (Xlib/Xcb). In case, program looks like an console, but any of above are pass, we treats is as GUI program.
Am I understanding that you would like for the system to open the script in a terminal window, rather than just silently executing the contents?
Right. System should detect it is a console program/script and spawn terminal. Many programs for Linux are written in assumption user ran it in terminal, but why user should worry about that? Many years ago, I created similar tool, but it needs to recompile program to link it against special library, which check program is running in terminal and (if not), spawn terminal window. But I thought: What about old applications? And this makes me thinking about current solution.
OKay, so here's the thing: we already have this ability: create a .desktop file that executes the script, and enable the "open in terminal" option, and then launch the .desktop file rather than the script However I can understand that this would be fairly cumbersome, since it means you have two files to keep track of and distribute, rather than one. I can see a few potential options for how we could improve this situation: 1. Always ask the user whether they want the script executed silently, or run in an interactive terminal. This would be helpful, but maybe annoying too. 2. Always open script files in an interactive terminal by default. This would have the potential to break existing scrips files written with the expectation of launching silently, though. 3. Add support for a developer-specified piece of metadata added as a comment into the script file that would signal to the system that the script file wants to be launched in an interactive terminal. However this pretty much duplicates the existing functionality of the .desktop file approach I listed above, and would be most effective if standardized as a FreeDesktop.org standard, which I imagine would be rejected for precisely that reason. I don't think there any way for the system to parse the script file and guess whether it should be opened in an interactive terminal or executed silently. That's always going to be super fragile, and the developer of the script is in the best position to make this kind of determination. Moving to KIO for further discussion.
Idea 3) But what about binary files? My solution work with binary files too. And there no analyze of content of file. There is only analyze of program behavior. We create pty (pseudoterminal), but do not spawn terminal window. In next step, we start the program. We now listen for request to read data from stdin. If program does, we assume it is console program. If it does, we spawn a terminal with server program attached. This server is some kind of proxy, which would redirect all signals from real terminal window to pty created in first step, show output of program, send input from real terminal to input of created pty, etc. As I said in forum post, the server is currently very simple and there is a lot of think to made better (for example reporting terminal size, etc.). It all is designed to work with program, which are not created to work with this tool. Of course, there is many problems currently: 1) Server program is very simple 2) It do not always detects program type correctly a) As I said, we assume program can write to console if it is graphical (I describe current solution further) b) There could exist bash script, which use zenity/kdialog (it is graphical, but zenity/kdialog is running in separate processes, so we do not detect this; maybe use cgroups?) c) Program could end very fast - before we properly detect it's type (as I said, we read info about loaded libraries and opened files) About a and c - if program end working and we do not recognize it as gui, we could show message telling user that program exits and user should click on show console button. About b - maybe cgroups allows us to detect if program run another process and introspect new child, so we detect it loads Xlib/Xcb or connect to wayland server? But.. this brings new problems, probably.
About 3) See cli2gui - my other project. It is a library, which on load into memory process check we had running in console. If not, we spawn terminal window and use special server, such like tool I present. This is only for binary programs. And for shell script solution is rather simple - call tty, check return code/output and fork (spawn itself in terminal window with all parameters it was called), wait child to terminate.
If yu think you've implemented something that's better than what we already have, feel free to submit it to KIO in a merge request!
Thanks, but as I said, it is not ready yet. I only submit this ticket to gather ideas/suggestions. I am fan of Plasma5, so I will be happy if this solution was merged. So maybe I send MR even if my solution is not completed? Maybe some part of it was merged or somebody will suggest something or help. Thanks. If nobody has suggestions, topic could been closed. PS: I cannot found this topic in search part of this page. I look at it by link in my e-mails.