I downloaded a few programs, go to execute them, but get message:

bash: ./Budget-Linux-bld1.sh: Permission denied

Im in as root, any ideas?

. ./script_with_extension_sh

. is an alias to "source" which is detailed in man bash

If you're in as root, it is indeed weird.

What does the following command give you?:
If you're logged as root, try this command:
It will give the file the following rights:
user: rwx
group: r-x
other: r-x

Doing: will then show the following permissions:
rwxr-xr-x

P.S:
r=read
w=write
x=execute

The way chmod works:
user/group/other
rwxrwxrwx
421421421

This means that 755=(4+2+1,4+1,4+1)=rwxr-xr-x

edit:
Ah, so I learned something new.
But what is the difference between "sh" and "source" then?

re-edit: Just corrected a little mistake.

scripts with sh extension are supposed to be "sourced" and don't need the x bit.
It may not work if you run it as ./script because this form will open a new shell and this subshell will only inherit of environment variables, not local variables of the calling shell.
Hope its more or less clear

"sh script" is a form I never use. ??
But it's supposed to be the same as ./script. The difference is with the "sh script" form, you donÄt need the x bit

suppose this is script.sh:
#!/bin/sh
echo "Hello"
echo $var

Now

var="world"

./script.sh
=>perm denied

sh ./script.sh
=>Hello

. ./script.sh
=>Hello world

chmod +x script.sh
./script.sh or sh ./script.sh
=>Hello -> We don't have var in the subshell (which is sh in the first case because of #!/bin/sh)

scripts with sh extension are supposed to be "sourced" and don't need the x bit.
Never read that rule? AFAIK ".sh" means "open with $PATH/sh if I don't know what to open it with".


"sh script" is a form I never use. ??
You use that to execute the script if it hasn't got the execute bit set.


AFAIK "./" means execute here, "at this location" which is something different than to source: ". something" (notice the space). Doing "sh ./Budget-Linux-bld1.sh" as non-root user runs the script with /bin/bash as shell and returns aprox 17 lines of help message. No problem here.

If it has no shebang then its supposed to be sourced. As it has no shebang you have to know with what to run it, so that's why it has an extension (which is actually called suffix in linux).
Now running sh script or . script depends on you want to do (in general you refer to the README): For example, if you run several scripts after the other, doing . script or sh script is not the same and with my super-example, running it with sh script fails.

Yes and you force sh to execute it. If your shell is bash and the shebang is /bin/sh, you will notice (on my system at least) that the shebang is not followed and your script will be executed by /bin/bash. That's probably a bash feature.
Here yes. But maybe there not. I'm sure you get the point

Just wanted to clear things, look at the documentation and do what it says...

If it has no shebang then its supposed to be sourced.
Could you please tell me where it says so? Not trying to catch you on words but "supposed" means it's not mandated. More like a convention you can or can decline to follow. It ain't in 'man bash' anyway.


As it has no shebang you have to know with what to run it, so that's why it has an extension (which is actually called suffix in linux).
AFAIK extensions are only for human recognition and applications that can't or won't find the associated application to open it with w/o "magic", MIME or equivalent. Binaries need no extension by default and neither do scripts. (And lets make it clear I mean 'man 5 magic'). Linking an application to a file by extension alone is a dumb move anyway as anyone who has messed with it knows.

If the script is executable and there's no shebang line the current shell will have execve() determine what to run it with, which in case of scripts means the default system shell. Extension doesn't matter. If the script is sourced permission and shebang line mean zilch since sourcing means "execute in the current shell" as does "sh script". Extension still doesn't matter.


Here yes. But maybe there not. I'm sure you get the point
No, I mean "here" as in "from that location", not as in "on my box".

Yes its a convention I had read on some linux mailing list. Can't remember where sorry. Not in man bash that's sure.
Then give me an explanation for this suffix? I agree suffixes are stupid unless needed..
How do you know from a script with which shell its supposed to run, if there's no shebang?
Take as example I'm running tcsh as my /bin/sh link
sh script opens a new shell I think (see my example)
And what about my script? It doesn't work if you call it by sh ./script.
It will fail on every machine, in every location.

Sorry but English is not my native language... every word has an importance and sometimes I miss what people really mean. /me Frustrated.

I'm surprised that I haven't been understood...
My point was: If a script is supposed to be sourced and you execute it, it may not work.

There are three ways of handling that. The usual way is to give the file execute permissions:

Or you can call bash explicitly, so that the file name is an ordinary argument to a command:

Or you can source the file:

...which is the same as:

Note that when you source a script, it is executed in the current environment, and variables in your current shell may be changed. Also, if an exit command is encountered, it will exit your interactive shell (or the calling script, it it is sourced from another script).

You shouldn't be logged in as root unless you absolutely have to be.

That is not the case. The only reason for a shebang is to tell the system (or the shell) to use an interpreter other than the default (usually /bin/sh).

How do you know from a script with which shell its supposed to run, if there's no shebang?
I don't. I can run it. If it isn't compatible I can guess or look at it or make it compatible (or if there's a suffix maybe take the hint ;-p ).


And what about my script? It doesn't work if you call it by sh ./script. It will fail on every machine, in every location.
Uh. Do you run tcsh everywhere?


My point was: If a script is supposed to be sourced and you execute it, it may not work.
Good point, but practically speaking most scripts are meant to be executed, not sourced, right? At least in my experience. The only things I source are static resources like function libraries and config files.

Erm humm approximatly nowhere I use dash for eliminating bashism