Discussion:
behaviour of kpsewhich on case-insensitive mac system
(too old to reply)
jfbu
2017-09-18 16:18:28 UTC
Permalink
Hi,

I have a question,

$ kpsewhich example-image-A.pdf

$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf

But I am on a case-insensitive file system:

$ touch foo

$ mv foo Foo

$ rm foo

$ ls Foo
ls: Foo: No such file or directory

I was wondering why an `\includegraphics{example-image-A}` failed
(which I got from some post on tex.sx) and I surmise from the above
that this has possibly to do with kpsewhich or at least with the way
pdftex finds files.

I guess the rationale is that if kpsewhich were to be
case-insensitive on OSes with case insensitive file systems,
TeX documents would more easily behave differently on different
systems ?

Best

Jean-François
George N. White III
2017-09-18 16:52:40 UTC
Permalink
Post by jfbu
Hi,
I have a question,
$ kpsewhich example-image-A.pdf
$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
It would save some guessing in such (not uncommon) searches if we could use:

kpsewhich --ignore-case eXample-ImaGe-A.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
Post by jfbu
$ touch foo
$ mv foo Foo
$ rm foo
$ ls Foo
ls: Foo: No such file or directory
I was wondering why an `\includegraphics{example-image-A}` failed
(which I got from some post on tex.sx) and I surmise from the above
that this has possibly to do with kpsewhich or at least with the way
pdftex finds files.
I guess the rationale is that if kpsewhich were to be
case-insensitive on OSes with case insensitive file systems,
TeX documents would more easily behave differently on different
systems ?
Best
Jean-François
--
George N. White III <***@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
Philip Taylor
2017-09-18 17:36:27 UTC
Permalink
Post by jfbu
Hi,
I have a question,
$ kpsewhich example-image-A.pdf
$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
Windows 7 Ultimate, 64-bit; TeX Live 2016 :

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Philip.Taylor>kpsewhich PLAIN.TEX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/PLAIN.TEX

C:\Users\Philip.Taylor>kpsewhich PLAIN.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/PLAIN.TeX

C:\Users\Philip.Taylor>kpsewhich Plain.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/Plain.TeX

C:\Users\Philip.Taylor>kpsewhich plain.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/plain.TeX
jfbu
2017-09-18 18:39:14 UTC
Permalink
Post by Philip Taylor
Post by jfbu
Hi,
I have a question,
$ kpsewhich example-image-A.pdf
$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Philip.Taylor>kpsewhich PLAIN.TEX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/PLAIN.TEX
C:\Users\Philip.Taylor>kpsewhich PLAIN.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/PLAIN.TeX
C:\Users\Philip.Taylor>kpsewhich Plain.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/Plain.TeX
C:\Users\Philip.Taylor>kpsewhich plain.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/plain.TeX
ah... I see, and I understand Enrico's comment
Post by Philip Taylor
It often happens that people
on Windows use wrong casing and are puzzled because
the same document doesn’t compile on another (non Windows)
machine.
but I conclude that kpsewhich on Windows has different
policy than on Mac.

Shouldn't the kpsewhich on Windows act like on Mac
and then only kpsewhich plain.tex would return a find?

Because as it stands portability of TeX documents
is diminished.

Best

