Hi,

I recently upgraded to MikTex 2.9 and find that my documents do not
process properly any more. There are tons of undefined references to
entries in my .bbl file. Is this a bug in MiKTeX? Is there a
workaround? Any ideas? Thanks.

Am Tue, 7 Dec 2010 15:55:03 -0800 (PST) schrieb Gus Gassmann:

> Hi,
> 
> I recently upgraded to MikTex 2.9 and find that my documents do not
> process properly any more. There are tons of undefined references to
> entries in my .bbl file. Is this a bug in MiKTeX? Is there a
> workaround? Any ideas? Thanks.

You are not giving any useful information. Make a complete small
minimal example that demonstrates your problem. 


-- 
Ulrike Fischer 

On Dec 8, 4:40=A0am, Ulrike Fischer <ne...@nililand.de> wrote:
> Am Tue, 7 Dec 2010 15:55:03 -0800 (PST) schrieb Gus Gassmann:
>
> > Hi,
>
> > I recently upgraded to MikTex 2.9 and find that my documents do not
> > process properly any more. There are tons of undefined references to
> > entries in my .bbl file. Is this a bug in MiKTeX? Is there a
> > workaround? Any ideas? Thanks.
>
> You are not giving any useful information. Make a complete small
> minimal example that demonstrates your problem.

Thanks for replying. I think I figured out what is going on. In my
previous version of MiKTeX, I could say

pdflatex osUsersmanual_2.2

and it would find the correct bbl file, osUsersManual_2.2.bbl. In the
updated version, for some reason it looks for osUsersManual_2.bbl,
although this information is buried in about 1000 lines of a log file.
The only symptom I see is "undefined references", which is normal the
first two times through the file, anyway.

My problem does go away when I type

pdflatex osUsersmanual_2.2.tex

Is this behavior a bug or a feature? I would tend to think the former.

Am Wed, 8 Dec 2010 03:43:10 -0800 (PST) schrieb Gus Gassmann:


>>> I recently upgraded to MikTex 2.9 and find that my documents do not
>>> process properly any more. There are tons of undefined references to
>>> entries in my .bbl file. Is this a bug in MiKTeX? Is there a
>>> workaround? Any ideas? Thanks.

>> You are not giving any useful information. Make a complete small
>> minimal example that demonstrates your problem.
 
> Thanks for replying. I think I figured out what is going on. In my
> previous version of MiKTeX, I could say
> 
> pdflatex osUsersmanual_2.2
> 
> and it would find the correct bbl file, osUsersManual_2.2.bbl. In the
> updated version, for some reason it looks for osUsersManual_2.bbl,
> although this information is buried in about 1000 lines of a log file.
> The only symptom I see is "undefined references", which is normal the
> first two times through the file, anyway.
> 
> My problem does go away when I type
> 
> pdflatex osUsersmanual_2.2.tex
> 
> Is this behavior a bug or a feature? I would tend to think the former.

Well I just checked in miktex 2.8 and 2.9.: 
"pdflatex test.dot" will process "test.dot.tex" (if it exists) and
write the output to test.pdf, test.aux and test.log and set the
\jobname to "test". So naturally the bibliography will look for
test.bbl (and not test.dot.bbl). 

I don't know how it was handled in previous miktex versions but I
found an rather old posting from 1998 which described the similar
behaviour for another TeX system. 

I also know from another discussion that the handling of file with
more than one dot in the name can differ between the TeX systems. So
my advice is: avoid dots, spaces and non-ascii chars in file names.
Even if they work now you never know what happens if you change the
TeX version, the TeX system or the OS. 



-- 
Ulrike Fischer 

Le 08/12/2010 16:53, Ulrike Fischer a �crit :
> Am Wed, 8 Dec 2010 03:43:10 -0800 (PST) schrieb Gus Gassmann:

> I also know from another discussion that the handling of file with
> more than one dot in the name can differ between the TeX systems. So
> my advice is: avoid dots, spaces and non-ascii chars in file names.
> Even if they work now you never know what happens if you change the
> TeX version, the TeX system or the OS.

