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
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 -----------------------------------------------------------------
On Thu, 28 May 2020 17:33:19 +0200 Hans Hagen j.hagen@xs4all.nl 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
On 5/28/2020 5:59 PM, Marco Patzer wrote:
On Thu, 28 May 2020 17:33:19 +0200 Hans Hagen j.hagen@xs4all.nl 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 && contextfoo.10.tex
MkIV: → foo.10.pdf LMTX: → foo.pdf
Is this intentional?
consider it to be so
That's unfortunate.
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.
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 -----------------------------------------------------------------
On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen j.hagen@xs4all.nl 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
On 5/28/2020 8:31 PM, Marco Patzer wrote:
On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen j.hagen@xs4all.nl 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.
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 -----------------------------------------------------------------
On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen j.hagen@xs4all.nl 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
This is something that has caused me problems in the past, too.
On Tue, Jul 6, 2021 at 4:51 PM Marco Patzer lists@homerow.info wrote:
On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen j.hagen@xs4all.nl 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
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" tkurtbond@gmail.com wrote:
This is something that has caused me problems in the past, too.
On Tue, Jul 6, 2021 at 4:51 PM Marco Patzer lists@homerow.info wrote:
On Thu, 28 May 2020 18:18:51 +0200 Hans Hagen j.hagen@xs4all.nl 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
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.
On Wed, 7 Jul 2021 21:57:27 +0200 Ulrike Fischer news3@nililand.de 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
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 -----------------------------------------------------------------
On Wed, 7 Jul 2021 12:25:29 -0600 Alan Braslau braslau.list@comcast.net 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
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 -----------------------------------------------------------------
On Thu, 8 Jul 2021 10:34:32 +0200 Hans Hagen j.hagen@xs4all.nl 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
On 7/8/2021 3:38 PM, Marco Patzer wrote:
On Thu, 8 Jul 2021 10:34:32 +0200 Hans Hagen j.hagen@xs4all.nl 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 -----------------------------------------------------------------
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 -----------------------------------------------------------------
On Thu, 28 May 2020 17:33:19 +0200 Hans Hagen j.hagen@xs4all.nl 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
-
Alan Braslau -
Hans Hagen -
Marco Patzer -
T. Kurt Bond -
Ulrike Fischer