Jean-François
Zdenek Wagner
2017-09-18 18:46:32 UTC
Permalink
Post by jfbu
Post by Philip Taylor
Post by jfbu
Hi,
I have a question,
$ kpsewhich example-image-A.pdf
$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Philip.Taylor>kpsewhich PLAIN.TEX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/PLAIN.TEX
C:\Users\Philip.Taylor>kpsewhich PLAIN.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/PLAIN.TeX
C:\Users\Philip.Taylor>kpsewhich Plain.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/Plain.TeX
C:\Users\Philip.Taylor>kpsewhich plain.TeX
c:/TeX/Live/2016/texmf-dist/tex/plain/base/plain.TeX
ah... I see, and I understand Enrico's comment
Post by Philip Taylor
It often happens that people
on Windows use wrong casing and are puzzled because
the same document doesn’t compile on another (non Windows)
machine.
but I conclude that kpsewhich on Windows has different
policy than on Mac.
Shouldn't the kpsewhich on Windows act like on Mac
and then only kpsewhich plain.tex would return a find?
I no longer have OS/2 but kpsewhich on OS/2 is case sensitive although the
file system is case insensitive.
Post by jfbu
Because as it stands portability of TeX documents
is diminished.
Included images are the greatest problem. If I get a document created on
Windows, it rarely works on my Linux computer and I have to fix names in
\input and \includegraphics.
Post by jfbu
Best
Jean-François
Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
Akira Kakuto
2017-09-18 23:04:03 UTC
Permalink
Post by Zdenek Wagner
Included images are the greatest problem. If I get a document
created on Windows, it rarely works on my Linux computer and
I have to fix names in \input and \includegraphics.
Sorry for the incompatibility with other platforms.
However, I will not change the present behaviors
on windows.

PS:
If example-image-a.pdf is in the current directory,
or in a directory for which there is not ls-R,
kpsewhich example-image-A.pdf
probably returns
./example-image-A.pdf
or
/somedir/example-image-A.pdf
on case-insensitive Mac.
Sorry if I am wrong.

Thanks,
Akira
Enrico Gregorio
2017-09-18 23:07:27 UTC
Permalink
Post by Akira Kakuto
Post by Zdenek Wagner
Included images are the greatest problem. If I get a document
created on Windows, it rarely works on my Linux computer and
I have to fix names in \input and \includegraphics.
Sorry for the incompatibility with other platforms.
However, I will not change the present behaviors
on windows.
If example-image-a.pdf is in the current directory,
or in a directory for which there is not ls-R,
kpsewhich example-image-A.pdf
probably returns
./example-image-A.pdf
or
/somedir/example-image-A.pdf
on case-insensitive Mac.
Sorry if I am wrong.
I confirm.

Ciao
Enrico
jfbu
2017-09-19 06:25:09 UTC
Permalink
Post by Akira Kakuto
Post by Zdenek Wagner
Included images are the greatest problem. If I get a document
created on Windows, it rarely works on my Linux computer and
I have to fix names in \input and \includegraphics.
Sorry for the incompatibility with other platforms.
However, I will not change the present behaviors
on windows.
If example-image-a.pdf is in the current directory,
or in a directory for which there is not ls-R,
kpsewhich example-image-A.pdf
probably returns
./example-image-A.pdf
Hi,

confirmed on my mac os 10.9.5

$ touch example-image-a.pdf

$ kpsewhich example-image-A.pdf
./example-image-A.pdf

and then

$ mv example-image-a.pdf ~/Library/texmf/source/latex/

$ kpsewhich example-image-A.pdf
/Users/xyxyxy/Library/texmf/tex/latex/example-image-A.pdf

$ kpsewhich Example-Image-a.pdf
/Users/jfb/Library/texmf/tex/latex/Example-Image-a.pdf

However, when I try Philip's examples:

$ kpsewhich plain.tex
/usr/local/texlive/2017/texmf-dist/tex/plain/base/plain.tex

$ kpsewhich plaiN.tex

$ kpsewhich Plain.tex

$ kpsewhich plain.TEX

i.e. I can't reproduce Justin's duplication on Mac of Philip's
findings on Windows

If I move my pseudo example-image-a.pdf to ~/Library/texmf/doc/
from ~/Library/texmf/tex/latex/

kpsewhich example-image-a.pdf

finds the real one in 2017/texmf-dist/tex/latex/mwe/

and then

kpsewhich example-image-A.pdf

finds nothing.

I am on Mac OS 10.9.5 with TeXLive 2017's kpsewhich (other binaries
such as pdftex are from MacPorts)

Best,

