Discussion:
Bug report for pdfTeX
(too old to reply)
Duncan Steele
2017-10-20 10:29:04 UTC
Permalink
Raw Message
I am not sure if this is the correct place to send this bug report, if it is not, please let me know and I’ll post it to the correct list.

I work on Texpad, a LaTeX editor for macOS/iOS and we have come across what we believe to be a bug. I have constructed a bash script to reproduce this bug (tested on macOS 10.12 with case insensitive HFS+, and on macOS 10.13 with APFS).

Running the script will create 3 pdfs in the /tmp/rootdir folder, all of which I believe should come out the same, however the 3rd pdf is missing some content. This is because a subfile has not been loaded when I think it should be. This happens when there is both a <somename.tex> file and a <somename> folder in the output folder, the <somename.tex> file will not be used. It does not happen if it is not in an output folder, and it does not happen if that <somename> folder is not there.

I have attached the script and also uploaded as a gist here https://gist.github.com/vallettaventures/484ff776d045422b07b369c905e2a3f3 <https://gist.github.com/vallettaventures/484ff776d045422b07b369c905e2a3f3>
Karl Berry
2017-10-20 20:28:02 UTC
Permalink
Raw Message
Hi Duncan - it's fine to report the problem here, although in principle
tex-***@tug.org would be a more specific place (no need to resend this
one). This behavior is presumably not particular to pdftex, as what
files get read in the presence of such conflicts is mostly resolved by
the common kpathsea code. I will take a look as soon as I can.

Thanks for the report. --karl
Akira Kakuto
2017-10-20 21:03:03 UTC
Permalink
Raw Message
Hi Karl,
Post by Karl Berry
Hi Duncan - it's fine to report the problem here, although in principle
one). This behavior is presumably not particular to pdftex, as what
files get read in the presence of such conflicts is mostly resolved by
the common kpathsea code. I will take a look as soon as I can.
I cannot reproduce the bug on windows.
I have made an equivalent environment:

c:/temp/rootdir/outputfolder/subdir
c:/temp/rootdir/subdir
c:/temp/rootdir/subdir.tex
c:/temp/rootdir/main.tex

main.tex:

\documentclass{article}
\begin{document}
1
\input{subdir}
3
\end{document}

subdir.tex:

2

In c:/temp/rootdir, I tried
pdflatex -output-directory c:/temp/rootdir/outputfolder main

I attach c:/temp/rootdir/outputfolder/main.log.
You can see that ./subdir.tex is successfully read.

Best,
Akira
Hironobu Yamashita
2017-10-21 00:14:47 UTC
Permalink
Raw Message
Hi Duncan,
Post by Duncan Steele
I have constructed a bash script to reproduce this bug
(tested on macOS 10.12 with case insensitive HFS+, and
on macOS 10.13 with APFS).
however the 3rd pdf is missing some content.
I tested on OS X (10.11.6 El Capitan) and Windows 7.

With your bugreport.sh,

On OS X 10.11.6 El Capitan
The second and third pdfs are missing "2".

On Windows 7:
All pdfs are the same and correct.

Hironobu Yamashita
Hironobu YAMASHITA
2017-10-21 08:23:52 UTC
Permalink
Raw Message
Post by Hironobu Yamashita
On OS X 10.11.6 El Capitan
The second and third pdfs are missing "2".
This was my mistake, as I ran the script twice.
That means, only the third pdf is missing "2".

---

The behavior of -output-directory is described in web2c/lib/openclose.c;

    /* Look in -output-directory first, if the filename is not
       absolute.  This is because .aux and other such files will get
       written to the output directory, and we have to be able to read
       them from there.  We only look for the name as-is.  */
    if (output_directory && !kpse_absolute_p (nameoffile+1, false)) {
        fname = concat3 (output_directory, DIR_SEP_STRING, nameoffile + 1);
        *f_ptr = fopen (fname, fopen_mode);

So, the file name should be as-is (including the file extension).
I'm not sure this is a desirable behavior or not.

The different behavior on win32 is due to the behavior of fopen().
fopen(dirname, "r") returns NULL on Windows, but returns a valid
pointer on Unix file system.

Hironobu Yamashita
Akira Kakuto
2017-10-21 09:39:28 UTC
Permalink
Raw Message
Hi Hironobu,
Post by Hironobu YAMASHITA
The different behavior on win32 is due to the behavior of fopen().
fopen(dirname, "r") returns NULL on Windows, but returns a valid
pointer on Unix file system.
Many thanks. I attach openclose.c.diff.
Please try that.

Thanks,
Akira
Hironobu Yamashita
2017-10-21 09:48:49 UTC
Permalink
Raw Message
Hi Akira,
Post by Akira Kakuto
Post by Hironobu YAMASHITA
The different behavior on win32 is due to the behavior of fopen().
fopen(dirname, "r") returns NULL on Windows, but returns a valid
pointer on Unix file system.
Many thanks. I attach openclose.c.diff.
Please try that.
Works perfectly (confirmed on OS X 10.11.6 x86_64-darwin). Thanks.

Hironobu Yamashita
Akira Kakuto
2017-10-21 10:35:27 UTC
Permalink
Raw Message
Hi Hironobu,
 Works perfectly (confirmed on OS X 10.11.6 x86_64-darwin). Thanks.
Many thanks for the test. Installed in r45565.

Thanks,
Akira
Duncan Steele
2017-10-24 10:57:07 UTC
Permalink
Raw Message
Dear All,

Thanks so much for fixing that. We’ll let our users know it is on its way.

Best Wishes,

Duncan Steele
Post by Hironobu Yamashita
Hi Akira,
Post by Akira Kakuto
Post by Hironobu YAMASHITA
The different behavior on win32 is due to the behavior of fopen().
fopen(dirname, "r") returns NULL on Windows, but returns a valid
pointer on Unix file system.
Many thanks. I attach openclose.c.diff.
Please try that.
Works perfectly (confirmed on OS X 10.11.6 x86_64-darwin). Thanks.
Hironobu Yamashita
Loading...