> : > Store file names are always ASCII so problems arise when they are stored
> : > as UTF-16 or UTF-32/UCS-4.
> : 
> : I understand that most programs stick to ASCII filenames, but what about the odd
> : one using non-English, special characters?
> 
> That’s a separate debate.  :-)  Essentially this restriction on store
> file names has always been there in Guix (and Nix before that).  If we
> were to change it, that would raise compatibility issues.

But what happens if we attempt to store "á" in the store?

> For example I guess we could always store the file name as a literal
> byte vector/list and add a call to turn that into a string.

In the case of Next, that would be a simple patch, but other programs could get
much more complicated.  In the end, this approach requires a linear amount of
work.  Conversely, adding UCS-* support to the scanner would fix this issue once
and for all.

> : > We did have a problem with Fish but I can no longer find it.  Do you
> : > remember what it was?  Something with C++, no?
> : 
> : I think bug #30265.
> 
> Oh I see, UCS-4 as well.  (I can’t believe this bug is still open given
> the relatively simple solutions outlined at
> <https://issues.guix.info/issue/30265#8>.  :-))

Well, if currently only two packages out of 8500+ suffer from this, then I think
it's easier to go with Ludo's suggestion of patching the code to use ASCII
strings.

Does anyone know about more packages with this issue?  It could also be that
more packages suffer from this, unbeknownst to us.

-- 
Pierre Neidhardt
https://ambrevar.xyz/