Add a method to mozdevice which runs a command and returns standard output

RESOLVED FIXED in mozilla18

Status

Testing
Mozbase
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: wlach, Assigned: mdas)

Tracking

Trunk
mozilla18
x86_64
Linux
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

The current shell function in devicemanager is great for when you want to read a bunch of data and write it directly to a file (or standard output), but it's unwieldly if we just want to run a simple command and operate directly on the output.

The most recent demand for something like this was in bug 792048, but it comes up quite often. I'd written a workaround for this myself in eideticker: 

https://github.com/mozilla/eideticker/blob/master/src/eideticker/eideticker/device.py#L62

Inspired by python's subprocess module, let's add a method called shellCheckOutput to devicemanager that works as above. For the cases that the command we're calling returns 0 (or otherwise fails), let's throw an exception. Yes, this amounts to a change in policy in devicemanager, but jmaher and I agreed it's for the better.
Assignee: wlachance → mdas
Created attachment 664593 [details] [diff] [review]
patch v1.0

This patch adds the shellCheckOutput command to devicemanager.py. The implementation is the same regardless of environment, so it's not an abstract method.

I've tested this in an adb and sut environment and this works as expected.
Attachment #664593 - Flags: review?(wlachance)
Comment on attachment 664593 [details] [diff] [review]
patch v1.0

Wonderful! Thank you so much. Hopefully we can guide people to using this now as opposed to checkCmd and sendCmd.

>diff --git a/mozdevice/mozdevice/devicemanager.py b/mozdevice/mozdevice/devicemanager.py
>index 3150176..c0c72f9 100644

>+        if retval == None:
>+            raise DMError("Did not successfully run command %s (output: '%s', retval: 'None')" % (cmd, output))

PEP8 suggests that this be written as retval is None

"Comparisons to singletons like None should always be done with is or is not, never the equality operators.
Attachment #664593 - Flags: review?(wlachance) → review+
> PEP8 suggests that this be written as retval is None
> 
> "Comparisons to singletons like None should always be done with is or is
> not, never the equality operators.

Cool, thanks, I've changed it, tested it and pushed to mozilla-inbound:


https://hg.mozilla.org/integration/mozilla-inbound/rev/0450cb4ef66a
Can you push to the github repo as well?

FYI (someone correct me if I'm wrong), we are now pushing to the github repo first, and then the changes will get mirrored in jhammel's weekly mozbase merge that he has started doing. If you need it right away you can mirror the mozbase repo immediately (see https://wiki.mozilla.org/Auto-tools/Projects/MozBase#Mirroring or ask jhammel)
(In reply to Andrew Halberstadt [:ahal] from comment #4)
> Can you push to the github repo as well?
> 
> FYI (someone correct me if I'm wrong), we are now pushing to the github repo
> first, and then the changes will get mirrored in jhammel's weekly mozbase
> merge that he has started doing. If you need it right away you can mirror
> the mozbase repo immediately (see
> https://wiki.mozilla.org/Auto-tools/Projects/MozBase#Mirroring or ask
> jhammel)

Yes, this is correct. The policy here is to commit to the github repo first and then use the mirroring script to move changes to m-c. For more details, see the wiki page that Andrew linked to.

That said, there is no particular harm done in this case. I think we can just commit to the github repository and be done with it: this would only be a problem if we did a mirror before that was done.
Yeah, it won't cause problems, just for future reference.
Agh, sorry, I forgot which way the mirror went. I'll do the commit to github now
https://hg.mozilla.org/mozilla-central/rev/0450cb4ef66a
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
You need to log in before you can comment on or make changes to this bug.