<div dir="ltr"><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<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>