Well: no dot in a .pdf file is good practice.
Requirement for no space is not admissible in 2010 !!!
And it's enormously annoying to rename your final document.

Best regards.

On 08/12/10 16:02, GL wrote:
> Le 08/12/2010 16:53, Ulrike Fischer a �crit :
>> Am Wed, 8 Dec 2010 03:43:10 -0800 (PST) schrieb Gus Gassmann:
> 
>> I also know from another discussion that the handling of file with
>> more than one dot in the name can differ between the TeX systems. So
>> my advice is: avoid dots, spaces and non-ascii chars in file names.
>> Even if they work now you never know what happens if you change the
>> TeX version, the TeX system or the OS.
> 
> Well: no dot in a .pdf file is good practice.

Don't believe everything Windows forces you to observe.

> Requirement for no space is not admissible in 2010 !!!

It is not good practice to use spaces in file names. The fact that it
may be attractive to users to do so is not a valid argument.

This is where practice bangs up against usability. Normal usability
rules would mean allowing users to use any character in a filename,
including the slash, backslash, colon, newline, and control characters.
For practical reasons, this is not sensible, so a compromise has to be
reached, and the jury is still out on this. Until all operating systems
and all applications, including scripting languages, accept arbitrary
filenames, the rule is "be conservative in what you supply; liberal in
what you accept"...which means never using bogus characters in filenames
you create yourself. It also means that applications like MiKTeX and
processors like TeX *ought* to try much harder, but that's not within a
user's control.

> And it's enormously annoying to rename your final document.

Don't create files with bogus names in the first place...

///Peter

Peter Flynn <peter.nosp@m.silmaril.ie> writes:

> On 08/12/10 16:02, GL wrote:
>> Le 08/12/2010 16:53, Ulrike Fischer a écrit :
>>> Am Wed, 8 Dec 2010 03:43:10 -0800 (PST) schrieb Gus Gassmann:
>> 
>>> I also know from another discussion that the handling of file with
>>> more than one dot in the name can differ between the TeX systems. So
>>> my advice is: avoid dots, spaces and non-ascii chars in file names.
>>> Even if they work now you never know what happens if you change the
>>> TeX version, the TeX system or the OS.
>> 
>> Well: no dot in a .pdf file is good practice.
>
> Don't believe everything Windows forces you to observe.

Windows doesn't force anything like that on file names.

>
>> Requirement for no space is not admissible in 2010 !!!
>
> It is not good practice to use spaces in file names.

A file name is a user-visible text string, and every normal character
should be allowed.  Spaces in file names have never posed a principal
problem in Windows for decades, and they are regularly used even by
system directories ("Program Files", "Documents and Settings"...).

> This is where practice bangs up against usability. Normal usability
> rules would mean allowing users to use any character in a filename,
> including the slash, backslash, colon, newline, and control
> characters.

