[guide] Hacking the startup sequence to run your own code - Android General

I have been trying to customise my MTK phones with a pre-defined user experience, with sepcific settings etc.
Perhaps one way to achieve this is to check if the device has been facory reset, then use a script to insert specific settings once. For this I need to launch a script early in the boot sequence.
This could be achieved by dismantling the boot.img, altering the init.rc, then re-building, which requires significant work and risks bricking the device. So I looked for a way to run a script without significant re-flashing. here goes:
xlog changes the system log level, and is called just a few times at boot-up. Xlog is run early, and as root, with the parameter boot.
This script renames xlog as xlogboot, introduces a script in place of xlog, which runs another script, startup.sh when xlog is called with parameter boot. All the original parameters are passed to the renamed xlog binary, so the system functionality should not be changed.
I pushed the script to the device, then run it as root. I can now edit /system/bin/startup.sh to run whatever initialisation commands I wish. I have so far tested on a ZTE v965 .
Code:
#!/system/bin/sh
#This script creates a hook into the bootup system of Android
#This hook operates when /system/bin/xlog is called with
#the first parameter 'boot'
#Use this script entirely at your own risk. I highly recommend
#you ensure YOU have a backup of YOUR device before going further
#Public Domain Nick Hill 2014
if [ -e /system/bin/xlogboot ] || [ -e /system/bin/startup.sh ]; then
echo "This script may have already been run, exiting.."
exit 1
fi
if [ ! -e /system/bin/xlog ]
then
echo "This script is not running in an expected environment. Exiting.."
exit 2
fi
if [ $USER != "root" ]
then
echo "This script must be run as root. try running su. Exiting.."
exit 3
fi
touch /system/bin/atestfile
if [ ! -e /system/bin/atestfile ]
then
echo "It appears system folder is not mounted read-write. Remounting..."
mount -o remount,rw /system
else
rm /system/bin/atestfile
fi
echo -e '#!/system/bin/sh\n' > /system/bin/startup.sh
chown root:root /system/bin/startup.sh
chmod 755 /system/bin/startup.sh
mv /system/bin/xlog /system/bin/xlogboot
echo -e '#!/system/bin/sh\n/system/bin/xlogboot $*\nif [ "$1" == "boot" ] \nthen\n/system/bin/startup.sh\nfi\n' >/system/bin/xlog
chown root:shell /system/bin/xlog
chmod 755 /system/bin/xlog
Enjoy!

Make your own custom rom
Problem: You have an android device which you want to give/sell in USA or England. The device has come with an array of auto-starting chinese pop-ups, horrible wallpaper, and a Chinese clock applet. You uninstall all those system apps, replace your widgets with nice English ones. The phone when factory reset, starts in Chinese. Returns the user to tacky wallpaper, and you have lost the nice theming and widgets you have painstakingly installed and set up in the system folder.
Solution: This backup script. I have tested it on a v965, it also appears the file system would be OK on an A766 and many other android devices.
Instructions:
Use my previous script on this thread to create a hacked startup sequence. You must already have the /system/bin/startup.sh in place.
Unpack the tarball
Check the script lists the files you intend to back up. You will need to edit the script for that. I have set it to preserve settings for language, launcher, the 3D clock app factory.widgets.ThreeDDigitalWeatherClock-1.apk , which I think is really cool, wallpaper and the ADB mode.
Copy the install.sh and busybox to a writable directory on your android device.
su (go to root)
In a shell, cd to the directory where you uploaded the files.
sh install.sh
This will create a directory /system/perm-config
When you have the device as you would like it,
cd /system/perm-config
./make-backup.sh
This will ceate a directory tree in /system/perm-config/data folder, containing the backups of specific app data.
If all goes well, next time the phone is factory reset, the defaults are reloaded.
You could then re-flash the system partition of devices, perform a factory reset to take the device to your own defaults. You can use the last script (to hack the startup sequence), and this script to make your own custom ROMs. The script should do it's job even after un-rooting a device.
As usual, use at your own risk. I take no responsibility if your phone bricks, explodes, turns to antimatter, suddenly drops into a parallel dimension or starts receiving calls from the future.

Related

Possible [How To] Moving all caches to SD?

