First, you must add the "execute" permission bit. Using chmod +x adds it, chmod -x removes it.
Second, in Unix you must use the exact file name. If the file is named hello.sh, you must run it by hello.sh, not hello. (You probably are used to Windows and its %PATHEXT%, which does not exist in Unix. Here, only the execute bit is considered and .sh is meaningless to the system – the file can be named simply hello if you want.)
Third, by default the current directory is not searched for commands (for security reasons). Either the script must be located in your $PATH, or you must run it by its full path name. Using . (which means "the current directory") will suffice.
~/Desktop chmod +x hello.sh
~/Desktop ./hello.sh
Hello, world!
~/Desktop ~/Desktop/hello.sh
Hello, world!
~/Desktop
(./hello.sh means "hello.sh in the current directory".)
When you typed date, you did not run your own script; you ran the system's date command (just like you run the system's chmod command when you type chmod). The @ is not making a difference here.
The @ character simply indicates the presence of "extended metadata" associated with that file; most likely something specific to TextEdit. According to the ls(1) manual page, you can use ls -l -@ (ls -l@) to see the metadata.
There's something wrong in your path. It works with sudo because it uses root settings.
Did you modify your $PATH environment variable?
In a terminal type $PATH. You should get something like: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I guess that yours would /usr/local/sbin:/home/otis/bin:/usr/sbin:/usr/bin:/sbin:/bin or something like that.
To solve this issue try typing: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Hope this helps.
Best Answer
It starts a bash shell as a
rootlevel user. You need it because typically normal users can't access/home/The danger of what you are doing is you are in a root shell -- you can mess up your machine rather easily.