I'm trying to build an automated build script with applescript on MacOS X.
For now everything works correctly with one glitch.
The command "do script ("zipalign -f -v 4 /tmp/src.apk /tmp/tgt.apk") works fine if I run it in a separate tell for application "Terminal" but leaves the terminal window open when it's done. Everything else in the script works fine in tells for application "Finder".
If I try to run the command via "do shell script" inside the tell for "Finder" I only get an error "command not found".
The path to zipalign is set in /etc/paths and is reachable through any terminal window and "do shell" but not to "do shell script" command.
What is the correct way to ensure that "do shell script" uses $PATH to find commands or alternatively is there a bulletproof way to close the terminal left by "do script"?
When you invoke bash as an interactive login shell, the paths in /etc/paths and /etc/paths.d/* are added to PATH by /usr/libexec/path_helper, which is run from /etc/profile. do shell script invokes bash as sh and as a non-interactive non-login shell, which does not read /etc/profile.
You can run path_helper manually though:
do shell script "eval `/usr/libexec/path_helper -s`; echo $PATH"
Though this question was four years ago, but I think the simplest answer is needed to be told. I use the command 'wkhtmltopdf' (which is used to print pdf and it is placed in /usr/local/bin) for example
--past
wkhtmltopdf out.html out.pdf
--now
PATH=$PATH:/usr/local/bin; wkhtmltopdf out.html out.pdf
It just add new PATH variable to the sh process called up by AppleScript.
Related
I have a simple bash script to push an executable to the android and then remove it.
#!/bin/bash
adb push CMakeBuild_Android_armv8/Out/Release/exec /data/local/tmp/exec
adb shell rm data/local/tmp/exec
This is saved as 'adb_push.sh'. I made sure that this is an executable via chmod.
chmod +x adb_push.sh
But when I run this script in the Cygwin ./adb_push.sh, I get an error that there is no such directory.
CMakeBuild_Android_armv8/Out/Release/exec: 1 file pushed, 0 skipped. 62.5 MB/s (7302616 bytes in 0.111s)
rm: data/local/tmp/exec: No such file or directory
Is there any obvious steps that I am missing in creating a bash script or is there any error in what I am doing?
Any hint or comment would be highly appreciated.
ADB version:
$ adb version
Android Debug Bridge version 1.0.41
Version 31.0.0-7110759
Installed as C:\platform-tools_r31.0.0-windows\platform-tools\adb.exe
Disclaimer: I already tried putting the source and destination path in quotes, it did not work for me. Also tried the same with a .wav file instead of an executable and I get the same error which lead me to believe that something's not right in the bash script.
Your second command assumes the working directory is the root /. It appears this assumption is false.
The first command is succeeding. Only the second command is failing.
If adb shell doesn't start at the root (/), then the destination path you supply in the first command (/data/local/tmp/exec) is different from the path you supply in the second command (data/local/tmp/exec, note the missing slash at the beginning).
I'm gonna guess adb shell on your device starts a shell in some user's home directory, not /.
Option 1: Use absolute file path
You can fix this by giving the full absolute file path in your second command:
adb shell rm /data/local/tmp/exec
Option 2: Change directories before your command
Alternatively, you can change to the root directory before running the command. adb shell (as of version 31.0.0-7110759) does not have the ability to set the working directory, but you can do this inside the shell by adding a cd before your rm. Note that the command must now be quoted to prevent your local shell from interpreting the list operator &&:
adb shell 'cd / && rm data/local/tmp/exec'
Note: The adb shell default working directory may vary by device or ROM. On my stock Pixel 3 it does in fact start at the root:
$ adb shell pwd
/
Since Oreo there is this fancy locksettings command, that allows you to change the screenlock from adb shell. Now, if I try to run it on my PC everything is working. On my handheld the command will just get an "Aborted." back. Why is that and how can I run the locksettings command from my device?
here is the code for the locksettings command, maybe you can already tell by that:
# Script to start "locksettings" on the device
#
base=/system
export CLASSPATH=$base/framework/locksettings.jar
exec app_process $base/bin com.android.commands.locksettings.LockSettingsCmd "$#"
Download QUTE, a command panel. Start from the first command click and run it. About 10 to 15 commands ran will give enough control over the system. Only because most of the commands are going to fail, unable to run. Then the terminal will suggest you to STACK, for the command code to lock setting. Copy the code and paste it in the terminal. For there your settings should be locked.
I want to enter a simple adb shell command, so I navigated to ...\sdk\platform-tools\adb.exe, and opened it. However, I am unable to type in it!
What is the solution?
.exe files are executable files for the Windows OS. They will not work on OSX.
There is a program called Terminal that is installed in OSX that you can use to run the adb shell command. You must open up a Terminal and navigate to the directory that is shown in your screenshot, and then you can run the command
./adb shell and it should work.
Alternatively, you can use the Terminal in Android Studio to perform the same operation.
Here is how I change my directory to platform-tools on a mac terminal:
Search the finder for "platform-tools". Then right-click on it, and left-click on "get info". You'll see a little window pop up with all the info for that folder.
Copy the "where", which is the file path.
Then paste into your terminal like this:
cd /Users/[user-name]/Library/Android/sdk/platform-tools
Be sure to add /platform tools on after pasting the path to the folder.
Then hit return. Your terminal should then be pointed to that folder and you can invoke the adb commands by using "./adb [whatever command]".
Or you can invoke adb shell commands: for example let's say you want to enable Analytics Debug mode on an Android device. Use the following command:
adb shell setprop debug.firebase.analytics.app [your_package_name]
I have a couple of shell scripts stored in the /Scripts folder of my AppleScript application.
I can access them by setting my base path
set basePath to POSIX path of ((path to me as text)) & "Contents/Resources/Scripts/"
But I'm only able to run the script if I call the Terminal app
-- This works
tell application "Terminal"
set currentTab to do script (basePath & "install_key.sh")
end tell
-- This does not work
do shell script basePath & "install_key.sh"
The error on do shell script complains about not being able to find adb (Android Debug Bridge)
FWIW, here is the shell script in question (install_key.sh)
#!/bin/bash
#Find script directory
DIR="$( cd "$( dirname "$0" )" && pwd )"
adb push $DIR"/key-dev.txt" /sdcard/ &&
adb shell mv /sdcard/key-dev.txt /sdcard/key.txt
Problem
If I understand correctly, your main issue is that your script cannot detect and hold the presence of a specific command located on a system.
Solution
I believe the following code will be effective in helping you achieve your goal. This applescript allows you to find whether ADB is stored on a system and store it's path in a variable. You can add the variable to your path and export as others have suggested or have a look at the export process in Apple's TN2065.
If ADB is not found on a system then users can receive a prompt telling them what actions to take (if that aligns with your use-case or you could begin the install sequence for ADB). To test the behavior of the script you can simply change the adp to some other (fake) command that does not exist on your system. I've added the path to the dialog so that you can see the do shell is passing the contents of the which command into a variable.
try
set adbPath to do shell script "which adb"
on error errStr number errorNumber
-- If our own error number, warn about bad data.
if the errorNumber is not equal to 0 then
display dialog "ADB is not loaded onto system. Please load ADB and run this app again"
return 0 -- Return the default value (0).
else
-- An unknown error occurred. Resignal, so the caller
-- can handle it, or AppleScript can display the number.
error errStr number errorNumber
end if
end try
if length of adbPath > 0 then display dialog "ADB found continue processing..." & adbPath
The structure defined in the TN2065 above is essentially:
$ VAR=something; export VAR $ osascript -e 'do shell script "echo $VAR"' something
You might also want to try the administrator option when calling the shell script:
do shell script "command" user name "me" password "mypassword" with administrator privileges
The Technical Note TN2065: do shell script in AppleScript is the key reference for this kind of issues.
when you use just a command name instead of a complete path, the shell
uses a list of directories (known as your PATH) to try and find the
complete path to the command. For security and portability reasons, do
shell script ignores the configuration files that an interactive shell
would read, so you don’t get the customizations you would have in
Terminal.
First: find the full path of adb
you have to open a Terminal and issue the following command:
$ which adb
suppose the response is:
/Users/ronda/projects/android/sdk/platform-tools/adb
this means that the path of adb is:
/Users/ronda/projects/android/sdk/platform-tools
, now we have several way to address the problem, for example follow one of these two options:
Option1: Fix the AppleScript
do shell script "PATH=${PATH}:/Users/ronda/projects/android/sdk/platform-tools; export PATH; echo $PATH; " & basePath & "install_key.sh"
Option2: Fix the shell script
for example you could specify full path to the adb command in your .sh this way:
#!/bin/bash
#Find script directory
DIR="$( cd "$( dirname "$0" )" && pwd )"
/Users/ronda/projects/android/sdk/platform-tools/adb push $DIR"/key-dev.txt" /sdcard/ &&
/Users/ronda/projects/android/sdk/platform-tools/adb shell mv /sdcard/key-dev.txt /sdcard/key.txt
The simplest solution would be running the same bash configuration as your terminal application. The main difference is that Terminal uses an interactive bash and do shell script command doesn't. To run an interactive shell you can simply execute a new one with option -i (stands for interactive). When an interactive shell is opened the ~/.bashrc file is used, while non-interactive shells don't use this file.
do shell script "bash -i <<<" & quoted form of (basePath & "install_key.sh" as text)
if you don't like that you can simply execute the bashrc file or read the path variable and set it in a do shell script.
I'm trying to deal with some SQLiteDB issues and wanted to use the ABD tool to access my emulators database. When I click on the adb file in the platform-tool file, it opens up but very quickly throws a bunch of text on the window and then closes. Its so fast I can't even tell what it is doing. I tried running as administrator and it didn't change. I'm using Vista if that has anything to do with it.
Any suggestions for how I can even get it to stop from closing so I can enter a command?
You start the command shell (WindowsKey + R, enter cmd in the window that appears and hit Enter.), then use it from there. adb shell is probably the command you need.
C:\> cd \Path\to\platform-tools
C:\Path\to\platform-tools\> adb shell
if you add the path to your environment PATH you don't need to cd there. [This] should be a good example how to do that.
As mentioned by zapl, you need to launch command prompt, add adb directory to path and then running adb commands. You may also be able to pull the trick with DDMS.
In the answer, it was not clear that you have to run a windows cmd.exe terminal program first. Make sure you are in the correct directory, Then start ADB from within this cmd program.
To ensure that windows can find adb.exe ("being in the correct directory), you can either navigate to the location of the adb.exe (usually Platform tools) manually using "cd" command, or update your path statement so that windows can find it regardless of where your cmd.exe prompt is pointing.