initialize.py may clone into dirnames containing \r #7
Description
Ajay (@kellender) reports that editing an init config on a Windows machine breaks the build process. I can reproduce the problem by appending a \r (by typing ^V^M) on the end of a line of the init config. This causes the repo on that line to be git-cloned into a directory reponame\r; subsequently, the build script fails as the dirname it uses doesn't match the one we cloned into.
The issue is in initialize.py, which loops over the files of the init config here, but doesn't care to strip() off whitespace (which includes \r and \n!) when constructing the git command line here.
Apart from the obvious fix, we may consider dealing with line endings on the level of local Git configs.
Example
# My config_initialize.txt. Note the ``^M'' at the end of the line
https://github.com/SeattleTestbed/seattlelib_v2 ../DEPENDENCIES/seattlelib_v2^M
This clones seattlelib_v2 into ../DEPENDENCIES/seattlelib_v2^M. Then, firing up the build:
albert$ python build.py
Building into /private/tmp/rv2/RUNNABLE
WARNING: File expression 'DEPENDENCIES/seattlelib_v2/*' does not match any files. Maybe the directory is empty, or the file / directory doesn't exist?
Done building!
History side-note
It has been brought to my attention that the fact that different operating systems historically use different character(s) to signal the end of a line of text should not be considered common knowledge.
Of relevance today are two different schools of line endings:
- Windows uses
\r\n(often rendered in descriptive text asCR/LF, from old line-printer commands "carriage return" and "line feed"; sometimes labelled "DOS line breaks"), whereas - all things Unixoid (Linux, Mac / the BSDs, ...) use
\n.
This causes some cross-platform grief for Seattle time and again. See here for a list of open issues/PRs concerning Seattle and CR/LF. For more intricate detail, please refer to Wikipedia.