Switching default shell

[Droidzone]

Having cross compiled an arm bash, I wanted to get rid of the limited ash shell. While trying to switch sh to bash, I've turned all the ramdisk scripts inside out, grepping the hell out of them, switching things like services and init scripts. But apparenty nothing I did switched the default shell.

I've even found the PS1 var in /system/etc/mkshrc and tried changing the shell there.

But I'm still missing the actual location where it gets set. Short of swapping out the file, replacing it with a bash softlink, I cant think of anything else. Does anyone know where the shell gets set?

 

[garyd9]

I suspect it's hardcoded. For example, the following can be found in adb's service.c:

#if ADB_HOST
#define SHELL_COMMAND "/bin/sh"
#define ALTERNATE_SHELL_COMMAND ""
#else
#define SHELL_COMMAND "/system/bin/sh"
#define ALTERNATE_SHELL_COMMAND "/sbin/sh"
#endif

On most android systems, /system/bin/sh is the shell run when the system is booted, and that's usually a symbolic link to /system/bin/mksh. So, perhaps just change the symlink to point to something else.

 

[Droidzone]

Isnt that the code for adb's default shell? I dont mind adb having ash as default, since one can easily exec 'adb shell bash' and start with bash.

On the Desire, the bootup shell had kernel level binaries in /sbin/sh. The system shell could be easily switched.

 

[Jarmezrocks]

I suspect it's hardcoded. For example, the following can be found in adb's service.c:

#if ADB_HOST
#define SHELL_COMMAND "/bin/sh"
#define ALTERNATE_SHELL_COMMAND ""
#else
#define SHELL_COMMAND "/system/bin/sh"
#define ALTERNATE_SHELL_COMMAND "/sbin/sh"
#endif

On most android systems, /system/bin/sh is the shell run when the system is booted, and that's usually a symbolic link to /system/bin/mksh. So, perhaps just change the symlink to point to something else.

How dependent is the ROM on the existing shell? I attempted to (I just created a new ROM to flash with these changes) to just remove the mksh and replace it with bash. Naturally (and as I was expecting) this did not work.

Here is what I think. You are right, but also wrong.
My thoughts are that that mksh is hard coded like you have said but the symbolic link is the other way around, mksh(parent) is symlinked to sh(child). sh without the symbolic link doesn't exist.
Replacing mksh with bash causes complete catastrophic failure ROM does not boot and all hell breaks loose. Reflash back to previous LOL. That being said, symlinking bash binary to sh also doesn't work, because the system is reading from hardcode mksh first and foremost and then sh beyond that.
replacing the mksh with bash and renaming bash to mksh also doesn't work (in an attempt to satisfy the existence of a required system file)

Apart from rebuilding the entire ROM from sources with everything patched to utilise the bash shell, I can't see this being an achievable goal.

May I ask why you want to specificially utilise the bash shell over sh? I know that this is much closer to native linux and it probably has some functionality benefits and syntax serendipities (no I am not trying to be funny - I am just stupid and cannot think of the right wording to use right now so that will do).....but is there something that you are trying to do within the sh shell environment that you cannot do that you know you can do with bash?

 

[Droidzone]

May I ask why you want to specificially utilise the bash shell over sh? I know that this is much closer to native linux and it probably has some functionality benefits and syntax serendipities (no I am not trying to be funny - I am just stupid and cannot think of the right wording to use right now so that will do).....but is there something that you are trying to do within the sh shell environment that you cannot do that you know you can do with bash?

Apart from the obvious advantages of bash completion, coloured shell output in ls, grep and others, and the init scripts?

ash interpretation of shell scripts is a bit different from bash. Try nesting more than two levels of loops, and it makes it jargon.

 

[qwerty12]

coloured shell output in ls

That's got absolutely nothing to do with the shell. ls is not a shell built-in. Install BusyBox and alias ls to 'busybox ls --color=auto' in mkshrc, just like CM's bashrc does.

Same with grep, except BusyBox does not provide a colour option for its grep, so I guess that's out.

As for init.d scripts: just change the scripts' shebangs to use bash? Ubuntu has dash as its default /bin/sh as it's able to run init.d scripts (provided that they don't have bashisms) quicker than bash would.

Sent from my GT-I9300 using Tapatalk 2

 

[Droidzone]

That's got absolutely nothing to do with the shell. ls is not a shell built-in. Install BusyBox and alias ls to 'busybox ls --color=auto' in mkshrc, just like CM's bashrc does.

Same with grep, except BusyBox does not provide a colour option for its grep, so I guess that's out.


Sent from my GT-I9300 using Tapatalk 2

dircolors needs an initialization script, and .bashrc was the easiest way I could find (short of using ramdisk scripts).

As per the manpages, dircolors has two formats-one for bourne and another for csh. So you need either of these as default shell to init .dircolors. If you dont need customization, it doesnt matter.

As for init.d scripts: just change the scripts' shebangs to use bash?

Yup.