Hi Andrew,
"Andrew Marshall" via GNU coreutils Bug Reports <[email protected]>
writes:
> In Coreutils v9.8 on macOS (I also tested on recent master,
> 5a00d0a65), `env` now adds the `__CF_USER_TEXT_ENCODING` var to the
> environment. This behavior is not present in v9.7. I suspect this may
> be due to commit c2e1816a53345ff9d5b89fc1fa566e87d0ee1b7e, but am
> unable to confirm as naive bisecting and reverting is confounded by
> failed builds.
>
> ./coreutils-bin/env -i /usr/bin/env # (empty)
> ./coreutils-bin/env -i ./coreutils/bin/env # has __CF_USER_TEXT_ENCODING
> /usr/bin/env -i ./coreutils-bin/env # has __CF_USER_TEXT_ENCODING
I recall seeing it ignored in tests. That was because of this commit:
$ git log --grep=__CF
commit 7b0db3c69c2171e352b219d473cb5469ba635d8d
Author: Jim Meyering <[email protected]>
AuthorDate: Sun Sep 19 22:44:25 2021 -0700
Commit: Jim Meyering <[email protected]>
CommitDate: Mon Sep 20 10:01:53 2021 -0700
tests: env-s.pl: avoid spurious failure on OS X
* tests/misc/env-S.pl: The __CF_USER_TEXT_ENCODING envvar
would cause many of these sub-tests to fail. Ignore it.
I also remeber seeing a ~/.CFUserTextEncoding file on my work system as
well.
My intuition is that calling the Core Foundation locale functions will
cause that environment variable to be set along with creating that file.
Can you share the ./configure options you used? Or did you download
Coreutils through Homebrew? That would help lead me in the right
direction, I think.
Thanks!
Collin