Of course, and that some of these characters are disallowed is a major
flaw.  (An even bigger flaw is the existence of the concept of file, but
that's a different story.)

> For practical reasons, this is not sensible,

There are very few irrevocable technical limitations on file names:
Windows forbids a small set of punctuation characters and a few special
names, Unix-like systems forbid the slash character and another set of
special names.  Apart from that, every Unicode string is a valid file
name, including strings with space characters.

> Until all operating systems
> and all applications, including scripting languages, accept arbitrary
> filenames

They already do, except for the few technical limitation that I
mentioned above.  Any system that doesn't accept all file names
supported by the underlying operating system is considered broken.

> the rule is "be conservative in what you supply; liberal in
> what you accept"

That rule has been proven wrong many times.

> It also means that applications like MiKTeX and
> processors like TeX *ought* to try much harder

AFAIK all current engines can process file names with spaces (but not
with arbitrary Unicode characters on Windows):

/tmp $ cat a\ b.tex 
Hello World!
\bye
/tmp $ tex a\ b.tex 
This is TeX, Version 3.1415926 (TeX Live 2010)
(./a b.tex [1] )
Output written on "a b.dvi" (1 page, 228 bytes).
Transcript written on "a b.log".

-- 
Change “LookInSig” to “tcalveu” to answer by mail.

On Dec 9, 5:59=A0am, Peter Flynn <peter.n...@m.silmaril.ie> wrote:
> On 08/12/10 16:02, GL wrote:
>
> > Le 08/12/2010 16:53, Ulrike Fischer a crit :
> >> Am Wed, 8 Dec 2010 03:43:10 -0800 (PST) schrieb Gus Gassmann:
>
> >> I also know from another discussion that the handling of file with
> >> more than one dot in the name can differ between the TeX systems. So
> >> my advice is: avoid dots, spaces and non-ascii chars in file names.
> >> Even if they work now you never know what happens if you change the
> >> TeX version, the TeX system or the OS.
>
> > Well: no dot in a .pdf file is good practice.
>
> Don't believe everything Windows forces you to observe.
>
> > Requirement for no space is not admissible in 2010 !!!
>
> It is not good practice to use spaces in file names. The fact that it
> may be attractive to users to do so is not a valid argument.
>
> This is where practice bangs up against usability. Normal usability
> rules would mean allowing users to use any character in a filename,
> including the slash, backslash, colon, newline, and control characters.
> For practical reasons, this is not sensible, so a compromise has to be
> reached, and the jury is still out on this. Until all operating systems
> and all applications, including scripting languages, accept arbitrary
> filenames, the rule is "be conservative in what you supply; liberal in
> what you accept"...which means never using bogus characters in filenames
> you create yourself. It also means that applications like MiKTeX and
> processors like TeX *ought* to try much harder, but that's not within a
> user's control.
>
> > And it's enormously annoying to rename your final document.
>
> Don't create files with bogus names in the first place...

I understand that this was not directed at me, but I can't help but
wonder. Why is it so heinous to want to call my file
osUsersManual_2.2.tex? 2.2 is the version number, and I feel that it
is an important part of the file name. MiKTeX 2.4 processed this file
perfectly well, but when I upgraded to version 2.9 things fell apart.
Could/should I have anticipated that?

Gus Gassmann <horand.gassmann@googlemail.com> writes:

> I understand that this was not directed at me, but I can't help but
> wonder. Why is it so heinous to want to call my file
> osUsersManual_2.2.tex? 2.2 is the version number, and I feel that it
> is an important part of the file name. MiKTeX 2.4 processed this file
> perfectly well, but when I upgraded to version 2.9 things fell apart.
> Could/should I have anticipated that?

No, and I think it can be considered a bug.  TeX Live doesn't choke on
such files:

/tmp $ cat osUsersManual_2.2.tex 
Hello World!
\bye
/tmp $ tex osUsersManual_2.2.tex 
This is TeX, Version 3.1415926 (TeX Live 2010)
(./osUsersManual_2.2.tex [1] )
Output written on osUsersManual_2.2.dvi (1 page, 228 bytes).
Transcript written on osUsersManual_2.2.log.

-- 
Change “LookInSig” to “tcalveu” to answer by mail.

Am Thu, 9 Dec 2010 19:01:20 -0800 (PST) schrieb Gus Gassmann:


>>>> I also know from another discussion that the handling of file with
>>>> more than one dot in the name can differ between the TeX systems. So
>>>> my advice is: avoid dots, spaces and non-ascii chars in file names.
>>>> Even if they work now you never know what happens if you change the
>>>> TeX version, the TeX system or the OS.

>> Don't create files with bogus names in the first place...
 
> I understand that this was not directed at me, but I can't help but
> wonder. Why is it so heinous to want to call my file
> osUsersManual_2.2.tex? 2.2 is the version number, and I feel that it
> is an important part of the file name. MiKTeX 2.4 processed this file
> perfectly well, but when I upgraded to version 2.9 things fell apart.

Well it didn't fell completly apart: You only need to call bibtex
"jobname" to regenerate a bbl with the name expected by pdflatex.

> Could/should I have anticipated that?

At the core of the problem is the fact that tex allows you to omit
the extension ".tex". 

\input test will find and input test.tex.

Now assume that you have in a folder this files:
test.cfg.tex, test.cfg, test.tex.tex, tex.tex

which one should be finded and used by 
\input test.cfg?
\input test.tex?

And this changed in the course of time.
See also:
http://groups.google.com/group/comp.text.tex/browse_thread/thread/d5ba449fd38051bc/e9f5a4681d6931f6


The second problem is the question of \jobname: In filenames with
more than one dot, miktex has to decide where the filename stops and
the extension starts. E.g. how would you separate 

file.tar.gz? file.v1.1.tex? file.txt.tex?


This said, I think that it would probably be better that miktex
should like TeXLive set the \jobname to test.dot when it process
test.dot.tex. I suggest that you make a bug report.  


-- 
Ulrike Fischer 

Philipp Stephani <LookInSig@arcor.de> writes:

> Gus Gassmann <horand.gassmann@googlemail.com> writes:
>
>> I understand that this was not directed at me, but I can't help but
>> wonder. Why is it so heinous to want to call my file
>> osUsersManual_2.2.tex? 2.2 is the version number, and I feel that it
>> is an important part of the file name. MiKTeX 2.4 processed this file
>> perfectly well, but when I upgraded to version 2.9 things fell apart.
>> Could/should I have anticipated that?
>
> No, and I think it can be considered a bug.  TeX Live doesn't choke on
> such files:
>
> /tmp $ cat osUsersManual_2.2.tex 
> Hello World!
> \bye
> /tmp $ tex osUsersManual_2.2.tex 
> This is TeX, Version 3.1415926 (TeX Live 2010)
> (./osUsersManual_2.2.tex [1] )
> Output written on osUsersManual_2.2.dvi (1 page, 228 bytes).
> Transcript written on osUsersManual_2.2.log.

the problem would appear to be with auxiliary files, and default
extensions.  auxiliary file names are generated by macros, and the
algorithms involved have always been troublesome.  heiko has a
replacement set as a contributed plug-in to the graphics package; i
don't know whether it could be configured for use elsewhere.

so i presume you're offering replacement macros for use in latex?
(note, of course, that by default you simply _can't_ use arbitrary
unicode characters in a file name in latex; you need xelatex or lualatex
-- inputenc's mediation really can't hack things like file names.)

it's all very well claiming that the authors of stuff are deficient in
not providing the latest and greatest ways forward ... in a free
software environment, you have to be aware that people may no longer be
in a position to move their stuff on.  in such a situation, it's up to
the complainer to provide, or to find someone else to provide, the
solution to the problem.

"unacceptable" just doesn't work here.
-- 
Robin Fairbairns, Cambridge

Ulrike Fischer <news3@nililand.de> writes:

> Now assume that you have in a folder this files:
> test.cfg.tex, test.cfg, test.tex.tex, tex.tex
>
> which one should be finded and used by 
> \input test.cfg?
> \input test.tex?

The files test.cfg and test.tex, of course!  Guessing the correct
extension is flawed anyway, and if a proper file name is given, it
should always be preferred (AFAIK TeX Live does so).

> The second problem is the question of \jobname: In filenames with
> more than one dot, miktex has to decide where the filename stops and
> the extension starts. E.g. how would you separate 
>
> file.tar.gz? file.v1.1.tex? file.txt.tex?

The relevant dot is always the last one.

-- 
Change “LookInSig” to “tcalveu” to answer by mail.

Robin Fairbairns <rf10@warp.cl.cam.ac.uk> writes:

> Philipp Stephani <LookInSig@arcor.de> writes:
>
>> Gus Gassmann <horand.gassmann@googlemail.com> writes:
>>
>>> I understand that this was not directed at me, but I can't help but
>>> wonder. Why is it so heinous to want to call my file
>>> osUsersManual_2.2.tex? 2.2 is the version number, and I feel that it
>>> is an important part of the file name. MiKTeX 2.4 processed this file
>>> perfectly well, but when I upgraded to version 2.9 things fell apart.
>>> Could/should I have anticipated that?
>>
>> No, and I think it can be considered a bug.  TeX Live doesn't choke on
>> such files:
>>
>> /tmp $ cat osUsersManual_2.2.tex 
>> Hello World!
>> \bye
>> /tmp $ tex osUsersManual_2.2.tex 
>> This is TeX, Version 3.1415926 (TeX Live 2010)
>> (./osUsersManual_2.2.tex [1] )
>> Output written on osUsersManual_2.2.dvi (1 page, 228 bytes).
>> Transcript written on osUsersManual_2.2.log.
>
> the problem would appear to be with auxiliary files, and default
> extensions.  auxiliary file names are generated by macros, and the
> algorithms involved have always been troublesome.  heiko has a
> replacement set as a contributed plug-in to the graphics package; i
> don't know whether it could be configured for use elsewhere.

The main problem seems to be that the LaTeX kernel assumes at most one
dot in file names, and no spaces.  In principle all current engines are
able to access files with multiple dots or spaces.

> so i presume you're offering replacement macros for use in latex?
> (note, of course, that by default you simply _can't_ use arbitrary
> unicode characters in a file name in latex; you need xelatex or lualatex
> -- inputenc's mediation really can't hack things like file names.)

AFAIK the situation isn't really different in XeTeX and LuaTeX—the
Unicode stuff plays its major role in the typesetting regime, and the
engines just use the standard C functions to open files.  There are a
few issues with this approach which are not directly related to TeX:
- On Linux, the file system encoding isn't fixed, and TeX doesn't really
  have a method to read it.
- On Windows, the file system encoding is UTF-16, but the standard C
  functions always use a legacy 8-bit encoding (at least in Microsoft's
  implementation).  Engines need to work around the C standard and use
  nonstandard extensions if they want to use Unicode file names.

>
> it's all very well claiming that the authors of stuff are deficient in
> not providing the latest and greatest ways forward ... in a free
> software environment, you have to be aware that people may no longer be
> in a position to move their stuff on.  in such a situation, it's up to
> the complainer to provide, or to find someone else to provide, the
> solution to the problem.

Concerning TeX engines, the problem is mostly solved since all of them
accept special syntax (braces or quotes) which allows a wide range of
file names.  The Windows problem is a bit harder to solve since it
requires conditional compilation and platform-dependent representation
of file names.  The LaTeX issues can't be solved because LaTeX is
frozen.

-- 
Change “LookInSig” to “tcalveu” to answer by mail.

Philipp Stephani <LookInSig@arcor.de> writes:

> Concerning TeX engines, the problem is mostly solved since all of them
> accept special syntax (braces or quotes) which allows a wide range of
> file names.  The Windows problem is a bit harder to solve since it
> requires conditional compilation and platform-dependent representation
> of file names.  The LaTeX issues can't be solved because LaTeX is
> frozen.

it's not as bad as that: you can write a package that patches the
latex kernel -- even such a simple one as footmisc has to do that.

i don't imagine it would be an easy thing to do.

however, you _are_ right to say that we have deemed latex itself
frozen, so the problem won't ever be corrected at root.  :-(
-- 
Robin Fairbairns, Cambridge

On 10/12/10 03:01, Gus Gassmann wrote:
> On Dec 9, 5:59 am, Peter Flynn <peter.n...@m.silmaril.ie> wrote:
>> On 08/12/10 16:02, GL wrote:
>>
>>> Le 08/12/2010 16:53, Ulrike Fischer a crit :
>>>> Am Wed, 8 Dec 2010 03:43:10 -0800 (PST) schrieb Gus Gassmann:
>>
>>>> I also know from another discussion that the handling of file with
>>>> more than one dot in the name can differ between the TeX systems. So
>>>> my advice is: avoid dots, spaces and non-ascii chars in file names.
>>>> Even if they work now you never know what happens if you change the
>>>> TeX version, the TeX system or the OS.
>>
>>> Well: no dot in a .pdf file is good practice.
>>
>> Don't believe everything Windows forces you to observe.
>>
>>> Requirement for no space is not admissible in 2010 !!!
>>
>> It is not good practice to use spaces in file names. The fact that it
>> may be attractive to users to do so is not a valid argument.
>>
>> This is where practice bangs up against usability. Normal usability
>> rules would mean allowing users to use any character in a filename,
>> including the slash, backslash, colon, newline, and control characters.
>> For practical reasons, this is not sensible, so a compromise has to be
>> reached, and the jury is still out on this. Until all operating systems
>> and all applications, including scripting languages, accept arbitrary
>> filenames, the rule is "be conservative in what you supply; liberal in
>> what you accept"...which means never using bogus characters in filenames
>> you create yourself. It also means that applications like MiKTeX and
>> processors like TeX *ought* to try much harder, but that's not within a
>> user's control.
>>
>>> And it's enormously annoying to rename your final document.
>>
>> Don't create files with bogus names in the first place...
> 
> I understand that this was not directed at me, but I can't help but
> wonder. Why is it so heinous to want to call my file
> osUsersManual_2.2.tex? 2.2 is the version number, 

It's not. There is nothing bogus about that at all. My comments were
directed at people who try to put characters like slashes and control
characters into filenames and expect them to be recognised.

Philipp is perfectly correct in his observations, but there is a
difference between the theory and practice. He cites the example of
$ tex a\ b.tex
which is precisely NOT what is needed. For a real-world application, the
user must be able to type
$ tex a b.tex
and the operating system must work out what is meant, and moderate any
conflicts that arise. So long as a space is the default token between
arguments in typed commands and in scripts, it remains practical and
courteous to avoid spaces in filenames, no matter how politically
correct it may be to want to include them.

///Peter

On 10/12/10 09:02, Ulrike Fischer wrote:
> Am Thu, 9 Dec 2010 19:01:20 -0800 (PST) schrieb Gus Gassmann:
> 
> 
>>>>> I also know from another discussion that the handling of file with
>>>>> more than one dot in the name can differ between the TeX systems. So
>>>>> my advice is: avoid dots, spaces and non-ascii chars in file names.
>>>>> Even if they work now you never know what happens if you change the
>>>>> TeX version, the TeX system or the OS.
> 
>>> Don't create files with bogus names in the first place...
>  
>> I understand that this was not directed at me, but I can't help but
>> wonder. Why is it so heinous to want to call my file
>> osUsersManual_2.2.tex? 2.2 is the version number, and I feel that it
>> is an important part of the file name. MiKTeX 2.4 processed this file
>> perfectly well, but when I upgraded to version 2.9 things fell apart.
> 
> Well it didn't fell completly apart: You only need to call bibtex
> "jobname" to regenerate a bbl with the name expected by pdflatex.
> 
>> Could/should I have anticipated that?
> 
> At the core of the problem is the fact that tex allows you to omit
> the extension ".tex". 
> 
> \input test will find and input test.tex.
> 
> Now assume that you have in a folder this files:
> test.cfg.tex, test.cfg, test.tex.tex, tex.tex
> 
> which one should be finded and used by 
> \input test.cfg?
> \input test.tex?

The "shortest minimum match" rule would seem to be appropriate here.


///Peter

On 10/12/10 00:02, Philipp Stephani wrote:
[...]
> A file name is a user-visible text string, and every normal character
> should be allowed. 

As an aside to this, I have just discovered that DOIs are permitted to
contain a slash character. IMHO this is no a good idea.

///Peter