[SOLVED] (Bourne shell) Why does ". ./myscript" run but ". sh myscript" does not?

FireWalkWithMe · 08-06-2015, 10:00 PM

Scripting newbie here. I do not understand two different errors I get.

In file myscript I have:

Code:

echo "Hello world\n"

I make it executable and I can run it in a forked sub-shell:

Code:

$ chmod +x myscript
$ ./myscript
OR
$ sh myscript

I can also run it in current shell using . (alias of source)

Code:

$ . ./myscript

BUT when I try to do this...

Code:

$ . sh myscript

I get:

Quote:

bash: .: /bin/sh: cannot execute binary file

That's the first error I don't understand.

My intuition is that since I am running it in the current shell with . (AKA source), I am not allowed to tell it to use another shell. Also, I believe I was able to leave out the #!/bin/sh line because I am in bash shell and it is compatible with Bourne shell. I don't think I can get away with that in a different interpreter.

So I tried another experiment. In file myscript (still executable):

Code:

#!/usr/bin/perl
print "Hello world\n";

I can run it in sub-shell:

Code:

$ perl myscript
AND
$ ./myscript

But if I run it in current shell

Code:

$ . ./myscript

I get the second thing I don't understand:

Quote:

Warning: unknown mime-type for "Hello world\n" -- using "application/octet-stream"
Error: no such file "Hello world\n"

which is also what I get if I run the perl script without #! line:

Code:

$ ./myscript

Quote:

Warning: unknown mime-type for "Hello world\n" -- using "application/octet-stream"
Error: no such file "Hello world\n"

Furthermore, I get the same error as above if I run

Code:

$ . perl myscript

Quote:

bash: .: /usr/bin/perl: cannot execute binary file

I say hey... what's going on? (I say heaeeyyyyeyaahheyayeeee... )

genss · 08-06-2015, 10:14 PM

http://ss64.com/bash/source.html
"Read and execute commands from the filename argument in the current shell context."

first argument is the file name
there is no file named "sh"

tronayne · 08-07-2015, 07:26 AM

Whenever you execute a program, any program, it executes in a new shell, a copy of your log in shell, with a new process identification number (PID). You type the command (and any arguments), a copy of your current shell is created, the program executes and the copy shell dies.

A shell program (a "script" is a shell program) can be executed in your current shell (not a copy) with the dot command. This is a common way to modify your current shell, for example you might wish to alter the content of a shell environment variable and you can do that by using the dot command.

The dot command does not work with anything but a shell program.

Something that seems to have gone out of favor is writing a shell program source (with the .sh extension) then making it executable with the make utility (which copies the file without the .sh and makes it executable).

For example:

Code:

prompt: cat hello.sh
#!/bin/ksh

print "Hello, world."
prompt: make hello
cat hello.sh >hello 
chmod a+x hello
prompt: hello
Hello, world.
prompt: . hello
Hello, world.

The "pound-bang" (#!) is how you specify the shell you wish to use for your shell program. In this case, I specified KornShell; I could have specified BASH or Bourne or whatever that way so that my shell program, written in the grammar and syntax of KornShell will run in that shell environment -- my log in shell might be BASH but my program will be executed by KornShell. The shell(s) are binary executable programs: that's why

Code:

. sh hello

does not work (you're already in a shell).

As time goes on, you'll be writing programs in multiple languages; C, C++, shell, AWK, Perl, what have you. You'll learn that you want to use some sort of source code control where you keep the source separate from the executable. That's particularly important when you develop applications that (most likely) will be a mix of sources and the make utility will be a valuable tool for building applications from a mix of source (such as pretty much everything in Linux is). make will make an executable from a shell source file (or C or C++ or whatever) and it will not tack an extension on the executable -- Linux doesn't need a .exe or .bin or .sh tacked on, that's a Windows thing.

Hope this helps some.