3 ms·
I would argue that a more expensive one-byte mistake was the computer industry failing to standardize on a newline representation (CR+LF versus LF). In mixed U
by mrb 15y ago
I would argue that a more expensive one-byte mistake was the computer industry failing to standardize on a newline representation (CR+LF versus LF).
In mixed Unix/Windows environments, I cannot even count the number of times that this discrepancy has created issues or slowed down work: config files accidentally saved with Windows newlines and causing cryptic error messages ("No such file or directory: filename" because "filename" from that config file has an invisible CR at the end), discovering that a tool had been silently converting newlines from one format to another when you wanted to preserve them but it is too late to fix because the files have been shipped to customers, tools stripping the LF but not the CR and corrupting text displayed on terminals, $ in a regex not matching the end-of-line because of the presence of CR, of course the pain of editing Unix files on Windows (the only reason why Wordpad exists), etc.
- Nick_C 15y ago> the pain of editing Unix files on Windows (the only reason why Wordpad exists) An FYI for anyone who might have this problem, Notepad2 is a drop-in replacement for notepad and can handle Unix/Windows line-ending conversions (plus a few other nice features for a small binary).