Can kitty-tool be ported to run an Android?

[salmankhilji]

I am wondering if kitty-tool can be compiled for armv7 or armv8 to allow remote-controlling kitty from within an adb shell session to an Android device.

[kovidgoyal]

No idea, try it and see. You will need to add the architecture in the build_static_binaries function in setup.py

[salmankhilji]

Before I plunge in, how does kitty-tool communicate with the main kitty app?

[kovidgoyal]

On Thu, Dec 22, 2022 at 04:37:57AM -0800, salmankhilji wrote: Before I plunge in, how does `kitty-tool` communicate with the main kitty app?

Over a socket or over a TTY

[salmankhilji]

I report having successfully tested kitty-tool on the following devices:

1. Android 10, aarch64
2. Android M, armv7l

I had to cross-compile kitty-tool for both linux/arm64 and linux/arm using this command: ./setup.py build-static-binaries. However, I patched as follows:

diff --git a/setup.py b/setup.py
index ee238281..5aaaaa00 100755
--- a/setup.py
+++ b/setup.py
@@ -953,7 +953,7 @@ def run_one(dest: str, **env: str) -> None:
 def build_static_binaries(args: Options, launcher_dir: str) -> None:
     arches = 'amd64', 'arm64'
     for os_, arches_ in {
-        'darwin': arches, 'linux': arches, 'freebsd': arches, 'netbsd': arches, 'openbsd': arches,
+        'darwin': arches, 'linux': ('amd64', 'arm64', 'arm'), 'freebsd': arches, 'netbsd': arches, 'openbsd': arches,
         'dragonfly': ('amd64',),
     }.items():
         for arch in arches_:

The edit-in-kitty feature is what drove me to try this, and I report once again, that my initial testing has been very positive. There are minor issues that I will report as separate tickets shortly.

The reason I am requesting arm arch to be built and readily available for download is that arm binaries work on both arm64 and arm devices, whereas arm64 binaries only work on arm64 devices. So for maximum portability, I would like to only download the arm binary and use it on both my arm and arm64 devices (preferring to be sub-optimal by using a 32-bit binary on my a 64 bit device.)

Unlike wanting to use the edit-in-kitty feature merely for having all the bells and whistles of a local vim over SSH, using edit-in-kitty on some Android devices is really a necessity. The reason is that my specific Android 10 aarch64 device has no vi! So prior to discovering edit-in-kitty feature, editing files on the device needed to manually pull the file off the device, edit it locally, and then manually push the file back and fix up permissions. edit-in-kitty is really cool!

Android has broken core tools like sed and less. (They are usually toybox or busybox versions.) Yes, one can manually compile the full GNU versions of these core tools, but doing so is very time consuming.

kitty-tool --help does not produce any output on Android, probably because of a broken less. My Ubuntu 20.04 LTS development PC also has a broken less where it does not correctly handle hyperlinks. Therefore, I would like to request to make less optional. See: #5744.

[kovidgoyal]

You are welcome to send a PR adding linux-arm You will need to modify both setup.py and ssh/kitty-tool the latter to use linux-arm on 32 bit hosts automatically. As for less being broken, its on my TODO list to write a replacement for less in kitty-tool pager if and when I do, the problem goes away.

[salmankhilji]

Thanks for taking care of building the 32-bit binaries for linux/arm by default.

(Having no experience in Python, I did not that one could do: 'linux': arches + ('arm',).)

I also see that there is a corresponding change in the kitty-tool shell integration script, which downloads kitty-tool as needed. My understanding is that this script is meant to be executed on the remote/target machine. Just wanted to let you know that in my use-case, I intend to manually download kitty-tool on my development PC and then manually push the binary to the device (using adb). (Of course, one must a priori know the target device OS and architecture with such approach.)

The reason being that Android having an embedded system lineage may not even have tools like curl or wget. (What can we expect of an OS which ships with broken sed, broken tar, and may even not have vi!). This is typical of embedded developmnt where all "real" work is done on a development PC and the built binaries are merely pushed to the device.

Long story short, as long as it is documented where to download the corresponding kitty-tool off GitHub, than my use-case should be good-to-go. I see that the URL is of the form:

https://github.com/kovidgoyal/kitty/releases/download/$release_version/kitty-tool-$OS-$arch

And I think it ought to be enough for me to script the installation of kitty and its corresponding kitty-tool.

PS: The following commit does away with current-version.txt approach:

commit ddf36383b4e5d31d49d3f6f41f8a4d41a01902a4
Author: Kovid Goyal <kovid@kovidgoyal.net>
Date:   Thu Jan 5 20:09:32 2023 +0530

    Dont need to fetch the current version since GitHub provides a redirecting constant download URL

