Installing in iSH (iPhone Alpine Linux emulator with BusyBox)

[MilesCranmer]

I’m trying to use juliaup to install Julia on my iPhone. For the Linux emulator I’m using https://ish.app/ which is based on AlpineLinux and includes BusyBox tools for the various utilities. While I obviously don’t expect this to be supported, I do think it’s a nice test case for how robust the installation is.

I use the Linux command

curl -fsSL https://install.julialang.org | sh

but this gives me the error

info: downloading installer
ps: unrecognized option: p
BusyBox v1.33.1 () multi-call binary.

Usage: ps [-o COL1,COL2=HEADER] [-T]

Show list of processes

        -o COL1,COL2=HEADER     Select columns for display
        -T                      Show threads
thread panicked while processing panic. aborting.

Why is the ps necessary in the installer? Could it be skipped if this command isn’t available?

[MilesCranmer]

I installed a more complete procps but now I get the error

info: downloading installer
thread panicked while processing panic. aborting.

[uncomfyhalomacro]

idk if juliaup supports busybox as of this moment.

[uncomfyhalomacro]

Why is the ps necessary in the installer? Could it be skipped if this command isn’t available?

Same question

[davidanthoff]

I believe we could move https://github.com/JuliaLang/juliaup/blob/bdcaa9dd04e256be6022f2a787defdc2fb911758/deploy/shellscript/juliaup-init.sh#L133 into the first if block just below and then one should be able to skip the call to ps with a silent install.

PR welcome!

[fingolfin]

I implemented David's suggestion in PR #781

The call to ps is used to determine the pty / pseudo terminal to which the user's shell is connected, so that input can be read from there (the input of the script being run is after all connected to the output of curl, which is why this is necessary).

However, what I don't understand at this point is why we can't use /dev/tty -- this is was the corresponding script in rustup does. Looking at the git history of this repository, this also used to be used here, but was changed in f0cb43778b78eb15c10afd559820ca24ebc1c35c and c88f57fe712acacfb8343e584d3eb9b350ff10b7, per the commit messages "to fix tty problem" -- but unfortunately it is not clear from this what the original problem was?

[fingolfin]

Based on content and timing I suspect issue #174 (and #220) is what lead to the change away from /dev/tty.

However, I cannot reproduce the issues there on a VM with macOS 12 (the issue does not specify the macOS version, so this is my best guess based on the date). Though maybe my test methodology is flawed? I first piped the output of curl into a file foo.sh; then edited that to replace the /dev/... command by just /dev/tty ; then did cat foo.sh | sh.

I also don't understand how the changes would be related to the issue (I am not claiming they aren't, just that I don't understand). That said, @davidanthoff wrote back then:

So this is just a generic Mac problem, unrelated to the chip used.

Which sounds like he knows more about the issue and perhaps can shed some light on what's going on.