<div dir="ltr"><div><div><div><div><div><div><div><div>Hello,<br><br></div>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).<br><br></div>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.<br><br></div>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.<br><br></div>Thus my rules how to survive are:<br><br></div>1. Lowercase file names unless a different case is required<br></div>2. ASCII file names without spaces and without punctuations<br></div>3. Never put two files differing in case only to the same directory<br><br></div>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.<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Zdeněk Wagner<br><a href="http://ttsm.icpf.cas.cz/team/wagner.shtml" target="_blank">http://ttsm.icpf.cas.cz/team/wagner.shtml</a><br><a href="http://icebearsoft.euweb.cz" target="_blank">http://icebearsoft.euweb.cz</a></div></div>
<br><div class="gmail_quote">2017-09-21 15:57 GMT+02:00 Paulo Roberto Massa Cereda <span dir="ltr"><<a href="mailto:cereda.paulo@gmail.com" target="_blank">cereda.paulo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">'ello,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. :)<br>
<br>
Cheerio!<span class="HOEnZb"><font color="#888888"><br>
<br>
Paulo</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
Em <a href="tel:21-09-2017%2009" value="+12109201709" target="_blank">21-09-2017 09</a>:46, Nelson H. F. Beebe escreveu:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Manfred Lotz <<a href="mailto:manfred@dante.de" target="_blank">manfred@dante.de</a>> writes on Wed, 20 Sep 2017 20:48:37<br>
+0200 about checking for a case-preserving filesystem:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br>
Is there time to check the case sensitivity of the filesystem by<br>
running<br>
<br>
    touch   some_weird_name<br>
    touch   SOME_WEIRD_name<br>
...<br>
</blockquote></blockquote>
<br>
Let us remember that such things are a property of the filesystem,<br>
rather than the O/S.  Thus, such a check cannot be done at configure<br>
time, but only at run time, and then only in the same filesystem where<br>
the question needs to be answered.  However, the touch command will<br>
fail if that filesystem is mounted read-only.<br>
<br>
At our large site (18K+ users), for performance reasons, our<br>
thin-client servers get read-only nightly copies of much shared<br>
software in local directory trees.  On other systems, ZFS snapshots<br>
may be distributed to secondary and tertiary servers, and then<br>
NFS-mounted from there by client machines: they too, being snapshots,<br>
are read-only.<br>
<br>
Thus, the problem of single-case vs case-insensitive vs<br>
case-insensitive + case-preserving vs case sensitive filesystem<br>
variants is not easy to deal with automatically by tools like tlmgr<br>
and TeX input commands.<br>
<br>
When I find filename lettercase conflicts in user (La)TeX files, I<br>
point out to them the necessity of consistent filenaming conventions,<br>
the easiest to remember being to downcase everything, except for two<br>
files: Makefile and README.  I also point out that spaces, and<br>
punctuation other than a single dot, should be avoided in filenames,<br>
and that while modern systems handle Unicode characters above the<br>
ASCII limit of U+007F, older ones, and many software tools, do not.<br>
Then there is the issue of filename length issues as well, 8 + 3, 31,<br>
63, 127, 255, ...  What a mess.<br>
<br>
------------------------------<wbr>------------------------------<wbr>-------------------<br>
- Nelson H. F. Beebe                    Tel: <a href="tel:%2B1%20801%20581%205254" value="+18015815254" target="_blank">+1 801 581 5254</a>                  -<br>
- University of Utah                    FAX: <a href="tel:%2B1%20801%20581%204148" value="+18015814148" target="_blank">+1 801 581 4148</a>                  -<br>
- Department of Mathematics, 110 LCB    Internet e-mail: <a href="mailto:beebe@math.utah.edu" target="_blank">beebe@math.utah.edu</a>  -<br>
- 155 S 1400 E RM 233                       <a href="mailto:beebe@acm.org" target="_blank">beebe@acm.org</a>  <a href="mailto:beebe@computer.org" target="_blank">beebe@computer.org</a> -<br>
- Salt Lake City, UT 84112-0090, USA    URL: <a href="http://www.math.utah.edu/~beebe/" rel="noreferrer" target="_blank">http://www.math.utah.edu/~beeb<wbr>e/</a> -<br>
------------------------------<wbr>------------------------------<wbr>-------------------<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div>