Please add mosh about a-shell

[jaclu]

tmux isn't really needed in a-Shell, can be started with mosh (or ssh) on the remote end
mosh user@server -- tmux new session -ADs sesname

[normen]

Shouldn't blink's mosh binary actually work in a-shell? They're both using the same backend. Extra cookie for anyone finding the actual binary in blink 😄

[berot3]

Why should blink be the only one? Why shouldn’t there be an alternative?

Also, for ease of use I could place a iOS shortcut on the Home Screen that directly starts mosh-command plus my flags/options. I can’t do this with blink.

[holzschu]

For the time being, you cannot download binaries inside an app that is on the AppStore (or, rather, you can download them but not execute them). That makes anything like brew close to impossible. iSH works around this using x86 binaries (not Arm64) that are interpreted. They can load anything, but it's not fast. a-Shell uses mostly native binaries that are embedded inside the app (these are fast), but can also load WebAssembly binaries (you can install these with pkg install). But it's not that easy to compile a command to WebAssembly, so the list of commands is relatively small.

[goerz]

Tmux would definitely be great, but if you're connecting to another machine (with mosh), how would a-shell improve on Blink?

[weiszr]

Can you ssh though? I get an error message that keys cannot be found. RW

…

______________________________________________________________ *Dr. Robert Weiss* Professor of Natural Hazards DRRMVT, Director; Coastal@VT, Co-lead Department of Geosciences Virginia Tech 4044 Derring Hall (0420) Blacksburg, VA 24061, U.S.A. Offices: 1068A Derring & 207A Fralin Phone:[phone] Fax: [phone] Web: http://coastalhazardsvt.weebly.com https://fralin.vt.edu/gssda/coastal.html https://www.drrm.fralin.vt.edu/index.php Twitter: @VTCoastal Research Web: http://coastalhazardsvt.weebly.com Education Web: https://fralin.vt.edu/DRRM.html Twitter: @VTCoastal

On Tue, Oct 1, 2019 at 3:52 PM Michael Goerz ***@***.***> wrote: Tmux would definitely be great, but if you're connecting to another machine (with mosh), how would a-shell improve on Blink? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=AAKYINSXQA4ERGFAS3MFUXTQMOS65A5CNFSM4IUVPLNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEACQRUI#issuecomment-537200849>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKYINWYQ75XI4UJ7CZ3VGTQMOS65ANCNFSM4IUVPLNA> .

[fauzias]

There are more to it than that on mosh, as it enable real "mobile" experiences terminal, faster, persistence, always on.
If in addition a-shell could have mosh builtin, i would (and i believe many will) move to a-shell.

[normen]

+1 for mosh support, ssh is nonsense on a mobile device

[jaclu]

+1 for mosh

[martinorob]

There are more to it than that on mosh, as it enable real "mobile" experiences terminal, faster, persistence, always on.
If in addition a-shell could have mosh builtin, i would (and i believe many will) move to a-shell.

Totally agree.
+1 for mosh

[weiszr]

Having mosh and tmux available in a-shell would still be great as they would two different use cases to work for me. I should not have put both in the same GitHub issue.

[drewcassidy]

+1 for mosh. Mosh support would make a-shell the only shell I ever need but for now I will have to use blink for remote connections. SSH is just too finicky on a mobile device

[holzschu]

The strong point of Blink is their management of SSH keys and how they make it seamless for the user, plus how they integrate it with iOS key system. I think that their commands that rely on this key management are deeply integrated with the main code.
Also, since iOS_system got started in large part thanks to them, I'm not very keen on being in direct competition with them.

[normen]

I'm not very keen on being in direct competition with them.

Well given that they expanded Blink to basically be Visual Studio Code plus they'd still have the advantages you mentioned I guess it won't be direct competition - but I get where you're coming from.

[xloem]

I wonder if the Blink team were conducive, if a-shell could somehow interoperate such that it called out to Blink to provide mosh functionality?

[jaclu]

