A continuation of the story of how write(1) saved the day. I still had to resolve the package manager issues at some point.
The problem? Of course, their computer is behind NAT, so I can't log into it directly, even if they enabled SSH logins.
I knew what I had to do: set up some way for their machine to initiate the connection and effectively connect me to a shell over there by redirecting streams.
At first, I was going to write it in shell. But I soon realized I couldn't do that because, at least unless I'm mistaken, shell can't read from and write to something at the same time.
I thought I'd do it in Python, because I like Python and I know the interpreter is installed on my friend's machine. But then I realized I needed concurrency to make a bidirectional connection, and concurrency in Python is a pain... I'd used that
selectors API or whatever before, but I didn't remember how it worked and didn't want to deal with it.
I was well familiar with Go's stdlib APIs for process and stream control and thought they were a bit more elegant than Python's, so I ended up writing it in Go. However, I still ran into issues with not block-buffering it and making it bidirectional because the server-side command I was communicating with was
Then I remembered netcat. Netcat would be easier than ssh and piping stuff through a fifo, because I know it's line-buffered and designed to be bidirectional. Alas, the next thing I remembered was that I'd neglected to install netcat on my friend's machine.
No problem! I'd scp the binary to the server and they could scp it back. I was already going to do the same thing for my Go binary.
And it worked! My friend was able to use this to give me a shell on their laptop, and I diagnosed the problem with XBPS and fixed it.