11 ms·

iSH – A Linux shell on iOS

153 points by gbrown_ 8y ago

ianwalter 8y ago
Is this the first time this is being done? Why isn’t this getting more attention? This would be amazing!
- saagarjha 8y ago
  > Is this the first time this is being done? No. There have been multiple efforts to do something like this before; I seem to recall one app on the App Store that attempted to simulate commands being run by parsing arguments and performing the correct actions as they were entered. Personally, I have an experimental shell that abuses cross-compiled Mach-O ARM64 shell binaries, but there are some limitations to this approach that I need to resolve regarding codesigning, App Store guidelines, and advanced shell features such as piping which are difficult to emulate in the single process that iOS gives you. I might get around to posting it online if I get the time.
- saurik 8y ago
  This is an obvious approach that absolutely has been done before (though maybe not as efficiently), but is not App Store complaint (as you can use this to download new functionality that the app did not ship with that is then executed on the device using a virtual machine that is not JavaScriptCore) and so is being distributed via Test Flight (which apparently has way more open terms of use than I would ever have expected). This really isn't that interesting (to some very real extent, "sadly": it sucks that Apple is allowed to say these kinds of apps can't exist).
  - saagarjha 8y ago
    > is not App Store complaint (as you can use this to download new functionality that the app did not ship with that is then executed on the device using a virtual machine that is not JavaScriptCore) Apple has recently added an exception to this rule if you’re willing to classify your app as an “educational” app, and allow for the viewing and editing of the source code you download. Since this shell allows for grabbing a copy of the source code of the packages you install, and compiling them yourself, I think it just barely falls within the rules: > 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user. > is being distributed via Test Flight (which apparently has way more open terms of use than I would ever have expected) There is no exemption for TestFlight apps; they should comply with the App Store Review Guidelines as usual: > Any app submitted for beta distribution via TestFlight should be intended for public distribution and should comply with the App Review Guidelines. Note that any builds that go through TestFlight are subject to a review process.
    - saurik 8y ago
      But I can use this to download things that are not open source... I can use this to download SOCKS proxies (that despite not being VPNs I believe are still banned in the Chinese App Store, though I might be wrong about that: they are definitely illegal in China)... hell: I can use this to download other (even less efficient) emulators for other architectures. I mean, this is literally "an emulator", which is a core example of a thing that Apple wants to not exist. I mean: this is a great implementation of an emulator. I have downloaded and tried iSH, and it is actually "kind of epic". This isn't exactly what I thought it would be, glancing at the source code: it sounded like it would be running the Linux kernel (so actually be Linux) in console mode, but this is a library operating system and is very similar in many ways to the project I sometimes talk about (which also provided a library operating system, but was going to distribute pre-compiled code as part of the application to avoid needing an emulator), but this is clearly better as an emulator (and is much easier to do, despite this emulator being a slightly harder emulator to build than most). So, this is a great implementation of this--this is even a "heroic" implementation of this--but, at the end of the day, this is the thing Apple was trying to stop (as much as I hate Apple for that).
      - saagarjha 8y ago
        > But I can use this to download things that are not open source. Ok, let's widen our view of open source then. Pythonista lets you download Python code and then it interprets it, and iSH lets you download compiled x86 code and then interprets that. So it's still open source, see! > I can use this to download SOCKS proxies (that despite not being VPNs I believe are still banned in the Chinese App Store, though I might be wrong about that: they are definitely illegal in China) I'm not following you. How would iSH be able to actually apply these proxies system-wide unless it's a VPN app, which as far as I'm aware it's not? All it can do is possibly download VPN profiles, but I can do that in Safari too. Perhaps I'm misunderstanding how SOCKS works, but I don't see how this could change anything except traffic you're sending in-app at the most. > I mean, this is literally "an emulator", which is a core example of a thing that Apple wants to not exist. You're going to have to provide evidence for that–Apple used to do this by citing 2.5.2 in their App Store Review Guidelines, which explicitly forbid this kind of thing, but as I mentioned there is now an exception poked in it for "educational use". Has any "educational" (i.e. non-piracy) emulator recently been rejected by Apple, and if so, under what grounds? > at the end of the day, this is the thing Apple was trying to stop Again, I disagree that Apple would try to stop this, at least under the current set of rules that they have. The fact that it made it through TestFlight review is pretty telling, I think.
  - k__ 8y ago
    I don't understand the problem here. Maybe it isn't App Store compliant, but who cares? I don't install my dev tools on the desktop via app stores either. For all I care, someone could port Homebrew for iOS and force me to install it via Xcode.
    - saagarjha 8y ago
      You do not have to sign your development tools on your desktop machine to get them to install. To have a semi-usable situation, i.e. one where you’re not forced to reinstall your tools every week, you need to pay a non-negligible amount to Apple regularly so that you can sign and run this software. Porting Homebrew would never work, at least in it’s current state, not the least because it seems to be designed around everything going in /usr/local and breaking violently if you don’t stick everything in there and forcefully chmod/chown it to yourself ;P
      - jsjohnst 8y ago
        > not the least because it seems to be designed around everything going in /usr/local and breaking violently if you don’t stick everything in there This hasn’t been true for a long time.
        saagarjha 8y ago
        Homebrew themselves recommend against installing software anywhere else: https://docs.brew.sh/Installation https://docs.brew.sh/Installation. It just isn’t built for installing to anywhere else, regardless of the security and usability issues this causes.
