Was the old bug ever fixed with PRINT # and newlines always assuming Windows?
Because today on Manjaro Linux KDE I wrote a QB64 program that created a "bash" script, which included CHR$(13) into the end of a filename. It took over half-hour to debug a program I had which couldn't find a filename that "looked the same" to me in the file manager but it wasn't until I attempted to load one of the target files into GIMP. The open file requester of GIMP showed "%0D" at the very end of each suspect filename.
The solution is either to wrap the desired filenames in single- or double-quotation marks on both sides of "cp" or "mv" statement to write into a script, or to put CHR$(10) with semicolon at the end of each PRINT # entry and never allow it to create a new line. Otherwise, the text file that is created would have to be loaded into Kate or other text editor that could re-save with Unix line endings instead of the CRLF combination for Windows.
Because today on Manjaro Linux KDE I wrote a QB64 program that created a "bash" script, which included CHR$(13) into the end of a filename. It took over half-hour to debug a program I had which couldn't find a filename that "looked the same" to me in the file manager but it wasn't until I attempted to load one of the target files into GIMP. The open file requester of GIMP showed "%0D" at the very end of each suspect filename.
The solution is either to wrap the desired filenames in single- or double-quotation marks on both sides of "cp" or "mv" statement to write into a script, or to put CHR$(10) with semicolon at the end of each PRINT # entry and never allow it to create a new line. Otherwise, the text file that is created would have to be loaded into Kate or other text editor that could re-save with Unix line endings instead of the CRLF combination for Windows.