Hello, I hope this is the right list for my question. The choice of pdftex log line breaks at 80 chars makes automatic parsing of errors and reporting the chosen ones by 3rd party apps unnecesarilly hard. I couldn't find any command line switch to turn this feature off (CMIIW) and using max_print_line variable is problematic (you don't want to mess with texmf.cnf as an independent app and using it as environment variable will give you headache with portability to different platforms). Would be adding command line parameter (like --max-print-line=num) or even disabling the line break by default possible in some future versions? Or is there some better option I missed? Thanks, Pavel
On 6/7/2019 5:53 PM, Pavel Sanda wrote:
Hello,
I hope this is the right list for my question.
The choice of pdftex log line breaks at 80 chars makes automatic parsing of errors and reporting the chosen ones by 3rd party apps unnecesarilly hard.
I couldn't find any command line switch to turn this feature off (CMIIW) and using max_print_line variable is problematic (you don't want to mess with texmf.cnf as an independent app and using it as environment variable will give you headache with portability to different platforms).
hm, you can have an additional cnf file in your local tree with overloads ... messing around with that and/or env vars is normally the least of ones problems with using tex as component
Would be adding command line parameter (like --max-print-line=num) or even disabling the line break by default possible in some future versions? Or is there some better option I missed? it makes no sense to add tons of extra arguments to suit specific needs while there is the cnf file that can do the job
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 Fri, Jun 07, 2019 at 09:12:18PM +0200, Hans Hagen wrote:
On 6/7/2019 5:53 PM, Pavel Sanda wrote:
The choice of pdftex log line breaks at 80 chars makes automatic parsing of errors and reporting the chosen ones by 3rd party apps unnecesarilly hard.
I couldn't find any command line switch to turn this feature off (CMIIW) and using max_print_line variable is problematic (you don't want to mess with texmf.cnf as an independent app and using it as environment variable will give you headache with portability to different platforms).
hm, you can have an additional cnf file in your local tree with overloads ... messing around with that and/or env vars is normally the least of ones problems with using tex as component
Would be adding command line parameter (like --max-print-line=num) or even disabling the line break by default possible in some future versions? Or is there some better option I missed?
it makes no sense to add tons of extra arguments to suit specific needs while there is the cnf file that can do the job
I see your points, but .cnf file is good solution if you do something manually for yourself not for generic app which might be sharing tex with other uses/apps on very different systems. In that case it's just absurd to write routines to manage .cnf files and solving potential conflicts, paths issues, etc. -- just for the sake of seeing unambiguous error output on longer line. I understand your fear of overcrowding by possible commandline arguments, so if there is aversion to an additional switch, would you consider to change the default of the line length for the log file? I can see that having 80 cols make sense if you sit on small console and watching output, but does it have a sense for regular file which can be edited/processed by completely different beasts? Thanks, Pavel
On 6/10/2019 3:03 PM, Pavel Sanda wrote:
On Fri, Jun 07, 2019 at 09:12:18PM +0200, Hans Hagen wrote:
On 6/7/2019 5:53 PM, Pavel Sanda wrote:
The choice of pdftex log line breaks at 80 chars makes automatic parsing of errors and reporting the chosen ones by 3rd party apps unnecesarilly hard.
I couldn't find any command line switch to turn this feature off (CMIIW) and using max_print_line variable is problematic (you don't want to mess with texmf.cnf as an independent app and using it as environment variable will give you headache with portability to different platforms).
hm, you can have an additional cnf file in your local tree with overloads ... messing around with that and/or env vars is normally the least of ones problems with using tex as component
Would be adding command line parameter (like --max-print-line=num) or even disabling the line break by default possible in some future versions? Or is there some better option I missed?
it makes no sense to add tons of extra arguments to suit specific needs while there is the cnf file that can do the job
I see your points, but .cnf file is good solution if you do something manually for yourself not for generic app which might be sharing tex with other uses/apps on very different systems. In that case it's just absurd to write routines to manage .cnf files and solving potential conflicts, paths issues, etc. -- just for the sake of seeing unambiguous error output on longer line.
I understand your fear of overcrowding by possible commandline arguments, so if there is aversion to an additional switch, would you consider to change the default of the line length for the log file? I can see that having 80 cols make sense if you sit on small console and watching output, but does it have a sense for regular file which can be edited/processed by completely different beasts? That is not up to me but to those who manage the distribution. But even
Which is why one can also set an environment variable which normally is no big deal (after all one can write a small wrapper to call pdftex with that setting). You also need to keep in mind that when you depend on some existing installations that users can have set all kind of properties. (pdf)TeX has been used in all kind of scenarios for decades so that proves that it's all doable. then your large value might not suit others. There's also the error context size, and special character escaping and such, so any app needs to take that into account. Anyway, if someone wants to implement a command line switch (which then probably has to be done for other engines too) fine, but often such common features influence multiple engines. However, don't expect more command line options in for instance the luatex engine (one can control most of these these aspects at runtime from the lua end). 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 -----------------------------------------------------------------
Pavel - if your setup can run pdftex ..., I surmise it can run env max_print_line=9999 pdftex ... That should be portable to everything except Windows; I have no good solution for Windows, sorry. I think we shouldn't change the default at this late date; it would potentially break log-parsing code, and human expectations, that have developed over these many years. Hans explained the drawbacks of adding Yet Another command line option. We all wish the log format were more machine-parsable, but, it isn't :(. Sorry. --best, karl.
Karl Berry wrote: Pavel - if your setup can run pdftex ..., I surmise it can run env max_print_line=9999 pdftex ... That should be portable to everything except Windows; I have no good solution for Windows, sorry. Does not "set max_print_line=9999" have the same effect for the Windows CMD command-line interpreter ? I assume that "env" is Unix's typically cryptic way of setting environment variables. [1] D:\>set max_print_line=9999 D:\>pdftex This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) (preloaded format=pdftex) restricted \write18 enabled. **\wlog {abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop} entering extended mode abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop [2] D:\>set max_print_line=99 D:\>pdftex This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/W32TeX) (preloaded format=pdftex) restricted \write18 enabled. **\wlog {abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop} entering extended mode abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabc defghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop *
On Mon, Jun 10, 2019 at 10:48:35PM +0000, Taylor, P wrote:
Karl Berry wrote:
Pavel - if your setup can run pdftex ..., I surmise it can run env max_print_line=9999 pdftex ... That should be portable to everything except Windows; I have no good solution for Windows, sorry.
Well, if desperately needed in Windows one could switch to MikTeX, which claims to have commandline --max-print-line=n option already, apparently this parameter is not considered equal in the set of million other possibilities just by me...
Does not "set max_print_line=9999" have the same effect for the Windows CMD command-line interpreter ? I assume that "env" is Unix's typically cryptic way of setting environment variables.
Yes, but I was suggesting universal solution which would be usable for very different hosting platforms. To name examples I know people who build packages from our sources for platforms like Haiku or OS/2 and who knows for what else. I knew about env variable and .cnf solution and both of them are not well suited. Anyway, thanks for your responses, at least I know there is no hope :) Pavel
at least I know there is no hope :) It occurred to me that a general option to allow any config setting from the command line (like ssh -o) sounds viable. As in (option name tbd): pdftex -cnf max_print_line=999 -cnf another=value ... It would parse the option argument like a line of texmf.cnf and putenv the variable=value, so the setting would override anything else. For integer and simple string values, as in your case, it seems it would be be portable across all known platforms. Wdyt? (Trying to set full path values this way across platforms would clearly have (shell) quoting difficulties, what with the $ and ; and other characters, but I don't think that's a problem.) --thanks, karl.
On 2019-06-14 at 15:15:12 -0600, Karl Berry wrote:
at least I know there is no hope :)
It occurred to me that a general option to allow any config setting from the command line (like ssh -o) sounds viable. As in (option name tbd): pdftex -cnf max_print_line=999 -cnf another=value ...
It would parse the option argument like a line of texmf.cnf and putenv the variable=value, so the setting would override anything else.
For integer and simple string values, as in your case, it seems it would be be portable across all known platforms. Wdyt?
Very good idea! It would even be a little bit more convenient if alternatively the argument of -cnf can be a comma separated list so that pdftex -cnf max_print_line=999 -cnf another=value and pdftex -cnf max_print_line=999,another=value are equivalent. Is the comma allowed in arguments on Windows? Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------
alternatively the argument of -cnf can be a comma separated list so Values often contain commas. In general, values can contain any character. I'm not inclined to create yet another quoting convention for the sake of merely not repeating -cnf ... -k
On Fri, Jun 14, 2019 at 03:15:12PM -0600, Karl Berry wrote:
at least I know there is no hope :)
It occurred to me that a general option to allow any config setting from the command line (like ssh -o) sounds viable. As in (option name tbd): pdftex -cnf max_print_line=999 -cnf another=value ...
It would parse the option argument like a line of texmf.cnf and putenv the variable=value, so the setting would override anything else.
Indeed, that would be sweet :) And you would avoid all sorts of 'need this special switch' future requests in one shot.
For integer and simple string values, as in your case, it seems it would be be portable across all known platforms. Wdyt?
Yes, it should and as you write other packages use similar technique for handling extended options. I do not know the guts of pdftex but I suppose it should be also quite cheap solution coding-wise. Pavel
> It occurred to me that a general option to allow any config setting from > the command line (like ssh -o) sounds viable. For the record, I just committed some changes to implement this to the TeX Live svn repository (r51830). I chose the option name --cnf-line. It will be available (TL 2020, I don't know if distros will pick it up sooner) in kpsewhich and all engines except the Lua/MetaPost-related programs, which don't share the common source that I modified (web2c/lib/texmfmp.c). I asked Luigi Scarso to look into implementing it for those as well. If anyone tries it out from the development sources and notices problems (not exceptionally unlikely, sorry to say), let me know. Thanks for the impetus :). --karl
On 2019-06-10 at 22:48:35 +0000, Taylor, P wrote:
Karl Berry wrote:
Pavel - if your setup can run pdftex ..., I surmise it can run env max_print_line=9999 pdftex ... That should be portable to everything except Windows; I have no good solution for Windows, sorry.
Does not "set max_print_line=9999" have the same effect for the Windows CMD command-line interpreter ? I assume that "env" is Unix's typically cryptic way of setting environment variables.
Look at Karl's example carefully. The variable setting affects only one process env max_print_line=9999 pdftex ... while your example sets max_print_line for the current shell and thus probably interferes with log-file parsers. On Windows you can write a batch file which sets max_print_line locally and calls pdftex. Regards, Reinhard -- ------------------------------------------------------------------ Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ------------------------------------------------------------------
Reinhard Kotucha wrote:
Look at Karl's example carefully. The variable setting affects only one process
env max_print_line=9999 pdftex ...
while your example sets max_print_line for the current shell and thus probably interferes with log-file parsers.
Not speaking Unix, it was totally unclear to me that the effect of the "env" command was restricted to the next command on the same line ...
On Windows you can write a batch file which sets max_print_line locally and calls pdftex.
But does one need to ? Could one not write set max_print_line=9999&pdfTeX <filename>&max_print_line=132 (or whatever the default value is) ? ** Phil.
participants (6)
-
Hans Hagen -
Karl Berry -
Pavel Sanda -
Philip Taylor -
Reinhard Kotucha -
Taylor, P