- jsjohnst 8y ago
  I booted full Linux (Also Windows 95, albeit very very very slowly) on Bochs using the first gen iPad six or seven years ago, so definitely been done. This just seems more polished and user friendly. With the performance of the latest iPad Pro, I’ve been meaning to dust off that code and see what’s possible now.
newusertoday 8y ago
Performance would have been much better if they did not emulated x86 on arm.
- saagarjha 8y ago
  How would you suggest that they go about doing this?
  - 0xdeadb00f 8y ago
    Shouldn't they just run Linux on arm? Seeing as Linux already supports it?
    - saagarjha 8y ago
      You’re going to have to be more specific; what exactly do you mean by “run Linux on ARM”? Sure, I can compile Linux for ARM and put it in an app, and provided I am careful, I can bootstrap the kernel and get Linux up and running. But what do I do from here? I have Linux “running”, but it no container app around it anymore to allow interaction with iOS. (This is, of course, considering that you have gotten codesigning to work correctly and have full control over when the kernel JITs).
      - 0xdeadb00f 8y ago
        I mean they should have just emulated Linux on an arm processor, seeing as the hardware (Apple A-series) is already arm-based I assume that wouldn't cause as many performance issues as emulating a completely different architecture, x86. I assume, based on the first comment in this chain - I'm not experienced with emulation of different processor architectures.
        saagarjha 8y ago
        Like I said, “emulat[ing] Linux on an arm processor” is not as simple as you make it seem. To do something similar on x86, that is, run Linux on your Intel processor, you need virtualization software that acts as a hypervisor. iOS devices do not provide the capabilities to write software like this, so doing any sort of emulation in this way would not really work.
