I simply want to run an executable from the command line, ./arm-mingw32ce-g++, but then I get the error message,
bash: ./arm-mingw32ce-g++: No such file or directory
I'm running Ubuntu Linux 10.10. ls -l lists
-rwxr-xr-x 1 root root 433308 2010-10-16 21:32 arm-mingw32ce-g++
Using sudo (sudo ./arm-mingw32ce-g++) gives
sudo: unable to execute ./arm-mingw32ce-g++: No such file or directory
I have no idea why the OS can't even see the file when it's there. Any thoughts?
This error can mean that ./arm-mingw32ce-g++ doesn't exist (but it does), or that it exists and is a dynamically linked executable recognized by the kernel but whose dynamic loader is not available. You can see what dynamic loader is required by running ldd /arm-mingw32ce-g++; anything marked not found is the dynamic loader or a library that you need to install.
If you're trying to run a 32-bit binary on an amd64 installation:
Up to Ubuntu 11.04, install the package ia32-libs.
On Ubuntu 11.10, install ia32-libs-multiarch.
Starting with 12.04, install ia32-libs-multiarch, or select a reasonable set of :i386 packages in addition to the :amd64 packages.
I faced this error when I was trying to build Selenium source on Ubuntu. The simple shell script with correct shebang was not able to run even after I had all pre-requisites covered.
file file-name # helped me in understanding that CRLF ending were present in the file.
I opened the file in Vim and I could see that just because I once edited this file on a Windows machine, it was in DOS format. I converted the file to Unix format with below command:
dos2unix filename # actually helped me and things were fine.
I hope that we should take care whenever we edit files across platforms we should take care for the file formats as well.
This error may also occur if trying to run a script and the shebang is misspelled. Make sure it reads #!/bin/sh, #!/bin/bash, or whichever interpreter you're using.
I had the same error message when trying to run a Python script -- this was not #Warpspace's intended use case (see other comments), but this was among the top hits to my search, so maybe somebody will find it useful.
In my case it was the DOS line endings (\r\n instead of \n) that the shebang line (#!/usr/bin/env python) would trip over. A simple dos2unix myfile.py fixed it.
I found my solution for my Ubuntu 18 here.
sudo dpkg --add-architecture i386
Then:
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386
I got this error “No such file or directory” but it exists because my file was created in Windows and I tried to run it on Ubuntu and the file contained invalid 15\r where ever a new line was there.
I just created a new file truncating unwanted stuff
sleep: invalid time interval ‘15\r’
Try 'sleep --help' for more information.
script.sh: 5: script.sh: /opt/ag/cont: not found
script.sh: 6: script.sh: /opt/ag/cont: not found
root#Ubuntu14:/home/abc12/Desktop# vi script.sh
root#Ubuntu14:/home/abc12/Desktop# od -c script.sh
0000000 # ! / u s r / b i n / e n v b
0000020 a s h \r \n w g e t h t t p : /
0000400 : 4 1 2 0 / \r \n
0000410
root#Ubuntu14:/home/abc12/Desktop# tr -d \\015 < script.sh > script.sh.fixed
root#Ubuntu14:/home/abc12/Desktop# od -c script.sh.fixed
0000000 # ! / u s r / b i n / e n v b
0000020 a s h \n w g e t h t t p : / /
0000400 / \n
0000402
root#Ubuntu14:/home/abc12/Desktop# sh -x script.sh.fixed
As mentioned by others, this is because the loader can't be found, not your executable file. Unfortunately the message is not clear enough.
You can fix it by changing the loader that your executable uses, see my thorough answer in this other question: Multiple glibc libraries on a single host
Basically you have to find which loader it's trying to use:
$ readelf -l arm-mingw32ce-g++ | grep interpreter
[Requesting program interpreter: /lib/ld-linux.so.2]
Then find the right path for an equivalent loader, and change your executable to use the loader from the path that it really is:
$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 arm-mingw32ce-g++
You will probably need to set the path of the includes too, you will know if you want it or not after you try to run it. See all the details in that other thread.
I got the same error for a simple bash script that wouldn't have 32/64-bit issues. This is possibly because the script you are trying to run has an error in it. This ubuntu forum post indicates that with normal script files you can add sh in front and you might get some debug output from it. e.g.
$ sudo sh arm-mingw32ce-g++
and see if you get any output.
In my case the actual problem was that the file that I was trying to execute was in Windows format rather than Linux.
Below command worked on 16.4 Ubuntu
This issue comes when your .sh file is corrupt or not formatted as per unix protocols.
dos2unix converts the .sh file to Unix format!
sudo apt-get install dos2unix -y
dos2unix test.sh
sudo chmod u+x test.sh
sudo ./test.sh
I had the same problem with a file that I've created on my mac.
If I try to run it in a shell with ./filename I got the file not found error message.
I think that something was wrong with the file.
what I've done:
open a ssh session to the server
cat filename
copy the output to the clipboard
rm filename
touch filename
vi filename
i for insert mode
paste the content from the clipboard
ESC to end insert mode
:wq!
This worked for me.
Added here for future reference (for users who might fall into the same case):
This error happens when working on Windows (which introduces extra characters because of different line separator than Linux system) and trying to run this script (with extra characters inserted) in Linux. The error message is misleading.
In Windows, the line separator is CRLF (\r\n) whereas in linux it is LF (\n). This can be usually be chosen in text editor.
In my case, this happened due to working on Windows and uploading to Unix server for execution.
I just had this issue in mingw32 bash. I had execuded node/npm from Program Files (x86)\nodejs and then moved them into disabled directory (essentially removing them from path). I also had Program Files\nodejs (ie. 64bit version) in path, but only after the x86 version. After restarting the bash shell, the 64bit version of npm could be found. node worked correctly all the time (checked with node -v that changed when x86 version was moved).
I think bash -r would've worked instead of restarting bash: https://unix.stackexchange.com/a/5610
I had this issue and the reason was EOL in some editors such as Notepad++. You can check it in Edit menu/EOL conversion. Unix(LF) should be selected.
I hope it would be useful.
Hit this error trying to run terraform/terragrunt (Single go binary).
Using which terragrunt to find where executable was, got strange error when running it in local dir or with full path
bash: ./terragrunt: No such file or directory
Problem was that there was two installations of terragrunt, used brew uninstall terragrunt to remove one fixed it.
After removing the one, which terragrunt showed the new path /usr/bin/terragrunt everything worked fine.
For those encountering this error when running a java program, it's possible that you're trying to run a 64-bit java program using on a 32-bit linux operating system.
I only realised when I ran ldd on 64-bit java which reported:
ldd /usr/java/jdk1.8.0_05/bin/java
'not a dynamic executable'
Whereas the old 32 bit java reported sensible results:
ldd /usr/java/jdk1.8.0_05/bin/java
In my case, it turns out the file was a symlink:
$ cat deluge-gtk.lock
cat: deluge-gtk.lock: No such file or directory
$ file deluge-gtk.lock
deluge-gtk.lock: broken symbolic link to 32309
Misleading errors like this are fairly common on Linux. Related discussion: https://lwn.net/Articles/532771/
Give it a try by changing the name of file or folder which is not showing in terminal/command prompt.
step1 : change the name of file or folder.
step2 : cd filename/foldername
For future readers, I had this issue when trying to launch a Django server using gunicorn. I was using AWS CodeBuild to build the virtual environment and run tests and using CodeDeploy to put the built artifacts onto the production server and launch the new version (all environments were Ubuntu 20.04). I had mistakenly thought that env/bin/... contained actual binaries of native libraries but that was not the case. It was just Python scripts with a shebang of the path to the Python interpreter on the build machine. In my case, the machine installing the packages and actually running the packages was different. To be more specific, all of the files in env/bin had the shebang #!/codebuild/output/src715682316/src/env/bin/python, so of course running env/bin/gunicorn on the production server would fail. The cryptic error message was when Ubuntu would tell me that env/bin/gunicorn didn't exist as opposed to saying /codebuild/output/src715682316/src/env/bin/python didn't exist. I was able to fix this problem by starting gunicorn using python3 env/bin/gunicorn instead of env/bin/gunicorn.
In a .sh script, each line MUST end with a single character - newline (LF or "\n").
Don't make mistakes like me, because my text-editor of choice is Notepad++ in Win.
Related
So I was trying to create little .sh script for my work and run into one little problem.
My cygwin terminal (x64) runs just fine and I'm using it often enough to do manual greps.
In the begging I had some issues with this command but now it works fine in cygwin terminal.
Once I wrote my little script and tried to run it only output I'm getting is "line 6: grep: command not found"
My execution method is:
Open cygwin terminal
cd to script location
type in ./script.sh
enter :)
Anyone knows how to fix that? I already added cygwin bin folder to my system path (Win 10 btw) but that didn't helped. Looked around for a while but haven't found anything useful, mostly issues with grep itself.
my script for reference:
mkdir -p output
PATH=$PWD"/output"
while IFS=";" read -r component location global
do
cd $location
grep -iRl $global --exclude-dir={wrongdir1,wrongdir2} > $PATH"/"$component".txt"
done < input.csv
you're overwriting you Cygwin system path: PATH=$PWD"/output" - instead of PATH use a diff var name.
edit : I ended up upgrading to macOS Catalina yesterday and replacing bash with zsh. One thing that should be noted is that the stackcommand worked previously, but despite all the tinkering not ghci
After deleting all the files that had anything to do with Haskell, I retried running curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
This second time there was an error with the command line tools so I had to install them manually with xcode-select --install. After rerunning the curl, I added the path to the environmental file to my zsh profile manually with :
. "$HOME/.ghcup/env"\
echo '. $HOME/.ghcup/env' >> "$HOME/.zshrc"
Here is the content of the env file :export PATH="$HOME/.cabal/bin:/Users/agnel/.ghcup/bin:$PATH"
Now everything seems to be working (I never reinstalled stack, but I think I might leave that to the side while I learn the basics of the language).
I installed the Haskell Platform yesterday but am having a hard time getting it to work correctly.
The firsts steps I did are:
curl -sSL https://get.haskellstack.org/ | sh
curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
On step 1. the instructions said to append /Users/.../.local/bin the PATH variable (which I did in /etc/paths. On step 2, the script was supposed to pop up a dialog box (and didn't) when installing the necessary command line tools. It also said to rerun the script once complete (which I did). The script also said I should adjust my PATH variable, and source /Users/.../.ghcup/env in my shell configuration. It asked to this automatically but failed having not found the ~/.bashrc File. (I read that on Mac in contrary to linux, only .bash_profile is loaded upon opening of a terminal window so I adjusted the path variable there manually. I've spent forever messing around with the path variables and every time I try and run "$ ghci" I get the same -bash: ghci: command not found error message. If anyone has a solution to this problem I would be very grateful for an answer. If not, could someone with a working distribution of Haskell on their computer show me what their path variables look like?
Thanks!
A simple solution would just be to restart your terminal and you are good to go.
After installing the Haskell platform for the first time on a new mac with Catalina, I also got
~> ghci
zsh: command not found: ghci
What worked in my case was to use, instead of the plain ghci,
stack ghci
To get back the familiar behaviour, I created in my homedirectory a file named .zshrc containing
alias ghci='stack ghci'
If you open a new terminal, this file will automatically be executed.
I'd be interested to know if there is another solution.
Check if the ghcup command is working or not.
If not, make sure the .zshrc file has command for execution of ghcup. It should look something like this -
[ -f "/Users/myusername/.ghcup/env" ] && source "/Users/myusername/.ghcup/env" # ghcup-env
If the file exists, simply restarting terminal will work.
If it is still not working, set GHC as default using ghcup - follow this
I'm installing harbor with source code.
✗ make install
the error is below:
...
Successfully built b917c04731a3
Successfully tagged goharbor/nginx-photon:dev
Done.
/bin/bash: --timeout: command not found
make[1]: *** [_build_registry] Error 127
make: *** [build] Error 2
I've tried to get coreutils and config my path
brew install coreutils
Edit :
The answer of #Arne Vogel is more likely to point the real problem.
Indeed it would be surprising that you don't have the command /bin/bash (so the steps I described here won't solve the issue).
coresutil is composed of GNU version of the most famous commands (cat, head, tail, wc, sort...), so it's not directly related to your problem.
You can use brew to install the latest version (version 5) of bash:
brew install bash
Double check if you really don't have a bash inside your /bin/:
sudo ls /bin/bash
It should returns a line like this (pay attention to the permission):
-r-xr-xr-x 1 root wheel 618416 Nov 30 12:55 /bin/bash
If it returns no result, then you may create a link:
sudo ln -s $(which bash) /bin/bash
TBH, I don't know about harbor, but this error seems to be caused by bad formatting in a script, specifically something like:
some-command --some-option --some-other-option \
--timeout
Now if the backslash (to continue the line) is missing, some-command will first be executed (without the --timeout option), and then bash will try to execute a command called --timeout, which, unsurprisingly, does not exist.
This problem can also be caused by an extraneous space after the backslash, a stray semicolon, wrong line terminators (in particular, Windows-style CRLF) etc.
Here are some suggestions for what you could do:
Make sure you have downloaded the source package appropriate for Mac OS X. Many open source packages are distributed in different formats, e.g. .zip and/or .7z for Windows, .tar.gz and/or .tar.bz2 for UNIX. You need either of the latter.
Check the documentation and/or forums, obviously.
If that doesn't help, use ktrace to find the offending script, and then look at it in a text editor. If you do find a bug in a script, consider reporting it to the developers.
I simply want to run an executable from the command line, ./arm-mingw32ce-g++, but then I get the error message,
bash: ./arm-mingw32ce-g++: No such file or directory
I'm running Ubuntu Linux 10.10. ls -l lists
-rwxr-xr-x 1 root root 433308 2010-10-16 21:32 arm-mingw32ce-g++
Using sudo (sudo ./arm-mingw32ce-g++) gives
sudo: unable to execute ./arm-mingw32ce-g++: No such file or directory
I have no idea why the OS can't even see the file when it's there. Any thoughts?
This error can mean that ./arm-mingw32ce-g++ doesn't exist (but it does), or that it exists and is a dynamically linked executable recognized by the kernel but whose dynamic loader is not available. You can see what dynamic loader is required by running ldd /arm-mingw32ce-g++; anything marked not found is the dynamic loader or a library that you need to install.
If you're trying to run a 32-bit binary on an amd64 installation:
Up to Ubuntu 11.04, install the package ia32-libs.
On Ubuntu 11.10, install ia32-libs-multiarch.
Starting with 12.04, install ia32-libs-multiarch, or select a reasonable set of :i386 packages in addition to the :amd64 packages.
I faced this error when I was trying to build Selenium source on Ubuntu. The simple shell script with correct shebang was not able to run even after I had all pre-requisites covered.
file file-name # helped me in understanding that CRLF ending were present in the file.
I opened the file in Vim and I could see that just because I once edited this file on a Windows machine, it was in DOS format. I converted the file to Unix format with below command:
dos2unix filename # actually helped me and things were fine.
I hope that we should take care whenever we edit files across platforms we should take care for the file formats as well.
This error may also occur if trying to run a script and the shebang is misspelled. Make sure it reads #!/bin/sh, #!/bin/bash, or whichever interpreter you're using.
I had the same error message when trying to run a Python script -- this was not #Warpspace's intended use case (see other comments), but this was among the top hits to my search, so maybe somebody will find it useful.
In my case it was the DOS line endings (\r\n instead of \n) that the shebang line (#!/usr/bin/env python) would trip over. A simple dos2unix myfile.py fixed it.
I found my solution for my Ubuntu 18 here.
sudo dpkg --add-architecture i386
Then:
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386
I got this error “No such file or directory” but it exists because my file was created in Windows and I tried to run it on Ubuntu and the file contained invalid 15\r where ever a new line was there.
I just created a new file truncating unwanted stuff
sleep: invalid time interval ‘15\r’
Try 'sleep --help' for more information.
script.sh: 5: script.sh: /opt/ag/cont: not found
script.sh: 6: script.sh: /opt/ag/cont: not found
root#Ubuntu14:/home/abc12/Desktop# vi script.sh
root#Ubuntu14:/home/abc12/Desktop# od -c script.sh
0000000 # ! / u s r / b i n / e n v b
0000020 a s h \r \n w g e t h t t p : /
0000400 : 4 1 2 0 / \r \n
0000410
root#Ubuntu14:/home/abc12/Desktop# tr -d \\015 < script.sh > script.sh.fixed
root#Ubuntu14:/home/abc12/Desktop# od -c script.sh.fixed
0000000 # ! / u s r / b i n / e n v b
0000020 a s h \n w g e t h t t p : / /
0000400 / \n
0000402
root#Ubuntu14:/home/abc12/Desktop# sh -x script.sh.fixed
As mentioned by others, this is because the loader can't be found, not your executable file. Unfortunately the message is not clear enough.
You can fix it by changing the loader that your executable uses, see my thorough answer in this other question: Multiple glibc libraries on a single host
Basically you have to find which loader it's trying to use:
$ readelf -l arm-mingw32ce-g++ | grep interpreter
[Requesting program interpreter: /lib/ld-linux.so.2]
Then find the right path for an equivalent loader, and change your executable to use the loader from the path that it really is:
$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 arm-mingw32ce-g++
You will probably need to set the path of the includes too, you will know if you want it or not after you try to run it. See all the details in that other thread.
I got the same error for a simple bash script that wouldn't have 32/64-bit issues. This is possibly because the script you are trying to run has an error in it. This ubuntu forum post indicates that with normal script files you can add sh in front and you might get some debug output from it. e.g.
$ sudo sh arm-mingw32ce-g++
and see if you get any output.
In my case the actual problem was that the file that I was trying to execute was in Windows format rather than Linux.
Below command worked on 16.4 Ubuntu
This issue comes when your .sh file is corrupt or not formatted as per unix protocols.
dos2unix converts the .sh file to Unix format!
sudo apt-get install dos2unix -y
dos2unix test.sh
sudo chmod u+x test.sh
sudo ./test.sh
I had the same problem with a file that I've created on my mac.
If I try to run it in a shell with ./filename I got the file not found error message.
I think that something was wrong with the file.
what I've done:
open a ssh session to the server
cat filename
copy the output to the clipboard
rm filename
touch filename
vi filename
i for insert mode
paste the content from the clipboard
ESC to end insert mode
:wq!
This worked for me.
Added here for future reference (for users who might fall into the same case):
This error happens when working on Windows (which introduces extra characters because of different line separator than Linux system) and trying to run this script (with extra characters inserted) in Linux. The error message is misleading.
In Windows, the line separator is CRLF (\r\n) whereas in linux it is LF (\n). This can be usually be chosen in text editor.
In my case, this happened due to working on Windows and uploading to Unix server for execution.
I just had this issue in mingw32 bash. I had execuded node/npm from Program Files (x86)\nodejs and then moved them into disabled directory (essentially removing them from path). I also had Program Files\nodejs (ie. 64bit version) in path, but only after the x86 version. After restarting the bash shell, the 64bit version of npm could be found. node worked correctly all the time (checked with node -v that changed when x86 version was moved).
I think bash -r would've worked instead of restarting bash: https://unix.stackexchange.com/a/5610
I had this issue and the reason was EOL in some editors such as Notepad++. You can check it in Edit menu/EOL conversion. Unix(LF) should be selected.
I hope it would be useful.
Hit this error trying to run terraform/terragrunt (Single go binary).
Using which terragrunt to find where executable was, got strange error when running it in local dir or with full path
bash: ./terragrunt: No such file or directory
Problem was that there was two installations of terragrunt, used brew uninstall terragrunt to remove one fixed it.
After removing the one, which terragrunt showed the new path /usr/bin/terragrunt everything worked fine.
For those encountering this error when running a java program, it's possible that you're trying to run a 64-bit java program using on a 32-bit linux operating system.
I only realised when I ran ldd on 64-bit java which reported:
ldd /usr/java/jdk1.8.0_05/bin/java
'not a dynamic executable'
Whereas the old 32 bit java reported sensible results:
ldd /usr/java/jdk1.8.0_05/bin/java
In my case, it turns out the file was a symlink:
$ cat deluge-gtk.lock
cat: deluge-gtk.lock: No such file or directory
$ file deluge-gtk.lock
deluge-gtk.lock: broken symbolic link to 32309
Misleading errors like this are fairly common on Linux. Related discussion: https://lwn.net/Articles/532771/
Give it a try by changing the name of file or folder which is not showing in terminal/command prompt.
step1 : change the name of file or folder.
step2 : cd filename/foldername
For future readers, I had this issue when trying to launch a Django server using gunicorn. I was using AWS CodeBuild to build the virtual environment and run tests and using CodeDeploy to put the built artifacts onto the production server and launch the new version (all environments were Ubuntu 20.04). I had mistakenly thought that env/bin/... contained actual binaries of native libraries but that was not the case. It was just Python scripts with a shebang of the path to the Python interpreter on the build machine. In my case, the machine installing the packages and actually running the packages was different. To be more specific, all of the files in env/bin had the shebang #!/codebuild/output/src715682316/src/env/bin/python, so of course running env/bin/gunicorn on the production server would fail. The cryptic error message was when Ubuntu would tell me that env/bin/gunicorn didn't exist as opposed to saying /codebuild/output/src715682316/src/env/bin/python didn't exist. I was able to fix this problem by starting gunicorn using python3 env/bin/gunicorn instead of env/bin/gunicorn.
In a .sh script, each line MUST end with a single character - newline (LF or "\n").
Don't make mistakes like me, because my text-editor of choice is Notepad++ in Win.
I am new to programming and am trying to follow an example which uses #! comment in ruby.
I am consistently get the message:
bash: matz.rb: command not found
I am using this comment:
#! /usr/bin/env ruby
I have tried it with and without the space after ! as well as with and without the env.
when I use the
$ which ruby
ruby is in: /usr/bin/ruby
I have also gone into the operating system and changed the permissions on the file matz.rb to rwx for all users w/ no effect. Am I doing something wrong or do I have my system set up incorrectly?
The /usr/bin/env part is fine. You need to give bash the path to matz.rb when you run it. If you're in the directory with matz.rb, type "./matz.rb". The directory "." means the current directory - bash doesn't look there by default when running programs (like Windows does).
The env program (/usr/bin/env) searches the executable search path - the PATH environment variable - for the ruby program as if you typed it at the command prompt, and runs that program. The shebang comment doesn't do this. If you want to give your script to other people who might not have ruby installed in the same place as you, then you should use the "#!/usr/bin/env ruby" comment so that it will work as long as they can run ruby by typing "ruby".
If you're in the same directory as the matz.rb file, be sure to run it as
$ ./matz.rb
and not just
$ matz.rb
Here's a shell session demonstrating this working:
$ ls -la m*
-rwxr-xr-x 1 gareth gareth 32 8 Jan 08:46 matz.rb
$ cat matz.rb
#!/usr/bin/env ruby
puts "Matz"
$ matz.rb
-bash: matz.rb: command not found
$ ./matz.rb
Matz
Your file wasn't created on Windows was it? If it has \r\n line endings, that will upset bash. You can open it with Vim and check:
vi matz.rb
:set ff=unix
:wq
If when you tab-complete the "ff=" part it says dos, then it has the wrong file format. Alternatively, run dos2unix and try to run the file again:
apt-get install sysutils
dos2unix matz.rb
It sounds like you're on a Unix/Linux system and just typing matz.rb on the command line. If you're trying to execute a command in the current directory, you need to call it like ./matz.rb. The "./" tells it to look in the current directory rather than just /usr/bin and friends.
I failed to see any answer indicating you to change the executable mode of the file, so you might wanna try and do
chmod +x matz.rb
before you go and try doing
./matz.rb
Also it might be better not to attach a .rb extension to the file, such is the case for normal ruby / rails scripts e.g. script/generate, script/console etc.
You can use the 'shebang' line with either:
#!/usr/bin/ruby
#!/usr/bin/env ruby
But the script needs to be executable (you indicated it is) and in your shell $PATH.
echo $PATH
Put the script in one of those directories, or modify your path, otherwise specify the full path to it, for example:
export PATH=$PATH:/home/user/bin
or one of these:
./matz.rb
/home/user/bin/matz.rb
You can also run the Ruby interpreter passing the script filename as an argument, and it will be executed. This is particularly useful if you have another version of Ruby installed on your system (say, for testing, like Ruby Enterprise Edition, REE):
/usr/bin/ruby matz.rb
/opt/ree/bin/ruby matz.rb
Have you tried the ShaBang as following to directly point to ruby?
#! /usr/bin/ruby
Then you call the script from the commandline as
./matz.rb
Under Unix/Linux systems the dot in front of a command to search for the command in the current directory. If you give a path like /usr/bin/ruby, it will search in the current directory for a directory called usr...
A command without a dot/ in front is searched in locations specified by the path variable of the environment.
A command with a / on the beginning is searched exactly from root following the specified path.
Inside your ShaBang, you want to specify the exact path to the interpreter so "/usr/bin/ruby" is the correct one. On the commandline, where you want your script to be executed, you need to call the script with "./matz.rb" otherwise the bash will search a command like /usr/bin/matz.rb what leads to your errormessage.