Discussion:
kpsewhich case insensitive?
Add Reply
Denis Bitouzé
2018-04-06 19:58:24 UTC
Reply
Permalink
Raw Message
Hi,

if I'm right, `kpsewhich' was case sensitive until TL 2017 but that's
not the case with TL 2018. Indeed, if a, say, `HyperRef.sty' is in
~/texmf/tex/latex/ :

┌────
│ $ kpsewhich hyperref.sty
│ /home/bitouze/texmf/tex/latex/HyperRef.sty
└────

Is it the intended behavior? (I hope not)
--
Denis
Paulo Roberto Massa Cereda
2018-04-06 20:10:09 UTC
Reply
Permalink
Raw Message
Hi, Denis,

Mine returns:

------------------
oxford:~ paulo$ kpsewhich hyperref.sty
/usr/local/texlive/2017/texmf-dist/tex/latex/hyperref/hyperref.sty
------------------

However, it might be interesting to note that my system *is* case
insensitive:

------------------
oxford:~ paulo$ diskutil info / | grep File
File System Personality: Journaled HFS+
------------------

So 'hyperref.sty' and 'HyperRef.sty' would technically be the same, at
least in here. How case sensitivity checking works under the hood is
beyond my humble knowledge...

Cheerio!

Paulo

Em 06-04-2018 16:58, Denis Bitouzé escreveu:
> Hi,
>
> if I'm right, `kpsewhich' was case sensitive until TL 2017 but that's
> not the case with TL 2018. Indeed, if a, say, `HyperRef.sty' is in
> ~/texmf/tex/latex/ :
>
> ┌────
> │ $ kpsewhich hyperref.sty
> │ /home/bitouze/texmf/tex/latex/HyperRef.sty
> └────
>
> Is it the intended behavior? (I hope not)
>
Denis Bitouzé
2018-04-06 22:03:27 UTC
Reply
Permalink
Raw Message
Le 06/04/18 à 17h10, Paulo Roberto Massa Cereda a écrit :

> Hi, Denis,

Hi Paulo,

> Mine returns:
>
> ------------------
> oxford:~ paulo$ kpsewhich hyperref.sty
> /usr/local/texlive/2017/texmf-dist/tex/latex/hyperref/hyperref.sty
> ------------------

And this even if there's a `HyperRef.sty' somewhere in the TeX search
PATHs?

> However, it might be interesting to note that my system *is* case
> insensitive:

But that's not the case of mine.

> ------------------
> oxford:~ paulo$ diskutil info / | grep File
> File System Personality: Journaled HFS+
> ------------------
>
> So 'hyperref.sty' and 'HyperRef.sty' would technically be the same, at
> least in here.

On insensitive systems, I can understand.

> How case sensitivity checking works under the hood is beyond my humble
> knowledge...

The same for mine :)

All the best.
--
Denis
Karl Berry
2018-04-06 21:46:37 UTC
Reply
Permalink
Raw Message
Is it the intended behavior? (I hope not)

Yes, it is. I wrote a new section in the Kpathsea manual explaining it
(Casefolding search), besides my various previous messages.

To turn it off in your case, there are two choices:

1) set the config/envvar texmf_casefold_search to 0;

2) specify TEXMFHOME with a leading !! in texmf.cnf, that is, using ls-R
(thus requiring you to run mktexlsr when any files are added or removed,
thus probably better not to do this.)

Well, there is 3) renaming your case-conflicting file, but you already
knew that.

You can thank Apple and its users for inflicting this pain. --best, karl
Denis Bitouzé
2018-04-06 22:14:31 UTC
Reply
Permalink
Raw Message
Le 06/04/18 à 21h46, Karl Berry a écrit :

> Is it the intended behavior? (I hope not)
>
> Yes, it is.

Sigh...

> I wrote a new section in the Kpathsea manual explaining it
> (Casefolding search), besides my various previous messages.

Read carefully tomorrow (not enough time this evening).

> To turn it off in your case, there are two choices:
>
> 1) set the config/envvar texmf_casefold_search to 0;

Sounds appealing! :)

> 2) specify TEXMFHOME with a leading !! in texmf.cnf, that is, using
> ls-R (thus requiring you to run mktexlsr when any files are added or
> removed, thus probably better not to do this.)

Indeed, doesn't sound appealing! :)

> Well, there is 3) renaming your case-conflicting file, but you already
> knew that.

Okay.

But I (and other users) could be bitten because of files they forgot or
they don't realize they could be conflicting (nearly happened to
me).

Hence why not the other way round: `texmf_casefold_search' 0 by default
and and letting users who want `kpathsea' insensitive to set it to 1?

> You can thank Apple and its users for inflicting this pain.

They are so much powerful? ;)

All the best.
--
Denis
Karl Berry
2018-04-06 23:35:47 UTC
Reply
Permalink
Raw Message
Sigh...

Agreed.

But I (and other users) could be bitten

Yes, I know. Do you really think we were unaware of this?

