no sh shell (POSIX bourne shell /bin/sh)

[drozdowsky]

I have installed oksh and I made it my default shell but when I run /bin/sh I expect shell to be POSIX bourne shell aka sh but oksh is started.
It seems like oksh replaced /bin/sh (it is not a symlink, its a binary) in my system (by pkg or by my mistake) - how to repair this? Or sh always points to default shell? I want my /bin/sh to be sh(1)

selfluv:/bin $ ls -al /bin | grep sh
-r-xr-xr-x   2 root  wheel  429104  7 gru  2018 csh*
lrwxr-xr-x   1 root  wheel      19 29 cze 20:30 oksh@ -> /usr/local/bin/oksh
-r-xr-xr-x   1 root  wheel  168936  7 gru  2018 sh*
-r-xr-xr-x   2 root  wheel  429104  7 gru  2018 tcsh*

selfluv:/usr/local/bin $ ls -al /usr/local/bin | grep oksh
-r-xr-xr-x   1 root  wheel   289808  7 lip 19:04 oksh*    # binary size does not match with sh

 

[SirDice]

It seems like oksh replaced /bin/sh (it is not a symlink, its a binary) in my system (by pkg or by my mistake)

No package or port would ever do this (not allowed).

Or sh always points to default shell?

The shell is set for the user, in the user's properties. There's no such thing as a "default" shell actually. You can pick a standard shell for new users in /etc/addusers.conf for example, but I wouldn't call that a "default", it's just a standard choice. The short story is, /bin/sh is sh(1), no setting will ever change that. The only way to change that would be to do a custom build(7).

how to repair this?

It depends on what you did. What does ls -l /bin/sh tell you?

 

[moridin]

but oksh is started

How exactly did you check that?

 

[ralphbsz]

The output from ls -l is actually above. Judging by the size of the binaries in /bin, they are most likely the x86-64 versions of /bin/sh and /bin/tcsh (likely, they are a few hundred bytes different from my 11.3 system, but I don't know what version the OP is running). And the binary for oksh is distinctly different.

If you run /bin/sh, you SHALL (<- pun!) get the standard shell. I would try doing that, and then looking at two things: the output of "echo $SHELL", and compare the output of "echo $$" with the list from "ps auxww" and see what executable is really running.
UPDATE: SEE BELOW.

By the way, who created the symlink in /bin for oksh? Is that a good or a bad thing? I always thought that adding links to /usr/local/... in the standard directories is bad, because it confuses the clear distinction between base system and optional packages/ports. But maybe that's wrong.

 

[_martin]

As SirDice mentioned no package can do this so this was changed by somebody else.

Or sh always points to default shell?

No, your (user's) default (login) shell has nothing to do with the contents of /bin.
I could imagine somebody wanted to have/bin/oksh so created a symlink. There's nothing wrong with that when admin knowns what he's doing.

but when I run /bin/sh

Does it mean that when you literally do /bin/sh korn shell is launched instead of posix one?
I don't know if you are the admin or not, but if some sneaky trolling admin wanted to cause some headaches he/she could have defined function /bin/sh() that would execute korn shell. But probably not. Do check it with set command if something alike is defined.

To sort out some weird behavior you could jump from one shell to other to see if the behavior is still the same.

 

[badbrain]

You should install bash and change your default shell to bash. Log out and log in again, open /bin/sh, then check what echo $SHELL reports. If it return plain sh then everything is fine. If it's not, check your dot file, if needed move them to a backup dir and log out and log in again and check again. I think you are in your own so I don't think it's someone trolling.

 

[SirDice]

Check the system's /etc/profile and user's ~/.profile too. I've seen people start alternative shells from there.

 

[drozdowsky]

You should install bash and change your default shell to bash. Log out and log in again, open /bin/sh, then check what echo $SHELL reports. If it return plain sh then everything is fine. If it's not, check your dot file, if needed move them to a backup dir and log out and log in again and check again. I think you are in your own so I don't think it's someone trolling.

So I am in oksh and start `sh` some shell starts (I think I could be wrong and it really is proper /bin/sh) BUT `echo $SHELL` still is oksh, the same with tcsh, $SHELL does not change.

selfluv:~ $ /bin/sh        # PS1 from .kshrc
selfluv:/home/self $ echo $SHELL
/usr/local/bin/oksh
selfluv:/home/self $  # different PS1 like in .shrc

I think the issue is not that sh is not started but that $SHELL is not changed

 

[SirDice]

start `sh` some shell starts (I think I could be wrong and it really is proper /bin/sh)

Make sure it's not an alias, start it using the full path; /bin/sh.

Check your shell startup scripts; ~/.profile, ~/.shrc and ~/.cshrc.

 

[gpw928]

I think the issue is not that sh is not started but that $SHELL is not changed

$SHELL is an environment variable (like PS1 and many others). It is set by specific assignment. Starting another shell, or any other executable program, will not generally change it.

The advice from SirDice is good.

 

[ralphbsz]

The shell /bin/sh does *NOT* set the environment variable $SHELL. So if you first start another shell (like bash, perhaps like oksh or tcsh, haven't tested those), then start /bin/sh from that outer shell, then you are still seeing the $SHELL variable that was set by bash. So checking that variable is pointless. Sorry for suggesting that above, I've updated my post above.

Instead, do this: "echo $$", followed by "ps auxww | grep nnn", where nnn is the process ID you get from "echo $$". That will tell you which shell you are really running.

By the way, anyone who switches to a different shell in .profile or /etc/profile needs to be hit with sticks, or at least tickled with feathers. That's just deliberate obfuscation, and making the system complex and unreliable. Bad idea.