Hi i have rooted successfully recently and was wondering how to move my caches to the SDcard, i have search around and stumble upon these 2 script that completely relocate anything with a cache to the SDcard.
Being a total noob with unix command, i can't be sure how perfect these commands are and was wondering if anyone can improve upon it, or notice if there is any problem in applying it?
Lastly, i was wondering if there is a method to activate the code easily then typing it all out?
I have done some searches but none or no one commented on how useful or practical these commands are?
Some of the searches brought me to multiple threads, and i was wondering if my suggestion would make it easier for people to look for it later on.
Again thanks in advance, i don't mind being the first to try any of these commands but wanted a error check first to see the feasibility of such codes.
Thanks to the coders who prepared the 2 code below.
daeglo said:
What it does (allegedly):
Searches /data/data for any file containing the string 'cache' which is not already a simlink.
Moves files to the supplied new cache directory.
Creates simlinks in place of the old files to the new files.
What you need to do:
Save the attached file (recache.zip)
Extract the two shell files (recache, relocate)
Examine the files to be certain I am not malicious/stupid (the latter is quite possible)
Push the files to a directory in the default path on your phone (/system/xbin works for me)
Make the files executable (chmod 555 /system/xbin/{recache,relocate})
Run the command: recache <new_cache_directory>
Synopsis
recache <new_cache_directory>
Moves all files matching /data/data/*/*cache* to new_cache_directory and creates a symlink from the old location of the file.
new_cache_directory - optional - defaults to '/sdcard/cache'
relocate file new_directory
Moves the named file to new directory, encoding the original path in the new file name and creates a symlink from the original file location.
file - required - the file to move
new_directory - required - the directory to move the file to.
edit: emphasized the need to examine the files -- I make no claim of fitness or usefulness of this script for any reason. Many eyes make deep cracks small. If anybody sees a problem with my script, post the problem and PM me about it.
Click to expand...
Click to collapse
Fnorder said:
This one should catch everything that uses 'webviewCache' - provided it's already created it's cache directory. It also has a configurable list for those that hog space in other ways.
Code:
#!/system/xbin/bb/ash
TARGET="/sdcard/cache"
CACHE="
/data/data/com.imeem.gynoid/cache
/data/data/com.google.android.street/cache
/data/data/com.android.vending/cache
/data/data/com.android.browser/app_thumbnails
/data/data/*/cache/webviewCache
"
sdtotal=0;mmctotal=0;successtotal=0;failtotal=0
if [ ! -d "$TARGET" ]; then
mkdir $TARGET
fi
for i in $CACHE; do
local odir=$(echo "$i"|sed s,^/data/data/,,)
local app=$(echo "$odir"|cut -d / -f1)
if [ -d "$i" ]; then
if [ ! -L "$i" ]; then
let mmctotal++
echo -e "$app:\n\t* Moving '$odir'..."
mkdir -p "$TARGET/$odir"
if [ ! -d "$TARGET/$odir" ]; then
echo -e "\t- Error creating directory: $TARGET/$odir"
let failtotal++
else
rm -r "$i"
ln -s "$TARGET/$odir" "$i"
if [ -L "$i" ]; then
echo -e "\t+ Success"
let successtotal++
else
echo -e "\t- Failure! Please investigate $i"
let failtotal++
fi
fi
else
let sdtotal++
fi
fi
done
echo "Matched cache dirs: $sdtotal symlinked, $mmctotal on mmc.";
if [ "$sdtotal" ]; then
echo "Successful moves: $successtotal, Failures: $failtotal"
fi
Click to expand...
Click to collapse
No one willing to look at the codes?
if you are asking on how to use that code there..
1. needs to be saved with an .sh extention eg: recache.sh and located at /usr/local/bin or you can just leave it in the root and esecute it with ./recache path/to/where/u/want/it eg: /sdcard/cache
2. need to give ti permisions.. chmod 555 recache.sh
if thats what u are looking to know?
Nitro212 said:
if you are asking on how to use that code there..
1. needs to be saved with an .sh extention eg: recache.sh and located at /usr/local/bin or you can just leave it in the root and esecute it with ./recache path/to/where/u/want/it eg: /sdcard/cache
2. need to give ti permisions.. chmod 555 recache.sh
if thats what u are looking to know?
Click to expand...
Click to collapse
No actually i was wondering if the codes are correct, and both says they do the same thing however the codes seems different. Was wondering which one should i run, and is the code correct.
Since i am a noob in Linux, i can't be sure what is happening.
I have been looking around and every other cache to sdcard method, are limited to certain programs, the code quoted by me earlier finds any cache and put it into Sdcard automatically, however other then wondering if the codes is correct, i was wondering if there is any possible drawback? And if possible, is there a method so that i can easily clear my caches too?
So my request to sum it up would be :
1)Is the code correct, and will it run?
2)Which of the 2 code is practical?
3)Anydrawback when i transfer all known cache? (Since settings to have cahce right?)
4)Last but not least, a code to clear the caches on my SDcard?
naTTan said:
No actually i was wondering if the codes are correct, and both says they do the same thing however the codes seems different. Was wondering which one should i run, and is the code correct.
Since i am a noob in Linux, i can't be sure what is happening.
I have been looking around and every other cache to sdcard method, are limited to certain programs, the code quoted by me earlier finds any cache and put it into Sdcard automatically, however other then wondering if the codes is correct, i was wondering if there is any possible drawback? And if possible, is there a method so that i can easily clear my caches too?
So my request to sum it up would be :
1)Is the code correct, and will it run?
2)Which of the 2 code is practical?
3)Anydrawback when i transfer all known cache? (Since settings to have cahce right?)
4)Last but not least, a code to clear the caches on my SDcard?
Click to expand...
Click to collapse
basically he created a repeating loop for cache .. the line you are interested in is the first part:
CACHE="
/data/data/com.imeem.gynoid/cache
/data/data/com.google.android.street/cache
/data/data/com.android.vending/cache
/data/data/com.android.browser/app_thumbnails
/data/data/*/cache/webviewCache
"
these are the only cache files at which he's looking .. now the /*/ would potentially mean all programs using /cache/webviewCache under their folder would also be moved .. there are other script and method out there that do the same thing
me personally .. i would change the target to /system/sd/cache and put them on the EXT2 partition .. it also appears he is deleting the existing cache and starting over .. i have a script that copies the existing cache before creating the link
bottom line .. should work ok
Thx for your help but one uses webview cahce while the other uses cahce alone in their command any significant difference?
There are other scripts? Mine linking me? If it not too much of a trouble?
Thanks again for all your help/.

Preferences Ownership issues?

I have been using JF 1.43 for a few months and loved it. Seeing that Cupcake became mainstream, I took the plunge two days ago and have been having issues. I tried JF 1.51, then a mod, then theDudes, all with some problems. I tried wiping and keeping apps in regular memory just for testing. I finally got a clean install using TheDudesCupcake which worked ok for me. When I pushed my preferences back using adb, it just hung on the "android" screen.
I was getting annoyed at myself for not understanding what was going on . The confounding problem was that the set of prefs that I was restoring had adb disabled, so I couldn't get a logcat to see what was really happening.
Long story shorter...
After some more fresh installs, I think what I have sorted out is that all of my preferences files lost their correct ownership. I found that when I had a program that was crashing, I would log in to an adb shell, use ps to see what user the app was running as, for example app_82. Then, I would chown app_82.app_82 for the directory within /data/data. I would then to it recursively since busybox doesn't have -R for chown by issuing the command chown app_82.app_82 /data/data/com.android.weather/cupcake/* and then chown app_82.app_82 /data/data/com.android.weather
It fixes programs that were having problems accessing their sqlite3 DBs which was the clue in the logs that led me to this solution.
As I am going through I see that it improves the performance and error rate of programs by doing this. Obviously core functionality doesn't have the same ease of repair.
Is this the wrong thing to do here? Is there a better way to restore files after an upgrade so that this doesn't happen again?
I saw that someone wrote a python script to fix these permissions, though I don't understand where they got python to run on Android in the first place. Is there a shell script that can parse an app's uid and fix its supplemental files accordingly?
I tried searching, but may not have used good keywords about this issue.
Any help/advice/info would be appreciated.
The answer
This guy has a python scirpt that nicely spits out a shell script to fix all of them
http://blog.elsdoerfer.name/2009/05/25/android-fix-package-uid-mismatches/
Code:
"""Parse Android's /data/system/packages.xml file and spits out
shell code to fix UIDs.
This helps you fix "Package x.y.z has mismatched uid: 10089 on disk, 10079
in settings" errors.
"""
from xml.dom import minidom
xmldoc = minidom.parse('packages.xml')
packages = xmldoc.getElementsByTagName('package')
ignored = []
for package in packages:
try:
userId = package.attributes['userId'].value
is_shared = False
except KeyError:
userId = package.attributes['sharedUserId'].value
is_shared = True
# do not touch permissions of shared apks (they userid always seems to be 1000)
if not is_shared:
print "busybox chown %s:%s %s" % (userId, userId, package.attributes['codePath'].value)
for subdir in ('', 'databases', 'shared_prefs'): # note we don't touch lib/
print "busybox chown %s %s:%s /data/data/%s/%s" % (
'-R' if subdir else '', userId, userId, package.attributes['name'].value, subdir)
Essentially, you can use adb pull to pull /data/system/packages.xml locally, run this python script on it, and then send each command back. One way to do this on *NIX is
Code:
adb pull /data/system/packages.xml . ; python fix.txt | xargs adb shell

[SCRIPT] Android-Linux Tools v0.2 for Linux [[Suggestions Needed]]

Okay. If this is not where the MODs want this post, please move it.
[UPDATE] - Jump over to Post #12 for some of my recent ideas and changes for this application.
I have been using mods for the G1 and the myTouch 3G for a little while now. I have used Backup for Root, and I use Nandroid. I created just a little simple script to backup your device to your linux-based machine and restore from there too. The concept behind this is having your backup on your computer, not your sd-card. Please, feel free to contribute. (If this is not your cup of tea, please do not leave a comment). I am limited on time, and wanted to contribute a little to the community. All this script is a compilation of adb commands. Anyone could compile these commands, I just wanted it organized and in one place.
README
After using all of the backup tools for root, I have ran into random FCs and bugs. This script uses Android SDK's adb tool and was designed to be simple. This script goes through and backs up your applications, bookmarks, sms, alarm clocks, settings, launcher settings and dictionary. There are plans for this script to be interactive in the future. As for now, it is a very basic script that will backup your device then restore your device.
Notes. As for now this script requires sudo. On every other linux pc tested, sudo was required (maybe because user did not install adb correctly?). This will change in future versions.
= Details =
REQUIREMENTS
1. Android SDK Toolkit 1.5 or higher
2. Bash v4.0.33
3. Root access to your device
4. Root access to your pc
HOWTO
Backing-Up
1. Plug your device in
2. Open command-line (On PC)
3. Run ./abrtool -b
4. Done.
Restoring
1. Reboot from flash of rom (Enter credentials and let phone setup first)
2. Open command-line (on PC)
3. Run ./abrtool -r
4. Restart device
5. Done
Changelog
Version 0.1.5
- Merged into Android-Linux-Tools (alt)
- Changed zenity commands (shows restore progress)
- Option to restart device after restore
- Can install abrtool via command-line (./abrtool --install)
Version 0.1.4
- Added Icons
- Runs Fix Permissions after restoration of applications
Version 0.1.3
- Fixed Restore (Again) - Sets $BACKUPDIR as $PATH
Version 0.1.2
- Restore applications now uses adb install instead of push
Version 0.1.1
- Fixed Restore arugement (-r restores now)
Version 0.1
- Created initial script
- Creates backups for Apps, Sms, Bookmarks, Alarms, Settings, User Dictionary, and Launcher
- Restores device
Download
Project Page for Android-Linux-Tools (ALT) http://code.google.com/p/android-linux-tools
Project Page for abrtool http://code.google.com/p/abrtool
Download abrtool ConvertVideoToAndroid
Download InstallOnAndroid Nautilus Script
InstallOnAndroid
Disclaimer
I am not responsible for anything. Anything at all. I'm just not. Blame someone else if something goes horribly wrong.
[Reserved]
[Reserved for future post]
Nice script but bart.sh can accomplish a full backup of your Android environment for restoration at a later date. While it does it to the SD card initially, these "barts" can easily be copied to any computer. I can, however, see a use for this as it serves a slightly different purpose. Thanks.
I wasn't sure what response I would get to this post. I have had to flash, partition, format, wipe.. enough times that I just wanted to plugin into my computer, backup, wipe-flash then restore. Thanks!
nice. I don't use linux myself, but i see the point of having the backup else where (not an SD card attached to the phone itself).
will this, in theory be made to work on windows? Cause that will be awesome.
@str4vag It would be really simple to just use a .bat file for Windows. I don't have any plans on making a windows script anytime soon. Sorry. Same commands especially though.
This is exactly what I've been looking for, now I just need to mod it to sync apps/bookmarks/etc automatically whenever I plug in my phone, and to only sync the new items to keep it speedy, great work dev!
@ggolemg I can play around with some "real" features soon. I plan on having it archive your backups and allow you to select which backup (default is most recent) you would like to use. I am sure I can play around with your idea too. Thanks.
subscribing to the thread, idea is very interesting. i've been looking for a foolproof way to backup and restore bookmarks, sms messages, and different alarms, without all the issues of backup for root users. gonna check out the script tonight.
Update coming by the end of the week.
- Will only backup apps not already backed up.
- Possibly apply the Python interface I have developed.
- More goodies.
How about switchrom?
Android-Linux-Tools
Okay, so this week has been crazy for me. (Mind you I am a restaurant manager first and a developer (primary web) second). I think I am going to gear this project in a different direction. First off, I have created GTK2 Dialogs and a settings panel for this application. I would like to gear towards general linux tools on the pc side. So over the next two weeks you can expect,
- Graphical Interface for abrtool (Android-Backup-Restore)
- Configuration for each application.
- Nautilus Scripts for all applications.
- Right-Click to Encode Video (With GTK2 Dialog progress)
- Right-Click to Install APK (With GTK2 Dialog progress)
- Right-Click to Sign APK (With GTK2 Dialog progress)
- Right-Click to Copy Files to SD Card
- abrtool will backup to Ubuntu One Cloud (Simple adb pull ~/Ubuntu\ One/? or maybe play with the API?)
Ideas and Possibilities
- User.conf editor
- Select with applications to backup
- Switchrom features?
Any other thoughts or suggestions are welcome. I want to start simple, keep working on the abrtool and then make my way out to some other useful tools for us linux (Ubuntu) users. Let me know what you think and what would be helpful.
i had to make a bynch of edits so this dosent run as root, id recomend everyone do the same, only run root when you must. Also changed ,.adb to adb so i dont have to run it in my android sdk dir
@ahronzombi Can you post those changes?
I am a firm believer of only running root when needed, Like I mentioned before I don't really have a huge amount of time, and when I tested this on a friends notebook adb required root to atleast kill-server then you could perform shell/push/pull.
AFAIK, adb server only requires root if ou haven't set the proper udev rules for the device.
Exactly. If we want this script to run universally we cannot rely on all users to have added the udev rules. If they don't they have to run sudo. Maybe a quick check for the udev file then sudo if not?
boulderjams said:
Exactly. If we want this script to run universally we cannot rely on all users to have added the udev rules. If they don't they have to run sudo. Maybe a quick check for the udev file then sudo if not?
Click to expand...
Click to collapse
no i think it would be wise to have people understand there udev permissions rather than run root so its universal. that kind of thinking leads to very big security problems. with root in the script most of the simplest linux users could exploit anyone
I fully understand that. Do you mind posting your changes to the script?
this is the secure version of the script that dosent run as root
keep in mind i set my own adb and home directorys so you'll have to change those
Code:
#! /bin/bash
# abrtool version 0.1
# Last Updated Wednesday, November 18, 2009
# Android Backup Data and Restore Data Script
#TODO
# 1- See if config file exists
# 2- If not, create config file (for now, select directory to backup to)
# 3- See if arguments are specified
# 4- If not, return an error via dialog
# 5- If argument -b exists, run backup
# 6- If argument -r exsists, run restore
export PATH=${PATH}:/home/ahron/android/android-sdk-linux/tools:/home/ahron/android/abr
BACKUPDIR=/home/ahron/android/backups
USER=${username-`whoami`}
backupscript() {
export PATH=$PATH:$BACKUPDIR
adb kill-server
adb pull /system/sd/app $BACKUPDIR/apps
adb pull /system/app $BACKUPDIR/apps/device
echo "---------- Backed Applications"
adb pull /data/data/com.android.providers.telephony/databases/mmssms.db $BACKUPDIR/msgs/mmssms.db
echo "---------- Backed Text Messages"
adb pull /data/data/com.android.browser/databases/browser.db $BACKUPDIR/bookmarks/browser.db
echo "---------- Backed Bookmarks"
adb pull /data/data/com.android.alarmclock/databases/alarms.db $BACKUPDIR/other/alarms.db
adb pull /data/data/com.google.android.providers.settings/databases/googlesettings.db $BACKUPDIR/other/googlesettings.db
adb pull /data/data/com.android.launcher/databases/launcher.db $BACKUPDIR/other/launcher.db
adb pull /data/data/com.android.providers.userdictionary/databases/user_dict.db $BACKUPDIR/other/user_dict.db
echo "---------- Backed Other Settings"
chown -R $USER $BACKUPDIR
zenity --info --text "Successfully Backed-up to $BACKUPDIR"
}
restorescript() {
export PATH=$PATH:$BACKUPDIR
adb kill-server
#sudo adb push $BACKUPDIR/apps /system/sd/app
echo "----------- Installing Applications"
cd $BACKUPDIR/apps
for searchfile in ./*.apk
do
echo "------------ Processing $searchfile"
sudo adb install "$searchfile"
done
echo "---------- Restored Applications"
adb shell su
adb shell fix_permissions
echo "---------- Fixed Application Permissions"
adb push $BACKUPDIR/msgs/mmssms.db /data/data/com.android.providers.telephony/databases/mmssms.db
echo "---------- Restored Messages"
adb push $BACKUPDIR/bookmarks/browser.db /data/data/com.android.browser/databases/browser.db
echo "---------- Restored Bookmarks"
echo "---------- (Please, make sure to restart your browser)"
adb push $BACKUPDIR/other/alarms.db /data/data/com.android.alarmclock/databases/alarms.db
adb push $BACKUPDIR/other/googlesettings.db /data/data/com.google.android.providers.settings/databases/googlesettings.db
adb push $BACKUPDIR/other/launcher.db adb pull /data/data/com.android.launcher/databases/launcher.db
adb push $BACKUPDIR/other/user_dict.db /data/data/com.android.providers.userdictionary/databases/user_dict.db
echo "---------- Restored Other Settings"
zenity --info --text "Successfully Restored Android device from $BACKUPDIR"
}
if [ "$#" -eq 0 ]
then
echo "Usage $0"
echo " -b Backup"
echo " -r Restore"
exit $E_OPTERR
fi
set -- `getopt "br:" "[email protected]"`
while [ ! -z "$1" ]
do
case "$1" in
-b) backupscript;;
-r) restorescript;;
esac
shift
done

[DEV][SCRIPT] First-Boot App Install

First-Boot Install System​
I have searched Far and wide for something like this since i first put out SleeperROM in November and always come up empty.
So with the latest release, i decided it was finally time to do it myself.
All you have to do is, using the following package as a template either on its own or in your ROM, make sure your batch folder with the .apk's to install are in /data/.firstboot/
Why
Some apps like QuickPic, ConnectBot, TinyFlashlight, Flash, Google Goggles and others that rely on linked libs don't like to simply be copied to their install dir because many won't install their own libs unless the PackageManager does it and/or they won't add themselves to the packages list (like QuickPic). The old solution is to include the lib either in the /data/data/appdir/lib with the rom install OR in /system/lib but this is quite wasteful especially in the case of big apps like Flash where including the libs separately from the app effectively doubles the space taken up on the rom by that single app since the apk still contains the lib files within.
So the solution is to install on first boot by including the apps in a batch folder for the script to process.
How it works
What it does is run from the init scripts, as one of the last scripts to run, it waits until the Android core system is up (checks to be sure by waiting for the SystemUI process is running then waits for an additional 10 seconds)
Then runs /data/.firstboot.sh, which is where you should put your first boot routines. Included in this script is the batch app installer which looks for the apps in /data/.firstboot/ and stores temporary app backups in /cache/tmp -- so be mindful that on MTD roms, the cache partition is smaller so may have to modify the $tmp variable to wherever you want to store temporaries
After installing, it sleeps for a proportional number of seconds (5 seconds per app installed) to ensure there is no race condition between installs or the final permissions_fix, zipalign and tmp cleanup. The /data/.firstboot.sh script removes itself when everything is complete.
The remaining components are kept in there for additional use by the /etc/init.d/Y02firstboot script in the future, so then all that needs to be put on the phone is a new /data/.firstboot/ dir and replacement /data/.firstboot.sh to run a batch of updates.
The Apps MUST be named by their package name.
I.e. Titanium Backup MUST be named com.keramidas.TitaniumBackup.apk
the file name must correspond with the name of the data dir in /data/data/ the script is lazy in that way, i didn't feel like keeping a file manifest of installs, instead just like to drop in apps to install.
The installer
consists of the following components:
- /system/etc/init.d/Y02firstboot
- /system/xbin/rsync
- /system/xbin/fix_permissions
- /system/xbin/batch_zipalign
- /system/xbin/sleeperlog (echos, logcats, and writes a log of activity to /sdcard/sleeperlog.txt)
- /data/.firstboot.sh
- /data/.firstboot/ (batch app directory)
- NOT INCLUDED, there must be a busybox bin somewhere in $PATH - this is not a problem for most roms
See the package link for a ready to use first-boot installer [CWM] flashable. Just drop your apks into /fs/data/.firstboot/ for a batch app updater
Download the template/usable package
DOWNLOAD MOD_CWM-FirstBoot-20120112.zip
File size: 341.07 KB / MD5 23d88c349b8d2fa3cd2f9958ae99a1f6
​
THE MAIN COMPONENTS:
/system/etc/init.d/Y02firstboot
Code:
#!/system/bin/sh
# execute post-install script on First boot
# 01022012 SENSEISIMPLE
SLEEP=3
FBSCR="/data/.firstboot.sh"
BB="busybox"
pg () {
$BB ps | $BB grep "[email protected]" | $BB grep -v "$( echo $BB grep [email protected] )"
}
if [ -f "$FBSCR" ]; then
#install apps on first boot after system services have started
sleeperlog "Found $FBLOC"
sleeperlog "Waiting for system"
$BB chmod 0755 $FBSCR
while : ; do
if pg systemui; then
$BB sleep 10
sleeperlog "system loaded."
log -p i -t boot "Executing $FBSCR script"
sleeperlog "Running FirstBoot init"
$FBSCR
break
fi
sleeperlog "WAITING FOR SYSTEM SERVICE: sleeping for $SLEEP s..."
$BB sleep $SLEEP
done
fi
/data/.firstboot.sh
Code:
#!/system/bin/sh
#
# 20120107 - SENSEISIMPLE
#
log -p i -t init:firstboot "INIT.firstboot BEGIN: USER SCRIPT $FBLOC.sh"
sleeperlog "FirstBoot Script OK TO RUN"
FBLOC="/data/.firstboot"
tmp="/cache/tmp/firstboot"
bak="$tmp/bak/data/data/"
BB="busybox"
RM="$BB rm"
CP="$BB cp"
MV="$BB mv"
MKDIR="$BB mkdir"
LS="$BB ls"
CHMOD="$BB chmod"
SLEEP="$BB sleep"
GREP="$BB grep"
pg () {
$BB ps | $BB grep "[email protected]" | $BB grep -v "$( echo $BB grep [email protected] )"
}
$CHMOD 0777 /data
#install apps on first boot
if [ -d $FBLOC ]; then
sleeperlog "Found $FBLOC"
if [ "$($LS $FBLOC)" ]; then
cd $FBLOC
$MKDIR -p $bak
for pkg in *.apk; do
log -p i -t init:firstboot "INIT.firstboot INSTALLING: $pkg"
sleeperlog "PREPARING: $pkg"
pkgname=${pkg%.*}
sleeperlog "BACKING UP APP DATA - $pkgname"
#back up data, delete the original data dir to prevent install errors (pm isn't very good at what it does)
if [ -d /data/data/$pkgname ]; then
$CP -a /data/data/$pkgname $bak/$pkgname
$RM -rf /data/data/$pkgname
fi
#WAIT, then install, then WAIT SOME MORE
$SLEEP 2
sleeperlog "INSTALLING $pkgname"
pm install -r $FBLOC/$pkg &
$SLEEP 10
#REIntegrate application data
if [ -d "$bak/$pkgname" ]; then
sleeperlog "\nSYNCING APP DATA \n\n$(/system/xbin/rsync -auv --exclude=lib $bak/$pkgname/ /data/data/$pkgname/)\n"
fi
i=$((i+1))
#Move the install .apk to tmp
if $LS /data/app | $GREP "$pkgname"; then
sleeperlog "Package appears to have installed."
$MV "$pkg" $tmp/
fi
#If the firstboot batch dir is empty, delete it now
! [ "$($LS $FBLOC)" ] && $RM -rf $FBLOC
done
#WAIT for [#ofapps x 5 seconds each] to avoid a race condition
waitsecs=$(( i * 5 ))
sleeperlog "Waiting for ${waitsecs}s before Fixing Permissions"
$SLEEP $waitsecs
sleeperlog "Fixing Permissions $(/system/xbin/fix_permissions)"
sleeperlog "Running batch zipalign \n\n $(/system/xbin/zipalign)"
sleeperlog "Clearing tmp $tmp"
fi
fi
sleeperlog "FIRSTBOOT SCRIPT COMPLETE"
log -p i -t init:firstboot "INIT.firstboot SELF DESTRUCT FIRSTBOOTSCRIPT"
if ! [ "$($LS $FBLOC)" ]; then
$MV $0 $tmp/.firstboot
# COMMENT THIS OUT FOR DEBUGGING, TO NOT REMOVE THE TMP DIR
$RM -r $tmp
echo ""
fi
echo -e "#\n#COMPLETED ON $(date)\n#" >> $0
sleeperlog "FirstBoot Apoptosis"
log -p i -t init:firstboot "INIT.firstboot END: USER SCRIPT $FBLOC.sh"
THANKS
CyanogenMod team for the Fix_permissions script
DarkyROM for the Batch Zipalign script
Saving this seat . . .
does this work with a bml rom?
^^^^In theory, it would work with an NTFS rom, if one existed - different filesystems don't [usually] create any changes on the surface... if you try to copy a file from a partition of any file system to a partition of any other file system, you don't have to explicitly tell the system the fs types involved. I haven't looked through the entire script, but if there are any commands that must specify the partition type, it would be a simple matter of changing any occurances of EXT4 to YAFFS2, etc.
This could be a great way to make a clean reinstall with all of your apps intact (minus app data, do a separate backup with your backup app of choice) - first, backup your installed apps by copying them to the appropriate directory, then do a full wipe and install, with the script automatically reinstalling your apps on first boot...
EDIT: I just looked through the script more closely. First, it appears that data is backed up. Second, I can confirm that the standard, non-file system-specific linux commands are used for file operations (cp to copy, etc), so this script shouldn't need any adjustment to accomodate different file systems
Sent from my SPH-D700 using XDA App
Is it possible for someone to develop an application to backup your personal apps and then running a script in clockwork or on first boot that does the same thing as this, alllowing for personal apps to be in the rom directly after flashing. I understand that sometimes apps may not be compatible, but can randomroms rdu script be modified to choose to do this?
Sent From My Cyan4g
Good looking script SenseiSimple!!
Okay, I'm trying to use this script, but you said to put the apps in fs/data/firstboot/ but where is "fs"? I found the "firstboot.sh" file, but I'm sure I can't put the apk's in there...
In loving memory of my son "Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 :'(
sniperkill said:
Okay, I'm trying to use this script, but you said to put the apps in fs/data/firstboot/ but where is "fs"? I found the "firstboot.sh" file, but I'm sure I can't put the apk's in there...
In loving memory of my son "Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 :'(
Click to expand...
Click to collapse
If you look at the folder structure inside the SleeperROM zip, you'll see he uses an fs directory to hold his system and data folders for installation. If you're developing a ROM, you can adapt the script to point to wherever your data folder is (most other ROMs just have system and data in the root directory of the zip, so the path would just be data/firstboot/).
EDIT: no need to look in SleeperROM zip, the firstboot zip in the OP has the same folder structure. It just doesn't seem to have the firstboot directory inside data. You'll need to add that.
Sent from my SPH-D700 using XDA App
bbelos said:
If you look at the folder structure inside the SleeperROM zip, you'll see he uses an fs directory to hold his system and data folders for installation. If you're developing a ROM, you can adapt the script to point to wherever your data folder is (most other ROMs just have system and data in the root directory of the zip, so the path would just be data/firstboot/).
EDIT: no need to look in SleeperROM zip, the firstboot zip in the OP has the same folder structure. It just doesn't seem to have the firstboot directory inside data. You'll need to add that.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
sniperkill said:
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
Click to expand...
Click to collapse
Are you trying to do this in a ROM or on the phone? Sorry if that's a dumb question, but I just want to be sure we're on the same page.
Sent from my SPH-D700 using XDA App
sniperkill said:
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
Click to expand...
Click to collapse
bbelos said:
Are you trying to do this in a ROM or on the phone? Sorry if that's a dumb question, but I just want to be sure we're on the same page.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
i hadn't noticed my zip routine apparently skips empty .folders
in the zip, there SHOULD have been /fs/data/.firstboot into which you place whatever apk files named according to their actual package name i.e. com.keramidas.TitaniumBackup.apk for Titanium Backup, com.alensw.PicFolder.apk for QuickPic and so on...
you can find out this info in Titanium Backup by finding the app in the list and tapping its name to show the data store location.
it HAS to correspond to the actual package name in order to properly back up the data files because the package manager binary as run from a script won't overwrite the data dir so the old data has to be synced back into the new install (rsync)
I am currently refactoring the script to reduce the number of dependencies... the system will then consist of the init.d script, zipalign and rsync bins, and the /data/.firstboot.sh, /data/.firstboot dir all in one place rather than scattered throughout the system.
irule9000 said:
Is it possible for someone to develop an application to backup your personal apps and then running a script in clockwork or on first boot that does the same thing as this, alllowing for personal apps to be in the rom directly after flashing. I understand that sometimes apps may not be compatible, but can randomroms rdu script be modified to choose to do this?
Sent From My Cyan4g
Click to expand...
Click to collapse
it would be possible to create an app to do this, and i considered it because of the need to make sure the android system is fully loaded for package manager to work, but given the requirement for full root access to start running before the system is up without having to worry about android permissions or getting SuperUser approval it's easier/more effective to do it as part of the system init in a script.
as far as randomking's rdu script, they would be compatible, but they exist separately as in one shouldn't interfere with the other, because the firstboot script runs long after install once the system is up and running.
you could modify the rdu setup to include/exclude the /data/.firstboot dir and .firstboot.sh script based on the selected config, since the init script does nothing if it doesn't see the /data/.firstboot.sh file, and the .firstboot.sh script does nothing if it doesn't see the .firstboot dir
SenseiSimple said:
it would be possible to create an app to do this, and i considered it because of the need to make sure the android system is fully loaded for package manager to work, but given the requirement for full root access to start running before the system is up without having to worry about android permissions or getting SuperUser approval it's easier/more effective to do it as part of the system init in a script.
as far as randomking's rdu script, they would be compatible, but they exist separately as in one shouldn't interfere with the other, because the firstboot script runs long after install once the system is up and running.
you could modify the rdu setup to include/exclude the /data/.firstboot dir and .firstboot.sh script based on the selected config, since the init script does nothing if it doesn't see the /data/.firstboot.sh file, and the .firstboot.sh script does nothing if it doesn't see the .firstboot dir
Click to expand...
Click to collapse
Expanding on the rdu script idea, how about a prop variable in the config to specify a user apps directory on the sdcard (best if standardized)? The user can store the apks to be installed after a clean flash in this directory. The rdu script would be modified to copy those apks to the firstboot directory. Although how to handle data? Maybe another script to be run before flashing that checks the apks in the sdcard folder, and copies the current data folder to the sdcard. This data is then restored somehow with the firstboot script. This all can be in addition to the firstboot apps included with the rom.
Sent from my SPH-D700 using XDA App
app
I honestly have no developing experience. To clarify, I was I simply asking if the app could back up the users personal apps/data to the specified folders, to make this script fool proof. Then when a rom is flashed the randomromkings rdu script which currently decides on lite roms or full roms could be modified to either install apps or not install apps depending on the rom compatibility. Finally data is wiped, rom flashes, and your script runs on boot allowing the apps to all be there. Expanding on that if the ROM allows apps to be re installed via your script, through the modified rdu, your script could be moved from one directory to another allowing the process to happen and at the end moves itself back to the original directory. This means that the end user who has no clue how to do anything but flash roms (like myself, but I want to learn) has done nothing accept backing up their apps. I know this is all hypothetical, but would this be possible, and also I have another idea that is probably impossible. If a script could be written so that the apps are backed up when the rom flashes, then the rom automatically does a factory restore and wipes the various caches, meaning that less people are going to have force close issues or other avoidable bugs because they didnt wipe. thanks for all your hard work
Clear Me Here !!
You said that the script (.firstboot.sh) removes itself, but does it remove Y02firstboot script from init.d?? I don't think so, also, there are no disadvantages of this after first boot, as it won't find .firsboot.sh and skip the operation, but why shud it execute unneccesarily everytime??
@OP--Plz. tell me if i am right or wrong.......If right, plz. add a function to remove that script from init.d. However files in /xbin are OK though, so no need to remove them............
Everybody is writing and making this appear as complicated as possible! So let me clarify what I believe the idea is here. First of all, the 'RDU script' I assume you're referring to is simply a flash-able zip to set you phone for a lite or full installation. It sets a config file. I use it in my rom, and I also currently use that config file to set several other features upon installation, and changeable at anytime one of my themes is flashed.
RDU was simply meant to jump start the idea of developers making installations more uniform. Which has happened to various extents, for example, I've used this first-boot install to solve my quickpic(I love the app) and flash pre-install problems. It also fixes usb tether, vlingo, terminal, etc.
SO, what are we saying here? We'd like to be able to backup our apps to the sd card, as many apps can do for us. Then, we'd like to either:
A. Build a script into a rom to restore these apps prior to or upon installation.
or
B. Build a separate script which would be run AFTER a rom installation to restore these apps from CWM.
Yes?
P.S. I see this is very late to the game, didn't realize this thread was being revived...
Still. Neat idea, sorry I hadn't noticed it yet.
+1 Thanks
After integrating this into my custom ROM, my phone (Galaxy S 4G) would only install the first .apk file in the .firstboot directory. After I removed the code which tells it to backup/restore the /data/data directories, it worked fine. I won't need that code since the ROM does a full wipe of /data every time anyway, but I'm not sure why it doesnt work when it's there. I'm not well versed enough with Java's syntax yet to comprehend why.
Also, your first post says that it should record logs to \sdcard\sleeperlog.txt but the script tries to record it to \sdcard\sleeperromlog.txt and neither one of those files actually appear on the sd card.
Edit: I had to remove the check to make sure the .firstboot directory is empty before deleting it, but it works fine on my Galaxy S 4G ROM as long as there are no /data/data directories for the programs I am installing.
does anyone still have a template of this? The link is down.
Edit: nevermind I don't need it anymore.

Duplicate Binaries

I just made an alarming discovery. There are some duplicate binaries installed on our system. rm is one example. I found this out using the rm command. Here is what I found. It exists in BOTH /system/bin AND /system/xbin. If you need proof, I can show you that too.
*********************************************************
Busybox installs its binaries to /system/xbin. Your $PATH is constructed from the /system/etc/mkshrc file that gets executed at boot. The path construct outputs PATH=/system/bin:/system/xbin. Notice that /system/bin comes before /system/xbin in your PATH.
So then the problem with duplicate binaries is that when commands are run from the terminal (without a full path specified to the command call), they are executed from the first directory found in the $PATH which is /system/bin not /system/xbin.
I could do some more **** Tracy and find all the duplicate binaries but I have an easier solution. The solution (for me) is to edit my mkshrc file, and force /system/xbin to come before /system/bin in the $PATH construct. That way I'm not getting jipped with a full Busybox installed by using their less functional Android counterparts. I will post the edited file here in case anyone needs it.
[Edit] On second thought after reviewing some feedback, I will not post this file modification. It has other unintended consequences. Read. Oops, I thought this was posted in the Help & TS section.
elfaure said:
I just made an alarming discovery. There are some duplicate binaries installed on our system. rm is one example. I found this out using the rm command. Here is what I found. It exists in BOTH /system/bin AND /system/xbin.
Click to expand...
Click to collapse
Well, the one in /system/bin is part of stock Android, and the one in xbin is from busybox. No surprise here. In many cases it does not matter which one you actually call, but the versions from busybox are usually more feature-rich. If you need the busybox version, the easiest and safest way to ensure you get the correct one is to explicitly call "busybox rm".
If you modify your PATH, you risk writing scripts that don't work on other devices.
_that said:
If you modify your PATH, you risk writing scripts that don't work on other devices.
Click to expand...
Click to collapse
Please explain.
[Edit] I just discovered other unintended problems with changing my $PATH in mkshrc. Because I have multiple superusers installed [I like to switch between them sometimes; one in /system/bin (active) and the other in /system/xbin (other one)] and by doing that when I rebooted it changed my superuser app. Interesting. So I will not post up the file then - bad idea.
[Edit] It just gets worse. After doing that I now can't sign into my Google account, and I just got a suspicious sign-in email from Google. Really bad idea.
[Edit] Yup. Just verified that my Google account was disabled due to suspicious activity and I had to reset my password. That email was not spam.
elfaure said:
Please explain.
Click to expand...
Click to collapse
I think I get what _that is saying.
For the same reasons that rm was causing some unexpected behavior in your Brower2Ram script, the same thing could happen if a system binary is not as feature-rich as the busybox version. It just so happens for the case of rm that the system binary has more switches than busybox, but who can say for other binaries?
shardsx said:
[Snipped] It just so happens for the case of rm that the system binary has more switches than busybox, but who can say for other binaries?
Click to expand...
Click to collapse
I think you have that backwards. Busybox binary is more feature rich, has more switches, and is the one we want to use. That is why I am suggesting pointing the PATH to busybox (/system/xbin) rather than Android (/system/bin). The one that does NOT have the -f option is the Android one; the default one that gets called from a terminal or my script.
elfaure said:
Please explain.
Click to expand...
Click to collapse
Just think what could happen:
1. You have modified your PATH.
2. You write a script that works on your device.
3. You publish your script.
4. I try running your script and it calls the wrong binary because my PATH is not modified.
elfaure said:
I think you have that backwards. Busybox binary is more feature rich, has more switches, and is the one we want to use. That is why I am suggesting pointing the PATH to busybox (/system/xbin) rather than Android (/system/bin). The one that does NOT have the -f option is the Android one; the default one that gets called from a terminal or my script.
Click to expand...
Click to collapse
Oops, you're right!
_that said:
Just think what could happen:
1. You have modified your PATH.
2. You write a script that works on your device.
3. You publish your script.
4. I try running your script and it calls the wrong binary because my PATH is not modified.
Click to expand...
Click to collapse
Gotcha. This is what I didn't understand @shardsx how modifying my local path in any way could affect anyone else running my script but @_that clearly shows why above. If I can't test it on the user's binary then I'm only testing it for operation on MY device which would be different than YOUR device. So like you said @_that, I need to specifically call the busybox binary for the rm command if I want to use the -f option by either:
1. /system/xbin/rm
or
2. busybox rm
instead of just simply rm (which calls /system/bin/rm). Drama concludes with effective solution.
Find duplicate binaries script
Here is a script to find all the duplicate binaries between /system/bin and /system/xbin. There are quite a few.
[Edit] The attached script was REMOVED because it is WRONG. Once I fix the problems and @_that has approved of the corrections I will post it back up.
elfaure said:
Here is a script to find all the duplicate binaries between /system/bin and /system/xbin.
Click to expand...
Click to collapse
Nice, short and sweet ... and wrong. You should test your scripts before publishing.
Read this: http://en.wikipedia.org/wiki/Test_(Unix) to find how to fix it.
This line is wrong:
Code:
if [ "OBJ"="$XBIN" ]; then
The "[" command (yes, that's a command also called "test") does not understand "=". In this invocation it will simply return true if the string between [ and ] is not empty, which is always. Edit: It does understand " = " though.
Even if test did understand "=" in the normal way of comparing for equality it wouldn't work. First, you forgot the $ before OBJ - you want to compare with the current file name, not with the fixed name "OBJ". Then, if you compare the current $OBJ with the whole list of the files in xbin, it will always be false.
You don't even need the list of all files in xbin - you only need to check for each file in bin if an equally named file in xbin exists. "test" (or "[") has an operator for that.
a working solution:
Code:
for OBJ in $(ls /system/bin)
do
if [ -e /system/xbin/$OBJ ]; then
echo $OBJ
fi
done
_that said:
Nice, short and sweet ... and wrong. You should test your scripts before publishing.
Read this: http://en.wikipedia.org/wiki/Test_(Unix) to find how to fix it.
This line is wrong:
Code:
if [ "OBJ"="$XBIN" ]; then
The "[" command (yes, that's a command also called "test") does not understand "=". In this invocation it will simply return true if the string between [ and ] is not empty, which is always.
Even if test did understand "=" in the normal way of comparing for equality it wouldn't work. First, you forgot the $ before OBJ - you want to compare with the current file name, not with the fixed name "OBJ". Then, if you compare the current $OBJ with the whole list of the files in xbin, it will always be false.
You don't even need the list of all files in xbin - you only need to check for each file in bin if an equally named file in xbin exists. "test" (or "[") has an operator for that.
a working solution:
Code:
for OBJ in $(ls /system/bin)
do
if [ -e /system/xbin/$OBJ ]; then
echo $OBJ
fi
done
Click to expand...
Click to collapse
Ouch! Busy at day job now but I felt that slap all the way from the E. Coast. Is _that called SIP - slap over IP?.
Agreed, I'm still too much of a newb to be QCing my own work. Won't publish anything else without your approval. I will investigate and fix it but it seemed to work when I ran it. Maybe it just listed all the contents of /system/bin?
[Edit] I just wanted to say until I look this over that I did run it and the output looked reasonable for matching binaries. I did not check more than a few.
Note: I have not opened your solution because I am not yet convinced I need to or this structure is wrong. But historically speaking you've never been wrong so I expect to be wrong and learn something from this, but for now I just don't see your point, I believe these work, so I will hold my ground.
Here is a simple test example with identical structure. I see no difference (besides forgetting the $). Comment?
Code:
#!/bin/sh
string1="blah"
string2="blah"
if [ $string1=$string2 ]; then
echo "$string1 $string2"
fi
and here is the code block from my sniper method script after which you called for a cleanup. This code compared a single variable (like $OBJ) to a list variable (like $XBIN).
Code:
If [ -d "${CACHE_NAME1}"=${BROWSER_LIST} ];
then...
[Edit] I put the $ infront of OBJ and re-ran my script and it produces identical output as without it. So every file in /system/bin is getting echoed and the script does not work you are (always) correct. But the test example script I provided does work. Hmm...thats a single variable not a list. But my sniper method worked. Hmm...hmm...
Nor did this make any difference
Code:
if [ "${OBJ}"="${XBIN}" ]; then
Conclusion: My sniper method never worked as intended. It just mounted all of the browser list without ever making the match to all /cache dirs. But it seemed to work as intended. Again, I state that it is difficult to impossible to know when you are doing something wrong in the code when you get your desired output thru a flawed code block which further substantiates your point about needing review. Because then we convince ourselves something worked and try to use the same method again and again only later to find out the method is flawed.
I'm going to follow your links and read up a bit before I take the bait and peek at your solution.
elfaure said:
Here is a simple test example with identical structure. I see no difference (besides forgetting the $). Comment?
Code:
#!/bin/sh
string1="blah"
string2="blah"
if [ $string1=$string2 ]; then
echo "$string1 $string2"
fi
Click to expand...
Click to collapse
Try these variants and observe the result:
Code:
if [ a=a ]; then echo yes; fi
if [ a=b ]; then echo yes; fi
if [ a ]; then echo yes; fi
if [ ]; then echo yes; fi
(I actually did the same to find out what's going on)
elfaure said:
The one that does NOT have the -f option is the Android one; the default one that gets called from a terminal or my script.
Click to expand...
Click to collapse
This seems to have changed between 10.4.4.25 and 10.6.1.14.4 (below, respectively):
Code:
rm [-rR] <target>
Code:
Usage: rm [-rR] [-f] <target>
Welcome to the world of code portability.
---------- Post added at 07:01 AM ---------- Previous post was at 06:48 AM ----------
elfaure said:
Here is a simple test example with identical structure. I see no difference (besides forgetting the $). Comment?
Code:
#!/bin/sh
string1="blah"
string2="blah"
if [ $string1=$string2 ]; then
echo "$string1 $string2"
fi
Click to expand...
Click to collapse
1. You need a space between the comparison operator and the variable names for this to work like you expect.
2. Get into the habit of always quoting variable names when performing such tests (i.e. if [ "$string1" = "$string2" ]; then). Not doing so may bite you when you're not expecting it.
becomingx said:
1. You need a space between the comparison operator and the variable names for this to work like you expect.
2. Get into the habit of always quoting variable names when performing such tests (i.e. if [ "$string1" = "$string2" ]; then). Not doing so may bite you when you're not expecting it.
Click to expand...
Click to collapse
1. I started out with these spaces and tested the script with and without the spaces and it did not make any difference (output was the same) so I removed them thinking they weren't needed. But I did question this. I observed other examples that had this space and was wondering why they were there. Also the spaces between the [ ] and the arguements are required. I did actually know that [=test was a command (from prior readings).
2. Why is this important for variables with no special characters? I thought that was only a grouping thing for variables like "${OBJ}_Cache"
[Edit] Wiki: The quotation marks around $1 ensure that the test works properly even if the value of $1 is a null string. If the quotation marks are omitted and $1 is the empty string, the test command displays the error message "test: argument expected"
_that said:
Try these variants and observe the result:
Code:
if [ a=a ]; then echo yes; fi
if [ a=b ]; then echo yes; fi
if [ a ]; then echo yes; fi
if [ ]; then echo yes; fi
(I actually did the same to find out what's going on)
Click to expand...
Click to collapse
But you may need the spaces around the "=" and quotes around the variables that @becomingx points out for accurate results. As the variable names become more complex this may fail.
Code:
if [ "a" = "b" ]; then echo yes; fi
elfaure said:
2. Why is this important for variables with no special characters? I thought that was only a grouping thing for variables like "${OBJ}_Cache"
[Edit] Wiki: The quotation marks around $1 ensure that the test works properly even if the value of $1 is a null string. If the quotation marks are omitted and $1 is the empty string, the test command displays the error message "test: argument expected"
Click to expand...
Click to collapse
Not only for that reason, but also for things like spaces.
Code:
THIS="and that"
if [ $THIS == "and that" ]; then
...
fi
== `[: too many arguments'
becomingx said:
Not only for that reason, but also for things like spaces.
Code:
THIS="and that"
if [ $THIS == "and that" ]; then
...
fi
== `[: too many arguments'
Click to expand...
Click to collapse
So I followed @_that's link to the Wiki for [=test, and there is absolutely no discussion at all about using "=" or "==" for testing comparisons between variables, only strings. Why?? These examples and your Firefox code for B2R script use the equal operator for comparison and that is what i am trying to do here but I can't yet make it work.
I have failed to figure this out. Here is my test code citing due dilligence. I will now peek at @_that 's solution.
Code:
#!/system/bin/sh
#This script finds duplicate binaries in /system/bin and /system/xbin and prints them to the screen
BIN="$(ls /system/bin)"
#XBIN="$(ls /system/xbin)"
XBIN="$(find /system/xbin -iname "{$OBJ}")"
for OBJ in $BIN
do
#if [ "${OBJ}" = "${XBIN}" ]; then
#if [ "${OBJ}" ] && [ "${XBIN}" ]; then
if [ "${OBJ}" == "$XBIN" ]; then
echo $OBJ
fi
done
I have failed to figure this out. Here is my test code citing due dilligence. I will now peek at @_that 's solution.
[Edit] Short, sweet, simple, works, brilliant. What cereal do you eat in the morning @_that? I think I need to change mine.
Question: Is there any way to make this work with my original structure??? I need a comprehensive method for test matching a string variable to a list variable AND a list variable to another list variable. I would think the latter could be reduced to the former thru the use of a for-do loop "for OBJ in $LIST_VARIABLE1 do ...something to...$LIST_VARIABLE2".
Code:
#!/system/bin/sh
#This script finds duplicate binaries in /system/bin and /system/xbin and prints them to the screen
BIN="$(ls /system/bin)"
#XBIN="$(ls /system/xbin)"
XBIN="$(find /system/xbin -iname "{$OBJ}")"
for OBJ in $BIN
do
#if [ "${OBJ}" = "${XBIN}" ]; then
#if [ "${OBJ}" ] && [ "${XBIN}" ]; then
if [ "${OBJ}" == "$XBIN" ]; then
echo $OBJ
fi
done

Categories

Resources