I might not have understood your reasoning, but why not just launch Blink for mosh sessions if you have both installed? That's what I do.
I agree that mosh would be a good feature in a-Shell, but if all the suggested feature does is to launch another application, it seems to build complexity and dependencies, whereas simply launching the other App would be far less error-prone. You would probably have to define the target host in Blink anyhow.

[xloem]

Honestly I use a-Shell because I can navigate a terminal much more easily than iOS's normal interface. It would also provide for launching mosh from scripts. But I am not asking you to hop to and write major infrastructure; it was just meant as an idea if there is further discussion and interest.

For example, a middle ground might be offering it to Blink as a mode for advertisement, and keeping the featureset minimal. If typing 'mosh' in a-Shell produced output recommending the user install Blink, this could directly impact Blink's profits and they could possibly be interested in contributing back.

What you say about complexities sounds important. What I like about a-Shell is how it is so reliable, compared to say iSH which has crashes and terminal corruptions everywhere. The simplicity of a-Shell does seem a major boon.

EDIT: I think what is meaningful here is that if a lot of the a-Shell technology stems from Blink already, it seems like working with them more closely would in general be beneficial to the project, as then there can be some design feedback or cooperation.

[berot3]

Sorry if this has been answered else where, but why can’t we simply have brew on Linux in a-Shell? Everyone could simply install what they need! 🥹😄

[drkmc]

Also going to beg for Mosh, or, at least what it does, looking at its dependencies it might be a chore to put together, but it isn't exactly stealing from another project (which I don't want to have to install and deal with another shell just so I don't get booted out of my remote connection every time I flip closed my iPad).
Dependencies:
Requires: | libc.so.6(GLIBC_2.34)(64bit)libstdc++.so.6()(64bit)libstdc++.so.6(GLIBCXX_3.4)(64bit)libstdc++.so.6(CXXABI_1.3)(64bit)libm.so.6()(64bit)libgcc_s.so.1()(64bit)libgcc_s.so.1(GCC_3.0)(64bit)libm.so.6(GLIBC_2.2.5)(64bit)libgcc_s.so.1(GCC_3.3.1)(64bit)libstdc++.so.6(GLIBCXX_3.4.21)(64bit)libstdc++.so.6(GLIBCXX_3.4.29)(64bit)libstdc++.so.6(GLIBCXX_3.4.20)(64bit)libstdc++.so.6(GLIBCXX_3.4.15)(64bit)libz.so.1()(64bit)/usr/bin/perllibcrypto.so.3()(64bit)libcrypto.so.3(OPENSSL_3.0.0)(64bit)libtinfo.so.6()(64bit)libtinfo.so.6(NCURSES6_TINFO_5.0.19991023)(64bit)opensshlibprotobuf-3.21.12.so()(64bit)libutempter.so.0()(64bit)libutempter.so.0(UTEMPTER_1.1)(64bit)perl-IO-Socket-INET6perl-IO-Tty

Yes, Perl. D'oh!

But, that is for my (openSUSE) distro, so I don't know how much of that is a client requirement vs. the code that runs on the server. If you are only using Perl on the server side to run the server side of the sync that isn't as bad as having to add Perl to A-shell (which I am certainly not about to suggest!)

More details (which I have not read): https://www.usenix.org/system/files/login/articles/winstein.pdf and https://mosh.org/mosh-paper.pdf).

There is a python project which does pretty much the same thing as the synchronization protocol running between the client and server https://github.com/Hadron/entanglement.

You don't actually need to run the same protocol as Mosh if you come up with something that does the same thing--since you, the user, starts the unprivileged application running at the time you connect, the actual protocol you use isn't important, it is the functionality and design that is relevant.

If A-Shell wanted to have its own connect-via-SSH-and-stay-connected method that wasn't Mosh it would be fine--you just even send the particular synchronization Python code when you connect and run that as yourself.

[xloem]

Functionality to associate a resume-script with a-shell windows would let users configure them to reconnect to remote tmux sessions automatically when loaded.

[jaclu]

Regarding basing something on entanglement or other alternate implementations.

mosh is widly used and is kind of the default for detachable sessions. An alternative with a similar usage case could certainly be used, but to be meaningful it needs to be ready to use and easily deployable.