Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi, > > On Thu, 8 Nov 2018, Junio C Hamano wrote: > >> I am tempted to say "//<token>/<the remainder>" might also be such a >> way, even in the POSIX world, but am not brave enough to do so, as I >> suspect that may have a fallout in the Windows world X-<. > > It does. //server/share is the way we refer to UNC paths (AKA network > drives).
Shucks. That would mean the patch that started this thread would not be a good idea, as an end-user could already be writing "//server/share/some/path" and the code with the patch would see '/' that begins it, and start treating it differently than the code before the patch X-<. > Granted, this is a highly unlikely scenario, but I would feel a bit more > comfortable with something like > > <RUNTIME_PREFIX>/ssl/certs/ca-bundle.crt > > Of course, `<RUNTIME_PREFIX>` is *also* a perfectly valid directory name, > but I would argue that it is even less likely to exist than > `$RUNTIME_PREFIX` because the user would have to escape *two* characters > rather than one. Yes, and it is naturally extensible by allowing <OTHER_THINGS> inside the special bra-ket pair (just like $OTHER_THINGS can be a way to extend the system if we used a special variable syntax). >> Are there security implications if we started allowing references to >> environment varibables in strings we pass expand_user_path()? > > Probably. But then, the runtime prefix is not even available as > environment variable... Ah, sorry. I thought it was clear that I would next be suggesting to add an environmet variable for it, _if_ the approach to allow env references turns out to be viable.
