The perils of having an ancient
$HOME (a yak shaving story)
I build Firefox from source for obscure reasons, and for equally obscure reasons I do this from the Firefox development repo instead of, say, the source for the current release. Mozilla has recently been moving towards making Rust mandatory for building Firefox (see especially the comments). If you build the Mercurial tip from source this is currently optional, but I can see the writing on the wall so I decided to get a copy of Rust and turn this option on. If nothing else, I could file bugs for any problems I ran into.
Getting a copy of Rust went reasonably well (although Rust compiles
itself painfully slowly) and I could now build the Rust component
without issues. Well, mostly without issues. During part of building
rustc (the Rust compiler) would print out:
note: link against the following native artifacts when linking against this static library
note: the order and any duplication can be significant on some platforms, and so may need to be preserved
note: library: dl
note: library: pthread
note: library: gcc_s note: library: c
note: library: m
note: library: rt
note: library: util
Exporting extension to source/test/addons/author-email.xpi.
Everything from the first 'note:' onwards was in bold, including
later messages (such as 'Exporting ...') that were produced by other
portions of the build process. Clearly
rustc was somehow forgetting
to tell the terminal to turn off boldface, in much the same way that
people writing HTML sometimes forget the '
</b>' in their markup and
turn the rest of the page bold.
This only happened in xterm; in gnome-terminal and other things, rustc turned off bold without problems. This didn't surprise me, because almost no one still uses and thus tests with xterm these days. Clearly there was some obscure detail about escape sequence handling that xterm was doing differently from gnome-terminal and other modern terminal emulators, and this was tripping up rustc and causing it to fail to close off boldface.
(After capturing output with
script, I determined that rustc was
both turning on bold and trying to turn it off again with the same
ESC [ 1 m'. Oh, I said to myself, this has clearly
turned into a toggle in modern implementations, but
stuck grimly to the old ways and is making you do it properly. This
is the unwonted, hubristic arrogance of the old Unix hand speaking,.)
Since life is short and my patience is limited, I dealt with this
simply; I wrote a cover script for
rustc that manually turned off
bold (and in fact all special terminal attributes) afterwards. It
#!/bin/sh rustc.real "$@" st=$?; tput sgr0; exit $st
This worked fine. I could still build Firefox with the Rust bits enabled, and my xterm no longer became a sea of boldface afterwards.
Today I ran across an announcement of git-series, an interesting looking git tool to track the evolution of a series of patches over time as they get rebased and so on. Since this is roughly how I use git to carry my own patches on top of upstream repos, I decided I was interested enough to take a look. Git-series is written in Rust, which is fine because I already had that set up, but it also requires Rust's package manager Cargo. Cargo doesn't come with Rust's source distribution; you have to get it and build it separately. Cargo is of course built in Rust. So I cloned the Cargo repo and started building.
It didn't go well.
In fact it blew up spectacularly and mysteriously right at the
start. Alex Crichton of the
Rust project took a look at my
strace output and reported helpfully
that something seemed to be adding a stray ESC byte to
output stream when the build process ran it and tried to parse the
Oh. Well. That would be the
tput from my cover script, wouldn't
it. I was running
tput even when standard output wasn't a terminal
and this was mucking things up for anything that tried to consume
rustc output. That fixed my issue with Cargo, but now I wanted
to get this whole 'doesn't turn off boldface right' issue in Rust
fixed, so I started digging to at least characterize things so I
could file a bug report.
In the process of poking and prodding at this, a little bit of my
strace output started nagging at me; there had been references
in it to
/u/cks/.terminfo. I started to wonder if I had something
outdated in my personal environment that was confusing Rust's
terminfo support library into generating the wrong output. Since
I couldn't remember anything important I had set up there, I renamed
.terminfo-hold and re-tested.
Magically, everything now worked fine. Rustc was happy with life.
What did I have in
.terminfo? Well, here:
; ls -l /u/cks/.terminfo-hold/x/xterm -rw-r--r--. 2 cks cks 1353 Feb 10 1998 .terminfo-hold/x/xterm
Here in 2016, I have no idea why I needed a personal
file in 1998, or what's in it. But it's from 1998, so I'm pretty
confident it's out of date. If it was doing something that I'm going
to miss, I should probably recreate it from a modern xterm terminfo
(This also explains why gnome-terminal had no problems; it normally
$TERM value of
xterm-256color, and I didn't have a custom
terminfo file for that.)
$HOME is really old by now, and as a result it has all sorts
of ancient things lingering on in its dotfile depths. Some of them
are from stuff I configured a long time ago and have forgotten
since, and some of them are just the random traces from ancient
programs that I haven't used for years. Clearly this has its
(Despite this experience I have no more desire to start over from scratch than I did before. My environment works and by now I'm very accustomed to it.)
Comments on this page:Written on 30 July 2016.