Make commands execution clearer for when 0 is returned.

[mirh]

Assume I'm pm granting something.
If you insert the wrong command, you get something like in #66.
But, if do everything good, you don't get any feedback that the thing even run at all.

I'm not necessarily saying to clutter the simple interface with a "line repeating the command that has just been inserted and then following it with a newline" like in a normal desktop CLI, but there should be some visual indication something happened.

[teou1]

This critic should actually go at google. I find it very annoying too, but it is how adb works. Ladb app is just a wrapper for googles adb.

So to "fix" would mean to use a workaround like what you mentioned. I don't think the author of ladb should waste resources trying to fix google. Would be better if he just updates the adb component and we go to Google's adb tracker to request the feature.

[mirh]

but it is how adb works.

Not at all. Adb itself returns 0 when a command succeeded. Meaning the pretty evident thing that control is returned to the caller.

And if you mean the built-in shell instead, like any other one regardless of whatever was the output of the previous command, a new prompt is shown every time.

[teou1]

Yes that was i meant, a new promt means success but no message. But you are right, there is no prompt here.
I am starting to think maybe the next version of adb should be with normal prompt if possible @tytydraco ? As mentioned in the other "ctrl+c" issue. #72

[tytydraco]

@mirh @teou1 Hmm I could maybe check this out. I actually saw something really interesting, it's a flutter package called xterm, it supports a full xterm emulator so you'd be able to use proper shell features and see the return codes. But obviously that requires rewriting the app in Flutter. I'll put this on the list, I could put a little color indicator maybe!

[tytydraco]

Turns out this is not possible because the ADB process is the only thing we have a handle on, not the subprocesses in the interactive shell

[mirh]

How is it that tools like top still works then?
And how can you print the ※\(^o^)/※ message in the same screen also?

[tytydraco]

How is it that tools like top still works then? And how can you print the ※(^o^)/※ message in the same screen also?

Basically LADB opens "adb shell", but "adb shell" can start up top. But if I send a process kill, it kills "adb shell", not the thing underneath. And it looks like I can't really send a key-combo. I need to send a process signal. But a SIGINT would kill ADB.

[mirh]

I see.
But how does that relate to the issue?
Like.. I suppose this may also mean that you can't really know when a command succeeded or not (unless something gets to be printed to stdout/stderr) but it should still be possible to come up with some UI element/design/gimmick to at least tell the user that the command has been sent and that the prompt is waiting for further input.

[tytydraco]

Basically yeah we can't get any info about the sub-command. I checked for an xterm emulator for Android but couldn't find any libraries. What would be a convenient way to notify the user about a command succeeding to send, in your opinion?

[mirh]

I didn't really have any specific idea.
The most obvious solution would be having some >, # or $ to signal readiness (with a blinking cursor perhaps?), but I can see why that could clash with the elegance of having the command prompt exists in its own separate input box at the bottom of the window.