Related
i want to alias ls='ls --color=always'. is there something like a .bashrc file for busybox sh?
bilclintonsdaman said:
i want to alias ls='ls --color=always'. is there something like a .bashrc file for busybox sh?
Click to expand...
Click to collapse
Just had a look at the busybox source and it says it uses the contents of environment variable ENV as a startup script so you could do
Code:
ENV=/system/sd/.bashrc ash
and it'll read /system/sd/.bashrc for your startup commands. Altrernatively, if you invoke it as a login shell (ash -l), it'll source /etc/profile then .profile from the current directory so if you create /system/sd/.profile to contain alias ls='ls --color=always' then as long as you do this
Code:
cd /system/sd
ash -l
you'll have your alias (I just tried this with JF1.51 and it worked great).
I also saw that it will record command history to the file named in HISTFILE so you may want to make your startup script look like this
Code:
alias ls='ls --color=always'
HISTFILE=/system/sd/.histfile
Also, keep in mind that this isn't bash -- you need to use ash shell scripting semantics.
Sweet! Thanks so much
~/.PROFILE
if you edit (may need to create it first) the .profile file in your home directory you shouldn't have an issue
i have the following in my ~/.profile file:
Code:
alias dir='ls -Alp'
alias cls='clear'
The next time you log in, you'll have your alias's
pre-compiled gnu bash
I can't remember where I found it, however, if you know enough to set it up, I have a pre-compiled gnu bash 3.2 file that allows you to execute something like this:
su -c '/path/to/bash --rcfile /path/to/.bashrc'
in the terminal emulator and you'll execute a bash shell with the .bashrc
I attached the pre-compiled gnu bash 3.2 in a zip file on the post, good luck getting it running! google is your friend!
I also compiled bash 4.0 for myself to use, but its kind of buggy since it was actually one of the first binaries that i've ever compiled on linux but it works! its just really slow >.>
I followed this tutorial to compile it
http://www.kbrandt.com/category/bash
Hi All,
The Ash shell provides a few advantages over the Android default sh shell such as command history and cursor handling at the prompt. There are other benefits, but these are the first that come in most handy (to me).
The following tutorial will get you ash as the login shell with as yet no ill effects:
Note: that in my case, I'm using my android2sd construct and thus this modification is being done to my active overlay profile setup, thus to undo it I can simply boot into "safe\\normal" mode and undo the changes without possibly locking me out of the console should it have failed (which it didn't) But you can edit the Android /system/bin/sh file in this manner directly.
Ash as Login Shell:
OK, make the /system fs read-write:
mount -o remount,rw /system
Click to expand...
Click to collapse
Note: that the fs type is not needed, and in my case is not yaffs but ext3, Android will figure it out proper.
Next,
cp -a /system/bin/sh /system/bin/sh0
Click to expand...
Click to collapse
(this is for backup purposes and allows us to undo the change if so desired, or delete it if no longer needed).
Note: I'm using JF1.51 roms, so busybox ash is available as /system/xbin/bb/ash, so that is what I am using here; use ash however you are able to access it.
echo "#!/system/xbin/bb/ash">/system/bin/sh
echo "/system/xbin/bb/ash \[email protected]">>/system/bin/sh
Click to expand...
Click to collapse
Please note the use of (redirect\\overwrite)> and (redirect\\append)>>.
This will overwrite sh with a script to load the desired shell, executing any command-line arguments passed, and preserve the permissions of the original sh file. You can manually set the permissions the same as they are for our sh0 backup if the permissions (root.shell)(0755) don't seem to keep.
Finally reset the read-only state of /system:
mount -o remount,ro /system
Click to expand...
Click to collapse
Now if you shell-in\\telnet-in you should get the ash prompt which unlike the Android sh default prompt, includes the present working directory(pwd) ie: '/#' instead of just '#'.
Note: A reboot should not cause the loss of the modification, but if does, copy the new sh script to your /data/local/bin location or something and copy it back via boot script or something.
Shell Scripts:
If you're like me, you discovered that Android didn't need the interpreter declaration comment in scripts, and thus may not have used them...Well, you will need to update your scripts to include them by adding something similar to the following as the first line of your scripts:
#!/system/xbin/bb/ash
Click to expand...
Click to collapse
Again, please note that I am using JF1.51 roms and the location of the busybox ash shell is what I'm listing; put the full location to the shell you intend to use as this location.
Without the interpreter declaration, ash simply complains 'not found' at the first command, as ash doesn't know how to interpret the script, and doesn't seem to default to the login shell.
Hope someone finds this helpful!
sweet. This is going to be very useful
BAM. thats sexy. i just did this on CM3.6.7.1. works like a charm.
scratches head. i'm lost. what does this do and how does this make my g1 better?
temporizer said:
scratches head. i'm lost. what does this do and how does this make my g1 better?
Click to expand...
Click to collapse
im not sure about the other features, but the one i installed it for is to have your working directory in front of ur prompt. ex:
Code:
/# cd /sdcard
/sdcard # cd /system/sd
/system/sd #
etc...
EDIT: Also, if you use ConnectBot, you'll notice with the regular sh, if u scroll up with tracball, you get BS characters on the prompt. with THIS one, when you scroll up, you get last command entered. VERY handy for when you mistype one character on a long-ass command.
I love you
Couldn't you do this?
Code:
mv /system/bin/sh /system/bin/sh0
ln -s /system/xbin/bb/ash /system/bin/sh
great job, i'm going to get ash working on my G1 (CM-3.6.7.1)
Thanks.
kanstin said:
Couldn't you do this?
Code:
mv /system/bin/sh /system/bin/sh0
ln -s /system/xbin/bb/ash /system/bin/sh
Click to expand...
Click to collapse
I tried this and it worked even after a reboot...
Sweet, I love the scroll back with trackball in the terminal!!! Me thinks this should get absorbed into the next Cyan release.
kanstin said:
Couldn't you do this?
Code:
mv /system/bin/sh /system/bin/sh0
ln -s /system/xbin/bb/ash /system/bin/sh
Click to expand...
Click to collapse
Yes, I reckon you could. Though I had done a few experiments where the symlink failed, but I'm fairly sure it was do to the link: /system/xbin/bb/ash -->../busybox and /system/bin/../busybox not existing...so I did it via script. Many ways to skin a cat they say.
Thank you all... this is fricken awesome!!
temporizer said:
scratches head. i'm lost. what does this do and how does this make my g1 better?
Click to expand...
Click to collapse
It gives a more advanced shell for when you use the command line interface or telnet into your G1. If you don't use the command line a lot, it won't help you.
As for specific benefits to the advanced version, it was listed in the first post.
Hi,
imho this is rather a hack that exposes you to the risk at least on CM to loose your
shell during boot as xbin.sqf the compressed squashfs filesystem containing
busybox is mounted rather late in the boot process. A cleaner solution would be to
move busybox to system/bin and link it to sh. That way you ensure that sh will
always be accessible during boot and also later on, thus not interfering with
further developments. A alternative could be to compile a standalone version
of busybox containing only ash (for size reasons, as size in /system/bin is precious)
copy that to /system/bin and link sh to it.
Seems to work fine on Dude's. Not really sure how it should open, but I type "ash" at the prompt and I get the /$ and /# if superuser. I also get the command history by rolling the trackball, which is a very nice feature.
Can i install this without using my PC?
temporizer said:
Can i install this without using my PC?
Click to expand...
Click to collapse
Should work using terminal.
Tried it on JACHero 2.7.1
I tried the hard link one and I get a read only fs error on the first move command. What should I chmod to get past that?
mugafuga said:
I tried the hard link one and I get a read only fs error on the first move command. What should I chmod to get past that?
Click to expand...
Click to collapse
Do this first before the mv and the symlink.
mount -o remount,rw /system
farmatito said:
Hi,
imho this is rather a hack that exposes you to the risk at least on CM to loose your
shell during boot as xbin.sqf the compressed squashfs filesystem containing
busybox is mounted rather late in the boot process. A cleaner solution would be to
move busybox to system/bin and link it to sh. That way you ensure that sh will
always be accessible during boot and also later on, thus not interfering with
further developments. A alternative could be to compile a standalone version
of busybox containing only ash (for size reasons, as size in /system/bin is precious)
copy that to /system/bin and link sh to it.
Click to expand...
Click to collapse
Is this in any way accurate? I dedicate my g1 to cyan's roms and wouldn't want anything to hinder any of the goodness that is cyanogenMod. Advice?
Load ash when terminal is started?
temporizer said:
Is this in any way accurate? I dedicate my g1 to cyan's roms and wouldn't want anything to hinder any of the goodness that is cyanogenMod. Advice?
Click to expand...
Click to collapse
Safest method will be to change to ash shell once terminal app is started (same as typing "ash" to switch shell from sh to ash). I don't know how to do it in android (in linux you could add it to your login script).
So if someone knows how to execute a command when we login using the terminal app, then switching to ash shell would work without fear of breaking any other functionality.
First off, all credit goes to nubecoder. Original post:
[Bash] android_bash: Bash, cross-compiled and modified for the android platform.
Introduction...
Most (All) modern Linux distributions utilize bash (Bourne Again SHell) rather than sh (Bourne SHell). Android, by default uses sh. Bash has numerous advantages over sh, sush as tab completion and history support.
Some ROM developers include bash in their ROMs by default. It makes adb, terminal, and scripted commands much easier and more powerful/flexible. I noticed that Sidekick 4G ROMs don't come with bash, hence this thread.
How to Install BASH...
Simpy flash this zip through Clockworkmod recovery: (if ORANGE, check mounts. Not sure if neccessary, but it doesn't hurt)
android_bash-4.1.11(2)_installer-SK4G.zip
Then load your preffered terminal emulator application, type bash, press enter, and there you go.
What's the difference between the SK4G version, and the original Epic 4G version?
- Modified device/product check in updater-script to "SGH-T839"
- Modified $PATH variable in /data/local/.profile to "/sbin:/system/bin:/system/xbin:/data/local/tmp:/bin"
- Modified $PATH variable in /system/etc/bash.bashrc to "/sbin:/system/bin:/system/xbin:/data/local/tmp:/bin"
- [Personal preference] Add alias su='su -c bash' to /data/local/.bash_aliases
- [Personal preference] Modified $PS1 to PS1="\[$txtgrn\]\w $ \[\e[m\]"
- [Personal preference] Modified root $PS1 to PS1="\[$txtred\]\w # \[\e[m\]"
- [Personal preference] Modified location of .bash_history from /sdcard/.bash_history to /data/local/.bash_history
Click to expand...
Click to collapse
As any experienced bash user should know, if you want to revert/modify my personal preferences, just modify "/data/local/.bashrc", "/data/local/.bash_aliases", or "/system/etc/bash.bashrc" to your liking.
Extras...
mntsystem Make /system partition read-only or read-write. Usage:
# mntsystem [ro|rw|status]
Unzip mntsystem.zip, copy mntsystem to /system/bin, chmod 744 /system/bin/mntsystem
Click to expand...
Click to collapse
defaultshell Replace sh with bash, or revert. Usage:
# defaultshell [bash|sh|current]
Unzip defaultshell.zip, copy defaultshell to /system/bin, chmod 744 /system/bin/defaultshell
Click to expand...
Click to collapse
More extras (bash scripts) to come! Please post you own as well!!
PS: I was confused on where I should post this (General vs. Development), figured it isn't "technically" ROM related, so I posted in General. Please move if necessary. Thanks.
mntsystem extra added!
Awesome
Oh man, I have been missing BASH so much, thank you! Now I will finally have a fully-functioning terminal on my phone. I can't wait to tab-complete (seriously).
One question about installation, though. I'm supposed to "install zip from sdcard" in CWM, correct? Will this replace anything I already have, or just copy over the files for BASH? Does it leave sh as the default shell?
nteleky said:
I'm supposed to "install zip from sdcard" in CWM, correct? Will this replace anything I already have, or just copy over the files for BASH? Does it leave sh as the default shell?
Click to expand...
Click to collapse
Yes, flash through Clockworkmod. And, no it will not replace any files already on your phone (unless you already have bash, or some bash configuration files on your phone). Yes, it will leave sh as the default shell.
I can make a bash script to "replace" sh with bash, and post in the Extras if you want. When I say "replace", I mean backup /system/bin/sh, then symlink bash to /system/bin/sh. Therefore any time you try to execute a script through sh, it actually is executed by bash.
Although, for your information bash is/should-be fully backwards compatible with any sh script. I say should be, because:
Bash (Unix shell) - Wikipedia said:
The vast majority of Bourne shell scripts can be executed by Bash without modification, with the exception of Bourne shell scripts stumbling into fringe syntax behavior interpreted differently in Bash or attempting to run a system command matching a newer Bash builtin, etc.
Click to expand...
Click to collapse
Very rare chance though.
I personally keep sh as the default though, android system level scripts are designed for sh (its works), I just use bash for any script that I decide run (through a shell, or adb). So, I start connectbot with a profile that runs "/system/bin/bash" automatically at start.
New extra!
defaultshell Replace sh with bash, or revert. Usage:
# defaultshell [bash|sh|current]
Unzip defaultshell.zip, copy defaultshell to /system/bin, chmod 744 /system/bin/defaultshell
Click to expand...
Click to collapse
Hey
I'm a noob and I'm curious if this could run on my galaxy s 2 running stock?
The bash binary (with supporting files) should work on any rooted android device, however the flashable zip file I posted WILL ONLY WORK on the sidekick 4g.
If you want to install bash, you can download the flashable zip, extract it and copy the the files to their correct location (Quick, easy solution), or you can modify the update-script to work with your phone. Be sure the mounts are the same! Then alter the device check. (More difficult at first, but results in easily reuseable and distributable, flashable zip)
Sent from my SGH-T839 using XDA App
hey after I go to the emulator and type bash.. what should it read?
Sent from my SGH-T839 using XDA App
Should be a green prompt that reads:
/ #
If you cd to, for example, to /sdcard, then the prompt will read:
/sdcard #
If you enter su, then the prompt will become red and use a $ instead of #.
If your prompt says sh-4.1 # then you invoked bash as sh, ie you symlinked (or renamed) bash to sh (usually /system/bin/sh).
Sent from my SGH-T839 using XDA App
well when i enter bash this comes up... 0localhost:// $
and the last two are green ..
What terminal emulator are you using?
Sent from my SGH-T839 using XDA App
The free one.. lol. Idle I just typed emulator and that's the first one in the list ..
Sent from my SGH-T839 using XDA App
I'm not sure why its doing that. Although, all it means is that bash is being accessed from localhost, aka from the phone itself (not an outside source). It doesn't mean anything is wrong.
If it bothers you, you can use connectbot (free on the market, also includes an ssh client) instead. Just create a profile and make sure its local. Then it will work as expected.
Sent from my SGH-T839 using XDA App
Ok. Thanks .. ill let u know if it works
Sent from my SGH-T839 using XDA App
Well it work. Lol.. thank you
Sent from my SGH-T839 using XDA App
bc54 said:
The bash binary (with supporting files) should work on any rooted android device, however the flashable zip file I posted WILL ONLY WORK on the sidekick 4g.
If you want to install bash, you can download the flashable zip, extract it and copy the the files to their correct location (Quick, easy solution), or you can modify the update-script to work with your phone. Be sure the mounts are the same! Then alter the device check. (More difficult at first, but results in easily reuseable and distributable, flashable zip)
Sent from my SGH-T839 using XDA App
Click to expand...
Click to collapse
I tried doing this for my Droid 3, by changing updater-script file to the values I get from my terminal emulator, like so:
Code:
assert(getprop("ro.product.device") == "cdma_solana" || getprop("ro.build.product") == "solana_vzw");
But CWM tells me it fails because "(bad)". Do you have to somehow change the update-binary file as well?
no i didnt change the update-binary file.
however i think the source of you problem is the "/dev/" names the sidekick uses for its partitions.
for example the sidekick "/dev/" name for the partition mounted to "/system" is "/dev/block/stl9"
the droid 3 most likely uses a different "/dev" naming scheme.
find out the "/dev/" name for "/system" on the droid 3.
in the update-script file, replace "/dev/blocl/stl9" with the corresponding name for the droid 3.
find out the "/dev/" name for the "/data" partition on the droid 3.
in the update-script file, replace "/dev/blocl/stl10" with the corresponding name for the droid 3.
then rezip it, and flash. if that fails, then you could just manually copy the files to their respective location using adb, a terminal emulator app, or even a file manager.
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?
I suspect it's hardcoded. For example, the following can be found in adb's service.c:
Code:
#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.
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.
garyd9 said:
I suspect it's hardcoded. For example, the following can be found in adb's service.c:
Code:
#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.
Click to expand...
Click to collapse
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?
Jarmezrocks said:
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?
Click to expand...
Click to collapse
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.
Droidzone said:
coloured shell output in ls
Click to expand...
Click to collapse
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
qwerty12 said:
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
Click to expand...
Click to collapse
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?
Click to expand...
Click to collapse
Yup.
*****************************************************************************************************************************************************
Credit for discovering this method goes to Sr. Staff gurus @_that (bet you could have guessed) and @becomingx for parsing GNU code to figure out file naming limitations (no dots!) to make this work.
******************************************************************************************************************************************************
This short Guide accompanies the need to run my B2R startup script (or any script) as root at boot. If you are rooted and have busybox installed on a stock ROM or any ROM that does not have init.d support thru init.rc, here's how you can add it. This is an alternative method to either using Script Manager (SManager) or hijacking the install-recovery.sh file directly to run a startup script. Enabling this support allows you to be able to run all executable scripts located in init.d as root at boot.
IMPORTANT: Your init script name can NEITHER have any dots in the filename NOR use an extension. Name it something like autostart or start-up or init_script. Also when you write a script, NEVER forget to start it with the hash-bang-path to shell (#!/system/bin/sh) and NEVER forget to press ENTER after the last character of the last line of code. You can't just use any simple text editor to create the file - you must pay close attention to "line ends". I use ES Note Editor on device and Notepad++ configured for UNIX/OSX line ends on PC. Always save the file AS PLAIN TEXT. Read "Additional Information" below on line ends.
[NOTE: /system/etc = /etc (symlink)]
1. Mount your /system rw
Code:
mount -o remount,rw /system
2. Make directory /system/etc/init.d
Code:
mkdir /system/etc/init.d
3. Create a shell script (using a text editor with UNIX line ends [LF only] ) named "/system/etc/install-recovery.sh" with the following contents:
Code:
#!/system/bin/sh
/system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
4. Put your init script in init.d and remember to make both /system/etc/install-recovery.sh and your script in /system/etc/init.d executable.
Code:
cd /system/etc
chmod 755 install-recovery.sh
cd /system/etc/init.d
chmod 755 name_of_your_init_script
5. Immediately reboot or if not, mount your /system ro
Code:
mount -o remount,ro /system
If you have busybox installed in /system/xbin this enables support for running init.d scripts from ROMs that do not offer native support thru init.rc.
Additional Information:
Every file has what are know as line ends or more technically end of line (EOL) conversions. These are HIDDEN characters that you normally don't see (if the line end are in the native OS format) at the end of lines in a text editor when editing files. This is the character that tells the OS where one line stops and the next starts in any file. In order to see the line ends you must enable "show all characters".
Your text editor must support UNIX line ends (LF only, not CR + LF = CRLF). Do NOT use Windows Notepad as it only creates Windows line ends (CRLF).
Always use UNIX line ends - a Windows editor like Notepad will create CRLF line ends, while your shell script MUST use LF line ends or it will fail to execute. Otherwise your first line will look like this to Linux:
Code:
#!/system/bin/sh^M
The ^M above is the common convention to display the control character Ctrl+M, which is CR (carriage return) before the LF (line feed) or (CRLF). The consequence is that the system can't find your shell under the name "sh^M" (or any subsequent command "some_command^M") and your script will fail.
This is VERY important to understand and also how to configure any cross-platform text editor. Using notepad++ in Windows without changing the default settings still results in CRLF at the end of lines because it knows its running in Windows and thinks you want Windows line ends. In order to change this behavior, Under the Edit menu find EOL conversion, and select Unix/OSX format. Also toggle the paragraph symbol on the top bar (backwards P with double verticles; show all characters) and now its clear as day what line ends you have, where they are, and if you have one after the end of the last line or not. Now its WYSIWYG. Once these setting are toggled, saving the file in Windows results in Unix/OSX line ends (LF) and when you open notepad++ the next time the settings are retained. See screenshot before attachment at the end of this post.
Example for changing default EOL conversion to Unix LF for an older version of notepad++:
http://techtips-it.blogspot.com/2011/04/can-i-convert-file-format-in-notepad.html
If done correctly, the output you will see if VIEWED (not edited) using Windows notepad will show a small hollow rectangle representing each LF. You will see one for each line end, and two together at the end of the last line itself - the first is the EOL LF for that line, and the subsequent is the LF you entered after the last line. If notepad just shows what you would normally see in the XDA code block with no extra special characters as described, you have Windows line ends and your script will fail to execute.
If you have multiple scripts to run at boot, the real purpose of init.d, you should name your init scripts prepended with two digits between 00 and 99. (Fairly) Evenly divide the range into 3 groups like 2# (20-29), 5# (50-59), and 8# (80-89). Scripts in the 20 series will be run first, followed by 50 series scripts, ending with 80 series scripts. They will be executed from lowest number to highest number, in that order. This allows you to define the load order for a group of init scripts. We didn't use 00-19 or 90-99 in case we need to put a future script before the first or after the last one without having to rename the rest of the scripts to do so.
Example init script names: 20firststart, 50mid_start, 80end-boot
******************************************************************************************************************************************************
Download the attachment and remove the txt extension and copy it into /system/etc and make sure it is executable. Make directory /system/etc/init.d, put your executable boot scripts in there, and reboot to run your executable init.d scripts as root.
This method replaces the depreciated method of directly hijacking install-recovery.sh with a single boot script run as root. Why have only one when you can have many?
Linkback to dev thread
http://forum.xda-developers.com/showthread.php?t=2191777
Reserved
Sent from my LG-LS970 using xda app-developers app
elfaure said:
@_that, please review and bless.
Click to expand...
Click to collapse
elfaure said:
IMPORTANT: Your init script name can NEITHER have any dots in the filename NOR use an extension. Name it something like autostart or start-up or init_script.
Click to expand...
Click to collapse
I still recommend using the common Unix convention of 2 digits + lowercase name for init.d scripts, e.g. 50something, 60dothislater, 90somethingtodolast. The numbers allow for clearly defining the order in which multiple startup scripts are executed.
elfaure said:
Also when you write a script, NEVER forget to start it with the hash-bang-path to shell (#!/system/bin/sh) and NEVER forget to press ENTER after the last character of the last line of code. You can use any simple text editor to create the file. I use ES Note Editor on device and Notepad++ on PC. Always save the file AS PLAIN TEXT.
Click to expand...
Click to collapse
And always use UNIX line ends - a Windows editor like Notepad will create CRLF line ends, while your shell script MUST use LF line ends. Otherwise your first line will look like this to Linux:
Code:
#!/system/bin/sh^M
The ^M above is the common convention to display the control character Ctrl+M, which is CR (carriage return) before the LF (line feed). The consequence is that the system can't find your shell under the name "sh^M" and your script will fail.
elfaure said:
4. Remember to make it executable and to create the /system/etc/init.d directory.
Click to expand...
Click to collapse
You already created init.d in step 1.
Looks like it could work like this. If you want to be sure, remove your existing scripts and rmdir your init.d directory, then follow your own guide and see if everything is OK. Then you can bless it yourself. In software development, peer review is always good, but testing is even more important.
_that said:
I still recommend using the common Unix convention of 2 digits + lowercase name for init.d scripts, e.g. 50something, 60dothislater, 90somethingtodolast. The numbers allow for clearly defining the order in which multiple startup scripts are executed.
And always use UNIX line ends - a Windows editor like Notepad will create CRLF line ends, while your shell script MUST use LF line ends. Otherwise your first line will look like this to Linux:
Code:
#!/system/bin/sh^M
The ^M above is the common convention to display the control character Ctrl+M, which is CR (carriage return) before the LF (line feed). The consequence is that the system can't find your shell under the name "sh^M" and your script will fail.
You already created init.d in step 1.
Looks like it could work like this. If you want to be sure, remove your existing scripts and rmdir your init.d directory, then follow your own guide and see if everything is OK. Then you can bless it yourself. In software development, peer review is always good, but testing is even more important.
Click to expand...
Click to collapse
Thanks for the review! I will make some edits, test drive the guide, and bless it myself. I was already going to add the two digit numerical discussion. I'm not trying to get you to do any extra or my work here, God knows you are a very busy multi-tasking hundreds of tasks , I just thought I was on newb patrol after posting a non-working script and then mandated to your must review list.
Is this method works on other phone too?
I really do want the init.d support on stock rom
Sorry for my bad English...
Sent from my HTC Desire 200 using XDA Premium 4 Mobile app
dicks93277 said:
Is this method works on other phone too?
I really do want the init.d support on stock rom
Click to expand...
Click to collapse
The method is reasonably generic that it is worth trying on your device.
so sad that i can't make this work on my phone
but still thanks for your reply @_that
Awesome it works on my Panasonic T41 running MIUI 5 beta
Could you tell how to do the same thing from init.rc ???
and also one script is not working
Code:
#!/system/bin/sh
su
mount -o rw,remount /
mkdir -p /rex
mount -o bind /data/data/com.spartacusrex.spartacuside/files/system /rex
mount -o rw,remount /system
mkdir -p /system/vendor/bin
mount -o /rex/bin /system/vendor/bin
Is there any thing wrong with it ?? I used unix terminators and also set the permissions to 755
uttarayan21 said:
Awesome it works on my Panasonic T41 running MIUI 5 beta
Could you tell how to do the same thing from init.rc ???
and also one script is not working
Code:
#!/system/bin/sh
su
mount -o rw,remount /
mkdir -p /rex
mount -o bind /data/data/com.spartacusrex.spartacuside/files/system /rex
mount -o rw,remount /system
mkdir -p /system/vendor/bin
mount -o /rex/bin /system/vendor/bin
Is there any thing wrong with it ?? I used unix terminators and also set the permissions to 755
Click to expand...
Click to collapse
The 'su' command with no arguments starts an interactive shell, everything after 'su' waits for the user to exit that shell, which you can't do. Init.rc and subsequent scripts are run as root anyway, including init.d scripts, so just delete the 'su' line and it should work.
Sent from my LGL41C using Tapatalk
Kor1134 said:
The 'su' command with no arguments starts an interactive shell, everything after 'su' waits for the user to exit that shell, which you can't do. Init.rc and subsequent scripts are run as root anyway, including init.d scripts, so just delete the 'su' line and it should work.
Sent from my LGL41C using Tapatalk
Click to expand...
Click to collapse
Thanks !!! It worked !!!!
uttarayan21 said:
Thanks !!! It worked !!!!
Click to expand...
Click to collapse
You're welcome [emoji6]
Sent from my LGL41C using Tapatalk
Why don't use service from init.rc ??
elfaure said:
*************************************,
3. Create a shell script (using a text editor with UNIX line ends [LF only] ) named "/system/etc/install-recovery.sh" with the following contents:
Code:
#!/system/bin/sh
/system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
Click to expand...
Click to collapse
But it is better to add a service to init.rc and launch sysinit from there for init.d support !!!
Maybe you should update your guide with that !!!
:laugh: :good:
uttarayan21 said:
But it is better to add a service to init.rc and launch sysinit from there for init.d support !!!
Maybe you should update your guide with that !!!
:laugh: :good:
Click to expand...
Click to collapse
Changing init.rc requires repacking the boot image.
_that said:
Changing init.rc requires repacking the boot image.
Click to expand...
Click to collapse
Yeah it does but if you install SuperSU then the install-recovery.sh file will be modified and init.d will be lost !!!