I’m not sure if this is an issue or just how things work in KDE. But I am unable to run shell scripts properly by simply clicking them in Dolphin. Namely to get them opening in a new console… I think they run but in the background. In order to see what’s happening, I need to right-click in an empty space, go to Actions, select Open Terminal here, then do “./myscript.sh” there instead.
What I tried was to right-click a .sh file, go to Open With → Other… and check “Run in terminal” and “Remember application association for this type of file”, then selecting “bash” and clicking OK. Sadly, remembering application association does not include the running in a terminal part, so when I click the sh script it still runs in the background. How do I fix this?
IMHO your idea bout what is “properly” is incorrect. You are mixing up two different things.
When you “click” on a filename in Dolphin and that is the name of an executable, Dolphin will ask the Kernel to start a new process with that file. This is true whatever the nature of the executable: a binary created by compiling/linking a C or Fortan program or a script of any kind. Start Dolphin and travel to */usr/bin. *There are many executables there. Take an innocent one, scroll down to xclock, click on it. The program xclock will now start. No terminal emulation will be started first. And IMHO this is what most people (excepting you) would expect
In a desktop environment, you can have a list of associations to couple data files of a certain type to certain applications. This is not done by checking the contents of such data files, but by the convention of letting their file names end in certain character combinations. E.g. file names ending in* .jpeg* can be associated with the program /usr/bin/gwenview. For KDE and Dolphin this means that when you click on a file name some.jpeg, Dolphin will ask the Kernel to start a new process with the program /usr/bin/gwenview and with *some.jpg *as argument. This is the same one could let do a shell do by typing
/usr/bin/gwenview some.jpeg
Now I am not sure, but my guess is that Dolphin first does check if the file name “clicked” is executable and when yes, never reaches 2. above.
Even when it reaches 2. above, this would require an association between a file name ending (it seems that you prefer .sh for your case(s)) and a program. The program in your case should be a terminal emulator (you did not mention which one you prefer). There is something that that terminal emulation must be able to do: use the argument as if it was typed in preceded by a ./ combination in the emulator window. Neither *konsole, *nor xterm does this.
On 2012-12-05 15:46, hcvv wrote:
> Even when it reaches 2. above, this would require an association
> between a file name ending (it seems that you prefer -.sh- for your
> case(s)) and a program. The program in your case should be a terminal
> emulator (you did not mention which one you prefer). There is something
> that that terminal emulation must be able to do: use the argument as
> if it was typed in preceded by a -./- combination in the emulator
> window. Neither -konsole, -nor -xterm- does this.
You could launch “xterm -e command [arguments]” instead of directly
launching the script. There are more options in the manual.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
You mean by adding the -e in the manage application subwindow of the appropriate application in the list of applications associated with a pattern in the file assosiations in Configure desktop in KDE?
Could work. But it could equaly break other things I think this is a case of asking about the symptom instead of explaining the real question. Either you create a program that runs in the CLI interactively and then you run it from the CLI, or you create a GUI program (interractive by design), or you create a stand-alone program.
Just a thought: in KDE file associations, you can set an executable extension to open in a terminal. If you define a special extension under the same class as an executable and set it to open in a terminal. it might work. Or not.
hcvv: That clarifies a lot. I didn’t know that for executables it’s a different “regime” when clicking them. I was expecting I could eg: Associate .sh with bash so it would open in a new console when clicked. For compiled binaries I prefer that they work this way (no console, just the program starting up).
But yes… my wish was that clicking a sh file would launch it in a new bash instance rather than in the background. Since unlike binaries, I am interested in seeing the output of shell scripts usually. But if it’s not possible I don’t wish to hack into things and force the system beyond what it can do. I can live with manually opening a console and writing ./myscript.sh to run it. Though it would be nice if Dolphin added a setting whether to launch programs in a visible console or not.
I hope you understand that it is not only different, but that it should be different. That is when one wants the feature that Dolphin starts a program when clicking on it (but what else would one want?). A script (bash, sh, csk, ksh, python, ruby) together with it’s interpreter is an executable program like any other.
None of them needs a terminal to be run from. But all can be run from a terminal with a running shell.
And even when you associate a file name ending in .sh with the application bash (which is easily possible), that application would be run unattached from any terminal.
It is btw completely useless to do so. Not only because Dolphin will start the executable without looking to a pattern in it’s name, but also because the script starts with
#!/bin/bash
end it is for this that the Kernel will load /usr/bin/bash to interprete the script (thus bash it is there by implication).
Thus when you click with Dolphin, it will ask the Kernel to execute it. The Kernel will check the file end see in it’s first line (looking for “the magic number”) that /bin/bash should be loaded and started instead and that the script is to be offered as an argument to that process. Nowhere in this a terminal is needed, wanted or involved.
That pretty much sounds like it’s not possible then… which is ok. Still, when you right-click the file and choose “Open With → Other…” then check “Run in terminal”, it does what I intend it to. So it seems like there is a way to pull it off, if you could only assign left-clicking to do that automatically. But it’s probably a feature Dolphin won’t have or need and I can live with manually running scripts from bash when I need to see output.
I wonder if I can at least add a line to custom shell scripts to always make them open in a new terminal. Anyone know if that’s possible instead?
On 2012-12-05 17:46, hcvv wrote:
> You mean by adding the -e in the manage application subwindow of the
> appropriate application in the list of applications associated with a
> pattern in the file assosiations in Configure desktop in KDE?
I’m not familiar with doing this type of things in GUIs: me, I open a
terminal in the appropriate directory and then start up the script. But
I’m thinking that instead of associating a extension with bash, it could
be associated with xterm and a certain combination of options and
parameters. I don’t know how exactly to do it O:-)
Or maybe modify the shebang to something equivalent, if that is possible.
However, if dolphin can be convinced to remember that it should open a
terminal with scripts ending in a certain extension, that would be perfect.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
On 2012-12-05 23:06, MirceaKitsune wrote:
> I wonder if I can at least add a line to custom shell scripts to always
> make them open in a new terminal. Anyone know if that’s possible
> instead?
Play with the shebang.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
BTW @MirceaKitsune,
When you put your script in the bin directory in your home directory ~/bin, there is no need to add the ./ in front of the command nor to first change your working directory to the directory the script resides, because that directory in in your PATH environment variable. Should not be a suprise, that bin directory id of course spcecialy pre-created for you as user to put executables in.
First, uncheck “Is executable” in file permissions (assuming you are using Dolphin).
Then, in “Open with” dialogue, type “bash” and check “Run in terminal”. I suppose you’d want to check “Do not close when command exists” and “Remember application association for this kind of file”, too.
You’ll get your desired behavior but files won’t run from shell manually with “./script.sh” command anymore, you’d have to use “bash script.sh” or “sh script.sh”, a relatively minor trade off.
If you leave your scripts as executable they’d simply fire off in the background, with Dolphin there’s apparently nothing you can do about it for reasons explained earlier in this thread.
I think this is a case of asking about the symptom instead of explaining the real question. Either you create a program that runs in the CLI interactively and then you run it from the CLI, or you create a GUI program (interractive by design), or you create a stand-alone program.