[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX-devel] Fix about usage of kpsewhich

From: David Kastrup
Subject: Re: [AUCTeX-devel] Fix about usage of kpsewhich
Date: Sat, 02 Dec 2017 19:39:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Ikumi Keita <address@hidden> writes:

> Hi Mosè and all,
>>>>>> Mosè Giordano <address@hidden> writes:
>> sorry for the late reply, these days I'm getting all 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
> at the time of writing this message.
>> 2017-12-01 23:34 GMT+01:00 David Kastrup <address@hidden>:
>>>> 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 {.,..}".


    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

> It would be robust since it would work on any platform and not be
> interfered with directory names with literal comma.


David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]