tools/cmd/update_self/main.go

However, I see that the kitty-tool shell integration script still does something with current-version.txt. Hopefully, it is my misunderstanding and not a miss.

[kovidgoyal]

kitty-tool script uses current-version because thats the only way it will work till kitty is released, since kitty-tool is currently only in nightly and latest redirects to an actual release.

…

On Sat, Jan 14, 2023 at 12:33:38AM -0800, salmankhilji wrote: Thanks for taking care of building the 32-bit binaries for `linux/arm` by default. (Having no experience in Python, I did not that one could do: `'linux': arches + ('arm',)`.) I also see that there is a corresponding change in the `kitty-tool` shell integration script, which downloads `kitty-tool` as needed. My understanding is that this script is meant to be executed on the remote/target machine. Just wanted to let you know that in my use-case, I intend to manually download `kitty-tool` on my development PC and then manually push the binary to the device (using `adb`). (Of course, one must a priori know the target device OS and architecture with such approach.) The reason being that Android having an embedded system lineage may not even have tools like `curl` or `wget`. (What can we expect of an OS which ships with broken `sed`, broken `tar`, and may even not have `vi`!). This is typical of embedded developmnt where all "real" work is done on a development PC and the built binaries are merely pushed to the device. Long story short, as long as it is documented where to download the corresponding `kitty-tool` off GitHub, than my use-case should be good-to-go. I see that the URL is of the form: ``` https://github.com/kovidgoyal/kitty/releases/download/$release_version/kitty-tool-$OS-$arch ``` And I think it ought to be enough for me to script the installation of kitty and its corresponding `kitty-tool`. **PS:** The following commit does away with `current-version.txt` approach: ``` commit ddf3638 Author: Kovid Goyal ***@***.***> Date: Thu Jan 5 20:09:32 2023 +0530 Dont need to fetch the current version since GitHub provides a redirecting constant download URL tools/cmd/update_self/main.go ``` However, I see that the `kitty-tool` shell integration script still does something with `current-version.txt`. Hopefully, it is my misunderstanding and not a miss. -- Reply to this email directly or view it on GitHub: #5805 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

--

_____________________________________ Dr. Kovid Goyal https://www.kovidgoyal.net https://calibre-ebook.com

_____________________________________

[kovidgoyal]

Note that I just renamed kitty-tool to kitten. So adjust your scripts accordingly.

[salmankhilji]

Thanks for the update. I have updated my scripts accordingly.

I thought it might help you understand how your customers are using kitty, so here a few technical details.

After installing/updating kitty, my installation script pre-downloads kitten for the expected architectures, to my local machine, like this:

mkdir -p ~/.local/kitty.app/share/kitten
for arch in arm arm64; do
  curl -L https://github.com/kovidgoyal/kitty/releases/download/nightly/kitten-linux-$arch \
    -o ~/.local/kitty.app/share/kitten/kitten-linux-$arch
  chmod 775 ~/.local/kitty.app/share/kitten/kitten-linux-$arch
done

Once the files reside on my local machine, these get pushed to the Android device by another script, like this:

ABI="$(adb shell getprop ro.product.cpu.abi | tr -d '\r')"
adb shell mkdir -p /data/bin
case "$ABI" in
  arm64*)
    adb push --sync $HOME/.local/kitty.app/share/kitten/kitten-linux-arm64 /data/bin/kitten
    ;;
  arm*)
    adb push --sync $HOME/.local/kitty.app/share/kitten/kitten-linux-arm /data/bin/kitten
    ;;
esac

(Of course, 32-bit binaries works on 64 bit machines, so this script can be simplified; however, since pre-built binares for both architectures are so conveniently available, so I took the liberty to optimize the scenario.)

My approach differs from the packaged kitty/shell-integration/ssh/kitten script where the latter downloads the needed binary onto the target machine as needed whereas my approach requires pre-downloading the needed binaries onto my local machine. I thought perhaps the https://sw.kovidgoyal.net/kitty/installer.sh script could be modified to pre-download the expected set of binaries ahead of time using a new command line option. Then, kitty itself might be able to push the kitten binary onto the target device instead of having to download it on-the-fly.

Given that the embedded development scenario is probably rare compared to SSH, I don't think any further optimizations are worth it.

[kovidgoyal]

