Professor sends out code template for a project

what in absolute FUCK

Attached: 566d75ab57d81028b728c2484727012af129e7a7cb20144f3282497ec6b88a6c.jpg (1920x1074, 402.1K)

Other urls found in this thread:

tools.ietf.org/html/rfc854
tools.ietf.org/html/rfc2616#page-16
twitter.com/NSFWRedditVideo

If you are too retarded to use dos2unix, you should drop out now.

This. OP is approaching levels of irony that shouldn't even be possible.

Larper detected

maybe he's angry that the prof uses an inferior os and inferior line endings?

Your problem is with ASCII itself. CRLF is the correct ASCII line ending because LF only advances the line and CR only returns to the beginning of the line. Just CR would overwrite characters on the same line and just LF would keep the same horizontal position.

VMS has STREAM (CRLF ending), STREAM_CR (CR ending), STREAM_LF (LF ending), and VARIABLE (two-byte length prefix) types of text files so this wouldn't even be a problem on VMS. UNIX doesn't even have a concept of text files, just sequences of bytes.

tools.ietf.org/html/rfc854
NAME CODE MEANING NULL (NUL) 0 No Operation Line Feed (LF) 10 Moves the printer to the next print line, keeping the same horizontal position. Carriage Return (CR) 13 Moves the printer to the left margin of the current line.
UNIX "translates" it's special line endings to the real CRLF control characters. If you display UNIX "text" on a real terminal or "raw" settings, the next line will begin in the same column as the previous line because that's how the ASCII control characters are defined.

$ stty raw; printf "\r\nAT&T sucks\rUNIX\n but VMS doesn't\r\n"UNIX sucks but VMS doesn't

>In another article WD writes:>|> [of VMS]>|> I sure hope so. Any o/s which puts file types in the o/s>|> instead of the program is really creating problems for the>|> user, and I find that more of a problem than the user>|> interface. If programs really want a "$ delimited left>|> handed nybble swapped hexadecimal" file type, let it be>|> done in the program or shared library, and not at a level>|> when all user-written file transfer and backup programs>|> have to deal with it. As my youngest says "yucky-poo!"Huh? Let's think about this.Tighter integration of file types to the OS are not aproblem. In my experience, UNIX offers the weakest filemaintenance offerings in the industry, save for MS-DOS. Inusing Tandem Guardian and VMS I've found that ultimately,one could:* Back up files.* Transfer files.* Convert files....much more easily and safely than with UNIX. Yes, it wasbetween Guardian or VMS systems but instead of going into an"open systems" (whatever THOSE are) snit, read on.As a result:* Each RDBMS has its own backup and restore facility of varying functionality, quality, and effectiveness, complicating support for sites adopting more than one RDBMS.* All existing UNIX backup and restore facilities are highly dysfunctional compared to similar facilities under the aforementioned operating systems. They can make only the grossest assumptions about file contents (back it up or not, bud?) and thus cause vast redundancy in backups; if you change a single byte in the file, you back up the whole thing instead of changed records.* Transferring files from system to system under UNIX requires that all layers of functionality be present on both sides to interpret files of arbitrary form and content. Embedded file systems ensure that file transfer is enhanced because the interpretation and manipulation facilities will be there even if the highest layers aren't (ie: you can at least decompose the file). Find me one person who guarantees they can decompose an Oracle or Ingres file (ie: someone who has a product that will always do it and guarantees it'll work for all successive releases of these packages).Once one strips away the cryptology, the issue is control.UNIX is an operating system that offers the promise ofultimate user control (ie: no OS engineer's going to take away from ME!), which was a good thing in itsinfancy, less good now, where the idiom has caused hugeredundancies between software packages. How many B*Treepackages do we NEED? I think that I learned factoring inhigh school; and that certain file idioms are agreed to inthe industry as Good Ideas. So why not support certaincommon denominators in the OS?Just because you CAN do something in user programs does notmean it's a terribly good idea to enforce it as policy. Ifsociety ran the same way UNIX does, everyone who owned a carwould be forced to refine their own gasoline from barrels ofcrude...

Just fuck off. Everyone knows you're one person even if you pretend otherwise.

The LF linebreak is the most practical one, even on Windows.
Text isn't bound to terminals and only needs a one character line break.
If you want to move around in the terminal you should use those fucking ansi escape codes for it.


OP, learn regex.

VMS is only good if you were raised on VMS. DCL is dogshit

If you're retarded enough to use DOS formatted text files you should kys

Honey, it's just LF now.

You are using one right now, moron

tools.ietf.org/html/rfc2616#page-16

Attached: 88928b4effb9d81d3687fec26bd40676.jpg (1111x1554, 825.15K)

I know how to fix it, but how little self-respect and awareness can you have to be a professional and send people this kind of shit?

Attached: 1426169438205.png (375x375, 102.73K)

None of the text-parsing programs I made even support the concept of carets and lines. The newline characters are nothing more than human-readable delimiters. languages like Java ignore newlines wholesale. I would put C in the same category if it didn't had what's basically a separate language embedded into it that follows different rules and semantics and cares about newlines.

Uh-huh.

This, but unironically.
The two bits will compress well to a single bit in most cases (newlines are very common in a doc so they get prioritized), while removing any possible ambiguity.

What ambiguity? Modern software doesn't support carets anymore, not with variable width characters being ubiquitous and default for absolute majority of text applications, and being nonexistent whatsoever for absolute majority of applications without text interface.

...

Are you retarded?

The one you get when notepad didn't support pure LF line breaks up to a few months ago?

Why waste low valued huffman codes on such a useless sequence? You should be trying to compress away common words and phrases.

That's a funny way of saying MS retardation.

tr -d '\r' < professor_file > output_file

fucking retard

And what's more common than line breaks?
As long as you don't have another 2+ char sequence that is more common than line breaks (and good luck with that), there's no reason not to encode them with 1 char.
Even if you have many common long sequences, the 1 char space is still pretty wide and chances are you'll fit them all in there together with line breaks anyways.
While notepad is the most blatant example of CR LF annoyances, it's far from the only one.

1.25 bytes is the way to go MIT nigger.

No, I'm not, because that's obviously not at all what I'm referring to.

the reason notepad matters is because it's installed by default. As soon as you can install your own software, anything is fair game. By your logic, I could write an editor that uses "\r\e\t\a\r\n" as linebreak, and this would be superior:

bash: ./tra.sh: /bin/bash^M: bad interpreter: No such file or directory
Winfag originally made it with notepad.exe!

He should have used wordpad.exe