RBerenguel 8y ago
Emacs (still?) not working, just tried. Had to!
dayvough 8y ago
I like how there's a goto and a fuck counter.
Walkman 8y ago
Unfortunately python3 returns with an "Illegal instruction" and doesn't start :( Would be very cool if it would be possible to run Python on this!
- update 8y ago
  python3 is breaking my heart. I upgraded my code from py2 to py3, and since then, seems like every 6 months my code will break due to a new python update (I'm on Fedora, fyi). Just last week a bunch of my python3 code stopped working for my IRC bot. I honestly regret switching to python 3 at this point.
  - saagarjha 8y ago
    Python breaking here is separate from Python 3 breaking your code, just FYI.
phelmig 8y ago
It works surprisingly well on my old iPad Pro! Thank you for building this. Sure, many tools that require additional privileges (and some syscalls?) do not work, but i’d love to see more progress here. Having a local linux shell on my iPad would be a game changer for me.
jonhohle 8y ago
I was just thinking about a busybox-like terminal emulator for iOS earlier this weekend that would be App Store compliant. Maybe this will scratch that itch.
SeriousM 8y ago
Isn't ios based on Linux? Sorry for the dumb question...
- wilsonnb3 8y ago
  I believe it uses the same kernel as MacOS which is based on some kind of BSD.
  - yjftsjthsd-h 8y ago
    The kernel is called XNU; it's a weird Mach derivative which I do believe has pieces of BSD grafted on.
- k__ 8y ago
  iOS is based on macOS, which is based on NeXTStep, which is based on BSD.
  - TickleSteve 8y ago
    NeXTStep is based on Mach, not BSD. MacOS has a BSD user-land, the kernel isn't anything to do with BSD.
    - lukeh 8y ago
      The macOS kernel has lots of BSD bits in it [1], it's not a classic microkernel in that sense. [1] https://github.com/apple/darwin-xnu/tree/master/bsd https://github.com/apple/darwin-xnu/tree/master/bsd
      - TickleSteve 8y ago
        If you look at the contents of that repo, you will see that the majority of the code there is headers to allow compilation of very specific parts (e.g the net and inet directories), not the whole codebase. Certainly, there is no kernel there and most calls redirect back into xnu. Most functionality is Mach-based, this is just for a user-facing API.
electrograv 8y ago
Does anyone else wish they could do real coding on an iPad, Unix style? That would be so awesome; the new iPad Pro’s especially are fantastic pieces of hardware, and it’s a shame that although you can be productive via word processing, media editing, etc on them, coding is not really viable. I’ll have to read more about iSH to learn if it’s a “true” shell, or effectively just emulated or with strict limitations, but either way the potential inspires of how great it would be to have a true shell and/or dev tools for iPads.
- jerkstate 8y ago
  I use mosh via the Blink client and the Logitech keyboard on my '17 iPad Pro and do a lot of coding on it on remote servers. The lack of an escape key sucks and I had to figure out how to do code folding in vim but it's pretty serviceable. Of course I still prefer giant monitors to fit a lot of different panes for inspection and debugging, but it's pretty serviceable.
  - saurik 8y ago
    You can plug an iPad into a giant external monitor using the lightning to HDMI cable, so really you directly just miss "lots of windows open at once".
    - bronco21016 8y ago
      How do you interface with it then? So many parts of most workflows still require using the touch interface.
    - goerz 8y ago
      In particular with Blink, the app will actually recognize the monitor as a second screen, and use it at full resolution (as opposed to mirroring the normal iPad screen). With tmux, this means you can arrange as many horizontal and vertical splits as you can fit onto the monitor.
    - saagarjha 8y ago
      > You can plug an iPad into a giant external monitor using the lightning to HDMI cable Or, on newer iPads, directly via the USB C connector. And apps can recognize that you have chosen to plug in a secondary display and suit their content to match on the other screen.
rsska 8y ago
On github page is not specified, but you can support iSH project on patreon.com.
f055 8y ago
Why not use Screens/NoMachine to remote access desktops on iPad Pro? It’s blazing fast on local network, and reasonable via the internet. You could have an on-demand bootable Ubuntu or Windows via Azure quite cheaply.
- terhechte 8y ago
  For many people, the use case scenario here is to use it while travelling. Oftentimes, there's no Internet when travelling around (or slow internet).
goerz 8y ago
This is so, so close to allow me to run a full local vim (with the necessary external tools, like python and git). The only thing I found that was a dealbreaker was the lack of unicode support (https://github.com/tbodt/ish/issues/28 https://github.com/tbodt/ish/issues/28), and not being able to map caps-lock to escape. For now, Nicolas Holzschuch's fork of iVim (https://github.com/holzschu/iVim https://github.com/holzschu/iVim) is still by far the best solution, but iSH definitely has the potential to take over.
d0mine 8y ago
If you are a Python developer, try StaSh - Shell for Pythonista on iOS. https://github.com/ywangd/stash https://github.com/ywangd/stash
notaplumber 8y ago
I feel like I'm a bit out of the loop here, getting a local shell on an iOS device was one of the immediate benefits from Jailbreaking. It was even a native iOS binary, usually bash or Korn Sell, along with sshd. No need for such an elaborate Linux ABI transposing layer, as the iOS kernel supported enough Unix to run this stuff fine. But even if the iOS SDK/libc has since dropped certain functions or POSIX headers, the kernel undoubtedly still supports it. If this software could be developed and installed, cross-compiling a native Unix toolchain, either from the open source code distributed by Apple, or the BSDs, or even GNU, should be just as easy to pull off. So what gives?
- JonathonW 8y ago
  The tricky part with an unjailbroken device (for third-party developers) is that apps can’t fork/exec, or any of the equivalents— aside from a couple exceptions around app extensions, the binary that gets run when the user taps the app on the home screen is the only one that ever can be run. That’s fine for most GUI-driven applications, but it’s kind of problematic for a traditional *nix-style shell. If you were Apple, or you had a jailbroken device and could circumvent the sandbox, you wouldn’t have any problems running a normal shell and command line utilities.
  - notaplumber 8y ago
    That's interesting, indeed-- it is unfortunate that developers have no ability to circumvent these restrictions even for local development. It makes owning such a device even more baffling, sounds incredibly useless to me. I didn't know iOS was such a trash fire.
    - umanwizard 8y ago
      Really, you can't understand why anyone would buy a device that you can't easily run a shell on? Can you run bash on your dishwasher?
      - notaplumber 8y ago
paultopia 8y ago
I AM RUNNING VIM ON MY IPAD BECAUSE OF THIS. THIS IS THE HAPPIEST DAY. Are there any plans to build some kind of connection between the filesystem here and the native ios filesystem-thingy? It would be delightful to be able to edit something in real vim and then save it to icloud...
- goerz 8y ago
  I think the connection is already there! You can access iSH files in the Files app and move them freely to and from iCloud.
  - paultopia 8y ago
    You're right! This is beautiful!
- drags7er 8y ago
  I tried out iVim for a few hours. It has vimrc support and integration with the files app. It also integrates with The blink shell app so that you can edit files on remote through vim and ssh
- emit_time 8y ago
  Have you used iVim[1]? [1]: https://itunes.apple.com/us/app/ivim/id1266544660?mt=8 https://itunes.apple.com/us/app/ivim/id1266544660?mt=8

153 points by gbrown_ 8y ago

ianwalter 8y ago

Is this the first time this is being done? Why isn’t this getting more attention? This would be amazing!

saagarjha 8y ago
> Is this the first time this is being done? No. There have been multiple efforts to do something like this before; I seem to recall one app on the App Store that attempted to simulate commands being run by parsing arguments and performing the correct actions as they were entered. Personally, I have an experimental shell that abuses cross-compiled Mach-O ARM64 shell binaries, but there are some limitations to this approach that I need to resolve regarding codesigning, App Store guidelines, and advanced shell features such as piping which are difficult to emulate in the single process that iOS gives you. I might get around to posting it online if I get the time.
saurik 8y ago
This is an obvious approach that absolutely has been done before (though maybe not as efficiently), but is not App Store complaint (as you can use this to download new functionality that the app did not ship with that is then executed on the device using a virtual machine that is not JavaScriptCore) and so is being distributed via Test Flight (which apparently has way more open terms of use than I would ever have expected). This really isn't that interesting (to some very real extent, "sadly": it sucks that Apple is allowed to say these kinds of apps can't exist).
- saagarjha 8y ago
  > is not App Store complaint (as you can use this to download new functionality that the app did not ship with that is then executed on the device using a virtual machine that is not JavaScriptCore) Apple has recently added an exception to this rule if you’re willing to classify your app as an “educational” app, and allow for the viewing and editing of the source code you download. Since this shell allows for grabbing a copy of the source code of the packages you install, and compiling them yourself, I think it just barely falls within the rules: > 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user. > is being distributed via Test Flight (which apparently has way more open terms of use than I would ever have expected) There is no exemption for TestFlight apps; they should comply with the App Store Review Guidelines as usual: > Any app submitted for beta distribution via TestFlight should be intended for public distribution and should comply with the App Review Guidelines. Note that any builds that go through TestFlight are subject to a review process.
  - saurik 8y ago
    But I can use this to download things that are not open source... I can use this to download SOCKS proxies (that despite not being VPNs I believe are still banned in the Chinese App Store, though I might be wrong about that: they are definitely illegal in China)... hell: I can use this to download other (even less efficient) emulators for other architectures. I mean, this is literally "an emulator", which is a core example of a thing that Apple wants to not exist. I mean: this is a great implementation of an emulator. I have downloaded and tried iSH, and it is actually "kind of epic". This isn't exactly what I thought it would be, glancing at the source code: it sounded like it would be running the Linux kernel (so actually be Linux) in console mode, but this is a library operating system and is very similar in many ways to the project I sometimes talk about (which also provided a library operating system, but was going to distribute pre-compiled code as part of the application to avoid needing an emulator), but this is clearly better as an emulator (and is much easier to do, despite this emulator being a slightly harder emulator to build than most). So, this is a great implementation of this--this is even a "heroic" implementation of this--but, at the end of the day, this is the thing Apple was trying to stop (as much as I hate Apple for that).
    - saagarjha 8y ago
      > But I can use this to download things that are not open source. Ok, let's widen our view of open source then. Pythonista lets you download Python code and then it interprets it, and iSH lets you download compiled x86 code and then interprets that. So it's still open source, see! > I can use this to download SOCKS proxies (that despite not being VPNs I believe are still banned in the Chinese App Store, though I might be wrong about that: they are definitely illegal in China) I'm not following you. How would iSH be able to actually apply these proxies system-wide unless it's a VPN app, which as far as I'm aware it's not? All it can do is possibly download VPN profiles, but I can do that in Safari too. Perhaps I'm misunderstanding how SOCKS works, but I don't see how this could change anything except traffic you're sending in-app at the most. > I mean, this is literally "an emulator", which is a core example of a thing that Apple wants to not exist. You're going to have to provide evidence for that–Apple used to do this by citing 2.5.2 in their App Store Review Guidelines, which explicitly forbid this kind of thing, but as I mentioned there is now an exception poked in it for "educational use". Has any "educational" (i.e. non-piracy) emulator recently been rejected by Apple, and if so, under what grounds? > at the end of the day, this is the thing Apple was trying to stop Again, I disagree that Apple would try to stop this, at least under the current set of rules that they have. The fact that it made it through TestFlight review is pretty telling, I think.
- k__ 8y ago
  I don't understand the problem here. Maybe it isn't App Store compliant, but who cares? I don't install my dev tools on the desktop via app stores either. For all I care, someone could port Homebrew for iOS and force me to install it via Xcode.
  - saagarjha 8y ago
    You do not have to sign your development tools on your desktop machine to get them to install. To have a semi-usable situation, i.e. one where you’re not forced to reinstall your tools every week, you need to pay a non-negligible amount to Apple regularly so that you can sign and run this software. Porting Homebrew would never work, at least in it’s current state, not the least because it seems to be designed around everything going in /usr/local and breaking violently if you don’t stick everything in there and forcefully chmod/chown it to yourself ;P
    - jsjohnst 8y ago
      > not the least because it seems to be designed around everything going in /usr/local and breaking violently if you don’t stick everything in there This hasn’t been true for a long time.
      - saagarjha 8y ago
        Homebrew themselves recommend against installing software anywhere else: https://docs.brew.sh/Installation https://docs.brew.sh/Installation. It just isn’t built for installing to anywhere else, regardless of the security and usability issues this causes.
jsjohnst 8y ago
I booted full Linux (Also Windows 95, albeit very very very slowly) on Bochs using the first gen iPad six or seven years ago, so definitely been done. This just seems more polished and user friendly. With the performance of the latest iPad Pro, I’ve been meaning to dust off that code and see what’s possible now.

newusertoday 8y ago

Performance would have been much better if they did not emulated x86 on arm.

saagarjha 8y ago
How would you suggest that they go about doing this?
- 0xdeadb00f 8y ago
  Shouldn't they just run Linux on arm? Seeing as Linux already supports it?
  - saagarjha 8y ago
    You’re going to have to be more specific; what exactly do you mean by “run Linux on ARM”? Sure, I can compile Linux for ARM and put it in an app, and provided I am careful, I can bootstrap the kernel and get Linux up and running. But what do I do from here? I have Linux “running”, but it no container app around it anymore to allow interaction with iOS. (This is, of course, considering that you have gotten codesigning to work correctly and have full control over when the kernel JITs).
    - 0xdeadb00f 8y ago
      I mean they should have just emulated Linux on an arm processor, seeing as the hardware (Apple A-series) is already arm-based I assume that wouldn't cause as many performance issues as emulating a completely different architecture, x86. I assume, based on the first comment in this chain - I'm not experienced with emulation of different processor architectures.
      - saagarjha 8y ago
        Like I said, “emulat[ing] Linux on an arm processor” is not as simple as you make it seem. To do something similar on x86, that is, run Linux on your Intel processor, you need virtualization software that acts as a hypervisor. iOS devices do not provide the capabilities to write software like this, so doing any sort of emulation in this way would not really work.

RBerenguel 8y ago

Emacs (still?) not working, just tried. Had to!

dayvough 8y ago

I like how there's a goto and a fuck counter.

Walkman 8y ago

Unfortunately python3 returns with an "Illegal instruction" and doesn't start :( Would be very cool if it would be possible to run Python on this!

update 8y ago
python3 is breaking my heart. I upgraded my code from py2 to py3, and since then, seems like every 6 months my code will break due to a new python update (I'm on Fedora, fyi). Just last week a bunch of my python3 code stopped working for my IRC bot. I honestly regret switching to python 3 at this point.
- saagarjha 8y ago
  Python breaking here is separate from Python 3 breaking your code, just FYI.

phelmig 8y ago

It works surprisingly well on my old iPad Pro! Thank you for building this. Sure, many tools that require additional privileges (and some syscalls?) do not work, but i’d love to see more progress here. Having a local linux shell on my iPad would be a game changer for me.

jonhohle 8y ago

I was just thinking about a busybox-like terminal emulator for iOS earlier this weekend that would be App Store compliant. Maybe this will scratch that itch.

SeriousM 8y ago

Isn't ios based on Linux? Sorry for the dumb question...

wilsonnb3 8y ago
I believe it uses the same kernel as MacOS which is based on some kind of BSD.
- yjftsjthsd-h 8y ago
  The kernel is called XNU; it's a weird Mach derivative which I do believe has pieces of BSD grafted on.
k__ 8y ago
iOS is based on macOS, which is based on NeXTStep, which is based on BSD.
- TickleSteve 8y ago
  NeXTStep is based on Mach, not BSD. MacOS has a BSD user-land, the kernel isn't anything to do with BSD.
  - lukeh 8y ago
    The macOS kernel has lots of BSD bits in it [1], it's not a classic microkernel in that sense. [1] https://github.com/apple/darwin-xnu/tree/master/bsd https://github.com/apple/darwin-xnu/tree/master/bsd
    - TickleSteve 8y ago
      If you look at the contents of that repo, you will see that the majority of the code there is headers to allow compilation of very specific parts (e.g the net and inet directories), not the whole codebase. Certainly, there is no kernel there and most calls redirect back into xnu. Most functionality is Mach-based, this is just for a user-facing API.

electrograv 8y ago

Does anyone else wish they could do real coding on an iPad, Unix style? That would be so awesome; the new iPad Pro’s especially are fantastic pieces of hardware, and it’s a shame that although you can be productive via word processing, media editing, etc on them, coding is not really viable. I’ll have to read more about iSH to learn if it’s a “true” shell, or effectively just emulated or with strict limitations, but either way the potential inspires of how great it would be to have a true shell and/or dev tools for iPads.

jerkstate 8y ago
I use mosh via the Blink client and the Logitech keyboard on my '17 iPad Pro and do a lot of coding on it on remote servers. The lack of an escape key sucks and I had to figure out how to do code folding in vim but it's pretty serviceable. Of course I still prefer giant monitors to fit a lot of different panes for inspection and debugging, but it's pretty serviceable.
- saurik 8y ago
  You can plug an iPad into a giant external monitor using the lightning to HDMI cable, so really you directly just miss "lots of windows open at once".
  - bronco21016 8y ago
    How do you interface with it then? So many parts of most workflows still require using the touch interface.
  - goerz 8y ago
    In particular with Blink, the app will actually recognize the monitor as a second screen, and use it at full resolution (as opposed to mirroring the normal iPad screen). With tmux, this means you can arrange as many horizontal and vertical splits as you can fit onto the monitor.
  - saagarjha 8y ago
    > You can plug an iPad into a giant external monitor using the lightning to HDMI cable Or, on newer iPads, directly via the USB C connector. And apps can recognize that you have chosen to plug in a secondary display and suit their content to match on the other screen.

rsska 8y ago

On github page is not specified, but you can support iSH project on patreon.com.

f055 8y ago

Why not use Screens/NoMachine to remote access desktops on iPad Pro? It’s blazing fast on local network, and reasonable via the internet. You could have an on-demand bootable Ubuntu or Windows via Azure quite cheaply.

terhechte 8y ago
For many people, the use case scenario here is to use it while travelling. Oftentimes, there's no Internet when travelling around (or slow internet).

goerz 8y ago

This is so, so close to allow me to run a full local vim (with the necessary external tools, like python and git). The only thing I found that was a dealbreaker was the lack of unicode support (https://github.com/tbodt/ish/issues/28 https://github.com/tbodt/ish/issues/28), and not being able to map caps-lock to escape. For now, Nicolas Holzschuch's fork of iVim (https://github.com/holzschu/iVim https://github.com/holzschu/iVim) is still by far the best solution, but iSH definitely has the potential to take over.

d0mine 8y ago

If you are a Python developer, try StaSh - Shell for Pythonista on iOS. https://github.com/ywangd/stash https://github.com/ywangd/stash

notaplumber 8y ago

I feel like I'm a bit out of the loop here, getting a local shell on an iOS device was one of the immediate benefits from Jailbreaking. It was even a native iOS binary, usually bash or Korn Sell, along with sshd. No need for such an elaborate Linux ABI transposing layer, as the iOS kernel supported enough Unix to run this stuff fine. But even if the iOS SDK/libc has since dropped certain functions or POSIX headers, the kernel undoubtedly still supports it. If this software could be developed and installed, cross-compiling a native Unix toolchain, either from the open source code distributed by Apple, or the BSDs, or even GNU, should be just as easy to pull off. So what gives?

JonathonW 8y ago
The tricky part with an unjailbroken device (for third-party developers) is that apps can’t fork/exec, or any of the equivalents— aside from a couple exceptions around app extensions, the binary that gets run when the user taps the app on the home screen is the only one that ever can be run. That’s fine for most GUI-driven applications, but it’s kind of problematic for a traditional *nix-style shell. If you were Apple, or you had a jailbroken device and could circumvent the sandbox, you wouldn’t have any problems running a normal shell and command line utilities.
- notaplumber 8y ago
  That's interesting, indeed-- it is unfortunate that developers have no ability to circumvent these restrictions even for local development. It makes owning such a device even more baffling, sounds incredibly useless to me. I didn't know iOS was such a trash fire.
  - umanwizard 8y ago
    Really, you can't understand why anyone would buy a device that you can't easily run a shell on? Can you run bash on your dishwasher?
    - notaplumber 8y ago

paultopia 8y ago

I AM RUNNING VIM ON MY IPAD BECAUSE OF THIS. THIS IS THE HAPPIEST DAY. Are there any plans to build some kind of connection between the filesystem here and the native ios filesystem-thingy? It would be delightful to be able to edit something in real vim and then save it to icloud...

goerz 8y ago
I think the connection is already there! You can access iSH files in the Files app and move them freely to and from iCloud.
- paultopia 8y ago
  You're right! This is beautiful!
drags7er 8y ago
I tried out iVim for a few hours. It has vimrc support and integration with the files app. It also integrates with The blink shell app so that you can edit files on remote through vim and ssh
emit_time 8y ago
Have you used iVim[1]? [1]: https://itunes.apple.com/us/app/ivim/id1266544660?mt=8 https://itunes.apple.com/us/app/ivim/id1266544660?mt=8