[tex-live] behaviour of kpsewhich on case-insensitive mac system

Thu Sep 21 16:51:16 CEST 2017

Hello,

personally I prefer case sensitivity but we do not live in such an ideal
world ensuring that it works Nelson described clearly the problem and I add
one more. Assume you commit a directory with two files the names of which
differ in case only to a versioning system. The a user tries to
checkout/clone (depending on the type of the VCS) the directory to a case
insensitive system and it fails. Even some names may be invalid, for
instance ptype.txt is invalid in OS/2 (ptype was an abbreviation for
property type and my colleagues had to rename the file so that I could
checkout the repo in OS/2).

File systems nowadays support Unicode but there are still FSs wothoout such
a support. If I get a zip file created on a non-Unicode system, I have
problems because I am not able to type the file name on my keyboard and
sometimes I am not even able to use the file via GUI because the graphical
application is unable to send the file name to the OS.

Even if the file name is legal, imagine what I can do with a file named in
Chinese. I do not know Chinese, I do not have Chinese keyboard and not
knowing Chinese I would not be able to find the glyphs on the keyboard. I
may be connected to the server via ssh from a thin client wothout any GUI
so that copy/paste is unavailable. I know that I can use "ls -1" followed
by awk to locate the file name and generate a script for working with it
but not all users know how to solve the problem of untypable file name.

Thus my rules how to survive are:

1. Lowercase file names unless a different case is required
2. ASCII file names without spaces and without punctuations
3. Never put two files differing in case only to the same directory

Some time ago a user created EPS files on Windows and the names had
inconsistend names and committed it to our svn server. The LaTeX document
was not compilable on Linux. I decided to convert everything consistently
to lowercase, it was jus a series of "svn mv" commands. I fixed
\includegraphics command and when it worked, I committed the changes. The
Windows user then tried "svn up" and it failed because svn was unable to
fetch the EPS files with names converted to lowercase. It seems that "svn
up" first fetches the new files and only after that deletes the old files
removed from the repo. The only solution was to delete the working copy and
checkout the fresh one. So you are asking for everyda's problems if you
collaborate with other people and do not follow the three simple rules
given above. And the change in the kpsea library will not solve them, the
world is too heterogeneous.

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2017-09-21 15:57 GMT+02:00 Paulo Roberto Massa Cereda <
cereda.paulo at gmail.com>:

> 'ello,
>
> I usually favour case sensitivity to be the norm, mostly because it makes
> things simpler (grain of salt here) by ensuring a deterministic result,
> i.e, the result maps 1:1 what we were looking for without potential traps
> and/or pitfalls.
>
> That said, case insensitivity is also interesting towards sanitising
> results (more salt please), i.e, "john" still refers to "John" which might
> be a good thing. However, there's a huge room for interpretation here.
> Also, I am not sure how sorting would be in these situations. I like to
> favour lexicographic rules most of the time, but when we ignore case, we
> are losing a potential significant information.
>
> In conclusion, nothing can be drawn for here (except the fact that I am
> trying to divert myself from writing a thesis). :) My suggestion is to keep
> things as they are, so we save energy and effort: entia non sunt
> multiplicanda praeter necessitatem. :)
>
> Cheerio!
>
> Paulo
>
>
> Em 21-09-2017 09:46, Nelson H. F. Beebe escreveu:
>
>> Manfred Lotz <manfred at dante.de> writes on Wed, 20 Sep 2017 20:48:37
>> +0200 about checking for a case-preserving filesystem:
>>
>> ...
>>>> Is there time to check the case sensitivity of the filesystem by
>>>> running
>>>>
>>>>     touch   some_weird_name
>>>>     touch   SOME_WEIRD_name
>>>> ...
>>>>
>>>
>> Let us remember that such things are a property of the filesystem,
>> rather than the O/S.  Thus, such a check cannot be done at configure
>> time, but only at run time, and then only in the same filesystem where
>> the question needs to be answered.  However, the touch command will
>> fail if that filesystem is mounted read-only.
>>
>> At our large site (18K+ users), for performance reasons, our
>> thin-client servers get read-only nightly copies of much shared
>> software in local directory trees.  On other systems, ZFS snapshots
>> may be distributed to secondary and tertiary servers, and then
>> NFS-mounted from there by client machines: they too, being snapshots,
>> are read-only.
>>
>> Thus, the problem of single-case vs case-insensitive vs
>> case-insensitive + case-preserving vs case sensitive filesystem
>> variants is not easy to deal with automatically by tools like tlmgr
>> and TeX input commands.
>>
>> When I find filename lettercase conflicts in user (La)TeX files, I
>> point out to them the necessity of consistent filenaming conventions,
>> the easiest to remember being to downcase everything, except for two
>> files: Makefile and README.  I also point out that spaces, and
>> punctuation other than a single dot, should be avoided in filenames,
>> and that while modern systems handle Unicode characters above the
>> ASCII limit of U+007F, older ones, and many software tools, do not.
>> Then there is the issue of filename length issues as well, 8 + 3, 31,
>> 63, 127, 255, ...  What a mess.
>>
>> ------------------------------------------------------------
>> -------------------
>> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>>       -
>> - University of Utah                    FAX: +1 801 581 4148
>>       -
>> - Department of Mathematics, 110 LCB    Internet e-mail:
>> beebe at math.utah.edu  -
>> - 155 S 1400 E RM 233                       beebe at acm.org
>> beebe at computer.org -
>> - Salt Lake City, UT 84112-0090, USA    URL:
>> http://www.math.utah.edu/~beebe/ -
>> ------------------------------------------------------------
>> -------------------
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20170921/0a08d35b/attachment-0001.html>