[C & in generale] Confusione con \r, \n e new line.

[Matrixbob]

Osservando la tabella ASCII mi chiedo se il \n è l'insieme di:
ritorno carrello + new line
oppure no:

[ilsensine]

No \n corrisponde solo a LF.

[Matrixbob]

Originariamente inviato da ilsensine

No \n corrisponde solo a LF.

.. e allora come mai oltre a cambiare riga, si mette a scrivere tutto a sinistra?!

A pagina 258 (Appendice B) di "Il linguaggio C", ultima traduzione del libro di BW Kernighan; ISBN: 88-7192-200-X.
Pare dire proprio: Ritorno Carrello + Fine Riga.

[Matrixbob]

In questo script ad esempio:

ovText = "AviSynth Authors:"+chr(13)+
	\ "----------------------------"+chr(13)+
	\ "Ben Radiak Gould"+chr(13)+
	\ "Klaus Post"+chr(13)+
	\ "Richard Berg"+chr(13)+
	\ "Dividee"+chr(13)+
	\ "Ian Brabham"+chr(13)+
	\ "David Pierre"+chr(13)+chr(13)+
	\ "Thanks to:"+chr(13)+
	\ "----------------------------"+chr(13)+
	\ "Everyone contributing to the project,"+chr(13)+
	\ "Doom9 & team, kwag, stickboy"+chr(13)+
	\ ""

#Genero clip vuoto bg della dimensione desiderata con colori YV12
#Colore dello sfondo: azzurro
bg = BlankClip(length=750,width=384,height=288,pixel_type="yv12",fps=25,color=$336699)

#Genero clip di report t_mask autoadattante con colori YV12
t_mask = MessageClip(ovText,384,288,true).converttoyv12().coloryuv(levels="tv->pc")

#Genero clip vuoto t_blank con le proprietà di t_mask, ma di colore diverso
#Colore del testo: argento
t_blank = BlankClip(t_mask, color=$e0e0e0)

#Uno strano overlay
last = overlay(bg, t_blank, mode="blend", mask=t_mask)

#Realizzano lo scroll?!
last = frameevaluate(last, "ol_x_offset = 40")
last = frameevaluate(last, "ol_y_offset = 256 - (current_frame)")

fadeio(15)
converttoyv12()

return last

Quello è il \r, ma lo script va anche a capo.

[ilsensine]

Originariamente inviato da Matrixbob

.. e allora come mai oltre a cambiare riga, si mette a scrivere tutto a sinistra?!

Perché lo schermo non è una stampante?

A parte gli scherzi, dipende da come viene implementato. Se apri un file scritto su unix (quindi solo con \n per i fine riga) con il notepad, vedi tutto su una riga. Se lo apri con il wordpad, viene visualizzato correttamente.

Riguardo \r che va anche a capo, non ho mai osservato questo comportamento (almeno sotto linux).

[71104]

@Matrixbob, forse ciò che non sai è che i line terminators sono definiti diversamente nei tre principali sistemi operativi, o famiglie di:

• in Windows il terminatore di linea è \r\n
• nei Mac è \r
• in Linux e altri Unix è \n
• Windows per compatibilità ammette anche il singolo \n, ma solo nei programmi CUI (console)

[ilsensine]

Originariamente inviato da 71104

• nei Mac è \r

[Matrixbob]

Originariamente inviato da 71104

@Matrixbob, forse ciò che non sai è che i line terminators sono definiti diversamente nei tre principali sistemi operativi, o famiglie di:

• in Windows il terminatore di linea è \r\n
• nei Mac è \r
• in Linux e altri Unix è \n
• Windows per compatibilità ammette anche il singolo \n, ma solo nei programmi CUI (console)

... in AVISynth che è 1 script language x Windows?
Quel chr(13) è in ASCII il \r.

Diciamo allora che il codice ASCII è quello che è, poi sarà l'applicazione che usiamo ad interpretarlo a suo modo il byte che trova?!

[andbin]

Originariamente inviato da Matrixbob

Osservando la tabella ASCII mi chiedo se il \n è l'insieme di:
ritorno carrello + new line
oppure no

Ahh .. ma stai usando il mio documento sui codici ASCII.

Comunque la risposta è no: carriage return e line feed sono due codici diversi e con significato differente. Come ti è già stato risposto dagli altri, un "newline" è codificato in maniera differente sui vari S.O.
Poi come mandare in output un newline dipende anche dal linguaggio usato. Ad esempio in "C" se metti un \n nella printf, ci pensa la funzione a mandare in output la sequenza di newline corretta per il sistema operativo.

Quindi ad esempio: printf ("Ciao\n"); se compilato su DOS/Win manderà in output Ciao CR LF, se compilato su Linux manderà in output Ciao LF (e con CR sui Mac).

Invece ad esempio con Java se fai: System.out.print ("Ciao\n"); manda in output sempre e solo un LF. Se si vuole mandare in output davvero un newline in modo portabile bisogna usare altri metodi (es. println oppure la proprietà "line.separator").

[Matrixbob]

Originariamente inviato da andbin

Ahh .. ma stai usando il mio documento sui codici ASCII.

Sempre e dovunque, Andbin.

[71104]

Originariamente inviato da ilsensine

ehm... non è così...?

allora ad aver sbagliato siamo in due, visto che l'ha detto anche andbin

