A-Shell Support (iOS)

[bbb651]

Is your feature request related to a problem? Please describe. I would like to use ani-cli with a-shell to automate downloading anime through iOS shortcuts. iSH also has really slow downloads compared to what iOS is capable of due to the overhead of virtualization (I'm pretty sure cloning the ani-cli repo in full on a-shell was faster than cloning it on iSH at depth 1).

Describe the solution you'd like I would like ani-cli to add official support (tier 2, in addition/in-place of the iSH support) for a-shell.

Describe alternatives you've considered Use this workaround to use ani-cli on iSH through shortcuts, downside being really complicated setup, requiring iSH to constantly run in the background, and the slow downloads.

Additional context a-shell added ffmpeg support recently which was the biggest blocker. After putting ani-cli in a-shell's ~/Documents/bin/, I got the following error:

[Documents]$ ani-cli
mkdir: /private/var/mobile/Containers/Data/Applica
tion/EAF521AC-5E25-4B87-8CBA-F32CC35D172C/.local/s
tate/ani-cli: Operation not permitted
/var/mobile/Containers/Data/Application/EAF521AC-5
E25-4B87-8CBA-F32CC35D172C/Documents/bin/ani-cli: 
341: cannot create /private/var/mobile/Containers/
Data/Application/EAF521AC-5E25-4B87-8CBA-F32CC35D1
72C/.local/state/ani-cli/ani-hsts: Directory nonexistent

[Derisis13]

Set environment variables XDG_CACHE_HOME and XDG_STATE_HOME if you want an alternative cache/state storage than .local/cache and .local/state. Also make sure that the directories they point to have write permission for your user.

[bbb651]

I’ll try to look into it further, XDG_STATE_HOME is the only one that isn’t set out of them (it’s a very weird environment where the home directory isn’t writable, but there are dedicated folders for specific things) which seems like an issue with a-shell and I’m honestly not sure what it should be set to, I tried setting it to something and I’m now blocked by fzf not being available. I also tried looking into rewriting ani-cli with iOS shortcuts and calling out to a-shell for ffmpeg or downloading which would also be a better experience in terms of ui but it’s incredibly hard to port with visual scripting, I might end up building some DSL that compiles to shortcuts like shortcuts-js

[bbb651]

Also, a-shell supports open to directly open uris rather than printing a link like on iSH (this also makes sense as an option on desktop, although on linux it might not be available by default, e.g. fish has it has a builtin but bash doesn't, so it needs to fallback to xdg-open).

I think it's currently detected as macOS, this is the output of uname -a:

[Documents]$ uname -a
Darwin localhost 23.2.0 Darwin Kernel Version 23.2.0: Sun Nov 12 06:35:57 PST 2023; root:xnu-10002.60.75.0.3~27/RELEASE_ARM64_T8020 iPhone11,6

iPhone seems like a good candidate to detect, for reference this is what iSH outputs for me:

localhost:~# uname -a
Linux localhost 4.20.69-ish SUPER AWESOME May 20 2023 23:41:32 i686 Linux

[CoolnsX]

I want to help in this, but I need to borrow the phone from my brother, and it's his primary phone.

[port19x]

iSH has been quite underwhelming and requires by far the most hoops to jump through, so I welcome any experiments to replace it with a better shell (a-shell)

[CoolnsX]

@Lockl00p can u check out a-shell? if all the requirements are fulfilled?

[bbb651]

I'm working towards getting download working, aria2c is GPL-2.0 licensed so it can't currently be included in a-shell, so I made a aria2c-optional I think it works but I'm not sure how to test it properly because everything I try to download is m3u8...

[Lockl00p]

Ooh this is interesting. An alternative to iShit?

[Lockl00p]

There are quite a few problems here: First off, there is no fzf package, so the user installing ani-cli would have to compile fzf. Another problem: building fzf requires go, which, turns out, no package, so they’d have to build go. And all of that might not even work cause of the restrictions of webassembly.

Essentially, if we want the install experience to be easier, we’d have to ship a pre-compiled version of fzf with ani-cli, one which (and I haven’t tested this, so can’t be sure) might have to be altered to work with webassembly.

This is a mess, and I’m not sure port19x would be ok with doing all of this. If they are, then I might give it a shot.

[Lockl00p]

@port19x what do ya think of this mess? fzf isn’t available so we’d have to either have the end user compile go (cause that ain’t available either), then fzf just to use ani-cli, ship a pre-compiled version of fzf with ani-cli, or somehow alter the script to integrate it with iOS shortcuts (the hardest solution for us, the easiest for the end user to deal with). Also, uname -a barely has an indicator that this is running on iOS specifically (instead opting to show as the Darwin kernel, which, to be fair, it is), with the only real indicator being the device showing up as iPhone, ipad, iPod, etc (which means we either have to check for the substring “ip” in uname -a, and you can see the problem with that, or add multiple cases to the switch case statement that account for different types of apple devices.)

You said you didn’t want it to be a mess to maintain, so, your call.

[bbb651]

Essentially, if we want the install experience to be easier, we’d have to ship a pre-compiled version of fzf with ani-cli, one which (and I haven’t tested this, so can’t be sure) might have to be altered to work with webassembly.

If you can compile fzf to wasm, especially if you can upstream it, it can be added as a package, holzschu (the developer of a-shell) isn't against adding it it's just a bit of work to port (specifically wasi doesn't support termios, you can workaround some things like window size with ansi codes), so it would be as easy as pkg install fzf.

Also, a-shell has iOS shortcuts support so even if the installation turns out complex it can be a simple shortcut linked from the README.

I've went ahead and made a little proof of concept to see how feasible creating a small fzf drop in replacement with nucleo would be, nucleo relays on a thread pool so it needs some tweaking (I assume wasm threads don't work on a-shell although I haven't tried), but nucleo-matcher works as is. crossterm doesn't support wasi, it's probably a similar amount of work to porting fzf itself, but for a simple fzf replacement simple ansi sequences are probably enough

Edit: I tried to test if the nucleo can work with wasi threads, and ran into this crossbeam issue. It turned out kinda pointless because a-shell uses wasm3 which doesn't support threads anyway 😒

[Lockl00p]

After looking into the absolute BS that is a-shell, I found a few things. First off, fzf uses go, and while go does allow you to compile to WASI, a-shell has a custom WASI SDK specifically for this app, so that’s quite a few missing features right there. In an attempt to find a replacement for fzf that doesn’t use ncurses (cause that also doesn’t exist here for some godforsaken reason), I found fzy, hopefully that works well enough.

[Lockl00p]

Sorry for the crude wording, I was just spending a while trying to find any fuzzy finder that would work because most used ncurses, the bane of my existence.

[port19x]

This sucks.

I don't think we're making any meaningful improvements over iSH if we have our users compile fzf and go. Also, we definitely won't be switching away from fzf just for better iOS support.

I suggest you collaborate with upstream to get go (and possibly fzf) into a-shell. Alternatively, if there is a package repo like there is on android for termux, make it available there. If neither seem plausible, we can pretty much close this

[bbb651]

Also, uname -a barely has an indicator that this is running on iOS specifically (instead opting to show as the Darwin kernel, which, to be fair, it is), with the only real indicator being the device showing up as iPhone, ipad, iPod, etc (which means we either have to check for the substring “ip” in uname -a, and you can see the problem with that, or add multiple cases to the switch case statement that account for different types of apple devices.)

I agree it's a little annoying, apparently macOS has sw_vers --productName for that although a-shell currently doesn't have it (well, it's pretty binary so it not existing in enough), it would still require an additional command to identify inside the Darwin case.

This sucks.

I agree, I've ran into so many iOS licensing issues, wasm/wasi bugs and limitations and weird a-shell behavior that it's been really frustrating, but I'm still optimistic I feel like it's feasible with a few upstream issues being fixed.

I don't think we're making any meaningful improvements over iSH if we have our users compile fzf and go.

This was never the problem, there's no saturation where the user has to bulid anything, worst case we ship/link to a single wasm file, but again if we add wasi support to fzf (ideally upstream) it can be added to the existing package manager.

we definitely won't be switching away from fzf just for better iOS support.

This also isn't really a problem, the options used for fzf are cosmetic:

fzf "$1" --reverse --cycle --prompt "$2"

so as long we can get any fuzzy finder to work and name it fzf it'll work. I'm pretty confident I can hack together something that at least works with nucleo-matcher and some ansi escape sequences.

The bigger problem is the aria2 licensing situation, I've made an issue asking if they'll consider dual licensing MPL-2.0 which would make it possible for a-shell to bundle it, I've also made a curl fallback would it be acceptable to upstream into ani-cli?

we can pretty much close this

I think I'll take a bit of a break as I'm a bit burnt out with this and I'm waiting on some upstream issues, I'd appreciate if this can stay open as I still have interest in working on this.

[Lockl00p]

This sucks.

I don't think we're making any meaningful improvements over iSH if we have our users compile fzf and go. Also, we definitely won't be switching away from fzf just for better iOS support.

I suggest you collaborate with upstream to get go (and possibly fzf) into a-shell. Alternatively, if there is a package repo like there is on android for termux, make it available there. If neither seem plausible, we can pretty much close this

I found an alternative to fzf (called fzy) that’s written in C this time, with the only bad part here being that it won’t support multiple selections (and is no longer maintained but that shouldn’t be a problem if it still works) If I can get this one to compile, I could just attempt to upstream fzy into a-shell repos and have ani-cli work with fzy.

[port19x]

and have ani-cli work with fzy

How? Is fzy sufficiently compatible with the fzf options we use? If so, a symlink is enough. If not, game over

[Lockl00p]

and have ani-cli work with fzy

How? Is fzy sufficiently compatible with the fzf options we use? If so, a symlink is enough. If not, game over

Eh, most of the fzf options are just “decorations” but no. However, it does have the prompt option.

[ykhan21]

There is fsh, which appears to be written in bash. https://github.com/yazgoo/fuzzysh

[Lockl00p]

ooh! I'll see if that works! Thanks for the suggestion!

[Lockl00p]

So uh, funny thing, no bash. Let's see if I can compile bash

[Lockl00p]

Well shit. So WASI cannot get key presses… meaning the only way it gets user text input is by waiting for the user to type the full string they want to input and press return. Basically every fuzzyfinder gets individual key presses, meaning we’re essentially screwed here.

[ykhan21]

Instead of getting bash, can you re-write it to be POSIX? It might already be POSIX.

[bbb651]

Well shit. So WASI cannot get key presses…

That's not true, it is missing some termios stuff and on a-shell you can't read from /dev/tty* devices because of permissions, but you can just read character by character from stdin. Although a-shell has the same issue as this (I still need to report it on the a-shell side) so I think differentiating between piped and user input is a little annoying.

Anways I'm working on porting fsh to posix sh syntax (turns out /dev/tty is a problem there too), porting bash to wasi is unrealistic and would be unnecessarily large and heavy.

[ykhan21]

Also, you shouldn't need fzf if you just want to automate downloads.

[Lockl00p]

Yeah we're trying to get a fuzzyfinder because ani-cli requires fzf and port19 doesn't want to have to go back to the previous interface just to support a-shell

[ykhan21]

I see. But downloading isn't interactive, right? Or is it? @port19x, if it isn't fzf shouldn't be checked as a dependency. Edit: Never mind, see my comment below.

[Lockl00p]

This sucks.

I don't think we're making any meaningful improvements over iSH if we have our users compile fzf and go. Also, we definitely won't be switching away from fzf just for better iOS support.

I suggest you collaborate with upstream to get go (and possibly fzf) into a-shell. Alternatively, if there is a package repo like there is on android for termux, make it available there. If neither seem plausible, we can pretty much close this

I'll try to get go working with a-shell though if I do, it will likely be with a ton of missing features (namely anything that requires interaction with the filesystem/os)

[ykhan21]

@bbb651, if you use the -S and -e (or the -S and -r) flags, ani-cli will be in non-interactive mode and won't check for fzf. The -S flag has to come before the -e flag for it to enter non-interactive mode. https://github.com/pystardust/ani-cli/blob/0ade589e649d7cb91a51c3a82a6e5b094f54c71b/ani-cli#L385

[Lockl00p]

iSH has been quite underwhelming and requires by far the most hoops to jump through, so I welcome any experiments to replace it with a better shell (a-shell)

Huh, funnily enough, if this ever works. it would require you to jump through a ton of hoops

[bbb651]

I know about non interactive mode but to supersede iSH support, we're going to need to support it (especially because it's the default, and guessing exact anime titles to avoid downloading the whole thing which might take a while and waste data is not an acceptable experience).

Also I was wrong about reading input from stdin instead of /dev/tty, I don't think it's possible while reading piped input, but you can workaround it by reading from stdout, I tested it and it works on a-shell.

[Lockl00p]

So I managed to get fzy-js algorithm to work with jsc (cause turns out you can install node modules to a-shell, which you can use when running any js file on there. I'm going to then try to make a basic fuzzyfinder in js that's similar enough to fzy so that I can add support to fzy, and also use that support with a-shell.

[71zenith]

js at this point i'd quit tbh if this wasnt obvious

[Lockl00p]

js at this point i'd quit tbh if this wasnt obvious

Eh, you’re right. I think I might just wait for his fsh port.

[Lockl00p]

I have noticed that a-shell is so much worse than iSH. In return for the speed boost, you have to deal with WASI, randomly crash when opening dash, and for some reason sometimes outputted text that’s longer than your screen width just doesn’t wrap… @bbb651 are you sure this is worth it right now? Shouldn’t we at least wait till the bugs are ironed out?