Jean-François
Ulrike Fischer
2017-09-19 09:15:00 UTC
Permalink
Post by Akira Kakuto
Post by Zdenek Wagner
Included images are the greatest problem. If I get a document
created on Windows, it rarely works on my Linux computer and
I have to fix names in \input and \includegraphics.
Sorry for the incompatibility with other platforms.
However, I will not change the present behaviors
on windows.
I would really like to have is a way to find out the correct casing
without having to look at the file itself. E.g. if I do

kpsewhich EXAMPLE-IMAGE-A.PNG
or in a document
\includegraphics{EXAMPLE-IMAGE-A.PNG}

then every data I get back says that I used the correct casing: On
the terminal and in the log I only see uppercase:
d:/texlive/2017/texmf-dist/tex/latex/mwe/EXAMPLE-IMAGE-A.PNG
<use EXAMPLE-IMAGE-A.PNG>

and when I then copy the code in some answer I get complains ;-(.

Couldn't there be some "case-debugging-mode"?
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
Zdenek Wagner
2017-09-19 09:35:25 UTC
Permalink
Post by Ulrike Fischer
Post by Akira Kakuto
Post by Zdenek Wagner
Included images are the greatest problem. If I get a document
created on Windows, it rarely works on my Linux computer and
I have to fix names in \input and \includegraphics.
Sorry for the incompatibility with other platforms.
However, I will not change the present behaviors
on windows.
I would really like to have is a way to find out the correct casing
without having to look at the file itself. E.g. if I do
kpsewhich EXAMPLE-IMAGE-A.PNG
or in a document
\includegraphics{EXAMPLE-IMAGE-A.PNG}
then every data I get back says that I used the correct casing: On
d:/texlive/2017/texmf-dist/tex/latex/mwe/EXAMPLE-IMAGE-A.PNG
<use EXAMPLE-IMAGE-A.PNG>
and when I then copy the code in some answer I get complains ;-(.
Couldn't there be some "case-debugging-mode"?
It is not easy. ls-R is (usually) case sensitive, it is case sensitive even
on OS/2 with case insensitive file system. In this case, if the file is
looked up in ls-R, kpsewhich is case sensitive. The problem is that the
file system does not return the correct file name

On Mac:
"ls" shows that the directory contains README.md
"cat readme.md" displays the contents of the file
"ls readme.md" returns readme.md, not README.md

On Windows 7 with NTFS:
"dir" shows that the directory contains README.md
"cat readme.md" displays the contents of the file
"dir readme.md" reports the correct file name README.md (I have tried "dir
Readme.MD" and again got the correct file name).

Thus it depends, it may or may not be possible.
Post by Ulrike Fischer
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
Justin C. Walker
2017-09-18 22:59:45 UTC
Permalink
[snip]
Post by jfbu
ah... I see, and I understand Enrico's comment
Post by Enrico Gregorio
It often happens that people
on Windows use wrong casing and are puzzled because
the same document doesn’t compile on another (non Windows)
machine.
but I conclude that kpsewhich on Windows has different
policy than on Mac.
Shouldn't the kpsewhich on Windows act like on Mac
and then only kpsewhich plain.tex would return a find?
I’m not sure that this makes sense: AIUI, ‘kpsewhich’ just hands a file name to the OS. The OS provides the answer, which is relayed to the user. I don’t think the TeX infrastructure (or the kpse infrastructure) puts any effort into dealing with case issues.
Post by jfbu
Because as it stands portability of TeX documents
is diminished.
Best
Jean-François
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
I'm beginning to like the cut of his jibberish.
-----------
Enrico Gregorio
2017-09-18 17:40:12 UTC
Permalink
Post by jfbu
Hi,
I have a question,
$ kpsewhich example-image-A.pdf
$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
$ touch foo
$ mv foo Foo
$ rm foo
$ ls Foo
ls: Foo: No such file or directory
I was wondering why an `\includegraphics{example-image-A}` failed
(which I got from some post on tex.sx) and I surmise from the above
that this has possibly to do with kpsewhich or at least with the way
pdftex finds files.
I guess the rationale is that if kpsewhich were to be
case-insensitive on OSes with case insensitive file systems,
TeX documents would more easily behave differently on different
systems ?
I find this the only really sensible behavior. Using the wrong casing
limits portability of documents. It often happens that people
on Windows use wrong casing and are puzzled because
the same document doesn’t compile on another (non Windows)
machine.

Ciao
Enrico
jfbu
2017-09-19 06:26:55 UTC
Permalink
Hi,
Post by jfbu
Hi,
I have a question,
$ kpsewhich example-image-A.pdf
$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
I’;m using TeXLive 2017 (up to date) on on macOS 10.11.6.
I duplicated Phillip’s example (i.e., I got the same results he did).
I also used your example, with the same results, so I don’t understand why case should affect the outcome.
What versions of TeX and (I assume) macOS are you using?
I am on mac os 10.9.5 and using TeXLive 2017.

Best,

Jean-François
jfbu
2017-09-19 07:15:04 UTC
Permalink
Hi Justin
The “HFS+” file system on macOS/OS X can be created to be case-sensitive (at least it once was; not sure whether it still is). Did you perhaps do this in the distant past?
Yes, it is possibly to format a hard disk with HFS+ case-sensitive file system,

but
from diskutil info / I get

File System Personality: Journaled HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended (Journaled)

which confirms that it is the case-insensitive file system (else "Case-sensitive" would appear therein)

I am not sure but to change that I think I would need to re-format the hard-disk and thus re-copy from a backup all files, which, as anyway this is my book-disk would be quite an adventure !

Jean-François
Justin C. Walker
2017-09-19 21:21:01 UTC
Permalink
Post by jfbu
Hi Justin
The “HFS+” file system on macOS/OS X can be created to be case-sensitive (at least it once was; not sure whether it still is). Did you perhaps do this in the distant past?
Yes, it is possibly to format a hard disk with HFS+ case-sensitive file system,
but
from diskutil info / I get
File System Personality: Journaled HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended (Journaled)
which confirms that it is the case-insensitive file system (else "Case-sensitive" would appear therein)
Correct.
Post by jfbu
I am not sure but to change that I think I would need to re-format the hard-disk and thus re-copy from a backup all files, which, as anyway this is my book-disk would be quite an adventure !
I wasn’t suggesting changing the parameters of the disk, because I believe you are right: that would entail reformatting. Not a pleasant job, especially for a boot disk :-}

Justin

--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
If it weren't for carbon-14, I wouldn't date at all.
-----------
Karl Berry
2017-09-19 22:42:38 UTC
Permalink
What I can imagine doing is first looking up the name as-is, and iff
that fails, doing a case-insensitive lookup. Patches welcome, else I
will put it on my ever-lengthening list. It essentially amounts to
removing the compile-time configuration done now, and falling back to
the case-insensitive test regardless of the system.

It would be wrong to "randomly" return any case-insensitive match if an
exact match exists. That is, on Unix, \input FOO.TEX should prefer a
file named "FOO.TEX" to "foo.tex".

-k

P.S. Explanation of the current behavior: Kpathsea was written at a time
when in practice there was no such thing as an operating system which
supported both case-insensitve and case-sensitive filesystems. (Also at
a time when no one dreamed that a company would make such a disruptive
and incompatible change to their systems, but never mind.) Therefore
the test was done at configure time. In kpathsea/config.h there is:

#if defined(OS2) || \
defined(MSDOS) || defined(__MSDOS__) || defined(DOS) || \
defined(WIN32) || defined(__WIN32__) || defined(_WIN32) || \
defined(DJGPP) || defined(__DJGPP__) || \
defined(MINGW32) || defined(__MINGW32__)
#define DOSISH
#endif

which is ultimately what determines whether case-sensitive or
-insensitive test is done.

(Zdenek, why this does not match on your OS/2 system, I can't say.)
Zdenek Wagner
2017-09-19 23:05:40 UTC
Permalink
Post by Karl Berry
What I can imagine doing is first looking up the name as-is, and iff
that fails, doing a case-insensitive lookup. Patches welcome, else I
will put it on my ever-lengthening list. It essentially amounts to
removing the compile-time configuration done now, and falling back to
the case-insensitive test regardless of the system.
It would be wrong to "randomly" return any case-insensitive match if an
exact match exists. That is, on Unix, \input FOO.TEX should prefer a
file named "FOO.TEX" to "foo.tex".
-k
P.S. Explanation of the current behavior: Kpathsea was written at a time
when in practice there was no such thing as an operating system which
supported both case-insensitve and case-sensitive filesystems. (Also at
a time when no one dreamed that a company would make such a disruptive
and incompatible change to their systems, but never mind.) Therefore
#if defined(OS2) || \
defined(MSDOS) || defined(__MSDOS__) || defined(DOS) || \
defined(WIN32) || defined(__WIN32__) || defined(_WIN32) || \
defined(DJGPP) || defined(__DJGPP__) || \
defined(MINGW32) || defined(__MINGW32__)
#define DOSISH
#endif
which is ultimately what determines whether case-sensitive or
-insensitive test is done.
(Zdenek, why this does not match on your OS/2 system, I can't say.)
HPFS on OS/2 is case retensive but case insensitive. If I create
SomeFile.tex, the file system will remember the case but it will match
somefile.tex and all other case alternatives. However, kpsea is compiled in
such a way that ls-R stores the names as they are listed by the file
system, i.e. it will store SomeFile.tex. If a TEXMF tree is configured to
search in the ls-R only, it will only match SomeFile.tex but not the other
variants. I no longer have OS/2 so I cannot run further tests.

However, the situation with case sensitivity is much more complex. OS/2 has
a limited support for ext2 which is case sensitive. The configuration file
for the driver allows switching case sensitivity on and off. The driver can
read files accessed via symlinks but is unable to create them.

Users of all OSes can use files via network which brings another mess. I
know some universities which provide one network installatin of TeX Live
supporting all platforms and the users hust mount the root of the tree and
set PATH. Thus Windows users invoke TeX Live from a case sensitive file
system although their disks are case insensitive.

And there is another big problem. In our institute we have Synology for
backup and sharing files. Since the majority of our users are on Windows,
Synology is configured to use Samba. The Samba protocol is case insensitive
although the underlying file system in Synology is case sensitive. It is
also possible to use WebDAV, sshfs, etc. Thus it depends how I mount
Synology on my Linux machine, if I mount it via Samba, I have case
insensitive system. If the directory has files with names differing only in
case and I try to overwrite one of them via Samba, I lose all the remaining
files. If I do the same action via sshfs or WebDAV, it works correctly as
it should on a case sensitive system.

So the right solution how to cope with case (in)sensitivity will definitely
be difficult.



Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
Norbert Preining
2017-09-20 00:01:45 UTC
Permalink
Post by Karl Berry
What I can imagine doing is first looking up the name as-is, and iff
that fails, doing a case-insensitive lookup. Patches welcome, else I
But that would change semantics on Unix file systems, right?
I know that within TL we check whether there are case clashes, but
we don't know what users are doing.

Lots of work I guess, but maybe one needs to check for each TEXMF tree
referenced whether the underlying FS is case-sensitive or not
(creating a lowercase file and check for uppercase existence),
and then do file searches sensitive according to the location of each
tree.

Not that I want to implement that, though :-(

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Akira Kakuto
2017-09-20 07:26:44 UTC
Permalink
Post by Karl Berry
It would be wrong to "randomly" return any case-insensitive match
I have changed to return actual file names on Windows,
probably with a little loss of performance.

In TeX Live 2018, users will obtain:

C:\Users\Philip.Taylor>kpsewhich PLAIN.TEX
c:/TeX/Live/2018/texmf-dist/tex/plain/base/plain.tex

C:\Users\Philip.Taylor>kpsewhich PLAIN.TeX
c:/TeX/Live/2018/texmf-dist/tex/plain/base/plain.tex

C:\Users\Philip.Taylor>kpsewhich Plain.TeX
c:/TeX/Live/2018/texmf-dist/tex/plain/base/plain.tex

C:\Users\Philip.Taylor>kpsewhich plain.TeX
c:/TeX/Live/2018/texmf-dist/tex/plain/base/plain.tex

C:\Users\Philip.Taylor>kpsewhich ieeetran.cls
c:/TeX/Live/2018/texmf-dist/tex/latex/ieeetran/IEEEtran.cls

Thanks,
Akira
George N. White III
2017-09-20 14:54:08 UTC
Permalink
Post by Karl Berry
It would be wrong to "randomly" return any case-insensitive match
I have changed to return actual file names on Windows,
probably with a little loss of performance.
I think this will be useful, but it doesn't fully address the problem of
documents shared between Windows and linux users where the file
last edited by the Windows user references "example-image-A.pdf".
It helps only in the sense that linux user asks Windows user where
to find "example-image-A.pdf". Windows user consults
the new kpeswhich and discovers: ".../tex/latex/mwe/example-image-a.pdf".
Post by Karl Berry
C:\Users\Philip.Taylor>kpsewhich PLAIN.TEX
c:/TeX/Live/2018/texmf-dist/tex/plain/base/plain.tex
C:\Users\Philip.Taylor>kpsewhich PLAIN.TeX
c:/TeX/Live/2018/texmf-dist/tex/plain/base/plain.tex
C:\Users\Philip.Taylor>kpsewhich Plain.TeX
c:/TeX/Live/2018/texmf-dist/tex/plain/base/plain.tex
C:\Users\Philip.Taylor>kpsewhich plain.TeX
c:/TeX/Live/2018/texmf-dist/tex/plain/base/plain.tex
C:\Users\Philip.Taylor>kpsewhich ieeetran.cls
c:/TeX/Live/2018/texmf-dist/tex/latex/ieeetran/IEEEtran.cls
Thanks,
Akira
--
George N. White III <***@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
Manfred Lotz
2017-09-20 18:48:37 UTC
Permalink
Is there time to check the case sensitivity of the filesystem by
running
touch some_weird_name
touch SOME_WEIRD_name
?

If there was a single file created then we have a case insensitive file
system. Otherwise we have a case sensitive file system. Ok, after that
I would delete the file or both files.

Just an idea, but perhaps a naive idea. In this case I apologize.
--
Manfred



On Tue, 19 Sep 2017 22:42:38 GMT
Post by Karl Berry
What I can imagine doing is first looking up the name as-is, and iff
that fails, doing a case-insensitive lookup. Patches welcome, else I
will put it on my ever-lengthening list. It essentially amounts to
removing the compile-time configuration done now, and falling back to
the case-insensitive test regardless of the system.
It would be wrong to "randomly" return any case-insensitive match if
an exact match exists. That is, on Unix, \input FOO.TEX should
prefer a file named "FOO.TEX" to "foo.tex".
-k
P.S. Explanation of the current behavior: Kpathsea was written at a
time when in practice there was no such thing as an operating system
which supported both case-insensitve and case-sensitive filesystems.
(Also at a time when no one dreamed that a company would make such a
disruptive and incompatible change to their systems, but never
mind.) Therefore the test was done at configure time. In
#if defined(OS2) || \
defined(MSDOS) || defined(__MSDOS__) || defined(DOS) || \
defined(WIN32) || defined(__WIN32__) || defined(_WIN32) || \
defined(DJGPP) || defined(__DJGPP__) || \
defined(MINGW32) || defined(__MINGW32__)
#define DOSISH
#endif
which is ultimately what determines whether case-sensitive or
-insensitive test is done.
(Zdenek, why this does not match on your OS/2 system, I can't say.)
Zdenek Wagner
2017-09-19 22:45:05 UTC
Permalink
The problem with case sensitivity is as follows:

A user on a case insensitive file system has files MAIN.TEX and
CHAPTER1.TEX. The MAIN.TEX contains the following line:

\input chapter1

The files are then sent to someone else wit a case sensitive file system.
The compilation will fail because chapter1.tex does not exist. If it is
just a fone failing file, it is not a big proble but imagine that you sned
a whole book with dozen chapters each of which includes dozen images and
the file names have wrong case. It is horror to make such document compile.
And some users include an image several times using different case each
time, e.g. \includegraphics{myimage1}, \includegraphics{MyImage1},
\includegraphics{Myimage1.EPS}, \includegraphics{MyImage1.Eps} etc. Believe
me, I had to process such books and it may take dozen hours to make it work.

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
Post by jfbu
Hi,
I have a question,
$ kpsewhich example-image-A.pdf
$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
I’;m using TeXLive 2017 (up to date) on on macOS 10.11.6.
I duplicated Phillip’s example (i.e., I got the same results he did).
I also used your example, with the same results, so I don’t understand why
case should affect the outcome.
What versions of TeX and (I assume) macOS are you using?
Post by jfbu
$ touch foo
$ mv foo Foo
$ rm foo
$ ls Foo
ls: Foo: No such file or directory
I was wondering why an `\includegraphics{example-image-A}` failed
(which I got from some post on tex.sx) and I surmise from the above
that this has possibly to do with kpsewhich or at least with the way
pdftex finds files.
I guess the rationale is that if kpsewhich were to be
case-insensitive on OSes with case insensitive file systems,
TeX documents would more easily behave differently on different
systems ?
Best
Jean-François
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
If it weren't for carbon-14, I wouldn't date at all.
-----------
Enrico Gregorio
2017-09-19 23:01:46 UTC
Permalink
Post by Zdenek Wagner
\input chapter1
I should add something I see rather frequently;

\usepackage[Francais]{babel}

which is accepted on Windows, but of course breaks on case sensitive systems. Or

\documentclass[ieeetran}

and

\bibliographystyle{ieeetran}

where it should be IEEEtran in order to be compatible across systems.

I understand that TeX Live/Windows likes/needs to be compatible with MiKTeX;
were it for me, I’d not allow it.

Ciao
Enrico
Zdenek Wagner
2017-09-19 23:07:38 UTC
Permalink
The problem with case sensitivity is as follows:

A user on a case insensitive file system has files MAIN.TEX and

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
Post by jfbu
Hi,
I have a question,
$ kpsewhich example-image-A.pdf
$ kpsewhich example-image-a.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf
I’;m using TeXLive 2017 (up to date) on on macOS 10.11.6.
I duplicated Phillip’s example (i.e., I got the same results he did).
I also used your example, with the same results, so I don’t understand why
case should affect the outcome.
What versions of TeX and (I assume) macOS are you using?
Post by jfbu
$ touch foo
$ mv foo Foo
$ rm foo
$ ls Foo
ls: Foo: No such file or directory
I was wondering why an `\includegraphics{example-image-A}` failed
(which I got from some post on tex.sx) and I surmise from the above
that this has possibly to do with kpsewhich or at least with the way
pdftex finds files.
I guess the rationale is that if kpsewhich were to be
case-insensitive on OSes with case insensitive file systems,
TeX documents would more easily behave differently on different
systems ?
Best
Jean-François
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
If it weren't for carbon-14, I wouldn't date at all.
-----------
Akira Kakuto
2017-09-20 21:42:59 UTC
Permalink
Post by Akira Kakuto
probably with a little loss of performance.
In my experiment, it is not usually noticeable.
It may become noticeable only when there are
many files with the same name and --all switch
is used, for example, kpsewhich --format=doc --all readme.md.

Best,
Akira
Nelson H. F. Beebe
2017-09-21 12:46:25 UTC
Permalink
Post by Manfred Lotz
...
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: ***@math.utah.edu -
- 155 S 1400 E RM 233 ***@acm.org ***@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Paulo Roberto Massa Cereda
2017-09-21 13:57:09 UTC
Permalink
'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 Lotz
...
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 -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Zdenek Wagner
2017-09-21 14:53:30 UTC
Permalink
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

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 Lotz
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
-
http://www.math.utah.edu/~beebe/ -
------------------------------------------------------------
-------------------
Zdenek Wagner
2017-09-21 14:51:16 UTC
Permalink
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 Lotz
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
-
http://www.math.utah.edu/~beebe/ -
------------------------------------------------------------
-------------------
Manfred Lotz
2017-09-21 15:42:31 UTC
Permalink
On Thu, 21 Sep 2017 06:46:25 -0600
Post by Nelson H. F. Beebe
Post by Manfred Lotz
...
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.
Of course, at run time. But read-only is a show stopper, I think.
Post by Nelson H. F. Beebe
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/ -
-------------------------------------------------------------------------------
Manfred Lotz
2017-09-21 15:58:03 UTC
Permalink
Nelson,
Do you know if filesystems provide an API call to query their
capabilities? I don't know of anything like this.

-- Manfred

On Thu, 21 Sep 2017 06:46:25 -0600
Post by Nelson H. F. Beebe
Post by Manfred Lotz
...
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 -
http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Zdenek Wagner
2017-09-21 17:18:40 UTC
Permalink
Post by Manfred Lotz
Nelson,
Do you know if filesystems provide an API call to query their
capabilities? I don't know of anything like this.
I think that ioctl should do it but I have never tried.
Post by Manfred Lotz
-- Manfred
Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
Post by Manfred Lotz
On Thu, 21 Sep 2017 06:46:25 -0600
Post by Nelson H. F. Beebe
Post by Manfred Lotz
...
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.
------------------------------------------------------------
-------------------
Post by Nelson H. F. Beebe
- Nelson H. F. Beebe Tel: +1 801 581
5254 -
- University of Utah FAX: +1 801 581
4148 -
http://www.math.utah.edu/~beebe/ -
------------------------------------------------------------
-------------------
Karl Berry
2018-02-12 00:04:11 UTC
Permalink
Date: Mon, 18 Sep 2017 13:52:40 -0300
From: "George N. White III" <***@gmail.com>
[...]
kpsewhich --ignore-case eXample-ImaGe-A.pdf
/usr/local/texlive/2017/texmf-dist/tex/latex/mwe/example-image-a.pdf

I didn't implement exactly that, but I did implement a subcase for 2018:
a case-insensitive fallback match in directories that are searched
explicitly (not texmf-dist or texmf-local). What I've observed in
practice is that the mixed-case errors are nearly all with user-created
files (.tex files and images), not system directories.(*)

Thus, on a case-sensitive (not Windows, not current Mac) (file)system,
if we have a ./foo.tex,
kpsewhich --casefold-search Foo.tex # or \input Foo
will return ./foo.tex, whereas before it would fail.

On the other hand, if we have both ./Foo.tex and ./foo.tex,
then \input Foo will still return Foo.tex, as it always has.

There are other shadowy cases where something different can be returned
now than before, but I hope they will not matter in practice. I wrote a
new section in the kpathsea manual full of details.

The feature is controlled by a variable in texmf.cnf, namely
texmf_casefold_search, which is on by default, and can be overridden in
all the usual ways.

The whole thing has zero effect on Windows; the code is not even
compiled.

We'll see how it goes when the pretest starts I guess ... --best, karl.

(*) I did not want to double my time and effort merely for the mwe
package, which was the occasion of the original report in this thread;
it seems to me that people using the mwe package should also be capable
of making the effort to get the case right.

Loading...