[71104]

Originariamente inviato da andbin

Quindi ad esempio: printf ("Ciao\n"); se compilato su DOS/Win manderà in output Ciao CR LF,

veramente che io sappia manda proprio Ciao\n, solo che come dicevo sopra Windows supporta (solo in CUI) anche il singolo \n per compatibilità.

[andbin]

Originariamente inviato da 71104

veramente che io sappia manda proprio Ciao\n, solo che come dicevo sopra Windows supporta (solo in CUI) anche il singolo \n per compatibilità.

La sprintf mette nel buffer solo \n ma la printf su DOS\Win manda in output CR+LF. Questo è quanto ho visto su tutti i compilatori Win32 che ho sempre usato (VC++ e BCC per dirne due).

[71104]

giorni fa ho fatto questo programma:

#include <windows.h>

INT main(VOID)
{
	CONST TCHAR pszMessage[] = TEXT("Hello world!\n");
	HANDLE hStdIn, hStdOut;

	DWORD dwDummy;

	hStdIn = GetStdHandle(STD_INPUT_HANDLE);
	hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);

	WriteConsole(hStdOut, pszMessage, sizeof(pszMessage) / sizeof(TCHAR) - 1, &dwDummy, NULL);

	ReadConsole(hStdIn, &dwDummy, 1, &dwDummy, NULL);

	return 0;
}

il quale funziona perfettamente, il che significa che i LF singoli sono supportati correttamente; ora non vedo perché mai il codice di una printf dovrebbe venire complicato aggiungendo \r ad ogni \n
se hai veramente letto sorgenti di printf che lo fanno erano sorgenti scritti male.

[Matrixbob]

Ehm direi che qui il confine tra compilatore/SO/applicazione diventa veramente sottile e sfumato.

Nell'appendice del libro sopra citato dice proprio LF+CR.

Anche da qualche altra parte trovai che x evitare problemi si metteva \r\n.
Ma non ricordo + bene il contesto in cui era.

Nell'altro script language (AVISynth), nel ben mezzo di una stringa ci sbattono l'ASCII di \r.
Ora dato che AVISynth è basato su C perchè fanno dei casini del genere gli autori?!
Dalla versione 2.5.7 è stato inserito il \n. Alleluia.

[andbin]

Originariamente inviato da 71104

il quale funziona perfettamente, il che significa che i LF singoli sono supportati correttamente; ora non vedo perché mai il codice di una printf dovrebbe venire complicato aggiungendo \r ad ogni \n
se hai veramente letto sorgenti di printf che lo fanno erano sorgenti scritti male.

Non è per fare polemiche ma .... rispondi:
a) Cosa c'entra printf (standard) con WriteConsole (e simili, specifiche di Win32)??
b) Come faresti con printf a mandare in output un newline in modo "portabile"??

#include <stdio.h>

int main (void)
{
    printf ("Ciao\nProva");
    return 0;
}

(con VC++)
prova.exe > prova



Quindi, secondo te?

[Matrixbob]

[ilsensine]

Originariamente inviato da 71104

ehm... non è così...?

Si che è così, non ricordavo che i Mac -- come al solito -- thinkasserto differentemente

[71104]

Originariamente inviato da andbin

a) Cosa c'entra printf (standard) con WriteConsole (e simili, specifiche di Win32)??

come si implementa una printf? se non è WriteConsole è WriteFile.

b) Come faresti con printf a mandare in output un newline in modo "portabile"??

\n

#include <stdio.h>

int main (void)
{
    printf ("Ciao\nProva");
    return 0;
}

(con VC++)

non so cosa tu abbia fatto e non conosco quel programma (Cygnus), ma è assolutamente impossibile che la stringa "Ciao\nProva" nell'eseguibile venga codificata con un carattere in più. giusto per scrupolo ho anche provato a compilare quel programma con Visual C++ 2005, e come immaginavo quella stringa risulta contenere solamente il carattere LF.

[andbin]

Originariamente inviato da 71104

come si implementa una printf? se non è WriteConsole è WriteFile.

Beh intanto (e indipendentemente dal sistema operativo) la printf non è un "banale" wrapper per una funzione nativa del S.O. È ... molto di più ... pensa solo alla gestione degli specificatori di formato.
Poi su Win32 che funzione nativa venga usata per mandare in output i caratteri non lo so ....
Quello che so è che su Win32, quando la printf incontra un \n manda in output CR+LF.

Originariamente inviato da 71104

non so cosa tu abbia fatto e non conosco quel programma (Cygnus), ma è assolutamente impossibile che la stringa "Ciao\nProva" nell'eseguibile venga codificata con un carattere in più. giusto per scrupolo ho anche provato a compilare quel programma con Visual C++ 2005, e come immaginavo quella stringa risulta contenere solamente il carattere LF.

Ma LOL

"Ciao\nProva" è una stringa literal, nel caso tu non l'abbia notato. Vuol dire che nell'eseguibile è così come è, senza alcun carattere aggiuntivo (perché mai il compilatore dovrebbe aggiungere dei caratteri??). Cioè nell'eseguibile tra Ciao e Prova c'è il carattere 0Ah e basta. E questo varrebbe su qualunque altro S.O.

È la printf che su DOS\Win quando trova un \n manda in output CR+LF.