I'm not a fan of kitty pushing kitten to remote hosts. In order to do that, it would require a round-trip greatly increasing latency for the common use case of using ssh over a network as opposed to connect locally. If I were to implement it, it would be by adding a per-host config to the ssh kitten specifying the destination path. However, this is a fair bit of work for something very easy for end users to script themselves, in the relatively rare case that the remote machine has no functional wget/curl.

[salmankhilji]

Agreed.

[salmankhilji]

Am I supposed to be able to run kitten edit-in-kitty in the background?

It appears that the edit-in-kitty feature wants the user to allow opening a file in a different window, tab, or even OS windows (just like @launch). So I could do, for example:

$ kitten edit-in-kitty --type os-window /etc/hosts

What happens is that the window where I launch the above command gets tied up like this:

$ kitten edit-in-kitty --type os-window /etc/hosts                                                                                                                                                           
Waiting for editing to be completed, press Esc to abort...

So I can't really do anything else in the original window till I finish my editing session in the new OS window. (Which makes me wonder as to how useful a new window was to me as I could have easily edited in the original window to begin with.)

So I tried putting the command in background:

$ kitten edit-in-kitty --type os-window /etc/hosts &
[1] 19139
$ Waiting for editing to be completed, press Esc to abort...

[1] + Stopped (tty output) \kitten edit-in-kitty --type os-window /etc/hosts

But then somehow kitten binary stops. I wonder if it is an Android limitation. (Haven't tried doing so over SSH.)

[kovidgoyal]

No, you cant, edit-in-kitty works by communicating over the tty device, only one program can communicate over the tty at a time.

…

On Thu, Jan 19, 2023 at 02:30:50AM -0800, salmankhilji wrote: Am I supposed to be able to run `kitten edit-in-kitty` in the background? It appears that the `edit-in-kitty` feature wants the user to allow opening a file in a different window, tab, or even OS windows (just like ***@***.***`). So I could do, for example: ``` $ kitten edit-in-kitty --type os-window /etc/hosts ``` What happens is that the window where I launch the above command gets tied up like this: ``` $ kitten edit-in-kitty --type os-window /etc/hosts Waiting for editing to be completed, press Esc to abort... ``` So I can't really do anything else in the original window till I finish my editing session in the new OS window. (Which makes me wonder as to how useful a new window was to me as I could have easily edited in the original window to begin with.) So I tried putting the command in background: ``` $ kitten edit-in-kitty --type os-window /etc/hosts & [1] 19139 $ Waiting for editing to be completed, press Esc to abort... [1] + Stopped (tty output) \kitten edit-in-kitty --type os-window /etc/hosts ``` But then somehow `kitten` binary stops. I wonder if it is an Android limitation. (Haven't tried doing so over SSH.) -- Reply to this email directly or view it on GitHub: #5805 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

--

_____________________________________ Dr. Kovid Goyal https://www.kovidgoyal.net https://calibre-ebook.com

_____________________________________

[salmankhilji]

The icat command is generating the following warning while running on an Android device:

$ kitten icat /data/data/com.preva.mpaqtapp/files/support_files/resources/images/bt_refresh_high.jpg                            
Failed to create SHM for data transfer, memory based transfer is disabled. Error: open /dev/shm/icat-f0c5341e: no such file or directory

Is this worth filing a ticket on?

The image BTW does display as expected.

[salmankhilji]

One more.

While running on Android, the clipboard kitten fails to guess the MIME type if input is directly from a file. Piping through stdin works.

$ head -n5 environment.txt                                                                                                            
################################################################################
# REQUIRED ENVIRONMENT VARIABLES
#
# The system will not function properly if these variables are not defined
################################################################################
$ kitten clipboard environment.txt                                                                                                    
Error: Could not guess MIME type for environment.txt use the --mime option to specify a MIME type
$ cat environment.txt | kitten clipboard                           

(I am reluctant to file these as tickets as broken embedded systems are probably not the main use case.)

However, I am wondering if the run_set_loop routine within write.go should default to text/plain for files as well. It currently does so if inputs[i].is_stream is true.

[kovidgoyal]

Both of these should now be fixed in master.

[salmankhilji]

Not completely fixed.

The attached file still produces this warning:

$ unzip mime-bug.zip 
Archive:  mime-bug.zip
  inflating: init.rc                 
precor@byteevo:~/Scratch$ kitty +kitten clipboard init.rc 
Error: Could not guess MIME type for init.rc use the --mime option to specify a MIME type
precor@byteevo:~/Scratch$ file init.rc 
init.rc: ASCII text

Notice that the file command can correctly detect the file type.

[kovidgoyal]

It doesn't use file contents, it detects MIME types purely based on extension. So if youa re using a file without a well known extension you have to specify MIME type manually.