I saw real live project where legitimate file names contained’:’. It was configuration files (so no $PATH interference. And Windows filesystem was (and is) completely out of scope
Sent from mobile On Sun, 18 Oct 2026 at 18:57, Paul Eggert <[email protected]> wrote: > On 2026-10-18 07:13, Kamila Szewczyk wrote: > > I think that extra checks should be added, where applicable, to reject > [:(<>)\r]. > > Ideally the only bytes we should prohibit in file names should be '\0' and > '\n' (both of these due to POSIX restrictions). I suppose it'd also be OK > to reject file names that contain encoding-error bytes. > > If we can't handle valid characters for some other reason, it's better to > reject them early rather than to fail mysteriously. If that's the case for > the characters you list, that's a good way to go. Though it'd be better to > fix the mysterious problems, we may not have time to do so. > > Of the characters you list, rejecting ":" seems a bit much. I assume that > this is in a context like $PATH. It makes sense to reject ":" in those > contexts, but I don't see why to reject it elsewhere. > > Whatever we reject, we should document for users. > > > I have a suspicion that something similar might be happening on Win32 > platforms (MSYS, and so on) with file names "nul", "con", and so on, but I > don't have the capacity to test that right now. > > Yes, it's not worth our time worrying about those, except perhaps to > document them. > > > >
