-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: Allow to get an InputStream from the addCommand callback #62
Comments
Use addCommand() with OnCommandLineListener rather than OnCommandResultListener to get output without it all being buffered in a large list. For reading text files, you can use 'cat'. Proper binary reading through libsuperuser is not currently supported well. |
Yes, I tried to read a JPG file as if it was a text file, and decode it, but it failed. I was almost sure it won't work, but I wanted to try nevertheless. Is it maybe possible to send the content of the file to a non-storage file (meaning in memory) that will be read later? I remember Linux/Unix has some special files that aren't really stored on the storage, but can be read as if they are in the storage. |
I would advise against modifying any file (changing its access), this seems like an accident waiting to happen. You could copy the file to /dev, this will be ram-based, but it's pretty dirty. libsuperuser should at some point be adapted to support this, but it's not going to happen today, even though it really shouldn't be all that complicated to do. What you could do in the meantime, is look at the deprecated Shell.run method ( https://github.com/Chainfire/libsuperuser/blob/master/libsuperuser/src/eu/chainfire/libsuperuser/Shell.java#L101 ) and adapt it to your needs. If you read through the method you will see that the While ideally you would use one |
I will check it all out. Thank you. About future versions of the library, can you please make it work like addCommand, so that it will not need to open a new shell ? |
Better late than never, but this is implemented in v1.1.0 |
OMG I don't remember why I wanted this . |
See the new README. It's mainly focused on using Shell.Thread but there's also an addCommand variant that works with Shell.Interactive |
You mean this part:
But now that I look at what I asked here, is it possible to use this in order to read from files that are protected, such as image files (to preview them without the need to copy them somewhere else) ? |
Your original question has two parts.
You use one of the Line callbacks for these.
The InputStream callbacks pass you an InputStream that reads directly from the command's STDOUT. The command itself runs as root, so if you run "cat /path/to/some/image" you'll get the binary content of said image. You can probably read the InputStream into a Bitmap by using BitmapFactory.decodeStream(inputStream) in the callback, then pass that Bitmap off to an ImageView. |
I just tried it now. Once I get the InputStream, it's stuck on the decoding. Any idea how to overcome this? |
You can try wrapping it in a BufferedInputStream, and call inputStream.close() after reading. Also wrap in try/except/printStacktrace |
OK had a bug related to CountDownLatch (called Look at the screenshot and the new project: I think the bitmap is produced. For some reason I can't debug anymore, so I added logs. I think it was fine before too, as |
You're not closing the inputStream if there's no exception, that might be it. The calling thread doesn't continue until the callback is complete, which it will not be, until either the entire stream is read or the inputStream is explicitly closed. |
Also, why are you even using a latch? The run() command will not continue until all the callbacks are complete. run() is synchronous, use addCommand() for asynchronous (but looking at the code that's not what you're after, you just want run()). In addition to the latch not being relevant, the onSTDERR callback can be called more than once, so wouldn't that break your logic too? |
The closing of the InputStream was the issue indeed. Now it works fine. Sorry about that. I thought I've put it in "finally" block or outside...
|
Ah in that case it's fine, I rarely use them so I don't know the contract. But it's still a synchronization mechanism, which isn't needed in the code you screenshotted, because run() doesn't return until the command has fully completed (error or not) |
Oh, so |
Yes, Even though You don't need to It is not done automatically so the stream can be passed off to other threads as well, which can be useful, as long as the user (so the dev using the library, you) keeps in mind that that specific root shell does not continue running until the stream is fully read/closed. |
I see. Sorry for that. Usually functions with listeners are running in async manner. |
So that if we call a command that will print a lot, we won't have to get it all in a list that takes a lot of memory.
Also, is it possible to get an InputStream of a protected file?
I know I can copy the file and then read it, but I wish to avoid it.
The text was updated successfully, but these errors were encountered: