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 <
Post by Paulo Roberto Massa Cereda'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
Post by Nelson H. F. Beebe...
Post by Manfred LotzIs 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
-
http://www.math.utah.edu/~beebe/ -
------------------------------------------------------------
-------------------