Hence why not the other way round: `texmf_casefold_search' 0 by default

I thought hard about doing it this way. I hate making incompatible
changes. I think this is the first user-level kpse change intentionally
made in ten years or more.

I think I wrote all this before, but I guess I'll do it again:

The change is motivated for the case of big documents being developed on
Macs, and thus \include and \includegraphics commands (for example) use
randomly cased filenames and work regardless. Then the document is
compiled on normal Unix and failures abound. It is a big pain to fix
this. There can easily be hundreds of images or subfiles involved.
This situation is more common than you or I might wish :(.
You can look it up on tex.sx etc.

Thus, it's a trade-off between causing strange new failures in the
strange case of case-conflicting files, and helping document projects
that are developed on both Mac and (other) Unix "just work" without
having to change anything.

I felt it was better for the TeX world, overall, if such rare case
conflicts were explicitly dealt with, one way or another, partly because
these same problems *have always existed* on Windows. By dealing with
the case conflicts, documents automatically become more portable.

If the case conflicts were going to be common, I would have decided
otherwise. But I believe your case is rare -- in practice, I think the
only likely culprit is, like yours, a file in TEXMFHOME with a
case-different name from one in TEXMFDIST. Not that many people use
TEXMFHOME in the first place, let alone install style files with only a
case change from a standard name.

If it turns out to be too painfully common, we can always change the
default.

They are so much powerful? ;)

Evidently so :(. -k
George N. White III
2018-04-07 00:20:43 UTC
Reply
Permalink
Raw Message
On 6 April 2018 at 20:35, Karl Berry <***@freefriends.org> wrote:

> Sigh...
>
> Agreed.
>
> But I (and other users) could be bitten
>
> Yes, I know. Do you really think we were unaware of this?
>
> Hence why not the other way round: `texmf_casefold_search' 0 by default
>
> I thought hard about doing it this way. I hate making incompatible
> changes. I think this is the first user-level kpse change intentionally
> made in ten years or more.
>
> I think I wrote all this before, but I guess I'll do it again:
>
> The change is motivated for the case of big documents being developed on
> Macs, and thus \include and \includegraphics commands (for example) use
> randomly cased filenames and work regardless. Then the document is
> compiled on normal Unix and failures abound. It is a big pain to fix
> this. There can easily be hundreds of images or subfiles involved.
> This situation is more common than you or I might wish :(.
> You can look it up on tex.sx etc.
>
> Thus, it's a trade-off between causing strange new failures in the
> strange case of case-conflicting files, and helping document projects
> that are developed on both Mac and (other) Unix "just work" without
> having to change anything.
>

I have been involved with multi-author projects where the authors are
scattered
across the globe and many are in government research institutes and must
use a "departmental standard" OS configuration. I can vouch for the wasted
time and effort caused when documents that work on Windows or macOS fail
on linux due to mis-cased filenames.


> I felt it was better for the TeX world, overall, if such rare case
> conflicts were explicitly dealt with, one way or another, partly because
> these same problems *have always existed* on Windows. By dealing with
> the case conflicts, documents automatically become more portable.
>
> If the case conflicts were going to be common, I would have decided
> otherwise. But I believe your case is rare -- in practice, I think the
> only likely culprit is, like yours, a file in TEXMFHOME with a
> case-different name from one in TEXMFDIST. Not that many people use
> TEXMFHOME in the first place, let alone install style files with only a
> case change from a standard name.
>
> If it turns out to be too painfully common, we can always change the
> default.
>
> They are so much powerful? ;)
>
> Evidently so :(. -k
>

In a large project you can have people with very different interests and
skills.
For some, the project may be their first encounter with TeX. It is not
just a
question of how common problems might be, but also the likelihood that
the person who encounters a problem will have some idea of how to go
about sorting it out. Keeping mis-case errors close to the where they are
made is often advantage.

--
George N. White III
Denis Bitouzé
2018-04-07 10:15:23 UTC
Reply
Permalink
Raw Message
Le 06/04/18 à 21h20, George N. White III a écrit :

> I have been involved with multi-author projects where the authors are
> scattered across the globe and many are in government research
> institutes and must use a "departmental standard" OS configuration.
> I can vouch for the wasted time and effort caused when documents that
> work on Windows or macOS fail on linux due to mis-cased filenames.

I see.

> In a large project you can have people with very different interests
> and skills. For some, the project may be their first encounter with
> TeX. It is not just a question of how common problems might be, but
> also the likelihood that the person who encounters a problem will have
> some idea of how to go about sorting it out. Keeping mis-case errors
> close to the where they are made is often advantage.

Right.

Thanks!
--
Denis
Denis Bitouzé
2018-04-07 10:12:22 UTC
Reply
Permalink
Raw Message
Le 06/04/18 à 23h35, Karl Berry a écrit :

> Sigh...
>
> Agreed.

:)

> But I (and other users) could be bitten
>
> Yes, I know. Do you really think we were unaware of this?

Obviously not. Sorry if I offended...

