two primary bash questions

English Programming/Scripting
#1

I have a two line test bash script:

#!/bin/bash
exit

…when run, the results are:

dan@A105-S4134:/windows/D/Devel/bash> bash test1
: command not found
Is ‘exit’ a valid bash shell command?

I also noticed in openSUSE 11.3, at least on this computer, there is no /bin/bash directory. And why is:

#!/bin/bash

needed, when the first char ‘#’ comments out the line anyways?

Looking for a ‘bash’ directory: On this computer, the command:

sudo find  /  -type d  -fstype ext4  -iname '*bash*' 2> /dev/null

yields:

/etc/bash_completion.d
/usr/share/bash
/usr/share/doc/packages/bash
Is this normal?

I’ve developed using different languages… but bash is unique regarding semantics and syntax.

Also, I am going to ask the obligatory question of “can there be a separate bash forum in forums.opensuse.org?”

Thank You,

Dan Perecky

#2

After you make a script file, you need to make it executable. Second, user scripts normally go into the home area bin folder. The tilde “`” symbol represents your home area. So, if you made or copied your bash script to the bin folder, you could make it executable with the terminal command:

chmod +x ~/bin/test1

I also have a script file that is useful to create script file headers, to better track what your script file is for and when it was made:

N.S.F. - New Script File Header Creator

You are in the right place for questions concerning script files. Look at what I have sent you then ask anymore questions that you have. I have another script file that is useful to look at your log files. Do what it says and then see how it works:

S.L.A.V.E. - SuSE Logfile Automated Viewer Engine - Version 2.00

another useful script is shown here:

Reboot from CLI to selective partitions

Thank You,

#3

Well, jdmcdaniel did allready try a good start, but else I would know where to start. Thus I will jump around a bit.

  1. /bin/bash is not a directory, correct. When you do
ls -l /bin/bash

you will see what it is.

  1. The “shebang” (see Shebang (Unix) - Wikipedia, the free encyclopedia) must be there to tell the system which interpreter to load to interprete (run) the script. Thus it is nonsense to type
bash test1

because the script itself tells allready it is bash. It is just

test1

provided (as jdmcdaniel pointed out) that the script (like every other program) is made executable by setting the x-bit(s) for those who may execute and by seeing that it can be found (again like for every other program). It can be found by
a) providing a complete path to the program either absolute

/home/danperecky/test1

or relative

./test1

b) or by having the directory it is in in your PATH environment variable (which is the case with* /home/danperecky/bin/* by default and then call

test1

But** your main problem** imho will be that you seem to use an non Linux partition for having the script in.
Am I right that /windows/D/ is a mounted Windows file system?
The mounting of Windows file system is fine for exchanging data with a Windows system (either for a multi boot situation or, for removable devices, with other systems. But it is not am alternative for a native Linux file system. E.g. that

chmod u+x test1

will NOT function on it.

You will have understood by now that

exit

is a valid bash command because no doubt you found that by reading

man bash
#4

Another possibility is that you have used a non-Linux editor to create the script, resulting in line endings of CR-NL.

#5

Any script that you’re going to make executable (as described in the other posts) needs that line at the first place in order for it to be executed by its name. It tells which interpreter to run. In that case, the interpreter is bash and its fullname is /bin/bash. If this first line were missing, you would have to type : ‘bash scriptname’ to execute the script.

#!/bin/bash

#!/usr/bin/csh

#!/usr/bin/python2.6

#!/usr/bin/perl

are examples of valid first lines you may find in scripts.

#6

wow… great responses…

jdmcdaniel3: I copied/pasted your ‘nsf’ script. It wouldn’t work when preceded with sudo, but did work excellently in su mode. Nice script.

hcvv: shebang. This was not intuitive. Every bash script starts out with a shebang… lol.

But** your main problem** imho will be that you seem to use an non Linux partition for having the script in.
Am I right that /windows/D/ is a mounted Windows file system?
… yes, you are right. I like to keep code in a seperate non-linux-dependant NTFS partition. This way, it can be shared between different linux distros (if any).

The commands:

su
A105-S4134:/windows/D/Devel/bash # bash nsf test7

resulted in a lot of error msgs, but the script did work. ‘nsf’ was in executable mode once copied over.
error msgs displayed from running nsf script:

_IceTransSocketUNIXConnect: Cannot connect to non-local host A105-S4134
_IceTransSocketUNIXConnect: Cannot connect to non-local host A105-S4134

(gedit:8673): EggSMClient-WARNING **: Failed to connect to the session manager: Could not open network socket

GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See GConf configuration system for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See GConf configuration system for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See GConf configuration system for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See GConf configuration system for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See GConf configuration system for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)
.
.
.
…

nsf script Ext4/NTFS status:

A105-S4134:/home/dan/bin # ls -l
total 12
-rwxr-xr-x 1 root root 1410 2010-09-26 15:18 nsf
-rwxr-xr-x 1 root root 19 2010-09-26 13:54 test1
-rwxr-xr-x 1 dan users 256 2010-09-26 15:10 test2
A105-S4134:/home/dan/bin # cp nsf /windows/D/Devel/bash/nsf
A105-S4134:/home/dan/bin # cd /windows/D/Devel/bash
A105-S4134:/windows/D/Devel/bash # ls -l nsf
-rwxrwxrwx 1 root users 1410 2010-09-26 15:51 nsf

ken_yap: You are correct. Looks like kedit will not be used for bash. ‘nsf’ worked, as described above. But ‘test1’ still failed, until I used vi to recreate it.

please_try_again: The shebang looked like a dir to me. Looking at the bash tutorials online, none of the ones I looked at explained this primary and important initial line. Thanks.

:shake:

#7

To share beween Linux systems, I guess one better uses a native Linux file system and not an NTFS one.
In any case, you will have big trouble in using all sorts of non-Linux file systems, editors, etc. when working with Linux.

And you usage of su and the like is beyond my understanding of your problem…

#8

On 2010-09-26 22:06, danperecky wrote:

>> But* your main problem* imho will be that you seem to use an non Linux
>> partition for having the script in.
>> Am I right that -/windows/D/- is a mounted Windows file system?..

> yes, you are right. I like to keep code in a seperate
> non-linux-dependant NTFS partition. This way, it can be shared between
> different linux distros.

Don’t.

Use a native linux filesystem to share code between those linux distros you have, or you will get
into all sort of weird problems. Use that ntfs partition only for data.

Linux source code will use things they give for granted on a linux filesystem, like linux
permissions, hardlinks, symlinks… and will not test for failure modes that only a windows
filesystem would provoke.

And NTFS on linux is much slower, too.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

#9

Just say dos2unix, or paste your code back from the browser.