Wow great bug!

> Bash forgot to reset errno before the call. For about 30 years, no one noticed

I have to say, this part of the POSIX API is maddening!

99% of the time, you don't need to set errno = 0 before making a call. You check for a non-zero return, and only then look at errno.

But SOMETIMES you need to set errno = 0, because in this case readdir() returns NULL on both error and EOF.

I actually didn't realize this before working on https://oils.pub/

---

And it should go without saying: Oils simply uses libc - we don't need to support system with a broken getcwd()!

Although a funny thing is that I just fixed a bug related to $PWD that AT&T ksh (the original shell, that bash is based on) hasn't fixed for 30+ years too!

(and I didn't realize it was still maintained)

https://www.illumos.org/issues/17442

https://github.com/oils-for-unix/oils/issues/2058

There is a subtle issue with respect to:

1) "trusting" the $PWD value you inherit from another process

2) Respecting symlinks - this is the reason the shell can't just call getcwd() !

    if (*p != '/' || stat(p, &st1) || stat(".", &st2) ||
        st1.st_dev != st2.st_dev || st1.st_ino != st2.st_ino)
        p = 0;

The response to the bug on the mailing list is disheartening. Report goes "set errno=0 so your error message makes sense". Didn't get a thanks, fixed.

Instead there's objections on the basis "filesystems shouldn't work like that".

Remember, folks: It's not enough to check $WEARING_PANTS before stepping outside. You need to check !$PANTS_BROKEN && !$SOLARIS too.

> Once the bug report becomes publicly visible, it will be linked here.

Here it is: https://lists.gnu.org/archive/html/bug-bash/2025-06/msg00149...

Most of the stuff that configure scripts check is obsolete, and breaks in situations like this as the checks are often not workable without running code. It is likely the check does not apply to any system that has existed for decades. Lots of systems have disabled eg Nix in 2017 [1]

[1] https://github.com/NixOS/nixpkgs/commit/dff0ba38a243603534c9...

Saving this to explain why software is hard.

For a long time, inode numbers from readdir() had certain semantics. Supporting overlay filesystems required changing those semantics. Piles of software were written against the old semantics; and even some of the most common have not been upgraded.

FWIW, if you are cross-compiling, while you might get a vaguely usable result by ignoring all of the warnings and letting worst-common-denominator defaults get applied, you absolutely should be paying more attention and either manually providing autoconf the answers it needs or (if at all possible, as this is more general) make sure to tell it how to run a binary on the target system (maybe in an emulator or over ssh)... you shouldn't just be YOLOing a cross-compile like this and expecting it to work (not to say that this wasn't a good bug in the fallback to fix, just that the premise is awkward).

Autoconf is the prime example of easy vs simple.

It looks easy on the surface to roll down support for any kind of operating system there is, based on auto-detection and then #if HAVE_THIS or #if HAVE_THAT, but it breaks in ways that maybe really hard to untangle later.

I'd rather have a limited set set of configurations targeting specific platforms/flavors, and knowing that no matter how I compile it, I would know what is `#define`-d and what is not, instead of guessing on what the "host" might have.

Interesting investigation, good read. Definitely illustrates how new paradigms (i.e. overlay filesystems) can subtly affect behaviors in ways that are complex to track down.