Shell functions are declared using this syntax: [ function ] name () compound-command [ redirectio... Example: function ll { ls -alF $* } Example 2: ll() { ls -alF $* } Shell functions can be exported to subshells with the -f switch: $ export -f ll However , I had problems logging in Ubuntu 11.10 after I added this to .profile : export -f ll

An alias defined in .profile does not work when you open a bash window from the desktop. Simply put, alias should be put in .bashrc ; PATH should be put in .profile . These are the facts: .profile is executed by the login shell, i.e., when you login. .bashrc is executed whenever a bash shell is opened - login or non-login. When you open a new bash window from the desktop, a non-login shell is created, it will execute .bashrc , not .profile . When you ssh to a remote system interactively, a login shell is created. When you ssh to a remote system and run a command directly, a non-login shell is created. PATH modifications should be put in .profile since it is usually...

Use the read command to pause a shell script and give the user a chance to stop it: #!/bin/sh echo "Press CTRL-C to stop this scrip...

The Android unit test framework is based on JUnit 3 , not JUnit 4. Test cases have to extend junit.framework.TestCase or a subclass (such as android.test.InstrumentationTestCase ). Tests are identified by public methods whose name starts with test , not methods annotated with @Test (as in JUnit 4). An Android test suite is packaged as an APK, just like the application being tested. To create a test package, first you need to identify the application package it is testing. Google suggests to put the test package source in a directory named tests/ alongside the src/ directory of the main application. At runtime, Android instrumentation loads both the test package and the application under test into the same process. Therefore, the tests can invoke methods on...

String comparison operators: Operator Meaning -n str the length of str is nonzero. -z str the length of str is zero (0). str1 = str2 str1 and str2 are the same (note one equal sign, not two!). str1 != str2 str1 and str2 are not the same. str str is not a null string Examples: # empty string is not null if [ '' ]; then ... Numerical comparisons ( integer expressions only! ): Operator Meaning int1 -eq int2 int1 and int2 are numerically equal int1 -ne int2 int1 and int2 are numerically NOT equal int1 -gt int2 int1 is greater than int2 int1 -ge int2 int1 is greater than or equal to int2 int1 -lt int2 int1 is less than int2 int1 -le...

I got this error while building an APK: [apply] [apply] UNEXPECTED TOP-LEVEL ERROR... Apparently the dx tool was running out of memory. The dx script (shell or bat) provides options to pass in Java options, but it's a lot easier just to bump up the default in dx : # By default, give dx a max heap size of 1 gig. Th... Here, I changed the default 1024M to 1624M and resolved the problem.

To start the Settings application: # am start -n com.android.settings/.Settings St... To start the Browser : # am start -n com.android.browser/.BrowserActivity... To start the phone dialer: # am start tel:210-385-0098 Starting: Intent { ... Help for am command: # am usage: am [subcommand] [options] ...

When you pass parameters from shell to Java, the list arguments may be messed up if there are spaces in the values. Start with a simple Java test class: public class EchoParams { public static voi... Tests: $ java EchoParams a b c Arg: a Arg: b Arg... Now wrap the command in a shell script ( echoparams.sh ): #!/bin/sh java EchoParams $* Tests: $ ./echoparams.sh a b c Arg: a Arg: b Arg... The quotes had no effect on the parameters list. Changing $* to $@ produces the same results. The correct way to quote the args list is: "$@" #!/bin/sh java EchoParams "$@" Test: $ ./echoparams.sh a b "c d" "1 2 3 4 5" Arg: a ...

The Unix shell passes these parameters to the shell script: Variable Meaning $* A single string representing all command line arguments separated by $IFS (internal field separator, usually a space) $@ A sequence of strings representing the command line arguments. $1,$2...$n $1 is the first argument, $2 is the second argument, and so on... $0 The name of the script itself. $# The number of arguments. Example shell script ( sharg.sh ): #!/bin/sh echo $# arguments passed to $0: $@ ... Output for ./sharg.sh "a b c d" : 1 arguments passed to ./sharg.sh: a b c d here ... Output for ./sharg.sh a "b c" d : 3 arguments passed to ./sharg.sh: a b c d here ...

This is a common problem with shell scripts running from cron. Everything works perfectly fine from the command prompt, but fails when running from cron. In the worst cases, the job fails silently, even giving a return code of 0! Usually, these are caused by differences between the execution environments: the interactive shell (command line) has more environment variables defined/exported (through .kshrc , .bashrc etc.) than the shell started by cron. A simple way to resolve the differences is to run set in the command prompt and compare the output with the output of set from cron (add a single line to the shell script). You can also make the shell script more verbose by adding the -x switch: #!/bin/sh -x