- removed comment
Handle parameter files with DOS newline convention
Issue #103
closed
I used a parameter file which used $parfile to indicate the location of the output directory. This parameter file also used DOS line ending conventions, i.e. \r\n instead of \n. The symptom was that an output directory called "$parfile" was created since the $parfile replacement did not occur.
Keyword:
Comments (5)
-
-
- removed comment
I think the problem is in the function src/ParseFile.c:ParseDefines() on the line
/* Look for the end of the define name */ if (c == '}' || c == '\0' || c == '\n')
which assumes that the end of the define will be a \n whereas for a DOS file it will be \r\n. However, this code is so hairy that I don't want to just add in an extra conditional || c == '\r' as I'm not 100% sure that this is correct.
Instead, I have added a function to convert the entire parameter file buffer to Unix convention when it is read in, as this seems the safest thing to do. There might also be other parts of the code which assume the Unix convention.
Try the attached patch - it fixes the problem for me.
There is one possible issue with the patch which is that I use strlen to find the size of the buffer. This assumes that the buffer doesn't contain a \0 character, but from the looks of the code this is already assumed (in fact a \0 is explicitly added to the end of the buffer to ensure the buffer can be treated as a string) so I think this is OK.
-
- removed comment
Patch was committed in r4663 (Cactus/src/util/ParseFile.c)
-
- changed status to resolved
- removed comment
-
- changed status to closed
- edited description
- Log in to comment
An aside: One reason that parameter files with DOS line endings can be generated, even though no one involved uses Windows, is that Apple Mail enables an option "Send Windows-friendly attachments" in the "Add attachment" dialogue box. As far as I can tell, this converts text-type files to DOS format. Unticking this option prevents the conversion.