There's currently no way to tell the native messenger to
provide a particular stdin to a "run" command. This leads to
awkward uses of here-docs, which in turn require hacks like
the one in 4a5dcd7557.
Instead, let's take the "content" field from the message
body and feed that to the command's stdin, which gives us a
more robust channel for passing arbitrary bytes.
Note that we have to switch to using subprocess.Popen's
communicate() method, which will make sure we don't deadlock
if the input or output exceeds a pipe buffer.
Note also that when no stdin is provided by the caller
(i.e., all current cases), we'll pass an empty string. This
actually fixes a minor bug. Because we didn't override the
command's stdin argument, it's hooked to the messenger's
stdin, which is the pipe coming from firefox. If the command
tries to read, it (and the messenger) will hang forever,
since firefox is waiting for the messenger to respond before
writing anything else.
I bumped the native messenger version. This is mostly
backwards compatible (existing callers just don't send any
stdin content at all). But a caller that wants to send stdin
should check to make sure we have at least 0.1.7.
This makes debugging work correctly on Linux. Otherwise
you'll generally get EPERM as `/home/user\.tridactyl` is a
path in `/home`, which you likely don't have access to
write.
We are passing None value to mkstemp which is only possible since python
3.5.0 [1]. Let's use our own mask with empty string as the prefix when
None is given. That works with both python API versions.
[1]
ad577b938b
Python's tempfile.mkstemp method returns an open file descriptor, but
native_main.py was ignoring that and re-opening the file. This commit
modifies the code to use os.fdopen so that the file descriptor is
closed when exiting the 'with ...' context manager.
