I can not run any scripts from within dolphin or a desktop icon.
Only from a console.
What is the deal ?
This is getting old. 
I’m not sure if I understand you.
If I create a test script eg test.sh
#!/bin/bash
kdialog --msgbox "hello"
and make it executable
chmod +x test.sh
then click on my script (in my home directory), it executes without issue, displaying a dialogue box with ‘hello’ as expected. Perhaps you need to share your script with us.
On Sat, 31 May 2014 23:06:01 +0000, andy77586 wrote:
> I can not run any scripts from within dolphin or a desktop icon.
>
> Only from a console.
>
> What is the deal ?
>
> This is getting old.
Please describe what is happening and what, if any, error messages you
get.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
I found the problem.
#!/bin/bash has to be the first line in OpenSuse.
Was not the case in other distros as in Puppy and Mint.
Thanks guys. 
It works for me.
Here’s the shell script that I used:
echo "hello world"
Note that the first line is blank. Sigh – the first line is being stripped out. That’s not good, particularly in a code block.
If I do not set the “x” bit (executable permission), then Dolphin opens it in a text editor.
If I do set the “x” bit, Dolphin executes it, and I can see the output at the end of the file “.xsession-errors-:0” in my home directory.
So I was right in the other thread? lol!
If you did not put a shebang on your script then it is just another text file, it is just a an example of the wrong idea about the *.sh extension in general. 
Correct, there is no such thing as an “extension” in Unix/Linux. When you use a suffix like this, it is for your own brains and may be it is recognised by some applications (like the desktop). But in fact .sh are just the three last characters of the file name.
And yes, when you write a script, the first line should be a shebang. How could anyone (the system in the first place) know which interpreter to start to interprete the script? Is it ksh, bash, sh, zsh, perl, …?
As far as I know, there’s a defacto standard. If the first line is a comment, use “csh”. Otherwise use “sh”. This is implemented by shells, not by execv(). With the “#!” line, execv() handles it.
Sorry, you may be correct, but I do not understand what you try to explain. Can elaborate a bit (with examples when possible)?
My normal practice is to begin scripts with “#! interpreter”. But, if there is some reason to not do that, then a script that starts with:
# some comment here
is normally run by “csh”, even if you invoke this script while using “sh”.
And a script that begins with a blank line, or with
: some comment here
is normally run by “sh”, even if the script is invoked while using “csh”. I think the “:” is treated as an empty label.
Or, at least, this was historically true. I have not tested it recently.
On 2014-06-01 15:36, nrickert wrote:
> Or, at least, this was historically true. I have not tested it
> recently.
I have, in the past, created scripts without the shebang (didn’t know about it), and I think they were run by bash. Let me try…
cer@Telcontar:~/bin> cat scriptwthoutsheband
echo "Hello"
ps afxu | less
read
cer@Telcontar:~/bin>
and I get:
cer 6124 0.0 0.1 70060 11120 ? S 02:54 0:01 xterm
cer 6126 0.0 0.0 14636 3324 pts/26 Ss 02:54 0:00 \_ bash
cer 23354 0.0 0.0 14636 2456 pts/26 S+ 15:53 0:00 \_ bash
cer 23355 0.0 0.0 16456 1680 pts/26 R+ 15:53 0:00 \_ ps afxu
cer 23356 0.0 0.0 6952 1048 pts/26 S+ 15:53 0:00 \_ less
I believe that’s the entry, because of the “ps afxu” in there. It is using bash…
and it is not identified as a script:
cer@Telcontar:~/bin> file scriptwthoutsheband
scriptwthoutsheband: ASCII text
cer@Telcontar:~/bin>
So maybe it tries “sh”, which in openSUSE is always bash. I modified the script thus:
# comment
echo "Hello"
ps afxu | less
read
and it is still run by bash.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I remember writing a shell script that began with a comment as the first line, and getting syntax errors from “csh” even though I was running it from “sh”. That was on solaris. Adding a blank line at the top fixed that.
Perhaps linux has never done it that way, but solaris did (and probably still does).
Testing your script with “csh” (really “tcsh”) – if I insert a blank line at the top, it is run by “sh” (no syntax error on the “read”).
I can not believe that when you have a script that starts with
# some text
and then call
sh script
that it then will be interpreted by csh.
When you start the POSIX shell (sh) and give it script as argument, it will go and read script. In reading, it wll skip the line starting with a # and not even know what is after the #. Let alone that it then will take the spontanious action action of calling the C shell (csh) with the script a argument.
Sorry, atm no time no prove this with a test (i have guests), maybe later.
No, it won’t.
But if the script is on your path, or if you call it with
./script
then, at least on some systems, it will be run by “csh”.
When you call it directly (as a command) and it has no shebang, in principle the Kernel does not know what to do. So it will fall back to something (to try to please the caller). It could be that that is csh on some systems or for some users. I e.g. can imagine that the Kernel will fall back to the default shell (from /etc/passwd) of the caller. Or maybe fall back to the shell where you type the command because that shell is the parent process. Thus imho it will differ from user to user and/or from system to system what happens.
On 06/01/2014 06:56 AM, hcvv pecked at the keyboard and wrote:
> jetchisel;2646686 Wrote:
>> If you did not put a shebang on your script then it is just another text
>> file, it is just a an example of the wrong idea about the *.sh extension
>> in general. 
> Correct, there is no such thing as an “extension” in Unix/Linux. When
> you use a suffix like this, it is for your own brains and may be it is
> recognised by some applications (like the desktop). But in fact .sh are
> just the three last characters of the file name.
>
> And yes, when you write a script, the first line should be a shebang.
> How could anyone (the system in the first place) know which interpreter
> to start to interprete the script? Is it ksh, bash, sh, zsh, perl,
> …?
>
>
It is defined in your login environment. Try:
env | grep SHELL
to find out what is set for you. It is the default if no shebang is used.
Ken
First of all you do not need the over head of grep
printenv SHELL
Second, although the default log-in shell should/will run your “shebang-less” script, what happens when you double click on a file depends on the desktop environment or if it is in the realm of the desktop environment.
If you try to execute such a script directly (say with execv()), you will probably get a permission denied, or other similar error. It won’t run at all. It is only the shell that you are using that will choose what to do with it. So the decision whether to treat it as a Bourne shell script or a c-shell script is then entirely up to the shell that you are currently running.
From a program, if you try to run it with “system()” or “popen()”, then I think “sh” is used to initially decide what to do.
jetchisel wrote:
> First of all you do not need the over head of grep
>
> Code:
> --------------------
> printenv SHELL
> --------------------
Thanks, my computer was struggling to execute the first command