starred/LADB

Fork 0

mirror of https://github.com/tytydraco/LADB.git synced 2026-04-27 08:26:00 +03:00

[GH-ISSUE #74] Make commands execution clearer for when 0 is returned. #56

New issue

Closed

opened 2026-03-04 02:11:13 +03:00 by kerem · 10 comments

kerem commented

2026-03-04 02:11:13 +03:00

Owner

Originally created by @mirh on GitHub (Jun 10, 2022).
Original GitHub issue: https://github.com/tytydraco/LADB/issues/74

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.

Originally created by @mirh on GitHub (Jun 10, 2022). Original GitHub issue: https://github.com/tytydraco/LADB/issues/74 Assume I'm `pm grant`ing 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*.

kerem

2026-03-04 02:11:13 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-04 02:11:14 +03:00

Author

Owner

@teou1 commented on GitHub (Oct 14, 2022):

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.

@teou1 commented on GitHub (Oct 14, 2022): 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.

kerem commented

2026-03-04 02:11:14 +03:00

Author

Owner

@mirh commented on GitHub (Oct 15, 2022):

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.

@mirh commented on GitHub (Oct 15, 2022): > 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.

kerem commented

2026-03-04 02:11:14 +03:00

Author

Owner

@teou1 commented on GitHub (Oct 15, 2022):

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

@teou1 commented on GitHub (Oct 15, 2022): 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

kerem commented

2026-03-04 02:11:14 +03:00

Author

Owner

@tytydraco commented on GitHub (Oct 15, 2022):

@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 commented on GitHub (Oct 15, 2022): @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!

kerem commented

2026-03-04 02:11:14 +03:00

Author

Owner

@tytydraco commented on GitHub (Oct 16, 2022):

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

@tytydraco commented on GitHub (Oct 16, 2022): 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

kerem commented

2026-03-04 02:11:14 +03:00

Author

Owner

@mirh commented on GitHub (Oct 16, 2022):

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

@mirh commented on GitHub (Oct 16, 2022): How is it that tools like `top` still works then? And how can you print the ※\\(^o^)/※ message in the same screen also?

kerem commented

2026-03-04 02:11:14 +03:00

Author

Owner

@tytydraco commented on GitHub (Oct 16, 2022):

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.

@tytydraco commented on GitHub (Oct 16, 2022): > 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.

kerem commented

2026-03-04 02:11:14 +03:00

Author

Owner

@mirh commented on GitHub (Oct 16, 2022):

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.

@mirh commented on GitHub (Oct 16, 2022): 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.

kerem commented

2026-03-04 02:11:15 +03:00

Author

Owner

@tytydraco commented on GitHub (Oct 16, 2022):

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?

@tytydraco commented on GitHub (Oct 16, 2022): > 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?

kerem commented

2026-03-04 02:11:15 +03:00

Author

Owner

@mirh commented on GitHub (Oct 17, 2022):

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.

@mirh commented on GitHub (Oct 17, 2022): 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.