Skip to content

fix: ignore '$TMPDIR' when it is an unusable directory#320

Open
Smattr wants to merge 2 commits intomainfrom
smattr/80b12840-6b00-4688-baaa-80018bd69d77
Open

fix: ignore '$TMPDIR' when it is an unusable directory#320
Smattr wants to merge 2 commits intomainfrom
smattr/80b12840-6b00-4688-baaa-80018bd69d77

Conversation

@Smattr
Copy link
Copy Markdown
Owner

@Smattr Smattr commented May 2, 2026

A recent audit of Ubuntu’s Rust utilities¹ led me to learn that $TMPDIR is only intended to be used when the directory it points to is accessible:²

If applications are written to use temporary or intermediate files,
they should use the TMPDIR environment variable, if it is set and
represents an accessible directory, to select the location of
temporary files.

The effect of this change is that rumur --help with an unusable $TMPDIR set will now fall back to using /tmp instead of trying (and failing) to use this $TMPDIR.

¹ https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
² https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap01.html

Smattr added 2 commits May 2, 2026 10:01
A recent audit of Ubuntu’s Rust utilities¹ led me to learn that
`$TMPDIR` is only intended to be used when the directory it points to is
accessible:²

  If applications are written to use temporary or intermediate files,
  they should use the _TMPDIR_ environment variable, if it is set and
  represents an accessible directory, to select the location of
  temporary files.

The effect of this change is that `rumur --help` with an unusable
`$TMPDIR` set will now fall back to using /tmp instead of trying (and
failing) to use this `$TMPDIR`.

¹ https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
² https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap01.html
The Ubuntu toolchain PPA seems to be having an outage wherein (at least)
GCC 15 and 16 are not currently available. Bizarrely apt’s behaviour
when failing to find an exact package is to treat the package name as a
regex, which in the case of g++x matches the corresponding Clang
package.¹ This causes a confusing situation where package installation
appears to succeed and then compilation either fails to find the
expected GCC or incorrectly finds Clang and builds with that.

This change should hopefully cause an earlier more obvious failure when
GCC fails to install.

¹ https://askubuntu.com/questions/1341002/apt-install-g-10-installs-clang-10-instead-of-g-10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant