I suffer from the behaviour of sh in my FreeBSD 4.6 distribution.
Constructs like:
let FAILED=$FAILED +1
do not work, I have to use
FAILED="$FAILED"+1
instead.

Because of this, almost no shell scripts written on my home Linux machine or downloaded from the internet work.
What is the reason for this behaviour of sh in FreeBSD, and what is the best remedy? Please be a bit specific, I am a newbie to unixes.

do you mean sh (Borne) or Korn do
echo $SHELL

You could install port of BASH if thats what your looking
If your actually using sh instead of Korn do

chsh -s /pathto/korn
log out and back in to get you new env.

I mean the shell in /bin/sh on the FreeBSD machine has a different behaviour (syntax) from the behaviour of /bin/sh on my linux machine.
Some programs explicitly call /bin/sh; and these programs will not work, no matter what my default script is.

So far as I can judge, the best solution would be to replace the present /bin/sh with an other sh version, if any, whose behaviour is closer to that usual on Linux. Are there different sh versions? (the one I have presently came with the FreeBSD release)?

let FAILED=$FAILED+1 is not valid sytax for sh, although it is valid syntax for bash

sh in most Linux distros is actually bash. sh is the bourne shell, bash is the bourne again shell. FreeBSD's sh really is sh.

If you haven't already, install bash2 via the ports system. Then change your scripts from #!/bin/sh to #!/usr/local/bin/bash If you want to change your login shell to bash, use chsh and change the /bin/sh line to /usr/local/bin/bash

Do NOT replace /bin/sh with a symlink to /usr/local/bin/bash. Don't do it. But you could place a symlink from /bin/bash to /usr/local/bin/bash if you really wanted to.

> let FAILED=$FAILED+1 is not valid syntax for sh, although it is valid syntax for bash

You may be right, but I have a program (anomy e-mail sanitizer), which has a shell with the following lines:

#!/bin/sh
.
.
let FAILED=$FAILED+1

The above works well on Linux, and fails on FreeBSD.
How could it work on Linux, if the "let..." syntax is invalid in sh? If it works on Linux, why does not work on FreeBSD?

Please re-read the following statement very carefully:

Try this on your Linux box if you still don't understand:

$ diff /bin/sh /bin/bash

Then try this on your FreeBSD box:

$ diff /bin/sh /usr/local/bin/bash

See?

I will try to summarize, please correct me if I am wrong:

1. I have to check any shells coming from Linux if it explicitly calls /bin/sh, and replace each occurance with /path/to/bash.

2. I will have no trouble with shells that do not explicitly call /bin/sh, since the default root shell is bash now.

But, just to be on the safe side, are there any tricky ways of explicitly calling /bin/sh that I cannot find with grep?

Re-compile bash

In theory, shell scripts that link to /bin/sh on Linux should work fine with FreeBSD's sh, because they should only use the features of sh and not bash's extensions.

Alex

I was advised once never to change root's shell to any shell that is not located in /bin/. In FreeBSD sh and csh are located in /bin/.

I think the reason for this has to do with emergency bootup situations where /usr/ is not mounted and shells in /usr/local/bin/ would not be available.

I am not positive about my accuracy on this issue. Can anyone in this forum confirm/deny this?

Thanks,

Andrew Gould

You were advised well. And yes, that is the primary reason why you should not do so. It is the same reason you shouldn't symlink /tmp to /var/tmp or some such.

However, you can put your shell of choice in /bin, assuming it is statically linked.

Install bash .Afther instalation it will be located in /usr/local/bin/bash and make a symlink to it
ln - s /usr/local/bin/bash /bin/bash.
That's all you need to make work the linux scripts.
if you want to change the shell chsh - s /bin/bash.
Good luck!

There is no need for a symbolic link. /usr/local/bin/ is in $PATH by default. If /usr/local/bin is in the same partition as /, then bash would be available during emergency boot up situations.

It is generally advised, however, that /usr/ be put in its own partition. If /usr/ is in its own partition and could not be mounted for some reason, the root user would not have access to it. In this case, the symbolic link would be useless.

Andrew Gould