- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
((student*)42/0b101010-1)->GetSemester();
Admin
TRWTF is Git fucking with line endings for no good reason. Store the code that I commit, don't try to guess what whitespace to use
Admin
Buchler - teaching advanced 'think outside the box' debugging techniques since forever.
Admin
I remember one Buildscript once over a OpenEmbed project breaking with weird compiler errors when Dos2unix was not installed and some CRLFs snuck in. Took too much time to figure out but it told that those differences matter sometimes
Admin
git bad svn good
Admin
The rwtf are the plethora of unix tools which refuse to recognize that there multiple possible line endings. When you point that truth out, they rant endlessly how windows is wrong and its ok that their shitty tools break. For example: try using a shell script with \r\n endings. Windows just works, but linux shits itself with totally absurd errors.
Admin
It gets worse. Cygwin uses just \n as line endings, apparently because there's too much Unixy software that opens text files without asking for them to be treated as text (because on Unixy systems it doesn't matter), and it's too much effort to go round all those projects and give them a solid nut-kicking.
God only knows how those programs would work on MTS.
Admin
There is good reason.
If you check in your code from Windows and then I check it out on my Mac to make a one line change and I find that the compiler barfs on the
\rat the end of each line, I have to change every line which makes the diff meaningless. You can argue that it's my tools that are rubbish, which may be true, but git inhabits a world in which people use rubbish tools. All source code control systems that aspire to be cross platform do similar things to git.Admin
Easy, don't use either Git or Mac. Personally, I write code on a piece of paper, or just dictate it, and my secretary types it in.
Admin
And he wanted the students to do the troubleshooting to figure out the why of their problem. They failed. Life doesn't always provide you with a TA....
Admin
Fancy, I prefer to use a hammer and chisel on a granite slab. When your code is dust mine will be in a museum.
Admin
Sounds like how Buchler writes his code.
Admin
I'm surprised it's not called out directly - my late-90s CompSci courses did automatic submission and validation, and the first thing they told us was that all the checks happened on a Unix machine, sometimes the Windows version of the compiler did things differently (and would compile for you but not for them)... and that was a You Problem. (With instructions on how to borrow the fifteen-floppy disk Linux distribution so that you could test on the same compiler that you'd be marked on.)
Admin
The thing here is, long before Ginger came on this scene, this same issue would hit anybody who would check in their project into RCS or CVS. I recall encountering this behavior with many other cross-platform revision control systems, not just those three, but I don't recall specifically all of the tools that do it.
The only reason why this was only students who use git was that was likely the only version control program people used that wasn't Windows specific.
Admin
TRWTF is really just that Windows and Linux still use different line endings. I am a little embarrassed every time I have to explain to someone that \r is a holdover from typewriters and super old printers.
Admin
TRWTF is Linux choosing to redefined the meaning of a character with an already well-defined meaning and expecting everyone to follow suit instead of specifying a new, previously unused character.
I'm not sure why it would be embarrassing either? There are tons of holdovers everywhere.
Admin
| I am a little embarrassed every time I have to explain to someone that \r is a holdover from typewriters and super old printers.
Don't forget that \r is also useful for Cathode Ray Tube displays - do you wish to display the following content in the cell immediately below the current position, instead of a long-winded cursor positioning sequence? \r allowed that distinction and shortcut by not always returning to column #1.
Admin
\r ==> Carriage Return (return to column 1) \n ==> Line Feed (advance vertically one line)
Admin
The sad thing is - many source control systems do it. I particularly hate a tool called "MKS" - it destroyed a lot of binary files just because it didn't recognize *.bin extension and "automatically" detected type - randomly making them to text and "fixing" eol characters... Forcing everything to binary wasn't a answer since MKS is not able to compare binary files...
Admin
Yes, Windows exists. Yes, Windows decided to use a different standard than everyone else. No, that does not mean that all software has to follow it. Linux software shouldn't have to bend over backwards to interoperate with Windows conventions. Maybe, to you, every piece of software should be compatible with line endings from other operating systems, but I disagree, and incompatibility with foreign environments does NOT make a tool shitty. Use a different tool.
Admin
So the professor is using a *nix system, but is splitting strings on '\r\n'? o.O
Though I am still not sure how the templates from the professor are being mashed into a single line if they don't get split in the first place. The split shouldn't be removing the *nix '\n' characters from the professor's template code. And if the problem is the #define from the template code being put in the middle of the line... I'm missing something here.
But probably the biggest problem that I see with all of this is that if the professor wants to split the input code into lines, that is fine. But he should recombine them with line endings too. Of whatever type desired. But they should have some line endings put back on.
Admin
A lot of people here don't seem to realize that line-endings are simply one of a myriad of text file encoding issues that exist in the world and both Unix and Windows have had their part in creating the current condition. The lesson here is the same as it often is: don't try to write your own code, use a library. Sure, splitting a text file into lines sounds trivial, but I assure you this isn't the only bug that will come up. Leave the bitching about who is right and who is wrong to the library maintainers. Signed 0xEF, 0xBB, 0xBF (just call me ).
Admin
Do you seriously refer to dumb terminals as "cathode ray tube displays"? You realize that Windows runs on CRTs too, right? And that a VT100 terminal can run on an LCD?
Admin
"Dr. Bulcher!" / horses heard neighing in the background
Admin
I always turn anything that screws with content automatically off. It's a nightmare otherwise. I don't know why people think it's right to configure their VCS to add a whole new layer of complexity screwing around with line endings. Why not character sets and switching between , or . as the decimal point along the way?
Admin
My mat told me that in windows rather than null terminated strings (hello world\0), that strings are carriage return null terminated (hello world\r\0). You learn something new on a daily basis.
Admin
@isthisunique. Whoever told you that was wrong. Or at least was speaking about some special corner case, not the typical case. You might find this informative: https://devblogs.microsoft.com/oldnewthing/20191025-00/?p=103025
Admin
Line endings are fun, and every OS has its own. Unix (and Linux) use \n (new line, or line feed). MacOS (traditional, pre OS X) used \r. And WIndows uses \r\n.
And on a proper TTY, you use \r\n, because \r returns the carriage to the beginning, and \n moves the platen up a line so you're starting at the beginning of a new line. In fact, on a serial console, it has to translate when it gets a \n to a \r\n sequence. (And since you're never really sure, you have to make sure when you get \n, to make sure \r didn't immediately precede it so you don't get \r\r\n, not that it really does any harm).
Though the good thing is that a lot of things stopped caring and treat \r, \r\n, and \n equally, so you could have code with mixed line endings work just fine (this was especially tricky for compilers and preprocessors). I think recent bash shells also are line ending agnostic.
Line endings and using the line continuation in a macro (a \ at the end of a line, because you were "quoting" the line ending) always made for a lot of fun errors.
Admin
I've used
core.autocrlf=input(convert everything I commit on Windows to LF line endings, and keep LF on disk) for years, never had problems with it. Now even notepad learned to handle LF as line ending, and if I accidentally introduce CRLF somewhere, it gets automatically fixed on the next commit.The other
core.autocrlfoptions are a way of slowly shooting onself in the foot, though.Admin
"but git inhabits a world in which people use rubbish tools."
Yeah, and Git happens to be one :)
Admin
And if you leave the land of Unix, Linux, PC-type DOS, its descendant Windows, and Mac OS (both OS and OS X) and look at the mainframe world, you will notice that there is the concept of "no line breaks at all". Fixed-width data, in "blocks" of 80 characters, 1 - 71 "text lines", followed by 8 "line numbers", typically optional, and the next "block" is the next "text line". Other "line widths" are possible, of course. Editors can be seen as a frontend to text files, no matter how you define them, and editors can deal with how to do the "next line" thing; however, as pointed out correctly, editors aren't the only tools you use: you can have preprocessors, compilers, diff, a version control system, statistical tools ("How many lines, captain?" - "THERE ARE FOUR LINES!!!") and anything you have in place to automate things. All of them would have to properly deal with not only one way of the thing at a time, but with mixed forms. And it's not that different from using more than one enconding in one file (someone adds german Umlauts or Eszett in UTF-8, 2 bytes, someone else adds some in ISO-8859-1, 1 byte, you get the idea). And if becomes much more interesting with the plethora of spaces, dashes and "lookalikes" (fun like s/semicolon/greek question mark/g) UTF-8 allows you to use. Those are still problems to be solved. Frau Blücher! neigh
Admin
Well yeah, as long as people use Git, people use rubbish tools. QED
Admin
Unix uses one line ending, windows uses another and mac a third.
And windows style came from American National Standards Institute originating 1963 which predates unix by 7 years.
Does this mean that unix and mac is the offending party?
No, it just means that there was many different standards and the different os'es picked different standards to go with, to bad ...
Source control tools just tries to help developers to not have to deal with it, with better or worse success .
Admin
I've seen worse. When I studied CS back in the early 1990s, the school had a seemingly quite workable system for submitting code for assessment tasks, with surprisingly well-defined submission procedures for the variety of languages in use (C, C++, LISP, Prolog, even the toy simulated assembly language invented by a couple of lecturers). Then one semester we had a visiting lecturer who handed out strict instructions with our first assignment that said that required the script for invoking our program had to be named cs2al1.sh and placed in our home directory - anything else would be automatic fail with zero marks. Someone asked why, to which he responded that they run a script with root privileges to execute that script in each student's home directory and capture the results to perform the assessment. While some students were thinking of what they could do once they got root access, others were asking why we didn't just use the standard submission system. "Because this is easier" was the response.
Given that the sysadmins valiantly attempted to block our access to anything like telnet on "security grounds" (heaven forbid we learn anything other than the curriculum), I'm surprised it took as long as a week for the update that we'd be using the normal submission system after all.
Admin
It is nice that the students were about to learn about line ending issues this early in their career.
Admin
Everyone else? What about most internet protocols? HTTP, FTP, SMTP etc are all defined as requiring CRLF (though most servers these days can work with either).
Admin
Nothing that FTP does is sane or correct. I guess that's a point in favor of UNIX style line endings.
Admin
Heh.... in general I've found most comp sci professors entirely unsympathetic to problems caused by windows. Even if this one is also partly git's fault.
Admin
"I write code on a piece of paper, or just dictate it, and my secretary types it in."
In my first job, I worked for a small company writing CAD/CAM software (in Fortran - it was the most portable language we could find in the mid 80s). We hired a contractor (an Expert in his Field) to write a major new feature to the system. Eventually, we received a package in the main containing not a floppy disk (mid-80s, remember), but rather a stack of Fortran coding sheets that he had dictated to his secretary. He obviously never even tried to compile it; he just assume he was So Good that he didn't have to. After find several obvious syntax errors on the first page, we never even bothered typing it in.
Admin
Imagine if he shipped granite slabs with chiseled code. Disposal would've been a bitch.
Admin
This reminds me of when I was overloaded with programming work, my manager offloaded some of it to another programmer, who after a long time, delivered me the files. They didn’t compile. The code was obviously never compiled, and I complained to my manager. Decades later I heard that this programmer hates my guts.
Admin
The WTF is not how the \n vs \r\n is handled by git or how it "should" be handled. The professors split is wrong! Lets say only one style of line ending existed... then the professors code gets broken by that split function.
The \n vs \r\n situation is simply masking the bad code the professor wrote.
Admin
The *nix line ending thing came about long before Windows was even thought of. It got changed from the <CR><LF> used by teletypes for the same reason that they're called "core" dumps. Memory on the computers at the time was usually made of little ferrite-cored coils. It takes 8 of those to make a byte. It was absurdly expensive. One kilobyte of memory required soldering 8192 coils to a circuit board somewhere. Each byte of memory or permanent storage consumed had a measurable cost, sometimes several cents apiece. Reducing line endings to one character wasn't done on a whim. It was a significant cost savings.
It's the same reason practically everybody used two-digit years. Those extra two characters, for no practical purpose, were an expensive waste of resources.
Admin
trwtf is autocrlf vsc is not a text editor