c - Vognretur kræves ved udskrivning til konsollen i Windows?

Indlæg af Hanne Mølgaard Plasc

Problem



Det lader til, at bare at lægge en linefeed er god nok, men jeg ved, at det skal være vognretur + linjefeed. Gør der noget forfærdeligt, hvis du ikke sætter vognreturen og kun bruger linjeprodukter?


Dette er i ANSI C og vil ikke blive omdirigeret til en fil eller noget andet. Bare en normal konsol app.

Bedste reference


Windows-konsollen følger den samme linjeafslutningskonvention, der antages for filer, eller for den sags skyld til fysiske terminaler. Det er nødvendigt at se både CR og LF korrekt at flytte til næste linje.


Når det er sagt, er der meget softwareinfrastruktur mellem et ANSI C-program og den konsol. Specielt vil enhver standard C-bibliotekets I/O-funktion forsøge at gøre det rigtige, forudsat at du har tilladt det chancen. Det er derfor fopen() 's t og b]] modifikatorer for parameteren mode blev defineret.


Med t (standard for de fleste strømme, og især til stdin og stdout) konverteres nogen til en CRLF-sekvens, og det omvendte sker for læsninger . For at slukke for denne adfærd skal du bruge b modifikatoren.


I øvrigt har terminalerne, der traditionelt er hooked til * nix-kasser, herunder DEC VT100, der er emuleret af XTerm, også brug for både CR og LF. Men i * nix-verdenen håndteres konverteringen fra en newline-karakter til en CRLF-sekvens i tty-enhedsdriveren, så de fleste programmer behøver ikke at vide om det, og t og b Modifikatorer ignoreres begge. På disse platforme, hvis du har brug for at sende og modtage tegn på en tty uden denne ændring, skal du kigge op stty (1) eller systemet kalder det afhænger af.


Hvis dit ellers ANSI C-program undgår C-bibliotekets I/O til konsollen (måske fordi du har brug for adgang til konsolens tegnfarve og andre attributter), så afhænger det af, om du skal sende CR eller ej, hvilket Win32 API kalder dig bruger til at sende tegnene.

Andre referencer 1


Hvis du er i et * nix-miljø, er \ n (Linefeed) sandsynligvis ok. Hvis du er i Windows og er ikke omdirigering (nu), er en linjepost også ok, men hvis nogen ved somepoint omdirigerer :-(


Hvis du laver Windows, kan der være problemer, hvis outputen omdirigeres til en tekstfil, og derefter forsøger en anden proces at forbruge dataene.


Konsollen ved, hvad der skal vises, men forbrugerne er måske ikke glade ...


Hvis du bruger C #, kan du prøve miljøet.NewLine 'konstant'.


http://msdn.microsoft.com/en-us/library/system.environment.newline.aspx[17]


Hvis du virkelig er i vanille c, sidder du fast med \ r \ n. :-)

Andre referencer 2


Det afhænger af, hvad du bruger dem til. Nogle programmer vil ikke vise nye linjer korrekt, hvis du ikke sætter både og .


Hvis du forsøger at skrive kun , kan nogle programmer, der bruger din tekstfil (eller output), vise din tekst som en enkelt linje i stedet for flere linjer.


Der er også nogle filformater og protokoller, der helt vil være ugyldige uden at bruge både og .

Andre referencer 3


Jeg har ikke prøvet det så længe, ​​at jeg ikke er sikker på, at jeg husker, hvad der sker ... men går det ikke med en linefeed i sig selv at flytte ned en linje uden at vende tilbage til den venstre kolonne?


Afhængigt af din compiler kan standardudgangen åbnes i teksttilstand, i hvilket tilfælde en enkelt linjeproduktion oversættes til \ r \ n, før den udskrives.


Rediger: Jeg har lige prøvet en hurtig test, og i XP vises en fil uden returneringer normalt. Jeg ved stadig ikke om nogen kompilatorer indsætter afkastet for dig.

Andre referencer 4


I C kommer filer (kaldet 'streams') i to varianter - binære eller tekst.


Betydningen af ​​denne sondring er efterladt implementering/platform afhængig, men i Windows (med fælles implementeringer, som jeg har set), når jeg skriver til tekststrømme '\ n' automatisk oversættes til '\ r \ n', og når man læser fra tekst strømmer '\ r \ n' oversættes automatisk til '\ n'.


'Konsollen' er faktisk 'standard output', som er en stream åbnet som standard som en tekst stream. Så i praksis på Windows skal skrive 'Hej verden! \ N' være ret nok - og bærbar.