LMTX: different output if dots are used in the file name

newer
[OT] TeXShop v4.66 adds support...

Marco Patzer

28 May 2020 28 May '20

6:49 a.m.

Hi! LMTX and MkIV behave differently if dots are used in the file name. Example: printf '%s\n' '\starttext\null\stoptext' > foo.10.tex && context foo.10.tex MkIV: → foo.10.pdf LMTX: → foo.pdf Is this intentional? This is LuaMetaTeX, Version 2.06.05 current version: 2020.05.25 23:39 Marco

Show replies by date

Hans Hagen

28 May 28 May

9:33 a.m.

On 5/28/2020 2:49 PM, Marco Patzer wrote:

...

Hi!

LMTX and MkIV behave differently if dots are used in the file name. Example:

printf '%s\n' '\starttext\null\stoptext' > foo.10.tex && context foo.10.tex

MkIV: → foo.10.pdf LMTX: → foo.pdf

Is this intentional?

consider it to be so Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Marco Patzer

9:59 a.m.

On Thu, 28 May 2020 17:33:19 +0200 Hans Hagen wrote:

...

On 5/28/2020 2:49 PM, Marco Patzer wrote:

...
Hi!

LMTX and MkIV behave differently if dots are used in the file name. Example:

printf '%s\n' '\starttext\null\stoptext' > foo.10.tex && context foo.10.tex

MkIV: → foo.10.pdf LMTX: → foo.pdf

Is this intentional?

consider it to be so

That's unfortunate. 1) The editor workflow with simple suffix replacement .tex → .pdf to open the corresponding PDF file doesn't work any more with lmtx. New logic is needed to find the correct pdf file name. 2) A project (of mine) that uses item numbers as file names (containing dots) compile to the same pdf: MkIV (everything's predictable and fine): 10.10.10.tex → 10.10.10.pdf 10.10.11.tex → 10.10.11.pdf 11.10.11.tex → 11.10.11.pdf LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix) MkIV is way more predictable and consistent in that regard. Marco

Hans Hagen

10:18 a.m.

On 5/28/2020 5:59 PM, Marco Patzer wrote:

...

On Thu, 28 May 2020 17:33:19 +0200 Hans Hagen wrote:

...
On 5/28/2020 2:49 PM, Marco Patzer wrote:

...
Hi!

LMTX and MkIV behave differently if dots are used in the file name. Example:

printf '%s\n' '\starttext\null\stoptext' > foo.10.tex && context foo.10.tex

MkIV: → foo.10.pdf LMTX: → foo.pdf

Is this intentional?

consider it to be so

That's unfortunate.

1) The editor workflow with simple suffix replacement .tex → .pdf to open the corresponding PDF file doesn't work any more with lmtx. New logic is needed to find the correct pdf file name.

2) A project (of mine) that uses item numbers as file names (containing dots) compile to the same pdf:

