Bug 727392

Summary: Request for better handling of spaces in file names.
Product: [Community] Publican Reporter: Scott Mumford <smumford>
Component: publicanAssignee: Jeff Fearn 🐞 <jfearn>
Status: CLOSED CURRENTRELEASE QA Contact: Ruediger Landmann <rlandman+disabled>
Severity: low Docs Contact:
Priority: unspecified    
Version: 2.6CC: mmcallis, publican-list, rlandman
Target Milestone: 3.0   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 3.0.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-31 03:11:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Scott Mumford 2011-08-02 02:42:54 UTC
Description of problem:

Using Publican on a book which contains a file with spaces in the name creates any number of problems depending on what action the user is taking with Publican and how prevalent the naming error is (ie: just the file or in xi;include entries as well).

For example:

A recent build with spaces accidently introduced into a file name produced reams of output when running 'clean_ids':

grep: en-US/User: No such file or directory
grep: and: No such file or directory
grep: Group.xml: No such file or directory
grep: en-US/User: No such file or directory
grep: and: No such file or directory
grep: Group.xml: No such file or directory
grep: en-US/User: No such file or directory
grep: and: No such file or directory
grep: Group.xml: No such file or directory
grep: en-US/User: No such file or directory
grep: and: No such file or directory

Although the clean_ids action seemed to work as expected, the output is a little unnerving and, unless a user happens to see the pattern and make the connection, it can be hard to diagnose the problem.

Also, spaces were included in the same file's xi;include entry, which produced cryptic error messages about Publican not being able to create a link (can't reproduce to get exact wording) when attempting to build the book.

Other scenarios of spaces in file names would produce different errors based on where the spaces have been used, and what the user is attempting to do with Publican.

Version-Release number of selected component (if applicable):
x86_64 Fedora 15
Publican 2.6-1.fc15.

How reproducible:
100% (using spaces in file names is guaranteed to create problems in Publican)

Steps to Reproduce:
1. Introduce spaces into a file name (and, optionally, any xi;include entries for the file).
2. Attempt some Publican actions.
  
Actual results:
Results (build success and/or error messages) vary depending on the exact circumstances, but none of them point to the underlying problem of spaces in a file name.

Expected results:
Publican should error out with a clear message that spaces have been found in a file name and that this will cause problems throughout the build and affect other Publican actions.

Additional info:
While all of these problems originate with human error, to err is human.

Comment 1 Ruediger Landmann 2011-08-22 05:52:43 UTC
Nothing to do with Fedora's packaging of Publican: redirecting upstream.

Comment 2 Jeff Fearn 🐞 2011-09-05 04:27:42 UTC
This should be fixed in Trunk as grep and sed have been removed from the code.

Comment 3 Scott Mumford 2012-05-04 03:49:48 UTC
Can confirm that 'publican clean_ids' now works without error with files that have spaces in their names.

Other errors still persist depending on where the spaces are propagated but these are kind of unavoidable .

Other build errors encountered when introducing spaces to filenames included just for informational purposes.
Space in file name:
FATAL ERROR: XInclude:1604 in Book_Name.xml on line 11: could not load filename.xml, and no fallback was found

Space in file name and xi:include:
FATAL ERROR: XInclude:1605 in Book_Name.xml on line 11: failed build URL
 at /usr/bin/publican line 818