Re: openin_any removal for TL'26?

Hi Karl,

On 27/12/2025 22:28, Karl Berry wrote:
> Hi Nicola,
> 
>      Does this mean that `kpsewhich --var-value=openin_any` will treat
>      `openin_any` as undefined for TL'26?
> 
> Thanks for the heads-up. I'm planning to leave openin_any in texmf.cnf,
> defined as a, for exactly that reason.

I'm sorry, I should have double-checked before posting rather than 
relying on memory (I was away at the time and didn't have full access to 
my files). It seems that I had already changed the default fallback to 
'a' for both bib2gls and texosquery (to accommodate MikTeX users who 
don't have openin_any). But it's good to know that it will still be defined.

> I'm also thinking to have the code give a warning if it sees any value
> besides a, since that would imply the user thinks they specified the
> reading restriction, but there is no such restriction now.

I think that's a good idea.

> 
> My theory is that there are zero such users (apart from testing),
> otherwise I would be taking a different tack. Do you know of anyone
> using openin_any != a?

I can't remember any specific instances for non-testing purposes. I ran 
a search for openin_any over all content in my (La)TeX mail 
sub-directories and the only results were messages to or from you, 
tlsecurity, CTAN (upload descriptions) and developers. The only GitHub 
issues (for my repositories) that I can find which relate to openin_any 
were from MikTeX users who were having problems because it wasn't set.

> 
> The code itself (the in_name_ok functions) will always return true,
> regardless of the setting. I don't plan to (ever) remove the functions,
> to avoid gratuitous linking problems.
> 

That's good to know. Thanks.

Regards
Nicola