What OS are you using? Don't fiddle with 'sh' unless you absolutely *have* to. A broken sh can render a system unbootable.
That said, if you just have the binaries, you can take a copy of the existing sh and overwrite with your new shell. If you are compiling from source, the taking copy bit still applies.
I'm using HP-UX.
The process i followed was as follows:
1: kill all the instance of "sh" except one.
2: # bash
3: copy the new sh <new_sh> to /bin/ directory
# cp /mydir/<newsh> /bin/
# mv /bin/<newsh> /bin/sh
4: then rename the sh in /sbin directory to something else. let it be <sh_old>
# mv /sbin/sh_old /sbin/sh_veryold
# cp /mydir/<newsh> /sbin/
# mv /sbin/newsh /sbin/sh
5: Logout from the machine.
now even though there is a "sh" in /sbin/ and in /bin, the machine getty could not find these new binaries and failed to open a session for the user.
let me know if there is a better work around for this.
and how can i find the version of "sh" on HP-ux machine.(for linux it is # sh --version)
For linux, it is actually bash and not sh. sh is a link to bash.
Also, what error did it give? Just "gave an error" does absolutely nothing toward describing the actual error.
Another thing, you cannot just replace /sbin/sh with the same binary as /bin/sh. They are two very different things. The /sbin/sh binary is statically linked (it uses no external libraries). This is helpful if your /usr partition ever gets corrupted and cannot be mounted during boot. If your /sbin/sh is also dynamically linked, if /usr does not mount, you are, in effect, screwed.
So, know what you are doing before you replace sh with your own binary. Remember that sh is used by the system rc scripts during boot. Your new sh better do all that the old one did.
Why, exactly, are you trying to do this? I'm wondering if you are just trying to do something in a dangerous way that can easily be done some other way, e.g. creating an alias, upgrading sh, creating symbolic links, etc.