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.
Related
Some of you are familiar with the adb install command.
Is there an equivalent of it in the terminal emulator?
Hi,
Adb is used from the computer and terminal emulator is used from the phone.
What are you trying to do?
I'm trying to install an app without using astro.
your best choise would be
cd to the location of the apk file and use
adb install appname.apk
or adb install C:\folder\appname.apk
think thats the correct way im not sure how you can install it in the terminal i knwowho to remove it.. but not install :/
Install .apk via Terminal EMulator
1) Place the .apk on the root of your SD card (for simplicity)
2) Type "su"
3) cd into the destination of your .apk (in this case it will be cd /sdcard)
4) Use "install "name of .apk" /"destination"/"name of .apk"
su
cd /sdcard
install com.makemobile.coursepro.apk /system/app/com.makemobile.coursepro.apk
further example:
install "space" com.makemobile.coursepro.apk "space" /system/app/com.makemobile.coursepro.apk
This will install the app on your phone using the Terminal Emulator. The destination location can change as well.
Additional help: http://www.busybox.net/downloads/BusyBox.html
On the flip side, could you uninstall from the ext2 partition this way?
install on/from ext2
not sure...I'll looks into this. I had my apps and data on my sd however, it seemed a little buggy and inconsistant. It may have been due to using original G1 1gb class 2 card.
-let me know if you find out first.
a1t said:
1) Place the .apk on the root of your SD card (for simplicity)
2) Type "su"
3) cd into the destination of your .apk (in this case it will be cd /sdcard)
4) Use "install "name of .apk" /"destination"/"name of .apk"
su
cd /sdcard
install com.makemobile.coursepro.apk /system/app/com.makemobile.coursepro.apk
further example:
install "space" com.makemobile.coursepro.apk "space" /system/app/com.makemobile.coursepro.apk
This will install the app on your phone using the Terminal Emulator. The destination location can change as well.
Additional help: http://www.busybox.net/downloads/BusyBox.html
Click to expand...
Click to collapse
nevermind..........used astro file manager and it worked fine
help
what's 'cd' ? the emulator is already installed on the phone ?
i'm trying to install an app but i don't understand the adb method. someone can help me ?
thanks
MikeMadden said:
what's 'cd' ? the emulator is already installed on the phone ?
i'm trying to install an app but i don't understand the adb method. someone can help me ?
thanks
Click to expand...
Click to collapse
cd is a command, meaning "change directory". Which is used to move your location on the system.
MikeMadden said:
what's 'cd' ? the emulator is already installed on the phone ?
Click to expand...
Click to collapse
cd is a *nix command , it is short for 'change directory' and it... changes directory
MikeMadden said:
i'm trying to install an app but i don't understand the adb method. someone can help me ?
thanks
Click to expand...
Click to collapse
it depends on what the app is
your best bet would be to get an app called 'Astro file manager' from the market
Its quite easy, so I won't go into further detail
Which to be honest is a fair trade
APrinceAmongMen said:
Some of you are familiar with the adb install command.
Is there an equivalent of it in the terminal emulator?
Click to expand...
Click to collapse
Some people have mentioned the `install' command from BusyBox, but this won't quite do what you probably want. To invoke the full Android package installation experience--the complete equivalent of `adb install'--you're looking for `pm install'. It takes the same arguments that `adb install' does, checks signatures, creates the appropriate user accounts, etc. so the package is installed the Android way. You can also use `pm uninstall' to remove a package (and as with `adb install', the "-k" option keeps its data around).
The `am' and `pm' commands are both underdocumented, but can be terribly useful. `am' can issue arbitrary Intents, including some Extra values. `pm' has other features not mentioned here, but which are shown in the help text.
olearyp said:
Some people have mentioned the `install' command from BusyBox, but this won't quite do what you probably want. To invoke the full Android package installation experience--the complete equivalent of `adb install'--you're looking for `pm install'. It takes the same arguments that `adb install' does, checks signatures, creates the appropriate user accounts, etc. so the package is installed the Android way. You can also use `pm uninstall' to remove a package (and as with `adb install', the "-k" option keeps its data around).
The `am' and `pm' commands are both underdocumented, but can be terribly useful. `am' can issue arbitrary Intents, including some Extra values. `pm' has other features not mentioned here, but which are shown in the help text.
Click to expand...
Click to collapse
'pm install' often fails with [INSTALL_FAILED_INSUFFICIENT_STORAGE]
which used to frustrate me no end ..
simple shell script
Code:
am start -a android.intent.action.VIEW -t application/vnd.android.package-archive -d file://$1
just pass the full path e.g
sh /sdcard/installapk.sh /sdcard/theapp.apk
and it pops up the Android Package installer
Firerat said:
'pm install' often fails with [INSTALL_FAILED_INSUFFICIENT_STORAGE]
which used to frustrate me no end ..
Click to expand...
Click to collapse
Interesting. I wonder if that's related to A2SD or a particular implementation, and pm getting confused as a result? Still, I like the idea of sending the VIEW intent to bring up the package installer. Good snippet.
I just cp the files to /system/sd/app/
from Windows Command prompt, and after switching to the folder containing the .apk file, type:
adb install filename.apk
if it is a reinstall:
adb install -r filename.apk
you could also push the file to the app folder. I use this method to push system apk:
adb remount <<<< you have to remount since you're going to mess with a sys folder
adb push filename.apk /system/app
seriously useful thread... especially after for some weird reason certain apps fail to install using the default Android installer. *cough* Radiant *cough*
Thanks for the help guys. Btw install command doesn't work. To clear things out for some clueless person like I am :
1. Open Terminal Emulator
2. Type -
su
cd /dir
pm install appname.apk
3. Done!
Example -
su
cd /sdcard
pm install AstroFileManager.apk
Hope that can help!
rajasyaitan said:
Thanks for the help guys. Btw install command doesn't work. To clear things out for some clueless person like I am :
1. Open Terminal Emulator
2. Type -
su
cd /dir
pm install appname.apk
3. Done!
Hope that can help!
Click to expand...
Click to collapse
This is very helpful, thanks!
rajasyaitan said:
Thanks for the help guys. Btw install command doesn't work. To clear things out for some clueless person like I am :
1. Open Terminal Emulator
2. Type -
su
cd /dir
pm install appname.apk
3. Done!
Example -
su
cd /sdcard
pm install AstroFileManager.apk
Hope that can help!
Click to expand...
Click to collapse
Thanks big time. Installed perfectly although apk won't open...just got to find one that will.
AS MENTIONED IN THE INTRODUCTION TEXT THIS HAS ONLY BEEN TESTED ON AMON RA ROM 1.6.2 BUT SHOULD REALLY WORK ON ANY ROM THAT HAS NO EXT2 AUTO-MOUNT. AND YEAH THIS WHOLE PROCESS HAS BEEN DONE ON A 32a BOARD. FOR THOSE THAT TRY THIS ON OTHER ROMS LET ME KNOW HOW IT GOES.
I've searched and shuffled through the entire forum and made inquiries to ROM authors without much light being shed on this issue. I doubt I am the only one who has been looking for a way of doing this so I decided to do a small HOW-TO. Here I will explain step by step as to how you can implement a script to be part of your ROM that will auto mount an ext2 partition on boot up if such partition is present. I have included all the tools I've used in order to pull this off, and as the title suggests this has only been done on Amon Ra's latest 1.6.2 ROM. In order to follow these instructions you are expected to allready have set up an adb enviroment on your linux box and for the signing process to work you must have sun-java present, the gnu java wont work. And of course a microSD card with an ext2 partition
1. Download install.sh to your home directory
Code:
wget http://www.grindhouse.no/androidtools/install.sh
chmod a+x install.sh
2. Now execute the install.sh script which will create a directory to work in and download a tool and script package and unpack it.
Code:
./install.sh
When the install.sh script is done you need to move the mkbootimg preferebly to your tools directory of your SDK.
Code:
mv toolstomove/mkbootimg <path/to/sdk/tools/mkbootimg>
3. Unpack the RA1.6.2 ROM into a directory in your home dir. In this HOW-TO we will use directory name "ra1.6.2" as an example through out the entire process.
4. Copy the boot.img from ra1.6.2 to the ROM-cooker dir
Code:
cp $HOME/ra1.6.2/boot.img $HOME/ROM-cooker/boot.img
cd $HOME/ROM-cooker
5. Use unpack.pl to extract the ramdisk from the boot image. I've modified the script a little so it automates the entire process and decompresses the ramdisk to a directory
Code:
./unpack boot.img
6. Now you can either replace the init.rc file here with the one I've included in this package or you can add these lines by yourself. In wich case do the following
Code:
cd boot.img-ramdisk
pico init.rc
Press CTRL+w and then CTRL+t and input 27. hit enter. This will take you to line 27 of init.rc so you can add a line right before the init process remounts the rootfs in read-only mode. Add following line:
Code:
mkdir /sdext2 0771 system system
Now scroll down to the end of the init.rc file and add the following:
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
7. You have now edited (or replaced) your init.rc file and prepared it to execute a script on boot that will detect an ext2 partition and boot it if there is one to be found. Now you have to make the mountsd script a part of the ROM. Do the following:
Code:
cd $HOME/ROM-cooker
mv toolstomove/mountsd $HOME/ra1.6.2/system/bin/mountsd
rm -rf toolstomove
8. Now that the init.rc file is sorted out and mountsd has been placed in /system/bin of the ROM so it is time to re-pack the boot.img:
Code:
cd $HOME/ROM-cooker
./repack boot.img-kernel boot.img-ramdisk boot.img
rm $HOME/ra1.6.2/boot.img
mv boot.img $HOME/ra1.6.2/boot.img
9. Your ROM now has a new boot image with an updated init.rc and the /system/bin dir has the script needed to auto-mount the microsd ext2. Now you must re-zip the ROM and sign it. Do the following:
Code:
cd $HOME/ra1.6.2
zip -r update.zip *
mv update.zip $HOME/ROM-cooker/update.zip
cd $HOME/ROM-cooker
./sign.pl update.zip
10. The ROM is now signed and you now have a file called update-signed.zip. Connect the phone to your computer and execute thus:
Code:
./push update-signed.zip
11. Now you are ready to flash the modified ROM which will auto-mount an ext2 partition on your microSD. There is no need to wipe before flashing. If you have no prior experience with ROM flashing or whatever just backup your current install. If you're using OpenHOME or anything similar, nothing will be changed or damaged but if you're using MontAlbert's themes with the ROM you will have to flash them again after flashing this modified ROM.
Code:
adb reboot recovery
12. Flash from choose zip and of course choose update-signed.zip. Reboot. After the system boots up again you can now check whats what with either one of the commands:
Code:
[email protected]:~$ adb shell mount | grep sdext2
/dev/block/mmcblk0p2 on /sdext2 type ext2 (rw,noatime,nodiratime,errors=continue)
[email protected]:~/boot$ adb shell busybox df -h | grep sdext2
/dev/block/mmcblk0p2 893.7M 13.0K 846.0M 0% /sdext2
13. Voila! Your RA 1.6.2 ROM now detects and mounts your microSD ext2 partition on boot. Woohoo?
I hope the HOW-TO was easy reading and that you have succeeded in hacking up your ROM. I know that certain ROMs have this as a built-in function but Amon Ra's does not. But since alot of people including myself use his ROM because of the high speed and stability I thought I should contribute to his project and add a cool (and missed?) function to it.
Mind you that you can use the ROM-cooker set to further adjust and hack up the ROM as you see fit. Happy learning!
Very nice!
Now the question many people will ask : why would you automount ext2 if you don't use apps2sd ?
I personally have ubuntu on my ext2 And besides this approach can be used for a number of things, people who have had the need, or wanted to experiment with init.rc doing things on boot, the mountsd script can easily be altered to do what ever needed.
For me its been a learning curve finding these things out, so by sharing it I may spare some people breaking their backs over this whole init.rc thing. people may want to modify init.rc for whatever reason, so I'm sure people wont have a problem finding a way of putting this to use, and its a subject that isnt all that covered on the forum .. and hey .. at least they get a rom kitchen out of the whole shabang
Very interesting! Thank you.
I used your unpack-program to unpack a recovery-image. It seems to work fine. What I am trying to do is change the state the recovery-image returns the phone to. Would it be possible to just replace your mountsd-script with, for example, a script that installs apps? Or is there a better way to do what Im trying to achieve?
Cheers,
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
sandis84 said:
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
Click to expand...
Click to collapse
That's indeed all you need to do.
Hi!
So I tried to create a signed update.zip, but it failed. It didnt create a "update-script"-file, so my device refused to install it. I wrote my own "update-script"-file, but then it complained "no digest" for the file. How do I solve this?
post the contents of your script people might see whats up
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
Says where its at in the first line : )
Code:
wget http://www.grindhouse.no/androidtools/install.sh
But now that I checked, I have to apologize, I see I have a missed payment with my hosting, I'll fix that within the day. Also sorry I havent been answering the few questions here I've been afk cause of surgery.
sitimber said:
post the contents of your script people might see whats up
Click to expand...
Click to collapse
well, I looked in another "update-script" file and found this:
assert compatible_with("0.2") == "true"
assert getprop("ro.product.device") == "dream" || getprop("ro.build.product") == "dream"
show_progress 0.5 0
write_radio_image PACKAGE:radio.img
show_progress 0.5 10
Click to expand...
Click to collapse
So I figured that nothing was essential other then the line "write_radio_image PACKAGE:radio.img". Also ofcourse I made sure it contained the name of my image-file instead of "radio.img". This gave me the "no digest" message, so now I feel unsure on how to create a working update.zip.
edit:
SOLVED! How silly of me. When you sign the update, a hash of each file is put in manifest.mf. Since I added the update-script after signing the file, ofcourse the digest(hash) was missing. Now everything works alot better and I can proceed... until I get stuck again
Cheers,
edit2:
Just to get a better understanding, what exactly does each line do here? Or where can I read about this?
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
edit3:
Ok, so I have experimentet, but I still dont manage to solve those last steps. I tried to edit init.rc and just add "mkdir /testdir 0000 system system" where the other directories were created. I then repacked it, zipped it, signed it, put it on my sdcard, started up a custom recovery, installed the update and rebooted. Everything seems to work fine. But when I start adb and check around, I dont see the "testdir"-directory. Also when I check in init.rc my line is gone. Do you guys have an idea of where I went wrong?
sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
it doesnot necesarily have to be linux ...you can also do it in windows using cygwin and dsxda's android rom kitchen
For a long time I have been running bash on my phone. However at some point you get tired of having to manually enter bash all the time from ssh, adb etc. Therefore I transferred my boot.img to my computer, changed the "console" line in init.rc to point at bash instead of sh and flashed it back to my phone. To my surprise this did not help. Neither adb nor ssh switched to bash by making this change.
I then created a symlink from bash to sh, but this does not work 100% as bash switches to sh mode when arg(0) = "sh", I don't like that.
So I made a script that calls bash and replaced sh with that. But for some reason this can make problems with you boot process some times.
This is where bind mounts come in.
By adding a small init.d script that bind mounts my bash calling script with the sh binary (yes bind mount also works for files), the boot process gets to use it's bellowed sh while I get to use bash as default from everywhere. Because the script is mounted to the sh binary (Not linked), a reboot will reset it back to to original file.
Now we just add /system/etc/bash.bashrc and place an alias from sh to bash so that the custom script is not called more than it has to. Also I have added the option to add a custom .bashrc in /mnt/sdcard/ that is called from /system/etc/bash.bashrc, and a /system/etc/debian_chroot file support for those of you that has a chroot system installed.
Why use bash?
Well you can add custom layout to your shell, create/change global variables which normally only can be done from init.rc, create aliases, execute custom scripts and so on to make your shell environment just the way you like it.
The update.zip contains a bash binary that looks for /etc/bash.bashrc, the bash call script to replace sh, a bash.bashrc file that creates the android missing user variables and more, and the init.d script that mounts the bash call script.
Requirements
init.d support
busybox
Download
Bash Route 1.0.0 (MD5: ebb539f5d07944ead77439b89e76f524) - bash_route-signed.zip
Sh is actually a symlink to mksh, so just delete it, and replace (not true for /sbin/sh, its linked to busybox)
From my fingers to your eyez
cdesai said:
Sh is actually a symlink to mksh, so just delete it, and replace (not true for /sbin/sh, its linked to busybox)
From my fingers to your eyez
Click to expand...
Click to collapse
It does not matter. The point is when someone/something makes a call to sh, bash switches to sh mode. It does not matter if you link bash to sh, mksh or copies bash to either two or whatever. You need to replace arg(0) with "bash" instead of "sh". The only way to do this is to make a script that answers the call and redirects that call to bash along with the message (the rest of the arguments). That way arg(0) will be replaced with "bash" and the bash shell will run it's regular mode instead of the "sh" mode.
dk_zero-cool said:
It does not matter. The point is when someone/something makes a call to sh, bash switches to sh mode. It does not matter if you link bash to sh, mksh or copies bash to either two or whatever. You need to replace arg(0) with "bash" instead of "sh". The only way to do this is to make a script that answers the call and redirects that call to bash along with the message (the rest of the arguments). That way arg(0) will be replaced with "bash" and the bash shell will run it's regular mode instead of the "sh" mode.
Click to expand...
Click to collapse
Necrobumping this thread for a few reasons.
1.) You have posted in the Android Software and Hacking General section. I was looking for something similar to this for GS3-LTE. Your updater script is specifically for MTD devices....like i9000 ICS or so on.
2.) There are mistakes in your script to install. unmount is not a linux busybox command. umount is though.
I will try out your idea. Thanks
You got this still? The zip has gone down.
Hi all, here is a package of command line tools I've put together, here's the readme with a few of the tools listed.
Android Command Line Tools
This Is Working Prefectly On Samsung Galaxy S3 'GT-I9305'
Your Phone Should Be Rooted To Perform These Steps!!!
Installation:
1. Copy The android-tools.zip To Your SD Card (Internal Or External) And Extract It
You Should Now Have A Directory Called 'android-tools'.
2. Open A Terminal On Your Phone And Type The Following
su
mkdir /data/tmp
cat /sdcard/android-tools/busybox > /data/tmp/busybox
cat /sdcard/android-tools/busybox-installer > /data/tmp/busybox-installer
cat /sdcard/android-tools/pkgs.tar > /data/tmp/pkgs.tar
cat /sdcard/android-tools/install.sh > /data/tmp/install.sh
cd /data/tmp
chmod 755 *
./install.sh
3. In Android Terminal Emulator Preferences, Set The Shell Path to '/system/bin/bash'
And Leave The Initial Command Blank.
4. Quit Terminal Emulator And Restart.
OpenSSH: ssh-keygen Save To '/data/local/home/root/.ssh/id_rsa'.
'ssh' And 'scp' Binaries Will Look For Keys In '/data/local/home/root/.ssh/'
So You Dont Need The '-i' Option, 'ssh-copy-id' Gets It From There Too.
Arduino:
There Is A Build Environment To Build And Upload Arduino Sketches With A Script Called 'arduino' To Wrap It Up
Type 'arduino --help' In Terminal To See Its Options, It Uses The Arduino-1.0 Core Library And I have Tested
Every Board And Can Confirm It Builds For All Boards Including 'micro' And 'leonardo'. It Uses 'avrdude'
'avr-libc-1.6.7' 'gcc-avr-4.5.1', I Wrote A 'arduino.nanorc' File For Writing Sketches Which Has All The
Functions And Constants Of The Arduino Core Library With The Same Colours As In The IDE.
Other Tools:
Some Other Binaries I Have Added Or Modified Are 'tar' With All Options Enabled, 'iwconfig', 'grep egrep fgrep'
With Colour And PCRE Enabled, '7zip', 'ipctool', 'shc' For Compiling Shell Scripts, 'ssh-copy-id', 'sed' With All Options
Enabled, 'macchanger', 'bootimg_baseaddr' In bash/sh, Compiled GNU 'core-utils', 'ncurses-hexedit', 'nmap', 'ngrep', 'nano'
'strace', 'gcc', 'g++', 'unpack-bootimg' In bash, 'unrar' And 'vim'.
Backtrack 5 ARM Is Configured And Ready To Go, Just 'mkdir /sdcard/Chroot'
And Copy Your bt5.img File Into It And Type 'bootbt', Then Edit The Scripts
For VNC Server 'startvnc' And 'stopvnc' To Reflect Your Screen Size, These
Are In The pkgs.tar
Replacing '/system/etc/mkshrc' With The One Included In This Package Enables Bash As Default In ADB Shell
If The Bash Binary Is Found In '/system/bin/bash' Else The Default Shell Will Drop Back To mksh.
Nano Does Not Save Through ADB Shell Using ^O Or '^X Then y' Method, Works Fine In Terminal Emulator App On Device.
There are more tools than listed above, here's the link> https://www.dropbox.com/s/yjumfljy7e1yoyc/android-tools.zip
If you're on an custom ROM and can't use the terminal emulator when you restart terminal emulator, get /system/lib/libncurses.so from stock ROM and use adb to copy it into /system/lib on your current ROM, I will fix this tomorrow.
Sent from my GT-I9305 using xda app-developers app
Please post the right link... this one is malformed.
sciurius said:
Please post the right link... this one is malformed.
Click to expand...
Click to collapse
op just updated the link, package is now ready for download again!
thank you, andreotti09!!!
greetz,
sUsH
*****************************************************************************************************************************************************
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 !!!