[Lldb-commits] [PATCH] D22081: Use shell cat command as a workaround if ADB stat cannot lookup a file

[Luke Drummond via lldb-commits]

ldrumm added a subscriber: ldrumm.

================
Comment at: source/Plugins/Platform/Android/PlatformAndroid.cpp:244
@@ +243,3 @@
+        char cmd[PATH_MAX];
+        snprintf (cmd, sizeof (cmd), "cat '%s'", source_spec.GetCString (false));
+
----------------
I have some issues with this approach.

If the filename contains the literal `'` character, this command fail with unpredictable results. The solution would seem to be to pass a list of strings a'la POSIX `exec` i.e.:

`- AdbClient::internalShell (const char* command, uint32_t timeout_ms, std::vector<char> &output_buf)`
`+ AdbClient::internalShell (std::vector<const char*> command, uint32_t timeout_ms, std::vector<char> &output_buf)`

but on a little investigation, it does seem that the adb protocol is limited to escaping for the shell command, and does not propagate return status. If I run the following python command:

```
import subprocess
print(subprocess.check_output(['adb', 'shell', 'cat', "/data/'"]))
```
The TCP conversation looks like this:
```
0017host:transport:6D8E7152
OKAY
0012shell:cat /data/\'
OKAY
```

When I try and `cat` a file that doesn't exist: 
```
0017host:transport:6D8E7152OKAY0016
shell:cat /nonexistent
OKAY/system/bin/sh: cat: /nonexistent: No such file or directory
```
So there's seemingly no way to know whether the file exists using `adb shell cat $FILE`, or whether you're getting the error message as contents.

However, if I use the adb pull command on the same file, the return status is propogated to the calling shell because the stat fails:
```
0017host:transport:6D8E7152
OKAY
0005sync:
OKAY
STAT..../nonexistent
STAT............
```
So it seems like the protocol itself does not handle escaping consistently but requires clients to do this on a per adb command basis and there is no way to know the difference between success and failure for the `cat file` approach.

Unfortunately, I don't actually have a better solution to offer here.


http://reviews.llvm.org/D22081