MkIV (everything's predictable and fine): 10.10.10.tex → 10.10.10.pdf 10.10.11.tex → 10.10.11.pdf 11.10.11.tex → 11.10.11.pdf

LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

MkIV is way more predictable and consistent in that regard. I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Marco Patzer

12:31 p.m.

On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen wrote:

...

...
MkIV (everything's predictable and fine): 10.10.10.tex → 10.10.10.pdf 10.10.11.tex → 10.10.11.pdf 11.10.11.tex → 11.10.11.pdf

LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

MkIV is way more predictable and consistent in that regard.

I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

OK, thanks. No hurry. The production projects run on some oldish 2019 MkIVs anyway. I'm trying to get my feet wet with lmtx and run it on some projects to check how usable and compatible it is. Marco

Hans Hagen

29 May 29 May

1:48 a.m.

On 5/28/2020 8:31 PM, Marco Patzer wrote:

...

On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen wrote:

...
...
MkIV (everything's predictable and fine): 10.10.10.tex → 10.10.10.pdf 10.10.11.tex → 10.10.11.pdf 11.10.11.tex → 11.10.11.pdf

LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

MkIV is way more predictable and consistent in that regard.

I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

OK, thanks. No hurry. The production projects run on some oldish 2019 MkIVs anyway. I'm trying to get my feet wet with lmtx and run it on some projects to check how usable and compatible it is. It should be compatible, although at some point there will be functionality that is only in lmtx. Okay, metapost is an exception, because there is a lot in lmtx that is not in mkiv, but that's a separate subsystem anyway.

Marco Patzer

6 Jul 6 Jul

2:43 p.m.

On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen wrote:

...

...
LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

I've checked again with 2021.07.06 18:49 LMTX 10.10.10.tex → 10.10.pdf + 10.log 10.10.11.tex → 10.10.pdf (file 10.10.pdf and 10.log are over-written) 11.10.11.tex → 11.10.pdf

...

...
MkIV is way more predictable and consistent in that regard. I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

A gentle reminder. As by my tests, something has changed in the last months, but the behaviour is still weird (e.g. log files differ from pdf file or 10.10.10.tex results in 10.10.pdf). Is there a chance you can look at that at some point? Marco

T. Kurt Bond

6:08 p.m.

This is something that has caused me problems in the past, too. On Tue, Jul 6, 2021 at 4:51 PM Marco Patzer wrote:

...

On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen wrote:

...
...
LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

I've checked again with 2021.07.06 18:49 LMTX

10.10.10.tex → 10.10.pdf + 10.log 10.10.11.tex → 10.10.pdf (file 10.10.pdf and 10.log are over-written) 11.10.11.tex → 11.10.pdf

...
...
MkIV is way more predictable and consistent in that regard. I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

A gentle reminder.

As by my tests, something has changed in the last months, but the behaviour is still weird (e.g. log files differ from pdf file or 10.10.10.tex results in 10.10.pdf).

Is there a chance you can look at that at some point?

Marco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

-- T. Kurt Bond, tkurtbond@gmail.com, https://tkurtbond.github.io

Alan Braslau

7 Jul 7 Jul

12:25 p.m.

Windows, I believe, does not take kindly to filenames containing multiple dots. Therefore, Hans never uses such filenames and does not expect them, either, so I am not surprised that this yields unpredictable results. An unfortunate side-effect of dealing with Windows. Alan On Tue, 6 Jul 2021 20:08:22 -0400 "T. Kurt Bond" wrote:

...

This is something that has caused me problems in the past, too.

On Tue, Jul 6, 2021 at 4:51 PM Marco Patzer wrote:

...
On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen wrote:

...
...
LMTX: 10.10.10.tex → 10.10 (not even a PDF suffix) 10.10.11.tex → 10.10 (file 10.10 is over-written) 11.10.11.tex → 11.10 (no suffix)

I've checked again with 2021.07.06 18:49 LMTX

10.10.10.tex → 10.10.pdf + 10.log 10.10.11.tex → 10.10.pdf (file 10.10.pdf and 10.log are over-written) 11.10.11.tex → 11.10.pdf

...
...
MkIV is way more predictable and consistent in that regard. I'll look at it but not today ... first I need to play with some other (neat) stuff and run tests.

A gentle reminder.

As by my tests, something has changed in the last months, but the behaviour is still weird (e.g. log files differ from pdf file or 10.10.10.tex results in 10.10.pdf).

Is there a chance you can look at that at some point?

Marco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Ulrike Fischer

1:57 p.m.

Am Wed, 7 Jul 2021 12:25:29 -0600 schrieb Alan Braslau:

...

Windows, I believe, does not take kindly to filenames containing multiple dots.

Therefore, Hans never uses such filenames and does not expect them, either, so I am not surprised that this yields unpredictable results.

An unfortunate side-effect of dealing with Windows.

Sorry but this is nonsense. I have seen many files with lots of dots in windows and it works fine. I wouldn't do it in tex, but not because of the OS but because until a few years you could run into problems with some tex applications or macros which didn't expect many dots. -- Ulrike Fischer https://www.troubleshooting-tex.de/

Alan Braslau

8 Jul 8 Jul

12:13 p.m.

On Wed, 7 Jul 2021 21:57:27 +0200 Ulrike Fischer wrote:

...

Am Wed, 7 Jul 2021 12:25:29 -0600 schrieb Alan Braslau:

...
Windows, I believe, does not take kindly to filenames containing multiple dots.

Therefore, Hans never uses such filenames and does not expect them, either, so I am not surprised that this yields unpredictable results.

An unfortunate side-effect of dealing with Windows.

Sorry but this is nonsense. I have seen many files with lots of dots in windows and it works fine.

Not nonsense: some MS/Windows filesystems couldn't deal with multiple dots in the filename. That my *now* be history, but wasn't. What is clear is that (perhaps due to this legacy), many programs and packages do not expect to find filenames having many dots. Indeed, *some* filesystem specifications even use "." to delimit file system hierarchy (similarly like / and \). Lua also uses this in table specifications, as does MetaPost for token separation, not mentioning structures in C (and C++). The bottom line is that using "." in a filename is best to be avoided, as are spaces in order to avoid surprises. As to "nonsense" and "Windows bashing", give me a break! (and for Hans, the VMS ";" version specification is a different feature). Alan

Hans Hagen

1:34 p.m.

On 7/8/2021 8:13 PM, Alan Braslau wrote:

...

(and for Hans, the VMS ";" version specification is a different feature). Sure, one being that one ran out of disk space (but there were enough unused accounts with simple passwords to take care of backups) but it would add an interesting challenge (probably some extra parameter in opening a file).

(btw, no tex on these vax machines, pretty unknown at that time so we rolled out our own ascii-art formatting / pagination) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Marco Patzer

7 Jul 7 Jul

2:13 p.m.

On Wed, 7 Jul 2021 12:25:29 -0600 Alan Braslau wrote: Thank you for your reply.

...

Windows, I believe, does not take kindly to filenames containing multiple dots.

Disclaimer: I don't use Windows, I know nothing about Windows. But I downloaded a Windows 10 VM and fired it up, installed LMTX, created a file (in the default editor): # file name: 10.10.10.tex \starttext foo \stoptext Then I ran install.bat setpath.bat # LMTX context 10.10.10.tex → 10.10.pdf → 10.log # MkIV context --luatex 10.10.10.tex → 10.10.10.pdf → 10.10.10.log So I can't confirm your findings. MkIV works exactly the same on a vanilla Windows 10 VM than it does on a Unix system and produces correct output files with multiple dots. No issues there.

...

Therefore, Hans never uses such filenames and does not expect them, either, so I am not surprised that this yields unpredictable results.

An unfortunate side-effect of dealing with Windows.

My short test above seems to suggest that it's not an OS issue since Unix and Windows behave exactly the same. MkIV (which seems to work fine on Windows) as well as the LMTX issue. But maybe I did something wrong there, in that case please let me know. And Hans said “I'll look at it” a while back, so I just wanted to send a reminder. Since it worked in MkIV it looks like a regression. I mean it used to work. Several of my projects rely on source files with multiple dots. I know it's not common to have multiple dots, but I hope there's chance it might be fixed. But maybe Hans can chime in and clarify. Marco

Hans Hagen

8 Jul 8 Jul

2:34 a.m.

On 7/7/2021 10:13 PM, Marco Patzer wrote:

...

But maybe Hans can chime in and clarify. I have to check it but syffixes and tex are kind of special. It has nothing to do with operating systems (sorry for those who love to bash windows for it). Personally I always use a suffix and don't look into files without them. (On VMS we even had version numbers with the name, which was also nice.) That said:

- tex needs to make a log file and an output file (.log, .pdf and maybe more like .tuc) - so, it determines a jobname, which is the input file with the suffix removed - actually it adds a suffix .tex when there is none and then looks for that file - in that respect, .10 is a suffix as is .foo or .pointless - in tds/kpse/web2c there were flags for 'multiple suffixes' (which of course also introduces compatibility issues) - as a side note: filenames are case sensitive unless the operating system makes them insensitive; this has long been yet another reason for bashing windows, but it looks like kpse/web2c now decided it's a good idea so there's also a flag (i think itis true by default) that enables insentivity (context always tried to be insensitive and mkiv/lmtx definitely is) Now, to the issue of names like 10.11.12.13 ... here .13 is the suffix, like it or not, so in principle we then get 10.11.12.log 10.11.12.tuc 10.11.12.pdf if not then indeed there is some issue. Now, although it's quite some work, one can think of seeing .13 as part of the filename, in which case the lookupe becomes 10.11.12.13.tex but we can optionally first check for 10.11.12.13 ... however, because there are many possibel suffixes (.tex being one of them) we then get 10.11.12.13.log 10.11.12.13.tuc 10.11.12.13.pdf but in the case of 10.11.12.13.tex we get 10.11.12.13.tex.log 10.11.12.13.tex.tuc 10.11.12.13.tex.pdf because there is no way to determine any longer that .tex is special (one can argue that .mk* also qualifies but what about .xml and all variants on that). Al this means that personally I always stick to (1) lowercase filenames (2) with no spaces (3) only a-z, A-Z, 0-9, and - (4) always with a suffix ... it never gives issues. (If you ever had to deal with third party files, especially graphics made by third parties, you'd know that most problems come from bad filenames where for instance a single space or multiple spaces and/or funny mixes in case get unnoticed.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Marco Patzer

7:38 a.m.

On Thu, 8 Jul 2021 10:34:32 +0200 Hans Hagen wrote:

...

Now, to the issue of names like 10.11.12.13 ... here .13 is the suffix, like it or not, so in principle we then get

10.11.12.log 10.11.12.tuc 10.11.12.pdf

It's not that I use files without (.tex, .mkiv, ...) suffixes, but your 10.11.12.13 example is processed by MkIV without problems: 10.11.12.pdf 10.11.12.tua 10.11.12.log LMTX, however doesn't like it: 10.11.pdf 10.11.tua 10.log

...

if not then indeed there is some issue.

According to my tests LMTX doesn't work like you describe it should.

...

Now, although it's quite some work, one can think of seeing .13 as part of the filename, in which case the lookupe becomes

10.11.12.13.tex

Just to make it clear: I don't use files without .tex/.mkvi/etc. suffix. So I don't expect 10.11.12.13 to work, but 10.11.12.tex should in fact work as far as I understand. Marco

Hans Hagen

5:07 p.m.

On 7/8/2021 3:38 PM, Marco Patzer wrote:

...

On Thu, 8 Jul 2021 10:34:32 +0200 Hans Hagen wrote:

...
Now, to the issue of names like 10.11.12.13 ... here .13 is the suffix, like it or not, so in principle we then get

10.11.12.log 10.11.12.tuc 10.11.12.pdf

It's not that I use files without (.tex, .mkiv, ...) suffixes, but your 10.11.12.13 example is processed by MkIV without problems:

10.11.12.pdf 10.11.12.tua 10.11.12.log

actually that's also not ok as it should be a .tuc file

...

LMTX, however doesn't like it:

10.11.pdf 10.11.tua 10.log

...
if not then indeed there is some issue.

According to my tests LMTX doesn't work like you describe it should. i'll check it

(in retrospect tex could better have enforced a suffix and not fallback on .tex but i suppose the usage scenarios were hard to foresee let alone the restart-the-program-time-penalty when you forgot to add .tex) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Hans Hagen

3:01 a.m.

On 7/7/2021 8:25 PM, Alan Braslau wrote:

...

Windows, I believe, does not take kindly to filenames containing multiple dots.

windowes is very kind to multiple dots but it (normally) sees the last suffix as an indication of what file is it (other operating system needs some 'open' command while windows works with associations)

...

Therefore, Hans never uses such filenames and does not expect them, either, so I am not surprised that this yields unpredictable results.

actually, mkiv will append a suffix for converted files, so foo.eps.pdf is made ... works ok

...

An unfortunate side-effect of dealing with Windows.

more an unfortunate side effect of the way users and porograms construct filenames and expect systems that use some heuristic to deal with that to work fine (unless one accepts that foo.tex gets a foo.tex.log and foo.tex.pdf file as result) (inconsistent font and file filenames can even make life even more misserable) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Marco Patzer

28 May 28 May

10:07 a.m.

On Thu, 28 May 2020 17:33:19 +0200 Hans Hagen wrote:

...

On 5/28/2020 2:49 PM, Marco Patzer wrote:

...
Hi!

LMTX and MkIV behave differently if dots are used in the file name. Example:

printf '%s\n' '\starttext\null\stoptext' > foo.10.tex && context foo.10.tex

MkIV: → foo.10.pdf LMTX: → foo.pdf

Is this intentional?

consider it to be so

1104

Age (days ago)

1510

Last active (days ago)

List overview

Download

17 comments

5 participants

participants (5)

Alan Braslau
Hans Hagen
Marco Patzer
T. Kurt Bond
Ulrike Fischer