David Kastrup <d...@gnu.org> writes: > Ikumi Keita <ik...@ikumi.que.jp> writes: > >> Hi Mosè and all, >> >>>>>>> Mosè Giordano <m...@gnu.org> writes: >>> sorry for the late reply, these days I'm getting all @gnu.org emails >>> with huge delay. >> >> It seems that the delivery system of GNU mail list suffers severe >> trouble these days. No mails since Nov 30 are listed on >> https://lists.gnu.org/archive/html/auctex/ >> https://lists.gnu.org/archive/html/auctex-devel/ >> https://lists.gnu.org/archive/html/bug-auctex/ >> at the time of writing this message. >> >>> 2017-12-01 23:34 GMT+01:00 David Kastrup <d...@gnu.org>: >>>>> Braces + comma should be fine. >>>> >>>> Unless there are directories containing comma itself in the PATH. Is >>>> that an allowed character in Windows file systems? >> >>> It's allowed in NTFS, according to Wikipedia[1]: >> >>> In Win32 namespace: any UTF-16 code unit (case-insensitive) except >>> /\:*"?<>| as well as NUL >> >> Actually, the code in question is used regardless of the platform, so >> the file systems involved are not limited to NTFS. >> >> I just thought of another approach using brace expansion. We can obtain >> the right path delimiter by just taking the second character of the >> output of "kpsewhich --expand-path {.,..}". > > Presumably > > kpsewhich --expand-path "{.,..}" > > That's really clever. Yes, it should do the trick, assuming the Windows > executable doesn't try to be helpful by inserting the current directory, > and "foreign" implementations of kpsewhich (like the MikTeX one) behave > accordingly.
Ok, here is how I suggest to use that trick: if the expanded string contains ; use ; as delimiter, otherwise :. That should work even if some executable considers it sane to insert drive letters or directory separators or whatever else. But a ; in there should never be accidental. -- David Kastrup _______________________________________________ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel