Hi Collin, > You mentioned removing the constants.nlconvert() stuff in > an earlier email [1]. How about these two patches?
I verified that on Cygwin, the test suite passes; this is because - Cygwin programs produce LF as line terminator, - Python's platform.system() returns "CYGWIN_NT-10.0". Regarding native Windows, I don't think there's a realistic use-case, as users would have to have a working autoconf and automake first, which is unlikely for that platform. So, I don't even spend time testing gnulib-tool on native Windows. And regarding z/OS — its newline conventions are that much of a mess [1] that it's better not to even think about it. > Patch 0001 removes nlconvert and all of its calls. That should make > sure gnulib-tool.py and gnulib-tool.sh deal with newlines the same > way. > > Patch 0002 removes the 'NL' constant. Thanks! Both patches applied. > I assume this was to match gnulib-tool.sh's use of "$nl"? Yes. In a shell script, use of literal newlines produces hard-to-read code. Bruno [1] https://lists.gnu.org/archive/html/bug-gnu-libiconv/2023-04/msg00010.html