> Hence why not the other way round: `texmf_casefold_search' 0 by
> default
>
> I thought hard about doing it this way. I hate making incompatible
> changes. I think this is the first user-level kpse change
> intentionally made in ten years or more.

Nice! Could be worth to mention this change in the section "Present ---
2018".

> I think I wrote all this before, but I guess I'll do it again:
>
> The change is motivated for the case of big documents being developed
> on Macs, and thus \include and \includegraphics commands (for example)
> use randomly cased filenames and work regardless. Then the document is
> compiled on normal Unix and failures abound. It is a big pain to fix
> this. There can easily be hundreds of images or subfiles involved.
> This situation is more common than you or I might wish :(. You can
> look it up on tex.sx etc.

I see.

> Thus, it's a trade-off between causing strange new failures in the
> strange case of case-conflicting files, and helping document projects
> that are developed on both Mac and (other) Unix "just work" without
> having to change anything.
>
> I felt it was better for the TeX world, overall, if such rare case
> conflicts were explicitly dealt with, one way or another, partly
> because these same problems *have always existed* on Windows. By
> dealing with the case conflicts, documents automatically become more
> portable.

Right.

> If the case conflicts were going to be common, I would have decided
> otherwise. But I believe your case is rare -- in practice, I think the
> only likely culprit is, like yours, a file in TEXMFHOME with
> a case-different name from one in TEXMFDIST. Not that many people use
> TEXMFHOME in the first place, let alone install style files with only
> a case change from a standard name.

Right, again :)

> If it turns out to be too painfully common, we can always change the
> default.

Okay.

> They are so much powerful? ;)
>
> Evidently so :(. -k

;)
--
Denis
Ulrike Fischer
2018-04-07 10:56:54 UTC
Reply
Permalink
Raw Message
Am Fri, 6 Apr 2018 23:35:47 GMT schrieb Karl Berry:

> The change is motivated for the case of big documents being developed on
> Macs, and thus \include and \includegraphics commands (for example) use
> randomly cased filenames and work regardless. Then the document is
> compiled on normal Unix and failures abound. It is a big pain to fix
> this. There can easily be hundreds of images or subfiles involved.
> This situation is more common than you or I might wish :(.

I fell in this trap quite often too. I wrote examples with
\includegraphics{example-image-A} (as the image shows a large A this
is quite natural ...) which worked fine on my windows and the people
complained that it fails on linux.

So on the whole I'm quite grateful that kpathsea is now case
insensitive and it is not only Apple who is to blame ;-)

--
Ulrike Fischer
http://www.troubleshooting-tex.de/
jfbu
2018-04-07 11:01:44 UTC
Reply
Permalink
Raw Message
Le 7 avr. 2018 à 12:56, Ulrike Fischer <***@nililand.de> a écrit :

> Am Fri, 6 Apr 2018 23:35:47 GMT schrieb Karl Berry:
>
>> The change is motivated for the case of big documents being developed on
>> Macs, and thus \include and \includegraphics commands (for example) use
>> randomly cased filenames and work regardless. Then the document is
>> compiled on normal Unix and failures abound. It is a big pain to fix
>> this. There can easily be hundreds of images or subfiles involved.
>> This situation is more common than you or I might wish :(.
>
> I fell in this trap quite often too. I wrote examples with
> \includegraphics{example-image-A} (as the image shows a large A this
> is quite natural ...) which worked fine on my windows and the people
> complained that it fails on linux.
>
> So on the whole I'm quite grateful that kpathsea is now case
> insensitive and it is not only Apple who is to blame ;-)
>

+1 for this remark. I also encounter this problem when copying pasting
code from questions on tex.sx by Windows users, and discover it
does not work on my Mac OS, then I had to read more closely and
see the "A" not "a".

Karl: I found your

> You can thank Apple and its users for inflicting this pain.

somewhat annoying, and it is not first time.

Best,

Jean-François
Adam R. Maxwell
2018-04-07 13:59:35 UTC
Reply
Permalink
Raw Message
> On Apr 7, 2018, at 04:01 , jfbu <***@free.fr> wrote:
>
>> You can thank Apple and its users for inflicting this pain.
>
> somewhat annoying, and it is not first time.

Mac users are perpetual whiners, and Karl has put
up with a lot from us on the mactex mailing list :).

Having said that, I rarely saw case issues come up on
the Mac OS X TeX email list for the decade or so that I
participated, so I'll blame the new generation of TeX
users who are on tex.sx. Darn kids.

-- adam
Paulo Roberto Massa Cereda
2018-04-07 14:44:50 UTC
Reply
Permalink
Raw Message
Case sensitivity would have gotten away with it if it weren't for those
meddling kids and that dog... :D

A 7 de abril de 2018 10:59:54 AM, "Adam R. Maxwell" <***@mac.com>
escreveu:

> > On Apr 7, 2018, at 04:01 , jfbu <***@free.fr> wrote:
> >
>> > You can thank Apple and its users for inflicting this pain.
> >
> > somewhat annoying, and it is not first time.
>
> Mac users are perpetual whiners, and Karl has put
> up with a lot from us on the mactex mailing list :).
>
> Having said that, I rarely saw case issues come up on
> the Mac OS X TeX email list for the decade or so that I
> participated, so I'll blame the new generation of TeX
> users who are on tex.sx. Darn kids.
>
> -- adam
Werner LEMBERG
2018-04-08 20:24:51 UTC
Reply
Permalink
Raw Message
> The change is motivated for the case of big documents being
> developed on Macs, and thus \include and \includegraphics commands
> (for example) use randomly cased filenames and work regardless. Then
> the document is compiled on normal Unix and failures abound. It is
> a big pain to fix this. There can easily be hundreds of images or
> subfiles involved. This situation is more common than you or I
> might wish :(. You can look it up on tex.sx etc.

This thread reminded me of a script written by Scott Pakin some years
ago. Attached is an updated and slightly extended version that
provides an option to check for duplicates ignoring uppercase and
lowercase.

I'v also attached the output of

$ TEXMF=/path/to/TeXLive/Master/texmf-dist \
perl kpfinddups.pl -i "*" &> kpfinddups.all

using SVN revision 47373 (from today). As can be seen, there are some
serious clashes which deserve closer inspection, for example

arabtex/afoot.sty vs. ledmac/afoot.sty
cherokee/cherokee.tfm vs. ocherokee/Cherokee.tfm


Werner
Karl Berry
2018-04-07 21:57:23 UTC
Reply
Permalink
Raw Message
mention this change in the section "Present --- 2018".

Darn it! It was the single most important thing on my mind when I was
putting together the list of changes, and I got so wrapped up in all the
others I just forgot. Added now, both to pretest.html and
texlive-en.tex. I'll make more specific links after the release.

Thanks ... -k
Karl Berry
2018-04-07 22:42:28 UTC
Reply
Permalink
Raw Message
> How case sensitivity checking works under the hood

Well, this is probably too long for anyone to read, but below is what I
wrote about it in the manual. As for the implementation, check out the
calls to the new function casefold_readable_file in
kpathsea/pathsearch.c. The casefolding operations are also reported in
various ways in the debugging output.

Scroll down to the end, and you'll see that kpse never even tries to
determine if a given filesystem is case-sensitive or not (because
there's no good way to do so). All it does is check whether access()
on a given name succeeds.

Also, the change is only seen on *case-sensitive* systems (normal
Unix). Mac people using the default case-insensitive Mac filesystem will
not see any difference, nor will Windows people (the new code is not
even compiled on Windows, as noted below). --best, karl.

-----------------------------------------------------------------------------
[From kpathsea.info.]
...

The fallback case-insensitive search is omitted at compile-time on
Windows, where (for practical purposes) all file names are
case-insensitive at the kernel level, and so the normal search will
already have definitively matched or not. Therefore, search results in
unusual cases can be different on Windows and Unix--but this has always
been true.

File: kpathsea.info, Node: Casefolding examples, Prev: Casefolding rationale, Up: Casefolding search

5.4.2 Casefolding examples
--------------------------

The casefolding implementation prefers exact matches to casefolded
matches within a given path element, so as to retain most compatibility.
Backward compatibility is not perfect, however, as a casefolded match
may be found in an earlier path element than an exact match was
previously found (see example #4 below). Still, preferring the match in
the earlier element seemed potentially less confusing than otherwise,
and is in fact consistent with past behavior on Windows. Since case
mismatches are rare to begin with, and name collisions with respect only
to case thus even more rare, the hope is that it will not cause
difficulties in practice.

If it's desirable in a given situation to have the exact same search
behavior as previously, that can be accomplished by setting the
configuration variable 'texmf_casefold_search' to '0' (*note Path
sources::).

Some examples to illustrate the new behavior follow.

Example #1: suppose the file './foobar.tex' exists. Now, searching
for './FooBar.TeX' (or any other case variation) will succeed, returning
'./foobar.tex'--the name as stored on disk. In previous releases, or if
'texmf_casefold_search' is false, the search would fail.

Example #2: suppose we are using a case-sensitive (file)system, and
the search path is '.:/somedir', and the files './foobar.tex' and
'/somedir/FooBar.TeX' both exist. Both now and previously, searching
for 'foobar.tex' returns './foobar.tex'. However, searching for
'FooBar.TeX' now returns './foobar.tex' instead of
'/somedir/FooBar.TeX'; this is the incompatibility mentioned above.
Also (as expected), searching for 'FOOBAR.TEX' (or whatever variation)
will now return './foobar.tex', whereas before it would fail. Searching
for all ('kpsewhich --all') 'foobar.tex' will return both matches.

Example #3: same as example #2, but on a case-insensitive
(file)system: both now and previously, searching for 'FooBar.TeX'
returns './foobar.tex', since the system considers that a match. The
Kpathsea casefolding never comes into play.

Example #4: if we have (on a case-sensitive system) both
'./foobar.tex' and './FOOBAR.TEX', searching with the exact case returns
that exact match, now and previously. Searching for 'FooBar.tex' will
now return one or the other (chosen arbitrarily), rather than failing.
Perhaps unexpectedly, searching for all 'foobar.tex' or 'FooBar.tex'
will also return only one or the other, not both (see more below).

Example #5: the font file 'STIX-Regular.otf' is included in TeX Live
in the system directory 'texmf-dist/fonts/opentype/public/stix'.
Because Kpathsea never searches the disk in the big system directory,
the casefolding is not done, and a search for 'stix-regular.otf' will
fail (on case-sensitive systems), as it always has.

The caveat about not searching the disk amounts to saying that
casefolding does not happen in the trees specified with '!!' (*note
ls-R::), that is, where only database ('ls-R') searching is done. In
TeX Live, that is the 'texmf-local' and 'texmf-dist' trees (also
'$TEXMFSYSCONFIG' and '$TEXMFSYSVAR', but those are rarely noticed).
The rationale for this is that in practice, case mangling happens with
user-created files, not with packages distributed as part of the TeX
system.

One more caveat: the purpose of 'kpsewhich' is to exercise the path
searching in Kpathsea as it is actually done. Therefore, as shown
above, 'kpsewhich --all' will not return all matches regardless of case
within a given path element. If you want to find all matches in all
directories, 'find' is the best tool, although the setup takes a couple
steps:

kpsewhich -show-path=tex >/tmp/texpath # search path specification
kpsewhich -expand-path="`cat /tmp/texpath`" >/tmp/texdirs # all dirs
tr ':' '\n' </tmp/texdirs >/tmp/texdirlist # colons to newlines
find `cat /tmp/texdirlist` -iname somefile.tex -print </tmp/texdirlist

Sorry that it's annoyingly lengthy, but implementing this inside
Kpathsea would be a lot of error-prone trouble for something that is
only useful for debugging. If your 'find' does not support '-iname',
you can get GNU Find from <https://www.gnu.org/software/findutils>.

The casefolding search is implemented in the source file
'kpathsea/pathsearch.c'. Two implementation points:

* Kpathsea never tries to check if a given directory resides on a
case-insensitive filesystem, because there is no efficient and
portable way to do so. All it does is try to see if a potential
file name is a readable normal file (with, usually, the 'access'
system call).

* Kpathsea does not do any case-insensitive matching of the
directories along the path. It's not going to find
'/Some/Random/file.tex' when looking for '/some/random/file.tex'.
The casefolding only happens with the elements of the leaf
directory.
Karl Berry
2018-04-08 20:31:20 UTC
Reply
Permalink
Raw Message
serious clashes which deserve closer inspection, for example

Thanks. I was aware of afoot and many others (I have another
duplicate-finding script that I run every night) that have been around
for years, seemingly impossible to resolve, and no practical bugs have
been reported for them. So they remain.

As for [cC]herokee.tfm and the like, I hadn't thought about that, but it
shouldn't be a problem, because case-insensitive matching is not done in
texmf-dist. --thanks again, karl.
Daniel H. Luecking
2018-04-09 20:03:28 UTC
Reply
Permalink
Raw Message
After all the discussion here about case (in)sensitive searching in the
pretest TL2018, I got the impression that Windows was immune, as all
its filenames are case insensitive.

However, in two different Windows 7 systems I got a "file not found"
errors from updmap, possibly because updmap.cfg contains "minionpro.map"
while on disk (and in ls-R) the file was named "MinionPro.map" (It resides
under texmf-local). There was no such problem in prior TL2017.

I'm sorry, but I just cannot tell from Karl's explanation whether this
is how it is supposed to behave, so I am reporting it here. I have since
renamed the file and rerun texhash, so the problem is no more for me.

Best,

Daniel H. Luecking, Graduate Coordinator
Dept. of Mathematical Sciences
University of Arkansas
Fayetteville, AR, USA
Akira Kakuto
2018-04-09 21:07:14 UTC
Reply
Permalink
Raw Message
> However, in two different Windows 7 systems
> I got a "file not found" errors from updmap, possibly
> because updmap.cfg contains "minionpro.map" while on
> disk (and in ls-R) the file was named "MinionPro.map"
> (It resides under texmf-local). There was no such problem
> in prior TL2017.

I think I didn't change the matching condition
in kpathsea for Windows. I don't know a reason of the above
behavior. Probably a feature of the program updmap.

However, I will change the matching condition in the next TL 2019:
case-sensitive matching is done even on Windows for trees with ls-R.

Best,
Akira
Norbert Preining
2018-04-10 02:56:45 UTC
Reply
Permalink
Raw Message
> However, in two different Windows 7 systems I got a "file not found"
> errors from updmap, possibly because updmap.cfg contains "minionpro.map"

This is interesting, can you show the actual output?

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
Norbert Preining
2018-04-10 23:51:30 UTC
Reply
Permalink
Raw Message
Hi Daniel,

please keep Cc the list.

> updmap [ERROR]: The following map file(s) couldn't be found:
> updmap [ERROR]: minionpro.map (in c:/tl/texmf-local/web2c/updmap.cfg)
> updmap [ERROR]: Did you run mktexlsr?

What does
kpsewhich minionpro.map
say? And what does
kpsewhich MinionPro.map
say?


Thanks


On Tue, 10 Apr 2018, Daniel H. Luecking wrote:
>
> Norbert:
>
>
> Here is the screen output of texhash, updmap, a directory
>
> listing of the relevant map file and a grep of both ls-R
>
> and the texmf-local updmap.cfg:
>
> =======================================
> [C:\work]texhash \tl\texmf-local\
> texhash: Updating /tl/texmf-local/ls-R...
> texhash: Updated /tl/texmf-local/ls-R.
> texhash: Done.
>
>
> [C:\work]updmap-sys
> updmap will read the following updmap.cfg files (in precedence order):
> c:/tl/texmf-local/web2c/updmap.cfg
> c:/tl/2018/texmf-dist/web2c/updmap.cfg
> updmap may write changes to the following updmap.cfg file:
> c:/tl/2018/texmf-config/web2c/updmap.cfg
> dvips output dir: "c:/tl/2018/texmf-var/fonts/map/dvips/updmap"
> pdftex output dir: "c:/tl/2018/texmf-var/fonts/map/pdftex/updmap"
> dvipdfmx output dir: "c:/tl/2018/texmf-var/fonts/map/dvipdfmx/updmap"
> updmap [ERROR]: The following map file(s) couldn't be found:
> updmap [ERROR]: minionpro.map (in c:/tl/texmf-local/web2c/updmap.cfg)
> updmap [ERROR]: Did you run mktexlsr?
>
> You can disable non-existent map entries using the option
> --syncwithtrees.
>
> C:\tl\2018\bin\win32\runscript.tlu:758: command failed with exit code 1:
> perl.exe c:\tl\2018\texmf-dist\scripts\texlive\updmap.pl --sys
>
>
> [C:\work]dir \tl\texmf-local\fonts\map\dvips\MinionPro\
>
> Volume in drive C is unlabeled Serial number is 52ca:aaa7
> Directory of C:\tl\texmf-local\fonts\map\dvips\MinionPro\*
>
> 4/10/2018 15:33 <DIR> .
> 4/10/2018 15:33 <DIR> ..
> 4/28/2007 4:38 32,470 MinionPro.map
> 32,470 bytes in 1 file and 2 dirs 32,768 bytes allocated
> 417,892,044,800 bytes free
>
>
> [C:\work]grep -C1 MinionPro.map \tl\texmf-local\ls-R
> ./fonts/map/dvips/MinionPro:
> MinionPro.map
>
> [C:\work]grep minionpro \tl\texmf-local\web2c\updmap.cfg
> Map minionpro.map
>
> ========================================
>
>
> If I rename the file MinionPro.map to minionpro.map (even without
>
> running texhash), or edit updmap.cfg to contain "MinionPro.map"
>
> instead of "minionpro.map" then updmap works.
>
>
> Best,
>
> Dan
>
>
> Daniel H. Luecking [***@uark.edu]
> Department of Mathematical Sciences
> 1 University of Arkansas
> Fayetteville, AR, USA 72701-1201
>
>
> ________________________________
> From: Norbert Preining <***@logic.at>
> Sent: Monday, April 9, 2018 9:56 PM
> To: Daniel H. Luecking
> Cc: tex-***@tug.org
> Subject: Re: [tex-live] kpsewhich case insensitive?
>
> > However, in two different Windows 7 systems I got a "file not found"
> > errors from updmap, possibly because updmap.cfg contains "minionpro.map"
>
> This is interesting, can you show the actual output?
>
> Norbert
>
> --
> PREINING Norbert https://urldefense.proofpoint.com/v2/url?u=http-3A__www.preining.info&d=DwIBAg&c=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA&r=TC6doj34eEZMeTCOMVYeIK4ttwYpTurqDpMOi43sP18&m=Xo7GRNAB_TQvcLEiv1sy5i3etDFiDU_F9Eygic_0j_w&s=7yjxrRddRJ7VN83XN9KA9OUxdaOjU7vfbTgNEawrHE8&e=
> Accelia Inc. + JAIST + TeX Live + Debian Developer
> GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
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
Daniel H. Luecking
2018-04-11 15:37:50 UTC
Reply
Permalink
Raw Message
Both the same:

================================

[C:\work]kpsewhich minionpro.map
c:/tl/texmf-local/fonts/map/dvips/MinionPro/MinionPro.map

[C:\work]kpsewhich MinionPro.map
c:/tl/texmf-local/fonts/map/dvips/MinionPro/MinionPro.map

================================


Further tests show that kpsewhich returns the same filename

as dir returns, regardless of the case in ls-R (when I

manually arrange for it to be different) and regardless

of the case on the command line.



Cheers,


Daniel H. Luecking [***@uark.edu]
Department of Mathematical Sciences
1 University of Arkansas
Fayetteville, AR, USA 72701-1201


________________________________
From: Norbert Preining <***@logic.at>
Sent: Tuesday, April 10, 2018 6:51 PM
To: Daniel H. Luecking
Cc: tex-***@tug.org
Subject: Re: [tex-live] kpsewhich case insensitive?

Hi Daniel,

please keep Cc the list.

> updmap [ERROR]: The following map file(s) couldn't be found:
> updmap [ERROR]: minionpro.map (in c:/tl/texmf-local/web2c/updmap.cfg)
> updmap [ERROR]: Did you run mktexlsr?

What does
kpsewhich minionpro.map
say? And what does
kpsewhich MinionPro.map
say?


Thanks


On Tue, 10 Apr 2018, Daniel H. Luecking wrote:
>
> Norbert:
>
>
> Here is the screen output of texhash, updmap, a directory
>
> listing of the relevant map file and a grep of both ls-R
>
> and the texmf-local updmap.cfg:
>
> =======================================
> [C:\work]texhash \tl\texmf-local\
> texhash: Updating /tl/texmf-local/ls-R...
> texhash: Updated /tl/texmf-local/ls-R.
> texhash: Done.
>
>
> [C:\work]updmap-sys
> updmap will read the following updmap.cfg files (in precedence order):
> c:/tl/texmf-local/web2c/updmap.cfg
> c:/tl/2018/texmf-dist/web2c/updmap.cfg
> updmap may write changes to the following updmap.cfg file:
> c:/tl/2018/texmf-config/web2c/updmap.cfg
> dvips output dir: "c:/tl/2018/texmf-var/fonts/map/dvips/updmap"
> pdftex output dir: "c:/tl/2018/texmf-var/fonts/map/pdftex/updmap"
> dvipdfmx output dir: "c:/tl/2018/texmf-var/fonts/map/dvipdfmx/updmap"
> updmap [ERROR]: The following map file(s) couldn't be found:
> updmap [ERROR]: minionpro.map (in c:/tl/texmf-local/web2c/updmap.cfg)
> updmap [ERROR]: Did you run mktexlsr?
>
> You can disable non-existent map entries using the option
> --syncwithtrees.
>
> C:\tl\2018\bin\win32\runscript.tlu:758: command failed with exit code 1:
> perl.exe c:\tl\2018\texmf-dist\scripts\texlive\updmap.pl --sys
>
>
> [C:\work]dir \tl\texmf-local\fonts\map\dvips\MinionPro\
>
> Volume in drive C is unlabeled Serial number is 52ca:aaa7
> Directory of C:\tl\texmf-local\fonts\map\dvips\MinionPro\*
>
> 4/10/2018 15:33 <DIR> .
> 4/10/2018 15:33 <DIR> ..
> 4/28/2007 4:38 32,470 MinionPro.map
> 32,470 bytes in 1 file and 2 dirs 32,768 bytes allocated
> 417,892,044,800 bytes free
>
>
> [C:\work]grep -C1 MinionPro.map \tl\texmf-local\ls-R
> ./fonts/map/dvips/MinionPro:
> MinionPro.map
>
> [C:\work]grep minionpro \tl\texmf-local\web2c\updmap.cfg
> Map minionpro.map
>
> ========================================
>
>
> If I rename the file MinionPro.map to minionpro.map (even without
>
> running texhash), or edit updmap.cfg to contain "MinionPro.map"
>
> instead of "minionpro.map" then updmap works.
>
>
> Best,
>
> Dan
>
>
> Daniel H. Luecking [***@uark.edu]
> Department of Mathematical Sciences
> 1 University of Arkansas
> Fayetteville, AR, USA 72701-1201
>
>
> ________________________________
> From: Norbert Preining <***@logic.at>
> Sent: Monday, April 9, 2018 9:56 PM
> To: Daniel H. Luecking
> Cc: tex-***@tug.org
> Subject: Re: [tex-live] kpsewhich case insensitive?
>
> > However, in two different Windows 7 systems I got a "file not found"
> > errors from updmap, possibly because updmap.cfg contains "minionpro.map"
>
> This is interesting, can you show the actual output?
>
> Norbert
>
> --
> PREINING Norbert https://urldefense.proofpoint.com/v2/url?u=http-3A__www.preining.info&d=DwIBAg&c=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA&r=TC6doj34eEZMeTCOMVYeIK4ttwYpTurqDpMOi43sP18&m=Xo7GRNAB_TQvcLEiv1sy5i3etDFiDU_F9Eygic_0j_w&s=7yjxrRddRJ7VN83XN9KA9OUxdaOjU7vfbTgNEawrHE8&e=
> Accelia Inc. + JAIST + TeX Live + Debian Developer
> GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Norbert

--
PREINING Norbert https://urldefense.proofpoint.com/v2/url?u=http-3A__www.preining.info&d=DwIBAg&c=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA&r=TC6doj34eEZMeTCOMVYeIK4ttwYpTurqDpMOi43sP18&m=4D_LfKoSFwp6NtrOR7lZhQXm2oXDDQqUKfIQD8CEMi8&s=66sMuTsz_u6wIqtpeiQX-Ckeq0Q89lBFtRg8cCyLN_U&e=
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Norbert Preining
2018-04-11 23:50:42 UTC
Reply
Permalink
Raw Message
> [C:\work]kpsewhich minionpro.map
> c:/tl/texmf-local/fonts/map/dvips/MinionPro/MinionPro.map

This is strange, because this is the way how updmap checks for the
existence of map files.

There is one more thing to be checked: What does
kpsewhich -all minionpro.map dvips35.map pdftex35.map ps2pk35.map
say? And the same with
kpsewhich -all MinionPro.map dvips35.map pdftex35.map ps2pk35.map

Thanks

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
Daniel H. Luecking
2018-04-12 20:41:47 UTC
Reply
Permalink
Raw Message
Here you go:

=====================================

[C:\work]kpsewhich -all minionpro.map dvips35.map pdftex35.map ps2pk35.map

c:/tl/texmf-local/fonts/map/dvips/MinionPro/MinionPro.map
c:/tl/2018/texmf-dist/fonts/map/dvips/tetex/dvips35.map
c:/tl/2018/texmf-dist/fonts/map/dvips/tetex/pdftex35.map
c:/tl/2018/texmf-dist/fonts/map/dvips/tetex/ps2pk35.map

[C:\work]kpsewhich -all MinionPro.map dvips35.map pdftex35.map ps2pk35.map

c:/tl/texmf-local/fonts/map/dvips/MinionPro/MinionPro.map
c:/tl/2018/texmf-dist/fonts/map/dvips/tetex/dvips35.map
c:/tl/2018/texmf-dist/fonts/map/dvips/tetex/pdftex35.map
c:/tl/2018/texmf-dist/fonts/map/dvips/tetex/ps2pk35.map
=====================================


Perhaps updmap does a case sensitive comparison of the kpsewhich

return value with the map line in updmap.cfg, and throws the error

without trying to get the file. The following looks like that to me

(although I know only a little about perl):

----------

my @fullpath = `kpsewhich --format=map @maps`;
chomp @fullpath;
foreach my $map (@maps) {
my ($ff) = grep /\/$map(\.map)?$/, @fullpath;
if ($ff) {
$alldata->{'maps'}{$map}{'fullpath'} = $ff;
} else {
# if the map file is not found, then push it onto the list of
# missing map files, since we know that it is enabled
push @missing, $map;
}
----------


Best,


Daniel H. Luecking [***@uark.edu]
Department of Mathematical Sciences
1 University of Arkansas
Fayetteville, AR, USA 72701-1201


________________________________
From: Norbert Preining <***@logic.at>
Sent: Wednesday, April 11, 2018 6:50 PM
To: Daniel H. Luecking
Cc: tex-***@tug.org
Subject: Re: [tex-live] kpsewhich case insensitive?

> [C:\work]kpsewhich minionpro.map
> c:/tl/texmf-local/fonts/map/dvips/MinionPro/MinionPro.map

This is strange, because this is the way how updmap checks for the
existence of map files.

There is one more thing to be checked: What does
kpsewhich -all minionpro.map dvips35.map pdftex35.map ps2pk35.map
say? And the same with
kpsewhich -all MinionPro.map dvips35.map pdftex35.map ps2pk35.map

Thanks

Norbert

--
PREINING Norbert https://urldefense.proofpoint.com/v2/url?u=http-3A__www.preining.info&d=DwIBAg&c=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA&r=TC6doj34eEZMeTCOMVYeIK4ttwYpTurqDpMOi43sP18&m=nkeqAhArwk0LzhMC90mPwP31jbwEV52q75TIyc-D-qk&s=5A_ITYet-teg0ll4B2s86tbFdJ_iEfODb8Zar8CraAU&e=
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Norbert Preining
2018-04-12 22:28:37 UTC
Reply
Permalink
Raw Message
On Thu, 12 Apr 2018, Daniel H. Luecking wrote:
> [C:\work]kpsewhich -all minionpro.map dvips35.map pdftex35.map ps2pk35.map
> c:/tl/texmf-local/fonts/map/dvips/MinionPro/MinionPro.map

Ahhh, here we go ...

> Perhaps updmap does a case sensitive comparison of the kpsewhich
> return value with the map line in updmap.cfg, and throws the error

Yes, that is the reason.

I will fix this but probably *after* release. For now please rename the
.map file.

Thanks for helping tracking this down

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
2018-04-09 21:24:04 UTC
Reply
Permalink
Raw Message
> I think I didn't change the matching condition
> in kpathsea for Windows.

I didn't change the matching condition, but
I changed the return value of kpathsea:
In TL2017,
kpsewhich ieeetran.cls
showed
c:/texlive/2017/texmf-dist/tex/latex/ieeetran/ieeetran.cls

In TL2018, it shows the 'actual' name:
c:/texlive/2018/texmf-dist/tex/latex/ieeetran/IEEEtran.cls

Maybe this is the reason of Daniel's example.

In the next TL2019,
kpsewhich ieeetran.cls
does not print anything.

Best,
Akira
Karl Berry
2018-04-09 21:45:24 UTC
Reply
Permalink
Raw Message
pretest TL2018, I got the impression that Windows was immune,

That was my impression too.

However, in two different Windows 7 systems I got a "file not found"
errors from updmap, possibly because updmap.cfg contains "minionpro.map"
while on disk (and in ls-R) the file was named "MinionPro.map" (It resides
under texmf-local). There was no such problem in prior TL2017.

All I can report is that to the best of my knowledge, the new kpathsea
code I wrote is not even compiled on Windows.

I suppose Akira's reply must somehow imply the difference, but I can't
understand how updmap could care what the case was of anything on
Windows. Surely Perl's open(IN,"SomeFile") succeeds even if the file
is named somefile on disk (in Windows)? -k
Akira Kakuto
2018-04-16 04:45:43 UTC
Reply
Permalink
Raw Message
> In TL2018, it shows the 'actual' name:
> c:/texlive/2018/texmf-dist/tex/latex/ieeetran/IEEEtran.cls
>
> Maybe this is the reason of Daniel's example.
>
> In the next TL2019,
> kpsewhich ieeetran.cls
> does not print anything.

After discussion with some people, I decided not
to change the present case-insensitive matching
on Windows, even in texmf trees with ls-R.
Thus, in the next TL2019 also
kpsewhich ieeetran.cls
shall show
c:/texlive/2019/texmf-dist/tex/latex/ieeetran/IEEEtran.cls

Best,
Akira
Loading...