Urbit: Logging to file dumps core

[yourfavouriteuncle]

Using urbit 1.0 on nixos unstable with the base hash u8adu. The terminal is alacritty with tmux and bash

[car@dev:~/fun/urbit]$ ./urbit -v rignet-bicteg > log.log
loom: mapped 2048MB
boot: protected loom
live: loaded: MB/143.982.592
boot: installed 286 jets
hija-tcsetattr-1: Not a tty
Assertion '!"hija-tcsetattr"' failed in vere/io/term.c:1465

bail: oops
bailing out
serf: pier unexpectedly shut down
Aborted (core dumped)

[yourfavouriteuncle]

I found this while debugging #4146

[joemfb]

By default, urbit expects to run interactively (in a tty). You can disable that expectation with -t, which should solve the problem here.

There's a check for this condition in the terminal code, with a helpful error message associated (see #3905). But we're hitting a related assertion before we get to the check, which is a bug.

[ohAitch]

(And the check aborting instead of just flipping on the flag is arguably also a bug)

[joemfb]

After some local testing, -t will indeed work around this problem. But redirecting output to a file is poorly supported: lots of things write to stderr (across two processes), and the cli options parser doesn't like ./build/urbit -t fake-zod 2>&1 log.out (which is pretty bizarre).

The isatty() check from #3905 is not really relevant -- stdout is a tty, but it's being a piped in a manner that is incompatible with tcsetattr(..., TCSADRAIN, ...). Which, in turn, is being called to hijack and reconfigure the console for logging ouput via fprintf(). The lowest levels of our terminal implementation are a (relatively small) pile of poorly-understood hacks ...

(As an aside for my future self, maybe the terminal hijack/lojack pattern should just be replaced with fmemopen()?)