Rubber does not print the correct filename if it contains spaces

Bug #569034 reported by Yannick Voglaire
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Rubber
Confirmed
Medium
Unassigned

Bug Description

When launching rubber on a file containing spaces in its name or directory (like "/home/user/dir with spaces/doc.tex"), it only outputs

/home/usr/dir: some error

instead of

/home/user/dir with spaces/doc.tex: some error

This is important for the gedit latex plugin which uses these filenames to show the error in the source, and fails to find the file because of that.

A simple solution is to replace line 122 in rubber/rules/latex/__init__.py

re_file = re.compile("(\\((?P<file>[^ \n\t(){}]*)|\\))")

by

re_file = re.compile("(\\((?P<file>[^\n\t(){}]*)|\\))")

(we accept spaces in the filename). This should perhaps be further modified as the last space is now included in the filename. It doesn't hurt for my purposes (gedit latex plugin), but it may for others (?).

Revision history for this message
Frederik Elwert (frederik-elwert) wrote :

I also suffered from this issue, breaking the gedit latex plugin in this regard.

I further adapted the regex, since I had two issues with the proposed solution:

1) I found random [number] snippets in the file name, probably coming from latex' page count output. Thus I forbid [] in the regex.
2) For me, the gedit plugin had in fact issues with the trailing space, so I require at least one alphanumeric character as the last one.

I’m no regex expert, so there might be more elegant ways, but this currently works for me™:

re_file = re.compile("(\\((?P<file>[^\n\t(){}\[\]]*\w)|\\))")

Changed in rubber:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → 1.2
Sebastian Kapfer (caci)
Changed in rubber:
milestone: 1.2 → 1.3
Revision history for this message
Sebastian Kapfer (caci) wrote :

This is rather troublesome to fix, since the LaTeX logfile is not uniquely parseable for files containing spaces and parentheses. Maybe we should check if the strings we find actually exist as filenames on disk?

Changed in rubber:
milestone: 1.3 → 1.4
Revision history for this message
Sebastian Kapfer (caci) wrote :

Another instance of fragile log parsing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384155

Revision history for this message
Sebastian Kapfer (caci) wrote :

We'll need fundamental changes to the LaTeX log parser to do this: Filenames cannot be unambiguously extracted from the logs. I'm postponing this to Rubber 1.5.

Changed in rubber:
milestone: 1.4 → 1.5
Changed in rubber:
milestone: 1.5 → none
Revision history for this message
Pietro Battiston (toobaz) wrote :

Rubber 1.5 is out... any hope to fix this?

I experimented a bit with the fix proposed by Yannick (today the line is in file "converters/latex.py"): it seems to fix the problem and to not cause any side effects. Could it be applied waiting for the planned deeper changes?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.