Closed thevoiceless closed 9 years ago
If line 41 failed in the original script, it failed over to line 46. What happens then? Does this also fail? What is the adb output when you execute the command manually?
I apologize, I should have said that both line 41 and 46 fail. When running the master
version of the script, this is the output:
$ ./humpty.sh -d com.my.package databases/mydatabase.db
humpty.sh v1.2.0
Dumping com.my.package/databases/mydatabase.db to dumps/com.my.package/databases/mydatabase.db...
humpty.sh: line 46: dumps/com.my.package/databases/mydatabase.db: No such file or directory
Failed; found database, but could not pull it
Everything I could find online relating to this issue seems to say that the only workaround is to copy the db file to the sdcard directory. I create the 'humpty' directory to avoid deleting anything unintentionally; I'm assuming users won't have a directory like that sitting around on their phone unless they're using this script.
When running the commands manually...
run-as
with chmod
worksadb pull
directly fails with the following output even though the file does exist:remote object '/data/data/com.my.package/databases/mydatabase.db' does not exist
- The fallback method fails due to
sed
:sed: RE error: illegal byte sequence
I'm not sure if the sed error is caused by Android or the fact that I'm running this on OS X.
I've updated my changes so that copying to /sdcard
is used as a third fallback.
Awesome, thanks for moving it into the third fallback.
I believe the SED error is caused by OS X; I haven't been able to find a solution on OS X. If you can find some way to strip that reg ex on Mac, it may be a more convenient solution.
On Thu, Jun 11, 2015, 18:39 Riley Moses notifications@github.com wrote:
I've updated my changes so that copying to /sdcard is used as a third fallback.
— Reply to this email directly or view it on GitHub https://github.com/Pixplicity/humpty-dumpty-android/pull/1#issuecomment-111200670 .
I'll try to look into it if I get some time; I assume all it's doing is stripping \r
? No hidden voodoo?
Thanks! Only \r at the end of lines, so effectively converting \r\n to \n, I believe.
To be honest, I don't know if it's entirely safe to do, as Windows style
like breaks in existing files are converted, but the trouble is caused by
the terminal output of cat
on various devices (including my Moto X 2014).
On Thu, Jun 11, 2015, 19:55 Riley Moses notifications@github.com wrote:
I'll try to look into it if I get some time; I assume all it's doing is stripping \r? No hidden voodoo?
— Reply to this email directly or view it on GitHub https://github.com/Pixplicity/humpty-dumpty-android/pull/1#issuecomment-111223010 .
I've pushed a proposed solution to the sed
problems on OS X. It appears that OS X ships with it's own implementation of sed
that deviates from the GNU version. Can you give it another shot?
Sure! I'll try it out later today. Sorry I haven't had time to investigate the sed
stuff
I'm now getting the following on Mac:
Dumping com.example/databases/database.db to dumps/com.example/databases/database.db...
sed: RE error: illegal byte sequence
Failed; found database, but could not pull it
... which is fixable by adding the following to ~/.bash_profile and restarting the terminal:
export LC_CTYPE=C
export LANG=C
It works for me now! (source: http://guidovanoorschot.nl/fix-for-re-error-illegal-byte-sequence-on-mac-os-x/)
The lastest version on master
still gives me the same sed: RE error: illegal byte sequence
output. I'm on OS X 10.9.5
Thanks for troubleshooting this, guys. Can you give it another swing with the latest revision?
Sorry, I didn't get a chance to test it before this PR was merged. Do you want me to go back and check?
One thing I've noticed with the suggestion from @monkeyinmysoup is that I already have $LANG
set to en_US.UTF-8
(must be the default value since I don't change it myself). $LC_CTYPE
does not have a value by default.
You might want to cache any existing value before setting new ones, based on http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html which says "It is unwise to conflict with certain variables that are frequently exported by widely used command interpreters and applications". For example, it looks like LC_CTYPE
is sent when starting ssh sessions: http://www.cyberciti.biz/faq/os-x-terminal-bash-warning-setlocale-lc_ctype-cannot-change-locale/
Good points. @monkeyinmysoup is my colleague; I'll take a look behind his OS X machine to see what we can do without chaning LANG
or LC_CTYPE
at all.
Hello!
At some point,
adb pull
lost the ability to pull from app's directories which would cause line 41 to fail. The workaround is to copy the desired file to/sdcard
and thenadb pull
from there. I've updated your script to do something along those lines.