Akapity - jak jest a jak być powinno?
artur
Mam taki oto problem z podziałem tekstu na akapity?
Wersja I. Spotkałem się z podziałem następującym. Tekst piszę w blokach, w
których mieści się kilka akapitów. Każdy blok oddzielam pustą linią. Przy
czym w tym przypadku widziałem dwie wersje. Wersja A zakłada, że
rozpoczynając blok jak i rozpoczynając akapit sensu stricte, robię
kilkuspacjowy odstęp [Tab]. W drugiej wersji (wersja B) nie robię żadnych
odstępów. Wersja B – IMO – jest mało czytelna, bo tekst jest zbity, ale może
jest prawidłowa? Co o tym myślicie?
Wersja II. Każdą nową myśl oddzielam jako oddzielny blok, tj. pozostawiam
pustą linię pomiędzy nimi. I tu także widziałem dwie wersje. W wersji A robię
kilkuspacjowy odstęp [Tab], natomiast w wersji B nie robię odstępów.
Która opcja jest wg Was prawidłowa i którą mam stosować?
Pozdrawiam,
artur
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Mo
> Witam wszystkich Forumowiczów!
>
> Mam taki oto problem z podziałem tekstu na akapity?
>
> Wersja I. Spotkałem się z podziałem następującym. Tekst piszę w blokach, w
> których mieści się kilka akapitów. Każdy blok oddzielam pustą linią. Przy
> czym w tym przypadku widziałem dwie wersje. Wersja A zakłada, że
> rozpoczynając blok jak i rozpoczynając akapit sensu stricte, robię
> kilkuspacjowy odstęp [Tab]. W drugiej wersji (wersja B) nie robię żadnych
Tzn. wcięcie? Bo dla mnie odstęp to może być między liniami, więc na
pewno nie kilkuspacjowy. Tak dosłownie, to właśnie to wcięcie jest
akapitem... (http://sjp.pwn.pl/haslo.php?id=555)
> odstępów. Wersja B – IMO – jest mało czytelna, bo tekst jest zbity, ale może
> jest prawidłowa? Co o tym myślicie?
Myślę, że wersja ta jest prawidłowa w tekstach angielskich.
>
> Wersja II. Każdą nową myśl oddzielam jako oddzielny blok, tj. pozostawiam
> pustą linię pomiędzy nimi. I tu także widziałem dwie wersje. W wersji A robię
> kilkuspacjowy odstęp [Tab], natomiast w wersji B nie robię odstępów.
>
> Która opcja jest wg Was prawidłowa i którą mam stosować?
Mnie w szkole uczono, że nową myśl zaczynamy od akapitu w obu
znaczeniach, tj. nowa linia +wcięcie. I w tej kwestii jestem
konserwatywna, jeśli chodzi o literaturę, listy prywatne, wypracowania
itd. Angielskie "blokowiska" z odstępami bez akapitów toleruję w listach
urzędowych, mówi się trudno, jak to już ustaliliśmy w podobnej dyskusji
na ten temat. :)
--
Pozdrawiam
M.
Gdyż rodzaj ludzki w swej niedoli rozporządza jedną naprawdę skuteczną
bronią [...] Nic nie może się przeciwstawić *napadowi śmiechu* (Mark Twain)
Fenestre
Akapit jest jednostką tekstu, która jest oddzielana od innych za pomocą
<przejścia do nowego wiersza>. Akapitem może być tytuł tekstu, linijka
poezji albo np. zdanie lub wiele zdań prozy. Akapit może być więc
jednowierszowy albo wielowierszowy. W tekście komputerowym łatwo go
rozpoznać, bo komputer kończy akapit po wciśnięciu klawisza Enter (Return),
pzrez wstawienie niewidocznego znaku zakończenia (w PC jest to znak nr 13 +
znak nr 10, w Macu znak nr 10 itd.). Można to zobaczyć w Wordzie,
uruchamiając w menu funkcję oznaczoną odwróconym "P" (pokaż znaki
niedrukowalne). Wtedy w tekście na końcach akapitów pokażą się takie
odwrócone "P". Wiersz po tym "P" jest pierwszym wierszem nowego akapitu.
Niektórzy mylą <wcięcie akapitowe> (odstęp pierwszego wiersza od lewego
marginesu) z samym <akapitem>. Akapit może mieć wcięcie (i najczęściej je
ma), ale wcale nie musi. To zależy od typografii tekstu (układu
graficznego).
Nie zaleca się wstawiania pustego wiersza między akapity tekstu głównego.
Tak się oddziela akapity tytułów od tekstu itd.
Pozdrawiam
Fenestre
Mo
> Akapit jest jednostką tekstu, która jest oddzielana od innych za pomocą
> <przejścia do nowego wiersza>. Akapitem może być tytuł tekstu, linijka
> poezji albo np. zdanie lub wiele zdań prozy. Akapit może być więc
> jednowierszowy albo wielowierszowy. W tekście komputerowym łatwo go
> rozpoznać, bo komputer kończy akapit po wciśnięciu klawisza Enter (Return),
> pzrez wstawienie niewidocznego znaku zakończenia (w PC jest to znak nr 13 +
> znak nr 10, w Macu znak nr 10 itd.). Można to zobaczyć w Wordzie,
> uruchamiając w menu funkcję oznaczoną odwróconym "P" (pokaż znaki
> niedrukowalne). Wtedy w tekście na końcach akapitów pokażą się takie
> odwrócone "P". Wiersz po tym "P" jest pierwszym wierszem nowego akapitu.
Wow! :-P
> Niektórzy mylą <wcięcie akapitowe> (odstęp pierwszego wiersza od lewego
> marginesu) z samym <akapitem>.
A byłeś/aś tu: http://sjp.pwn.pl/haslo.php?id=555 ? (Nie lubię się
powtarzać, ale widocznie czasem trzeba...)
> Akapit może mieć wcięcie (i najczęściej je
> ma), ale wcale nie musi. To zależy od typografii tekstu (układu
> graficznego).
I właśnie w tym rzecz, że w polskiej typografii "od akapitu" oznacza "od
nowej linii z wcięciem".
> Nie zaleca się wstawiania pustego wiersza między akapity tekstu głównego.
Nawet jeśli nowe akapity są bez wcięcia? Widziałeś taki tekst? I do tego
wyjustowany? Przypominam, że niektórzy jeszcze czytają wydruki, a nie
tylko w dokumenty Worda na podglądzie znaków niedrukowanych....
--
Pozdrawiam
M.
Gdyż rodzaj ludzki w swej niedoli rozporządza jedną naprawdę skuteczną
bronią [...] Nic nie może się przeciwstawić *napadowi śmiechu* (Smark Twain)
Katarzyna
bo tylko te zatrudniają korektorów.
Każdy akapit zaznaczaj Tabulatorem, wtedy uzyskasz równy odstęp. Dodatkowej
wolnej linii się nie stosuje, tekst z "wcięciem" na początku wersu jest
wystarczająco przejrzysty.
Zauważyłam, ze wiele osób rozróżnia akapity "ważniejsze" i "mniej ważne",
jedne pisząc od nowej linii, a inne od nowej linii i z "wcięciem" albo z
dodatkową wolną linią między wierszami. To jeden z najczęstszych błędów
graficznych. Ciekawe skąd się wziął?
K.
Fenestre
Wyklepał nie wyklepał, ale chyba nie zrozumiałeś tekstu, do którego
odsyłasz.
Oto on: "akapit m IV, D. -u, Ms. ~icie; lm M. -y. 1. druk. «początkowy
wiersz fragmentu tekstu wyróżniony zazwyczaj wcięciem, czasem inicjałem». 2.
druk. «nowy fragment tekstu; ustęp». Przeczytać akapit".
Pierwsze znaczenie jest rzadko używane, najczęściej to drugie.
Wyrażenie "od akapitu" jest dosłownym tłumaczeniem łacinskiego "ab
accapite", tzn. 'od początku, od głowy', a nie połączeniem "od" ze
spolszczonym rzeczownikiem "akapit", który oznacza drukarską jednostkę
tekstu.
I nie mieszaj ludziom w głowie.
Fenestre
> Wyklepał nie wyklepał, ale chyba nie zrozumiałeś tekstu, do którego
> odsyłasz.
> Oto on: "akapit m IV, D. -u, Ms. ~icie; lm M. -y. 1. druk. «początkowy
> wiersz fragmentu tekstu wyróżniony zazwyczaj wcięciem, czasem inicjałem».
> 2.
> druk. «nowy fragment tekstu; ustęp». Przeczytać akapit".
> Pierwsze znaczenie jest rzadko używane, najczęściej to drugie.
> Wyrażenie "od akapitu" jest dosłownym tłumaczeniem łacinskiego "ab
> accapite", tzn. 'od początku, od głowy', a nie połączeniem "od" ze
> spolszczonym rzeczownikiem "akapit", który oznacza drukarską jednostkę
> tekstu.
> I nie mieszaj ludziom w głowie.
> Fenestre
>
>
Jeszcze dodam, że "od akapitu" (zaczynać itp.) ma pełną postać: "od nowego
akapitu".
Fenestre
Być może wzięło się to z zapatrzenia w typografię amerykańską (a może i
brytyjską, nie jestem pewien), w której pierwszym akapitom tekstów (np.
rozdziałów) nie daje się wcięcia (ale dalszym już tak). W krótkich tekstach
czasem (rzadko) w ogóle nie stosuje się wcięć akapitowych, i jeśli nie
utrudnia to czytania, nie jest to błąd. W każdym razie obowiązuje
konsekwencja, albo wszędzie wcięcia, albo nigdzie. Katarzyna ma rację.
F.
W.Kotwica
> Akapit jednowierszowy albo wielowierszowy. W tekście komputerowym łatwo go
> rozpoznać, bo komputer kończy akapit po wciśnięciu klawisza Enter (Return),
> pzrez wstawienie niewidocznego znaku zakończenia (w PC jest to znak nr 13 +
> znak nr 10, w Macu znak nr 10 itd.).
Bardzo proszę nie wprowadzać w błąd.
1. "Znakiem" końca akapitu, a właściwie - znakiem końca linii - NIE jest
"na PC" sekwencja #13+#10. Taka konwencja występuje *tylko* w przypadku
systemów DOS i Windows. W systemach uniksowych - *BSD, GNU/Linux,
SCO Unix itp., także w wersjach na PC, "od zawsze" znakiem końca linii
jest pojedynczy znak nr 10.
2. Na Macintoshach nie jest to znak nr 10, lecz znak nr 13.
Uniksowe - #10 (LF, ^J)
DOS/Windows - #13+#10 (CR+LF, ^M+^J)
Macintosh - #13 (CR, ^M)
> Można to zobaczyć w Wordzie, uruchamiając w menu funkcję oznaczoną
> odwróconym "P" (pokaż znaki niedrukowalne).
Moim zdaniem nie jest to "odwrócone 'P'", lecz w przybliżeniu duża grecka
litera PI.
> Wtedy w tekście na końcach akapitów pokażą się takie odwrócone "P".
Tu także.
> Wiersz po tym "P" jest pierwszym wierszem nowego akapitu.
Bardzo dziwne postawienie sprawy. W szczególności okazuje się, że
w tym ujęciu na końcu tekstu zawsze występuje pusty akapit(?).
Prawidłowe podejście to: "ten znak oznacza koniec akapitu".
--
HQ
Jarosław Sokołowski
> Bardzo proszę nie wprowadzać w błąd.
Bardzo słuszna uwaga. Natury ogólnej.
> 1. "Znakiem" końca akapitu, a właściwie - znakiem końca linii - NIE
> jest "na PC" sekwencja #13+#10. Taka konwencja występuje *tylko*
> w przypadku systemów DOS i Windows.
Tylko? Jest Pan o tym przekonany, Panie Wojtku? Weźmy przykład pierwszy
z brzegu -- RFC-854 (albo poprzednia wersja RFC-724, która powstała
jeszcze przed DOS-em).
> W systemach uniksowych - *BSD, GNU/Linux, SCO Unix itp., także
> w wersjach na PC, "od zawsze" znakiem końca linii jest pojedynczy
> znak nr 10.
W wymienionych systemach zdarzało mi sie spotkać programy, które w dość
swobodny sposób podchodzą do zaleceń RFC, ale tych jest mniejszość.
--
Jarek
W.Kotwica
> Pan W.Kotwica napisał (we właściwy sposób kończąc każdą linijkę):
Przepraszam, nie rozumiem?
>> Bardzo proszę nie wprowadzać w błąd.
>
> Bardzo słuszna uwaga. Natury ogólnej.
Hmm... tak.
>> 1. "Znakiem" końca akapitu, a właściwie - znakiem końca linii - NIE
>> jest "na PC" sekwencja #13+#10. Taka konwencja występuje *tylko*
>> w przypadku systemów DOS i Windows.
>
> Tylko? Jest Pan o tym przekonany, Panie Wojtku?
Nie są mi znane inne przykłady współczesnych ("występUJE") systemów
operacyjnych dla PC, w których przyjęto takie rozwiązanie.
> Weźmy przykład pierwszy z brzegu -- RFC-854 (albo poprzednia wersja
> RFC-724, która powstała jeszcze przed DOS-em).
Te RFC (szczególnie 724) świadczą tylko o neutralnej postawie twórców,
przyjętej wobec braku jednoznacznego rozstrzygnięcia w standardach.
Proszę zauważyć, że nie twierdziłem i nie twierdzę, jakoby istniał
jeden i tylko jeden prawidłowy (=ujęty standardem) sposób oznaczania
końca wiersza. Ani też, że nigdy nie występOWAŁY inne systemy,
na jakiejkolwiek platformie, kodujące koniec linii jako CR+LF.
Podtrzymuję natomiast, że mylące i fałszywe są stwierdzenia:
pisząc, iż:
a) "na PC" znakiem końca linii jest #13+#10
b) na macintoshach jest to #10
Gwoli ścisłości: tradycyjne dla macintoshy zakończenie wierszy to #13.
Mimo że obecnie, w Mac OS X, bywa nim #10, szczególnie w narzędziach
wiersza poleceń, bo nowe systemy jabłuszkowe czerpią z uniksowych
rozwiązań. Pomijając nawet stawianie np. GNU/Linuksa ma "maczku".
>> W systemach uniksowych - *BSD, GNU/Linux, SCO Unix itp., także
>> w wersjach na PC, "od zawsze" znakiem końca linii jest pojedynczy
>> znak nr 10.
>
> W wymienionych systemach zdarzało mi sie spotkać programy, które w dość
> swobodny sposób podchodzą do zaleceń RFC, ale tych jest mniejszość.
Rad bym poznać przykłady takich, które używają CR+LF zamiast LF.
Bo takich, które "rozumieją" obce CR+LF i traktują jakby napotkały
samo LF, nie brakuje (mcedit chociażby).
--
HQ
Wojtek Szweicer
>Katarzyna <katar...@poczta.onet.pl> napisał(a):
>
>
>>Zauważyłam, ze wiele osób rozróżnia akapity "ważniejsze" i "mniej ważne",
>>jedne pisząc od nowej linii, a inne od nowej linii i z "wcięciem" albo z
>>dodatkową wolną linią między wierszami. To jeden z najczęstszych błędów
>>graficznych. Ciekawe skąd się wziął?
>>
>>
>Być może wzięło się to z zapatrzenia w typografię amerykańską (a może i
>brytyjską, nie jestem pewien), w której pierwszym akapitom tekstów (np.
>rozdziałów) nie daje się wcięcia (ale dalszym już tak).
>
>
Pierwszy akapit niewcięty to zaszłość z czasów, gdy robiło się inicjał
na jego początku.
A co do wolnej linii: ona raczej nie oddziela akapitów, a dwa teksty.
- Szwejk
Marcin 'Qrczak' Kowalczyk
> 2. Na Macintoshach nie jest to znak nr 10, lecz znak nr 13.
Był. Do czasów uniksowatego MacOS X, który stosuje 10, jak inne Uniksy.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
W.Kotwica
> wkot...@post.pl (W.Kotwica) writes:
>
>> 2. Na Macintoshach nie jest to znak nr 10, lecz znak nr 13.
>
> Był. Do czasów uniksowatego MacOS X, który stosuje 10, jak inne Uniksy.
>
Owszem. Uściśliłem w <news:cl578a$slj$1...@nemesis.news.tpi.pl>.
Dla kompletności obrazu: mam wrażenie, że gdzies czytałem, że nawet
w MacOS X część programów nadal stosuje stary sposób kończenia linii.
--
HQ
Jarosław Sokołowski
[...głownie o tym, że wiersz jest jak mężczyzna, poznać go można po tym
jak się kończy, a nie jak rozpoczyna...]
[... *BSD, GNU/Linux, SCO Unix itp...]
>> W wymienionych systemach zdarzało mi sie spotkać programy, które w dość
>> swobodny sposób podchodzą do zaleceń RFC, ale tych jest mniejszość.
>
> Rad bym poznać przykłady takich, które używają CR+LF zamiast LF.
Zamiast? Dlaczego "zamiast"? Chodzi o przestrzeganie reguł, nie
o dowolność. Ale jeśli chodziło Panu o programy używające CR+LF
na końcach wierszy (używające, nie tylko rozumiejące) to telnetd
będzie dobrym przykładem.
> Bo takich, które "rozumieją" obce CR+LF i traktują jakby napotkały
> samo LF, nie brakuje (mcedit chociażby).
Coś Panu ten przykład nie wyszedł. U mnie mcedit pokazuje na końcach
wierszy w plikach dosowych znaczek "^M", czyli właśnie <LF>. Ale pomogę
Panu -- edytor joe wywołany z opcją -crlf używa sekwencji <CR><LF>
przy odczycie i zapisie plików. Ostatnia jego wersja (3.1) nawet bez
tej opcji sama rozpoznaje z jakim plikiem ma do czynienia.
Co innego jednak miałem na myśli pisząc o swobodnym podchodzeniu do
zaleceń RFC. Spotkałem się kiedyś z kodem programu, w którym jakiś
młody gniewny pozamieniał wszystkie "\r\n" na "\n". Pozamieniał, bo sam
tego nie wymyślił, skopiował tylko ogólnie znany zapis. Umiejętności
miał akurat tyle, że wiedział iż "taka konwencja występuje *tylko*
w przypadku systemów DOS i Windows". Pewnie gdzieś przeczytał, że
<CR><LF> od złego pochodzi, być może nawet, że wymyślił to sam Bill Gates.
Trudno się dziwić, że ten program miał czasem trudności z komunikacją.
Proszę mi nie mieć za złe, że zechciałem skorygować publicznie Pańskie
poglądy na rzeczywistość, zwłaszcza, że zachęcony zostałem apelem
o niewprowadzanie w błąd. Grupę czyta młodzież, która się uczy, więc
niech się od razu dobrze nauczy.
--
Jarek
W.Kotwica
> Pan W.Kotwica napisał:
>
> [...głownie o tym, że wiersz jest jak mężczyzna, poznać go można po tym
> jak się kończy, a nie jak rozpoczyna...]
> [... *BSD, GNU/Linux, SCO Unix itp...]
>>> W wymienionych systemach zdarzało mi sie spotkać programy, które w dość
>>> swobodny sposób podchodzą do zaleceń RFC, ale tych jest mniejszość.
>>
>> Rad bym poznać przykłady takich, które używają CR+LF zamiast LF.
>
> Zamiast? Dlaczego "zamiast"? Chodzi o przestrzeganie reguł, nie
> o dowolność.
Reguły bezwzględnej, uniwersalnej dla każdego systemu nie ma.
Dlatego "zamiast", bo w systemach uniksowych jest właściwa
im "reguła LF", więc stosowanie CR+LF jest używaniem "obcego"
znacznika zamiast typowego dla danego systemu.
> Ale jeśli chodziło Panu o programy używające CR+LF na końcach wierszy
> (używające, nie tylko rozumiejące)
Doprawdy nie wiem, jak należało rozumieć Pańską uwagę o tym, iż:
zdarza się "swobodne podejście do RFC" w programach systemów uniksowych
w kontekście mojej poprzedzającej ją wypowiedzi. Gdyż wymienione przez Pana
RFC dopuszczają zarówno LF jak i CR+LF. Uważam, że uwaga ta albo jest
nieprawdziwa, albo - wbrew pozorom - nie stanowi faktycznie komentarza
ni kontrargumentu dla mojego zdania, do którego zdaje się odnosić.
Ale owszem, w pytaniu chodziło mi o przykłady programów uniksowych,
które używają CR+LF na końcach wiersza, zamiast przyjętego w ich
systemie LF.
> to telnetd będzie dobrym przykładem.
Nigdy z niego nie korzystałem, więc nie miałem potrzeby zaglądać
do podręcznika systemowego tego demona, przepraszam, tej usługi ;-)
ani tym bardziej do jego źródeł.
>> Bo takich, które "rozumieją" obce CR+LF i traktują jakby napotkały
>> samo LF, nie brakuje (mcedit chociażby).
>
> Coś Panu ten przykład nie wyszedł.
Doprawdy?
> U mnie mcedit pokazuje na końcach wierszy w plikach dosowych znaczek
> "^M", czyli właśnie <LF>.
1. A u mnie nie pokazuje. Tak robił OTB w SuSE aż do 7.2 włącznie,
tak samo robi w Mandrake'u dziś.
2. Skoro prostujemy błędy: "^M" to jest <CR>, a nie "właśnie <LF>".
> Ale pomogę Panu
W czym? Nie mam żadnego kłopotu z kodowaniem końców wierszy w plikach
z różnych systemów.
> -- edytor joe wywołany z opcją -crlf używa sekwencji <CR><LF>
> przy odczycie i zapisie plików.
Nigdy nie było mi to potrzebne, a z joe'go przestałem korzystać
dość dawno temu.
> Ostatnia jego wersja (3.1) nawet bez tej opcji sama rozpoznaje
> z jakim plikiem ma do czynienia.
Ostatnia wersja, z jakiej korzystałem (niestety, nie zróciłem uwagi
na numer wersji), domyślnie "obstawiała" tylko LF, pozostawiając
ewentualne poprzedzające znak LF znaki "^M" i przedstawiając je
tak samo, jak inne znaki postrzegane jako "nie dające się wyświetlić"
(proszę wybaczyć uproszczenie).
> Co innego jednak miałem na myśli pisząc o swobodnym podchodzeniu
> do zaleceń RFC. Spotkałem się kiedyś z kodem programu, w którym jakiś
> młody gniewny pozamieniał wszystkie "\r\n" na "\n". Pozamieniał,
> bo sam tego nie wymyślił, skopiował tylko ogólnie znany zapis.
Nie wiem, po co, skoro - jak zakładam - bez tej zmiany program działał
poprawnie.
> Umiejętności miał akurat tyle, że wiedział iż "taka konwencja występuje
> *tylko* w przypadku systemów DOS i Windows". Pewnie gdzieś przeczytał,
> że <CR><LF> od złego pochodzi, być może nawet, że wymyślił to sam Bill
> Gates. Trudno się dziwić, że ten program miał czasem trudności
> z komunikacją.
Bardzo ładna opowiastka. Co ma wspólnego z *moimi* poglądami?
> Proszę mi nie mieć za złe, że zechciałem skorygować publicznie Pańskie
> poglądy na rzeczywistość
Proszę wybaczyć, ale niczego Pan w moich poglądach nie skorygował.
Pańskie mniemanie o moich poglądach na temat CR+LF vs. LF było i pozostaje
wyłącznie mniemaniem. Nie wiem, skąd ono Panu do głowy przyszło, bo
z moich wypowiedzi nie sposób wysnuć o moich poglądach takich wniosków,
jakie Pan wysnuwa.
> zwłaszcza, że zachęcony zostałem apelem o niewprowadzanie w błąd.
Czyżbym kogoś wprowadzał w błąd? Bardzo proszę mi wskazać, jaką
konkretnie wypowiedzią.
> Grupę czyta młodzież, która się uczy, więc niech się od razu
> dobrze nauczy.
Niech się uczy.
--
HQ
Jarosław Sokołowski
>> Zamiast? Dlaczego "zamiast"? Chodzi o przestrzeganie reguł,
>> nie o dowolność.
>
> Reguły bezwzględnej, uniwersalnej dla każdego systemu nie ma.
> Dlatego "zamiast", bo w systemach uniksowych jest właściwa
> im "reguła LF",
...do zapisywania plików tekstowych.
> więc stosowanie CR+LF jest używaniem "obcego" znacznika zamiast
> typowego dla danego systemu.
...albo dostosowaniem się do protokołu transmisyjnego, czy też choćby
do sposobu działania drukarki.
[...RFC oraz inne pytania i prośby o komentarz...]
> Ale owszem, w pytaniu chodziło mi o przykłady programów uniksowych,
> które używają CR+LF na końcach wiersza, zamiast przyjętego w ich
> systemie LF.
>
>> to telnetd będzie dobrym przykładem.
>
> Nigdy z niego nie korzystałem,
To akurat ma małe znaczenie dla jakości przykładu.
Nie wiem z czego Pan korzysta, ale weźmy następny z brzegu przykład.
Protokół SMTP. Zaraz się pewnie dowiem, że tak pisać nie należy,
bo SMTP to Simple Mail Transport Protocol (z pewnością wszyscy
subskrybenci pl.hum.polszczyzna świetnie znają rozwinięcie skrótu),
ale co mi tam. W każdym razie z emaila korzystał Pan wielokrotnie.
No to w takim razie raczy Pan sobie wystawić, że wszelkie erefce
opisujące negocjację z serwerem pocztowym nakazują wprost kończenie
wiersza (linii) sekwencją <CRLF>.
>> U mnie mcedit pokazuje na końcach wierszy w plikach dosowych znaczek
>> "^M", czyli właśnie <LF>.
>
> 1. A u mnie nie pokazuje. Tak robił OTB w SuSE aż do 7.2 włącznie,
> tak samo robi w Mandrake'u dziś.
No to trzeba było od razu, że o SuSE czy Mandrake chodzi, a nie o mcedit.
A byłby Pan łaskaw sprawdzić dla mnie, czy jeśli dopiszemy linijkę, to
pojawi się też <CR><LF> na końcu?
> 2. Skoro prostujemy błędy: "^M" to jest <CR>, a nie "właśnie <LF>".
Dziękuję, rzeczywiście to moja pomyłka.
>> Ale pomogę Panu
> W czym?
...w znalezieniu przykładu.
>> Co innego jednak miałem na myśli pisząc o swobodnym podchodzeniu
>> do zaleceń RFC. Spotkałem się kiedyś z kodem programu, w którym jakiś
>> młody gniewny pozamieniał wszystkie "\r\n" na "\n". Pozamieniał,
>> bo sam tego nie wymyślił, skopiował tylko ogólnie znany zapis.
>
> Nie wiem, po co, skoro - jak zakładam - bez tej zmiany program działał
> poprawnie.
Nie przed zmianą, lecz po zmianie. Najpierw jego autor zmienił
(najprawdopodobniej z przyczyn niżej opisanych) włączając i częściowo
modyfikując kod telnetd do swojego programu, który (między innymi)
korzystał z protokołu telnet. A zmiana z "\n" na "\r\n", dokonana
później w niektórych miejscach, istotnie pomogła.
>> Umiejętności miał akurat tyle, że wiedział iż "taka konwencja występuje
>> *tylko* w przypadku systemów DOS i Windows". Pewnie gdzieś przeczytał,
>> że <CR><LF> od złego pochodzi, być może nawet, że wymyślił to sam Bill
>> Gates. Trudno się dziwić, że ten program miał czasem trudności
>> z komunikacją.
>
> Bardzo ładna opowiastka.
Dziękuję. Dla mnie ważniejsze, że pouczająca.
> Co ma wspólnego z *moimi* poglądami?
A to poniżej...
>> Proszę mi nie mieć za złe, że zechciałem skorygować publicznie
>> Pańskie poglądy na rzeczywistość
>
> Proszę wybaczyć, ale niczego Pan w moich poglądach nie skorygował.
> Pańskie mniemanie o moich poglądach na temat CR+LF vs. LF było
> i pozostaje wyłącznie mniemaniem. Nie wiem, skąd ono Panu do głowy
> przyszło, bo z moich wypowiedzi nie sposób wysnuć o moich poglądach
> takich wniosków, jakie Pan wysnuwa.
[...]
> Czyżbym kogoś wprowadzał w błąd? Bardzo proszę mi wskazać, jaką
> konkretnie wypowiedzią.
Na temat sekwencji <CR><LF>, że występuje ona *tylko* w przypadku
systemów DOS i Windows. Chodziło mi o sprostowanie tego zabobonu.
Hołdowanie przesądowi może mieć zgoła nieoczekiwane konsekwencje.
>> Grupę czyta młodzież, która się uczy, więc niech się od razu
>> dobrze nauczy.
>
> Niech się uczy.
Myśli Pan, że wezwania posłucha?
--
Jarek
Maciek
Użytkownik "Jarosław Sokołowski" <ja...@lasek.waw.pl> napisał
w wiadomości news:slrncncptu...@falcon.lasek.waw.pl...
> Pan W.Kotwica napisał:
>
>>
>> Reguły bezwzględnej, uniwersalnej dla każdego systemu nie ma.
>> im "reguła LF",
>
> ...do zapisywania plików tekstowych.
>
>> więc stosowanie CR+LF jest używaniem "obcego" znacznika zamiast
>> typowego dla danego systemu.
>
> ...albo dostosowaniem się do protokołu transmisyjnego,
> czy też choćby do sposobu działania drukarki.
... co na jedno wychodzi. :) To co dla ZU może się nazywać
sposobem działania drukarki, dla programu jest protokołem
komunikacyjnym, definiującym sposób przekazywania drukarce
opisu pożądanej postaci wydruku.
>
>>
>>> (....................)
>>
>
> Nie wiem z czego Pan korzysta, ale weźmy następny z brzegu przykład.
> Protokół SMTP. Zaraz się pewnie dowiem, że tak pisać nie należy,
> bo SMTP to Simple Mail Transport Protocol (z pewnością wszyscy
> subskrybenci pl.hum.polszczyzna świetnie znają rozwinięcie skrótu),
> ale co mi tam. W każdym razie z emaila korzystał Pan wielokrotnie.
> No to w takim razie raczy Pan sobie wystawić, że wszelkie erefce
> opisujące negocjację z serwerem pocztowym nakazują wprost kończenie
> wiersza (linii) sekwencją <CRLF>.
Przepraszam - jaki to ma związek z tematem?
Protokół komunikacyjny z definicji służy do komunikacji.
Czyli wymiany wiadomości. Oczywiście (w tym przypadku)
z INNYM komputerem. Zatem fakt przyjęcia takiej czy innej
konwecji w protokole nie ma ABSOLUTNIE NIC wspólnego
ze stosowaniem "w komputerze" PC czy iMac, albo "w systemie"
DOS, Unix, Windows *.*, MacOS czy jakimkolwiek innym.
Protokół jest bowiem "międzysystemowy".
Można nawet powiedzieć "ponadsystemowy".
Maciek
PS.
Czy szanowni potężni szermierze mogliby na marginesie
swej ciekawej dyskusji wyjaśnić istotom podrzędnym,
jak w systematyce ceerów i elefów ująć fakt użycia
samotnego <CR> do rozdzielania wierszy tekstu
w mswordowych plikach .doc?
Michał Szafrański
> Przepraszam - jaki to ma związek z tematem?
Żaden, przecież ten wątek jest już dawno poza tematem.
> Protokół komunikacyjny z definicji służy do komunikacji.
> Czyli wymiany wiadomości. Oczywiście (w tym przypadku)
> z INNYM komputerem. Zatem fakt przyjęcia takiej czy innej
> konwecji w protokole nie ma ABSOLUTNIE NIC wspólnego
> ze stosowaniem "w komputerze" PC czy iMac, albo "w systemie"
> DOS, Unix, Windows *.*, MacOS czy jakimkolwiek innym.
>
> Protokół jest bowiem "międzysystemowy".
> Można nawet powiedzieć "ponadsystemowy".
Czyli zgadza się Pan, że CR+LF jest ponadsystemowy a sam LF
uniksowy. Wbrew twierdzeniu, jakoby CR+LF był *tylko* używany
w DOS/Windows, od czego dyskuja się zaczeła.
A tak poza tym to przy wyświetlaniu każdy unix również używa
CR+LF. Po prostu terminal ma domyślnie włączoną opcję "onlcr",
dzięki czemu wyświetlany tekst jest tłumaczony w locie.
Oczywiście nadal można argumentować, że jest to protokół
komunikacji z użytkownikiem i nie ma ABSOLUTNIE NIC wspólnego...
--
m.
Mo
> Wyklepał nie wyklepał, ale chyba nie zrozumiałeś tekstu, do którego
> odsyłasz.
> Oto on: "akapit m IV, D. -u, Ms. ~icie; lm M. -y. 1. druk. «początkowy
> wiersz fragmentu tekstu wyróżniony zazwyczaj wcięciem, czasem inicjałem». 2.
> druk. «nowy fragment tekstu; ustęp». Przeczytać akapit".
No dobrze, biję się w piersi, zastosowałAm skrót myślowy. Wg Ciebie
nawet pomyliłAm itd, choć z definicji wynika (jak dla mnie), że pierwszy
wiersz jest akapitem, jeśli jest wyróżniony (co uzasadnia mój skrót).
Jeśli zaś nie pierwszy wiersz, to powinien być wyróżniony cały ustęp,
np. poprzez oddzielenie go od pozostałych ustępów (co uzasadnia
wstawianie pustej linii), czyż nie?
> Pierwsze znaczenie jest rzadko używane, najczęściej to drugie.
To dlaczego występuje jako pierwsze?
> Wyrażenie "od akapitu" jest dosłownym tłumaczeniem łacinskiego "ab
> accapite", tzn. 'od początku, od głowy', a nie połączeniem "od" ze
> spolszczonym rzeczownikiem "akapit", który oznacza drukarską jednostkę
> tekstu.
Cóż za pokaz erudycji! Wybacz, ANSP od złośliwości, kiedy ktoś pomija
sedno sprawy, by uraczyć wszystkich mądrobrzmiącą sieczką...
> I nie mieszaj ludziom w głowie.
I wzajemnie.
--
Pozdrawiam
M.
Bywają takie chwile z życiu człowieka, kiedy żadne radio nie gra jego
ulubionej piosenki...
Maciek
Użytkownik "Michał Szafrański" <sta...@variable.not.found>
napisał w wiadomości news:cl66ot$2nc$1...@81.210.81.243...
> Maciek wrote:
>
>> Przepraszam - jaki to ma związek z tematem?
>
> Żaden, przecież ten wątek jest już dawno poza tematem.
Proszę nie odwracać kotka fiutkiem do góry.
Z TEMATEM, NA JAKI DYSKUTUJECIE :
czy i w jakim zakresie znaki ASCII
<CR>, <LF>
lub ich pary są "przypisane" do konkretnych
typów komputerów lub systemów operacyjnych.
Z tematem, który rozpoczął Fenstre w wiadomości
news:cl3emn$2fi$1...@inews.gazeta.pl, pisząc:
>>>>>>>>>
>>>>>>>>> komputer kończy akapit po wciśnięciu klawisza
>>>>>>>>> Enter (Return), pzrez wstawienie niewidocznego znaku zakończenia (w PC jest to znak nr 13 + znak nr 10, w Macu znak nr
>>>>>>>>> 10 itd.).
>
>> Protokół komunikacyjny z definicji służy do komunikacji.
>> (....)
>> z INNYM komputerem. Zatem fakt przyjęcia takiej czy innej
>> konwecji w protokole nie ma ABSOLUTNIE NIC wspólnego
>> ze stosowaniem "w komputerze" PC czy iMac, albo "w systemie"
>> DOS, Unix, Windows *.*, MacOS czy jakimkolwiek innym.
>>
>> Protokół jest bowiem "międzysystemowy".
>> Można nawet powiedzieć "ponadsystemowy".
>
> Czyli zgadza się Pan, że CR+LF jest ponadsystemowy a sam LF
> uniksowy. Wbrew twierdzeniu, jakoby CR+LF był *tylko* używany
> w DOS/Windows, od czego dyskuja się zaczeła.
Nie mam pojęcia, skąd ta insynuacja. O ile pamiętam, nie
zajmowałem stanowiska w Waszej dyskusji. Nie rozumiem więc,
co znaczy że "się zgadzam" -- gdzie się zgadzam, z czym?
Proszę zacytować - w którym miejscu wypowiadałem się
na temat "co gdzie jest, a co nie jest stosowane",
zgadzając się tym samym z jakąś opinią...?
Maciek
W.Kotwica
> Pan W.Kotwica napisał:
>
>>> Zamiast? Dlaczego "zamiast"? Chodzi o przestrzeganie reguł,
>>> nie o dowolność.
>>
>> Reguły bezwzględnej, uniwersalnej dla każdego systemu nie ma.
>> Dlatego "zamiast", bo w systemach uniksowych jest właściwa
>> im "reguła LF",
>
> ...do zapisywania plików tekstowych.
O tym właśnie dyskutujemy. Przecież nie o występowaniu bądź niewystępowaniu
pary CR+LF w plikach binarnych różnych systemów. Ani o protokołach wymiany
informacji *pomiędzy* różnymi systemami.
>> więc stosowanie CR+LF jest używaniem "obcego" znacznika zamiast
>> typowego dla danego systemu.
>
> ...albo dostosowaniem się do protokołu transmisyjnego, czy też choćby
> do sposobu działania drukarki.
Uważa Pan, że wymiana danych z inną maszyną, o innym zapewne systemie
lub przesyłanie danych do drukarki za przykład "kończenia linii parą
CR+LF *w* *systemie* uniksowym"? Czyżby nasza rozmowa, z powodu traktowania
o cechach systemów operacyjnych, więc na temat właściwy raczej dla p.c.o.a.,
miała zejść na poziom argumentacji WO?
> [...RFC oraz inne pytania i prośby o komentarz...]
>> Ale owszem, w pytaniu chodziło mi o przykłady programów uniksowych,
>> które używają CR+LF na końcach wiersza, zamiast przyjętego w ich
>> systemie LF.
>>
>>> to telnetd będzie dobrym przykładem.
>>
>> Nigdy z niego nie korzystałem,
>
> To akurat ma małe znaczenie dla jakości przykładu.
Owszem, nie ma wcale. Ma natomiast znaczenie to, że telnetd nie służy
do zapisywania i odczytywania plików tekstowych w systemie. Czyli jest
nie na temat, niczego nie dowodzi.
> Nie wiem z czego Pan korzysta, ale weźmy następny z brzegu przykład.
> Protokół SMTP. Zaraz się pewnie dowiem, że tak pisać nie należy,
> bo SMTP to Simple Mail Transport Protocol (z pewnością wszyscy
> subskrybenci pl.hum.polszczyzna świetnie znają rozwinięcie skrótu),
> ale co mi tam.
Dobry przykład przepowiedni zapobiegającej własnemu spełnieniu się.
Ad rem: SMTP jest, jak nazwa wskazuje, protokołem *transportu*,
przekazywania informacji, więc nic nie mówi na temat konwencji
zakańczania wierszy plików tekstowych w danym systemie.
Maciek zwrócił już Panu na to uwagę.
> W każdym razie z emaila korzystał Pan wielokrotnie.
Nigdy. Korzystałem tylko z e-maila.
> No to w takim razie raczy Pan sobie wystawić, że wszelkie erefce
> opisujące negocjację z serwerem pocztowym nakazują wprost kończenie
> wiersza (linii) sekwencją <CRLF>.
Nakazują robienie tego w plikach tekstowych systemu, ma Pan na myśli?
Panie Jarku, Pan mnie chyba zbyt nisko ocenia, próbując mi wmówić,
że "używanie w systemie OpenBSD znaku LF do kończenia wierszy" jest
nieprawdą, bo *BSD do komunikowania się ze "światem zewnętrznym"
używa pary CRLF.
>>> U mnie mcedit pokazuje na końcach wierszy w plikach dosowych znaczek
>>> "^M", czyli właśnie <LF>.
>>
>> 1. A u mnie nie pokazuje. Tak robił OTB w SuSE aż do 7.2 włącznie,
>> tak samo robi w Mandrake'u dziś.
>
> No to trzeba było od razu, że o SuSE czy Mandrake chodzi, a nie
> o mcedit.
Przepraszam, co Pan usiłuje w ten sposób powiedzieć?
Czy uważa Pan, że w SuSE lub Mandrake'u (w Debianie było, jeśli dobrze
pamiętam, tak samo) mcedit nie występuje? Czy też może zachowanie
mcedit świeżo po instalacji w powyższych systemach jest nietypowe
dla tego programu? Jest dla mnie oczywistym, że skoro mówimy o kończeniu
wierszy w *systemach*, to podajemy przykłady systemów, a nie programów
"jako takich", w oderwaniu od systemu. Chyba nie wysunie Pan jako kolejnego
swojego przykładu perla, tylko dlatego, że wersje dla DOS/Windows stosują
domyślną parę CR+LF, a implementacje dla systemów uniksowych LF?
> A byłby Pan łaskaw sprawdzić dla mnie, czy jeśli dopiszemy
> linijkę, to pojawi się też <CR><LF> na końcu?
Właśnie sprawdziłem. W nowym Mandrake, 10.1 Community, mcedit (4.6.0)
wyświetla tak, jak Pan napisał. Przepraszam. Ale przy edycji pliku
pochodzącego z DOS/Windows, z "^M" przed końcami wierszy, wstawione
przeze mnie nowe wiersze kończy zwyczajnie, pojedynczym znakiem LF.
Nawet jednak, gdyby było inaczej, gdyby w plikach z CR+LF zawsze dodawał
taką samą parę na zakończenie wierszy, to i tak dowodziłoby to tylko tego,
że mcedit (czy joe) potrafią poprawnie edytować pliki o końcach linii
oznakowanych niezgodnie z panującą w ich macierzystym systemie konwencją,
że rozumieją obcą konwencję i ją *również* potrafią się posługiwać.
Że mają *dodatkowo* taką możliwość, prócz domyślnego zachowania zgodnego
z konwencją przyjętą w systemie.
>>> Ale pomogę Panu
>> W czym?
> ...w znalezieniu przykładu.
Przykładu współczesnego *systemu*, innego niż systemy DOS/Windows,
w którym konwencją jest inne kończenie wierszy w plikach tekstowych
niż parą CR+LF. Proszę bardzo, nadal czekam na taki przykład.
>>> Co innego jednak miałem na myśli pisząc o swobodnym podchodzeniu
>>> do zaleceń RFC. Spotkałem się kiedyś z kodem programu, w którym jakiś
>>> młody gniewny pozamieniał wszystkie "\r\n" na "\n". Pozamieniał,
>>> bo sam tego nie wymyślił, skopiował tylko ogólnie znany zapis.
>>
>> Nie wiem, po co, skoro - jak zakładam - bez tej zmiany program działał
>> poprawnie.
>
> Nie przed zmianą, lecz po zmianie.
Więc dobrze zrobił, skoro naprawił.
> Najpierw jego autor zmienił (najprawdopodobniej z przyczyn niżej opisanych)
Czy było coś co Pana upoważniało do mniemania, że uczynił tak dlatego, iż
"Pewnie gdzieś przeczytał, że <CR><LF> od złego pochodzi, być może nawet,
że wymyślił to sam Bill Gates"? Chyba nie ma Pan zwyczaju przypisywania
innym rozmaitych motywów (w tym głupich) bez żadnych podstaw ku temu?
> włączając i częściowo modyfikując kod telnetd do swojego programu, który
> (między innymi) korzystał z protokołu telnet. A zmiana z "\n" na "\r\n",
> dokonana później w niektórych miejscach, istotnie pomogła.
Skoro pomogła, to dobrze zrobił poprawiając, bez względu na *nieznane*
nam powody, którymi się kierował.
>>> Umiejętności miał akurat tyle, że wiedział iż "taka konwencja występuje
>>> *tylko* w przypadku systemów DOS i Windows". Pewnie gdzieś przeczytał,
>>> że <CR><LF> od złego pochodzi, być może nawet, że wymyślił to sam Bill
>>> Gates. Trudno się dziwić, że ten program miał czasem trudności
>>> z komunikacją.
>>
>> Bardzo ładna opowiastka.
>
> Dziękuję. Dla mnie ważniejsze, że pouczająca.
A czegóż to naucza, skoro nie wiemy, z jakiego powodu ten programista
poprawiał w taki sposób, w jaki poprawiał?
>> Co ma wspólnego z *moimi* poglądami?
>
> A to poniżej...
Bardzo bym prosił o wskazanie wprost takiego związku. Bo Pańskie sugestie,
jakoby ta opowiastka w jakikolwiek sposób ilustrowała lub przypominała moje
poglądy lub wypowiedzi, są nieuzasadnione i obraźliwe dla mnie. Mam nadzieję,
że ująłem to wystarczająco jasno?
>>> Proszę mi nie mieć za złe, że zechciałem skorygować publicznie
>>> Pańskie poglądy na rzeczywistość
>>
>> Proszę wybaczyć, ale niczego Pan w moich poglądach nie skorygował.
>> Pańskie mniemanie o moich poglądach na temat CR+LF vs. LF było
>> i pozostaje wyłącznie mniemaniem. Nie wiem, skąd ono Panu do głowy
>> przyszło, bo z moich wypowiedzi nie sposób wysnuć o moich poglądach
>> takich wniosków, jakie Pan wysnuwa.
> [...]
>> Czyżbym kogoś wprowadzał w błąd? Bardzo proszę mi wskazać, jaką
>> konkretnie wypowiedzią.
>
> Na temat sekwencji <CR><LF>, że występuje ona *tylko* w przypadku
> systemów DOS i Windows. Chodziło mi o sprostowanie tego zabobonu.
> Hołdowanie przesądowi może mieć zgoła nieoczekiwane konsekwencje.
Po pierwsze, bardzo bym prosił, żeby nie zniekształcać mojej wypowiedzi.
Pisałem:
# "Znakiem" końca akapitu, a właściwie - znakiem końca linii - NIE
# jest "na PC" sekwencja #13+#10. Taka konwencja występuje *tylko*
# w przypadku systemów DOS i Windows.
Chyba nisko mnie Pan ceni, uważając, iżbym mógł twierdzić, że "*sekwencja*
<CR><LF> *występuje* tylko w DOS/Windows". Jestem przekonany, że taka
sekwencja występuje w naturze w wielu rozmaitych systemach, w plikach
binarnych niemal na pewno gdzieś się trafi.
Po drugie, nadal proszę o wykazanie, że jest to twierdzenie błędne, ba! -
przesąd i zabobon.
Bo na razie niczego podobnego Pan nie pokazał.
Dla skrócenia dyskusji: nawet jeśli np. w "Janosiku" pliki KEDU mają
połamane wiersze na znacznikach i wiersze te zawsze kończą się parą CR+LF,
nawet dla GNU/Linuksa, to co najwyżej oznacza to, że istnieją programy,
które, z różnych powodów, nie stosują się do konwencji obowiązującej
w danym systemie. Nie oznacza to, że *systemy* linuksowe posługują się
konwencją CR+LF do kończenia wierszy w plikach tekstowych.
>>> Grupę czyta młodzież, która się uczy, więc niech się od razu
>>> dobrze nauczy.
>>
>> Niech się uczy.
>
> Myśli Pan, że wezwania posłucha?
Myślę, że posłucha argumentów. Wezwania nie poparte argumentami puste są.
--
HQ
W.Kotwica
> PS.
> Czy szanowni potężni szermierze mogliby na marginesie
> swej ciekawej dyskusji wyjaśnić istotom podrzędnym,
Maćku... czyżbyśmy się gniewali? Nie uważam się za potężnego szermierza
w tej dziedzinie. Ani nawet za dobrego. Tym bardziej zdziwiło mnie, że
mój Szanowny Oponent, skądinąd znany z wielkiej wiedzy i wieloletniego
doświadczenia, wysuwa tak zaskakujące, rzekłbym nawet - kuriozalne tezy.
> jak w systematyce ceerów i elefów ująć fakt użycia
> samotnego <CR> do rozdzielania wierszy tekstu
> w mswordowych plikach .doc?
Aż zajrzałem do środka. Nie mam pojęcia, czemu tak zrobili. Pewnie
łatwiej im było analizować, jeśli to jeden znak kończy akapit,
a nie dwa. A LF nie wzięli, bo z wrogiego obozu? ;)
Ale mswordowe pliki .doc to nie są pliki tekstowe, prawda? Problem
kodowania informacji w plikach binarnych leży poza naszym tematem.
--
HQ
Maciek
Użytkownik "W.Kotwica" <wkot...@post.pl> napisał
w wiadomości news:cl7ljo$t8a$2...@atlantis.news.tpi.pl...
> Maciek napisał:
>
>> PS.
>> Czy szanowni potężni szermierze mogliby na marginesie
>> swej ciekawej dyskusji wyjaśnić istotom podrzędnym,
>
> Maćku... czyżbyśmy się gniewali?
Ależ skąd. Próbowałem tylko błysnąć, jak pewien
piosenkarz-żartowniś, zapowiadając na koncercie swą
piosenkę o wkładzie straży pożarnej w historię opery...
> Nie uważam się za potężnego szermierza
> w tej dziedzinie. Ani nawet za dobrego.
W dziedzinie komputerologii - może i nie.
Ale ja miałem na myśli Sztukę Dyskusji. :-)
>
>> jak w systematyce ceerów i elefów ująć fakt użycia
>> samotnego <CR> do rozdzielania wierszy tekstu
>> w mswordowych plikach .doc?
>
> Aż zajrzałem do środka.
Ciekaw(sk)ość ludzka nie ma granic, prawda?
> Nie mam pojęcia, czemu tak zrobili. Pewnie łatwiej
> im było analizować, jeśli to jeden znak kończy akapit,
> a nie dwa. A LF nie wzięli, bo z wrogiego obozu? ;)
Raczej zużyli go już do czego innego (ale nie wiem
do czego - też nie znam formatu DOC).
> Ale mswordowe pliki .doc to nie są pliki tekstowe, prawda?
Jak dla kogo, jak dla kogo.... ;-)
W zasadzie *system operacyjny* w ogóle nie zna pojęcia
"plik tekstowy". Plik jest tekstowy dla użytkownika.
A kryterium ZU wcale nie jest sposób zakodowania informacji
w pliku, tylko możliwość obróbki przy użyciu ulubionego
programu do redakcji tekstów.
> Problem kodowania informacji w plikach binarnych
> leży poza naszym tematem.
No ale właśnie nie ma znaku - znaku pisarskiego, symbolu
graficznego - "koniec wiersza". Koniec wiersza to abstrakt,
wynikający z przestrzennej organizacji napisu.
W pliku koniec wiersza właśnie JEST KODOWANY. :-))
Zresztą tak samo jak kodowane są litery i cyfry. I podobnie
jak litery i cyfry mogą być zapisywane różnymi kodami, koniec
wiersza może być zapisywany różnie.
Oczywiście *wygodniej* jest, gdy pliki w obrębie jednego
systemu zapisywane są w tym samym formacie (w szczególności:
z takim samym oznaczeniem końca wiersza), bo taka konwencja
ujmuje programistom zbędnej roboty i ułatwia życie
użytkownikom ich dzieł. Jednakże jest to tylko *konwecja*,
w żadnym razie nie immanentna cecha jakiegoś systemu
operacyjnego (czy rodziny systemów).
Coraz bardziej off-topic:
Nieświadomość w tej materii może czasem sporo kosztować.
Zwłaszcza gdy niewiedzę (lub niefrasobliwość) wykażą osóby
standaryzujące formaty wymiany informacji:
http://www.w3.org/TR/2001/NOTE-newline-20010314
Mniej oftopicznie - zob. dodatki w ww tekście:
http://www.w3.org/TR/2001/NOTE-newline-20010314#appa
http://www.w3.org/TR/2001/NOTE-newline-20010314#appb
Maciek
W.Kotwica
> Użytkownik "W.Kotwica" <wkot...@post.pl> napisał
> w wiadomości news:cl7ljo$t8a$2...@atlantis.news.tpi.pl...
>> Maćku... czyżbyśmy się gniewali?
>
> Ależ skąd. Próbowałem tylko błysnąć, jak pewien
> piosenkarz-żartowniś, zapowiadając na koncercie swą
> piosenkę o wkładzie straży pożarnej w historię opery...
Nie słyszałem, możesz opowiedzieć?
>> Nie uważam się za potężnego szermierza
>> w tej dziedzinie. Ani nawet za dobrego.
>
> W dziedzinie komputerologii - może i nie.
> Ale ja miałem na myśli Sztukę Dyskusji. :-)
To już nie mnie oceniać. Dziękuję.
>> Aż zajrzałem do środka.
>
> Ciekaw(sk)ość ludzka nie ma granic, prawda?
Ponoć kluczowa cecha ludzkiej inteligencji.
>> Ale mswordowe pliki .doc to nie są pliki tekstowe, prawda?
>
> Jak dla kogo, jak dla kogo.... ;-)
Niektórzy jako pliki sygnaturek podkładają czytnikowi msdoce
i dziwią się, że coś sygnaturki nie działają.
> W zasadzie *system operacyjny* w ogóle nie zna pojęcia
> "plik tekstowy". Plik jest tekstowy dla użytkownika.
Niezupełnie. Zobacz np. AUTOEXEC.BAT, Win.ini, /etc/fstab.
Żaden z nich nie jest "dla użytkownika".
> A kryterium ZU wcale nie jest sposób zakodowania informacji
> w pliku, tylko możliwość obróbki przy użyciu ulubionego
> programu do redakcji tekstów.
Pod warunkiem, że redaguje teksty - dokumenty.
Tekstowe pliki konfiguracyjne nie są dla ZU i tworzenie np.
WinStart.bat przy użyciu MS-Worda daje - mówimy o ZU! - bardzo
kiepskie rezultaty, podobnie jak utworzenie ~/.logout przy użyciu
Write'a z pakietu OpenOffice, nieprawdaż?
>> Problem kodowania informacji w plikach binarnych
>> leży poza naszym tematem.
>
> No ale właśnie nie ma znaku - znaku pisarskiego, symbolu
> graficznego - "koniec wiersza". Koniec wiersza to abstrakt,
> wynikający z przestrzennej organizacji napisu.
> W pliku koniec wiersza właśnie JEST KODOWANY. :-))
Jasne. Dodajmy, że istnieje skończona i niewielka liczba praktycznie
stosowanych konwencji kodowania końca wiersza w pliku.
> Oczywiście *wygodniej* jest, gdy pliki w obrębie jednego
> systemu zapisywane są w tym samym formacie (w szczególności:
> z takim samym oznaczeniem końca wiersza), bo taka konwencja
> ujmuje programistom zbędnej roboty i ułatwia życie
> użytkownikom ich dzieł.
I tak też jest. Programy-wyjątki, posługujące się innym końcem wiersza
w plikach tekstowych niż to przyjęte w danym systemie stanowią pewnie
mniej niż 1% wszystkich programów operujących na plikach tekstowych
w tym systemie.
> Jednakże jest to tylko *konwecja*,
Różnie to bywa. Ze zwyczajów, konwencji tworzą się standardy.
> w żadnym razie nie immanentna cecha jakiegoś systemu operacyjnego
> (czy rodziny systemów).
Zobaczmy :-)
POSIX jednoznacznie nakazuje <LF> jako jedyny właściwy znak końca linii
(wyróżnienia moje):
newline character
A character that in the output stream indicates that printing
should start at the beginning of the next line. The newline
is the character designated by '\n' in the C language.
line
A sequence of zero or more non-newline characters plus a terminating
newline *character*.
text file
A file that contains characters organised into one or more lines.
[...] The newline character referred to in this specification set
is **not** *some generic line separator*, but a *single* character;
files created on systems where they use multiple characters for ends
of lines are not portable to all XSI-conformant systems without some
translation process.
Wydaje mi się, że wszystkie współczesne systemu uniksopodobne dążą
zgodności ze standardem POSIX. Zatem używanie LF dla zakończenia
wierszy w plikach tekstowych jest immanentną cechą tej rodziny systemów.
Jeśli wolisz hiperprecyzyjnie: z pewnością jest to immanentna cecha
systemów POSIX-owych. Jeśli dobrze rozumiem, co nazywasz "immanentną
cechą systemu operacyjnego".
> Coraz bardziej off-topic:
>
> Nieświadomość w tej materii może czasem sporo kosztować.
> Zwłaszcza gdy niewiedzę (lub niefrasobliwość) wykażą osóby
> standaryzujące formaty wymiany informacji:
> http://www.w3.org/TR/2001/NOTE-newline-20010314
Hi, hi! Zapomnieli sobie o mainframe'ach.
> Mniej oftopicznie - zob. dodatki w ww tekście:
> http://www.w3.org/TR/2001/NOTE-newline-20010314#appa
> http://www.w3.org/TR/2001/NOTE-newline-20010314#appb
Ta druga tabelka powinna wystarczyć "młodzieży uczącej się".
Dzięki serdeczne.
--
HQ
Jarosław Sokołowski
>> ...do zapisywania plików tekstowych.
>
> O tym właśnie dyskutujemy. Przecież nie o występowaniu bądź niewystępowaniu
> pary CR+LF w plikach binarnych różnych systemów. Ani o protokołach wymiany
> informacji *pomiędzy* różnymi systemami.
Po pewnym doprecyzowaniu okazało się, że rzeczywiście o tym. No to jeszcze
w takim razie dodam, że ten protok..., no wie Pan, ten SMTP, miał już to
<CRLF> wtedy, gdy DOSa i Windows jeszcze nie było na świecie.
>>> więc stosowanie CR+LF jest używaniem "obcego" znacznika zamiast
>>> typowego dla danego systemu.
>>
>> ...albo dostosowaniem się do protokołu transmisyjnego, czy też
>> choćby do sposobu działania drukarki.
>
> Uważa Pan, że wymiana danych z inną maszyną, o innym zapewne
> systemie lub przesyłanie danych do drukarki za przykład
> "kończenia linii parą CR+LF *w* *systemie* uniksowym"?
Jako argument falsyfikujący stwierdzenie "Taka konwencja występuje
*tylko* w przypadku systemów DOS i Windows"? Oczywiście.
> Czyżby nasza rozmowa, z powodu traktowania o cechach systemów
> operacyjnych, więc na temat właściwy raczej dla p.c.o.a.,
> miała zejść na poziom argumentacji WO?
W takim razie powienien Pan mi na to odpowiedzieć "argment szmargument".
> Ad rem: SMTP jest, jak nazwa wskazuje, protokołem *transportu*,
> przekazywania informacji, więc nic nie mówi na temat konwencji
> zakańczania wierszy plików tekstowych w danym systemie.
> Maciek zwrócił już Panu na to uwagę.
Dodać jeszcze warto, że do czasu opracowania rozszerzeń MIMIE, służył
on wyłącznie do transportu *wiadomości tekstowych*. A te wiadomości,
o czym też już wspomniano, są teżpóźniej pokazywane z <CRLF>.
>> W każdym razie z emaila korzystał Pan wielokrotnie.
>
> Nigdy. Korzystałem tylko z e-maila.
Najprawdopodobiej oba systemy są zgodne ze sobą. Być może nieraz
czytając jakiś e-mail nie zdawał Pan sobie sprawy, że ktoś wysłał
go jako email. Można mieć różne zdania na ten temat, ale jedną
z "A note on email versus e-mail" może Pan przeczytać na przykład
tu: http://www-cs-faculty.stanford.edu/~knuth/email.html
>>>> U mnie mcedit pokazuje na końcach wierszy w plikach dosowych znaczek
>>>> "^M", czyli właśnie <LF>.
>>>
>>> 1. A u mnie nie pokazuje. Tak robił OTB w SuSE aż do 7.2 włącznie,
>>> tak samo robi w Mandrake'u dziś.
>>
>> No to trzeba było od razu, że o SuSE czy Mandrake chodzi, a nie
>> o mcedit.
>
> Przepraszam, co Pan usiłuje w ten sposób powiedzieć?
> Czy uważa Pan, że w SuSE lub Mandrake'u (w Debianie było, jeśli dobrze
> pamiętam, tak samo) mcedit nie występuje? Czy też może zachowanie
> mcedit świeżo po instalacji w powyższych systemach jest nietypowe
> dla tego programu?
Dlatego prosiłem o wykonanie testu.
> Jest dla mnie oczywistym, że skoro mówimy o kończeniu wierszy w
> *systemach*, to podajemy przykłady systemów, a nie programów "jako
> takich", w oderwaniu od systemu. Chyba nie wysunie Pan jako kolejnego
> swojego przykładu perla, tylko dlatego, że wersje dla DOS/Windows stosują
> domyślną parę CR+LF, a implementacje dla systemów uniksowych LF?
A stosują? Czy 'print "foo\n"' w dosowym perlu zrobi coś innego niż
w uniksowym? Podobno w Usenecie można się wielu ciekawych rzeczy
dowiedzieć, więc skorzystam z okazji i zapytam.
>> A byłby Pan łaskaw sprawdzić dla mnie, czy jeśli dopiszemy
>> linijkę, to pojawi się też <CR><LF> na końcu?
>
> Właśnie sprawdziłem. W nowym Mandrake, 10.1 Community, mcedit (4.6.0)
> wyświetla tak, jak Pan napisał. Przepraszam. Ale przy edycji pliku
> pochodzącego z DOS/Windows, z "^M" przed końcami wierszy, wstawione
> przeze mnie nowe wiersze kończy zwyczajnie, pojedynczym znakiem LF.
No to dobrze robi. Już się obawiałem, że i tam dotarli młodzi gniewni.
> Nawet jednak, gdyby było inaczej, gdyby w plikach z CR+LF zawsze dodawał
> taką samą parę na zakończenie wierszy, to i tak dowodziłoby to tylko tego,
> że mcedit (czy joe) potrafią poprawnie edytować pliki o końcach linii
> oznakowanych niezgodnie z panującą w ich macierzystym systemie konwencją,
> że rozumieją obcą konwencję i ją *również* potrafią się posługiwać.
> Że mają *dodatkowo* taką możliwość, prócz domyślnego zachowania zgodnego
> z konwencją przyjętą w systemie.
A czy też Pan zauważył to samo co i ja? Jakoś ostatnio się te wszystkie
systemy uprzejme porobiły. Specjalnie poszedłem zobaczyć jak to jest
w MS Office XP. Gdym mu kazał zapisać coś w pliku tekstowym, to
zaproponował kurtuazyjnie, by na końcach każdego wiersza było gołe <LF>.
Proponował też <CRLF> i <CR>, a nawet <LFCR>, żadnego jednak nie wyróżniał.
>>> Nie wiem, po co, skoro - jak zakładam - bez tej zmiany program działał
>>> poprawnie.
>>
>> Nie przed zmianą, lecz po zmianie.
>
> Więc dobrze zrobił, skoro naprawił.
Nie naprawił a zepsuł. Zmiany były dwie. W obie strony. Ta pierwsza
z <CRLF> na <LF>.
>> Najpierw jego autor zmienił (najprawdopodobniej z przyczyn niżej opisanych)
> Czy było coś co Pana upoważniało do mniemania, że uczynił tak dlatego, iż
> "Pewnie gdzieś przeczytał, że <CR><LF> od złego pochodzi, być może nawet,
> że wymyślił to sam Bill Gates"? Chyba nie ma Pan zwyczaju przypisywania
> innym rozmaitych motywów (w tym głupich) bez żadnych podstaw ku temu?
Nie, skąd. Ma Pan jakiś motyw by mi taki zwyczaj przypisać?
>> A zmiana z "\n" na "\r\n", dokonana później w niektórych miejscach,
>> istotnie pomogła.
>
> Skoro pomogła, to dobrze zrobił poprawiając, bez względu na *nieznane*
> nam powody, którymi się kierował.
Nie wiem czemu nagle zaczął Pan o mnie w trzeciej osobie pisać. Nie wiem
też czemu pisze Pan o *nas* -- akurat między *mną* a *Panem* są istotne
różnice, choćby w znajomości rzeczonych powodów.
[...legenda o powstaniu ceerelefów...]
>>> Bardzo ładna opowiastka.
>> Dziękuję. Dla mnie ważniejsze, że pouczająca.
>
> A czegóż to naucza, skoro nie wiemy, z jakiego powodu ten
> programista poprawiał w taki sposób, w jaki poprawiał?
Naucza choćby tego, by czytać dokładnie.
[...gusła, zabobony i podania ludowe...]
> Pisałem:
> # "Znakiem" końca akapitu, a właściwie - znakiem końca linii - NIE
> # jest "na PC" sekwencja #13+#10. Taka konwencja występuje *tylko*
> # w przypadku systemów DOS i Windows.
> Chyba nisko mnie Pan ceni, uważając, iżbym mógł twierdzić, że "*sekwencja*
> <CR><LF> *występuje* tylko w DOS/Windows". Jestem przekonany, że taka
> sekwencja występuje w naturze w wielu rozmaitych systemach, w plikach
> binarnych niemal na pewno gdzieś się trafi.
To może trzeba było jasno i wyraźnie napisać, że konwencji i konwenansów
systemowych rzecz się tyczy. Tymczasem Pan o unikalności ceerelefa pisał,
podkreślając jeszcze słowo *tylko*, jakby to o jakiś kwiat paproci chodziło.
[...zbójecka argumentacja ciupagą przeze mnie wycięta...]
[...na temat młodzieży chowania rzeczy pospolite...]
>>> Niech się uczy.
>> Myśli Pan, że wezwania posłucha?
> Myślę, że posłucha argumentów. Wezwania nie poparte argumentami puste są.
A jakeż tu można mieć argumenta? Są dwie szkoły na ten temat, ja z tej
jestem, która mówi, że jak się uczyć nie zechce, to się uczyć nie będzie.
Żaden argument tu na nic. Wezwania, prośby i groźby takoż. Taka to już
ta (dzisiejsza) młodzież jest. Chyba żeby im przykładem w oczy zaświecić,
wtedy to co innego.
--
Jarek
Jarosław Sokołowski
>> Nie wiem z czego Pan korzysta, ale weźmy następny z brzegu przykład.
>> Protokół SMTP. Zaraz się pewnie dowiem, że tak pisać nie należy,
>> bo SMTP to Simple Mail Transport Protocol (z pewnością wszyscy
>> subskrybenci pl.hum.polszczyzna świetnie znają rozwinięcie skrótu),
>> ale co mi tam. W każdym razie z emaila korzystał Pan wielokrotnie.
>> No to w takim razie raczy Pan sobie wystawić, że wszelkie erefce
>> opisujące negocjację z serwerem pocztowym nakazują wprost kończenie
>> wiersza (linii) sekwencją <CRLF>.
>
> Przepraszam - jaki to ma związek z tematem?
Z którym tematem? O tych akapitach, co to ani nie wiadomo jak jest,
ani jak byc powinno? Żaden. A może z tym, co jest o tym, czy bez
zaglądania w zęby, po samych ceerelefach jeno, można rozpoznać jaki
to system operacyjny?
> Protokół komunikacyjny z definicji służy do komunikacji.
> Czyli wymiany wiadomości. Oczywiście (w tym przypadku)
> z INNYM komputerem. Zatem fakt przyjęcia takiej czy innej
> konwecji w protokole nie ma ABSOLUTNIE NIC wspólnego
> ze stosowaniem "w komputerze" PC czy iMac, albo "w systemie"
> DOS, Unix, Windows *.*, MacOS czy jakimkolwiek innym.
A, więc to tak, to jednak można. Wiarę w człowieka mi Pan wraca,
Panie Maćku, tak ostatnio mocno nadszarpniętą. To i ja mogę napisać
coś, z czego da się zrozumieć, że gdy ktoś zoczy gdzieś <CRLF>, to
wcale nie będzie znaczyło, że w pobliżu czai się DOS z Windowsem,
tylko że taką to właśnie sekwencję w Uczonych Księgach zapisano
i wszędy stosować polecono.
> Maciek
-- Jarek
> PS.
> Czy szanowni potężni szermierze mogliby na marginesie swej ciekawej
> dyskusji wyjaśnić istotom podrzędnym, jak w systematyce ceerów
> i elefów ująć fakt użycia samotnego <CR> do rozdzielania wierszy
> tekstu w mswordowych plikach .doc?
Agdzieżbytam. Ja tam docom do środka zaglądać nie zamierzam.
--
...a Puccini wsłuchany uśmiechał się bosko,
bo w tym czasie akurat pracował nad Toscą...
[W.Młynarski]
W.Kotwica
> Pan W.Kotwica napisał:
>
>>> ...do zapisywania plików tekstowych.
>>
>> O tym właśnie dyskutujemy. Przecież nie o występowaniu bądź
>> niewystępowaniu pary CR+LF w plikach binarnych różnych systemów.
>> Ani o protokołach wymiany informacji *pomiędzy* różnymi systemami.
>
> Po pewnym doprecyzowaniu okazało się, że rzeczywiście o tym.
Jakoś poniżej zdaje się Pan być innego zdania. Ale może się mydlę.
>> Uważa Pan, że wymiana danych z inną maszyną, o innym zapewne
>> systemie lub przesyłanie danych do drukarki za przykład
>> "kończenia linii parą CR+LF *w* *systemie* uniksowym"?
>
> Jako argument falsyfikujący stwierdzenie "Taka konwencja występuje
> *tylko* w przypadku systemów DOS i Windows"? Oczywiście.
Uważa Pan wysyłanie CR+LF do drukarki XYZ za przykład konwencji
obowiązującej *wewnątrz* danego *systemu operacyjnego*? Jestem
zdumiony.
>> Czyżby nasza rozmowa, z powodu traktowania o cechach systemów
>> operacyjnych, więc na temat właściwy raczej dla p.c.o.a.,
>> miała zejść na poziom argumentacji WO?
>
> W takim razie powienien Pan mi na to odpowiedzieć "argment szmargument".
Argument szmargument.
>> Ad rem: SMTP jest, jak nazwa wskazuje, protokołem *transportu*,
>> przekazywania informacji, więc nic nie mówi na temat konwencji
>> zakańczania wierszy plików tekstowych w danym systemie.
>> Maciek zwrócił już Panu na to uwagę.
>
> Dodać jeszcze warto, że do czasu opracowania rozszerzeń MIMIE,
> służył on wyłącznie do transportu *wiadomości tekstowych*.
Tak, ICTZ? Wiadomości tekstowe są zapisywane w danym systemie
jako pliki tekstowe. Ze znacznikami końca wiersza właściwymi
dla tego systemu, o ile zauważyłem.
> A te wiadomości, o czym też już wspomniano, są teżpóźniej
> pokazywane z <CRLF>.
Doprawdy? No pacz Pan, a u mnie wiadomości są zapisywane albo
z gołym LF na końcu, albo z CR+LF, w zależności od tego, czy
odbiorę na Windows, czy na Linuksie.
>>> W każdym razie z emaila korzystał Pan wielokrotnie.
>>
>> Nigdy. Korzystałem tylko z e-maila.
>
> Najprawdopodobiej oba systemy są zgodne ze sobą. Być może nieraz
> czytając jakiś e-mail nie zdawał Pan sobie sprawy, że ktoś wysłał
> go jako email. Można mieć różne zdania na ten temat, ale jedną
> z "A note on email versus e-mail" może Pan przeczytać na przykład
> tu: http://www-cs-faculty.stanford.edu/~knuth/email.html
Przykro, mi, ale Knuth nie jest dla mnie w sprawach językowych
takim autorytetem, jak dla Pana.
>> Jest dla mnie oczywistym, że skoro mówimy o kończeniu wierszy w
>> *systemach*, to podajemy przykłady systemów, a nie programów "jako
>> takich", w oderwaniu od systemu. Chyba nie wysunie Pan jako kolejnego
>> swojego przykładu perla, tylko dlatego, że wersje dla DOS/Windows stosują
>> domyślną parę CR+LF, a implementacje dla systemów uniksowych LF?
>
> A stosują? Czy 'print "foo\n"' w dosowym perlu zrobi coś innego niż
> w uniksowym? Podobno w Usenecie można się wielu ciekawych rzeczy
> dowiedzieć, więc skorzystam z okazji i zapytam.
Owszem. Perl dla DOS/Windows na 'print "foo\n"' wysyła na swoje
wyjście "foo" plus parę znaków: CR i LF, podczas gdy na Linuksie
wysyła "foo" plus jeden znak - LF. Coś nie tak?
(Bardzo proszę o niewyciąganie $/).
>>> A byłby Pan łaskaw sprawdzić dla mnie, czy jeśli dopiszemy
>>> linijkę, to pojawi się też <CR><LF> na końcu?
>>
>> Właśnie sprawdziłem. W nowym Mandrake, 10.1 Community, mcedit (4.6.0)
>> wyświetla tak, jak Pan napisał. Przepraszam. Ale przy edycji pliku
>> pochodzącego z DOS/Windows, z "^M" przed końcami wierszy, wstawione
>> przeze mnie nowe wiersze kończy zwyczajnie, pojedynczym znakiem LF.
>
> No to dobrze robi.
Dobrze robi. Ale równocześnie oznacza to, że w tej swojej, domyślnej
konfiguracji NIE posługuje się konwencją <CR><LF>, tylko trzyma się
tego, co przyjęto w systemie. QED.
> Już się obawiałem, że i tam dotarli młodzi gniewni.
Powinien Pan napisać "pryszczersi podniecający się kernelowaniem kompili".
>> Nawet jednak, gdyby było inaczej, gdyby w plikach z CR+LF zawsze dodawał
>> taką samą parę na zakończenie wierszy, to i tak dowodziłoby to tylko tego,
>> że mcedit (czy joe) potrafią poprawnie edytować pliki o końcach linii
>> oznakowanych niezgodnie z panującą w ich macierzystym systemie konwencją,
>> że rozumieją obcą konwencję i ją *również* potrafią się posługiwać.
>> Że mają *dodatkowo* taką możliwość, prócz domyślnego zachowania zgodnego
>> z konwencją przyjętą w systemie.
>
> A czy też Pan zauważył to samo co i ja? Jakoś ostatnio się te wszystkie
> systemy uprzejme porobiły. Specjalnie poszedłem zobaczyć jak to jest
> w MS Office XP. Gdym mu kazał zapisać coś w pliku tekstowym, to
> zaproponował kurtuazyjnie, by na końcach każdego wiersza było gołe <LF>.
Niemożliwe? Świat się kończy!
(Na oczy nie widziałem MSO XP, ale skłonny jestem uwierzyć).
> Proponował też <CRLF> i <CR>, a nawet <LFCR>, żadnego jednak
> nie wyróżniał.
Widać w M$ (nie jesteśmy na pcoa, więc nie muszę przydeptywać gardła...)
za słabo weryfikują przyjmowanych ludzi.
>>>> Nie wiem, po co, skoro - jak zakładam - bez tej zmiany program działał
>>>> poprawnie.
>>>
>>> Nie przed zmianą, lecz po zmianie.
>>
>> Więc dobrze zrobił, skoro naprawił.
>
> Nie naprawił a zepsuł. Zmiany były dwie. W obie strony. Ta pierwsza
> z <CRLF> na <LF>.
Pan wybaczy, ale czy nie można było od początku tego napisać?
>>> Najpierw jego autor zmienił (najprawdopodobniej z przyczyn niżej
>>> opisanych)
>> Czy było coś co Pana upoważniało do mniemania, że uczynił tak dlatego, iż
>> "Pewnie gdzieś przeczytał, że <CR><LF> od złego pochodzi, być może nawet,
>> że wymyślił to sam Bill Gates"? Chyba nie ma Pan zwyczaju przypisywania
>> innym rozmaitych motywów (w tym głupich) bez żadnych podstaw ku temu?
>
> Nie, skąd. Ma Pan jakiś motyw by mi taki zwyczaj przypisać?
Z Pańskiej relacji wynika, że "najprawdopodobniej" jest czystym mniemaniem,
nie popartym żadną przesłanką prócz tego, że istnieją "młodzi gniewni, acz
niemądrzy". Odnoszę też z Pańskich listów nieodparte wrażenie, że wlicza
mnie Pan w nich w grono owych młodych gniewnych, dla których "Window$ ssie,
Linux rulez!", i dlatego usiłuje wyprowadzać mnie z mniemanych błędów.
(Och, wiem, jak w WO-dyskusji odpiera się zarzut o insynuowanie, nie musimy
się w to bawić).
>>> A zmiana z "\n" na "\r\n", dokonana później w niektórych miejscach,
>>> istotnie pomogła.
>>
>> Skoro pomogła, to dobrze zrobił poprawiając, bez względu na *nieznane*
>> nam powody, którymi się kierował.
>
> Nie wiem czemu nagle zaczął Pan o mnie w trzeciej osobie pisać. Nie wiem
> też czemu pisze Pan o *nas* -- akurat między *mną* a *Panem* są istotne
> różnice, choćby w znajomości rzeczonych powodów.
Przepraszam, ale z Pańskiej relacji nie wynika, żeby Pan te jego powody
znał, a wręcz przeciwnie ("pewnie gdzieś przeczytał..."). Zatem uzasadnionym
było przyjęcie przeze mnie, że nasza wiedza na temat szczegółów jego wiedzy
i powodów jest jednako zerowa.
> [...legenda o powstaniu ceerelefów...]
>>>> Bardzo ładna opowiastka.
>>> Dziękuję. Dla mnie ważniejsze, że pouczająca.
>>
>> A czegóż to naucza, skoro nie wiemy, z jakiego powodu ten
>> programista poprawiał w taki sposób, w jaki poprawiał?
>
> Naucza choćby tego, by czytać dokładnie.
Jakoś nie dojrzałem w niej tego morału. Zechce Pan palcem wskazać
zdanie, które mówi o tym, że ów programista czytał niedokładnie
i dlatego pobłądził?
> [...gusła, zabobony i podania ludowe...]
>> Pisałem:
>> # "Znakiem" końca akapitu, a właściwie - znakiem końca linii - NIE
>> # jest "na PC" sekwencja #13+#10. Taka konwencja występuje *tylko*
>> # w przypadku systemów DOS i Windows.
>> Chyba nisko mnie Pan ceni, uważając, iżbym mógł twierdzić, że "*sekwencja*
>> <CR><LF> *występuje* tylko w DOS/Windows". Jestem przekonany, że taka
>> sekwencja występuje w naturze w wielu rozmaitych systemach, w plikach
>> binarnych niemal na pewno gdzieś się trafi.
>
> To może trzeba było jasno i wyraźnie napisać, że konwencji i konwenansów
> systemowych rzecz się tyczy.
Bardzo proszę o dostrzeżenie w wyżej zamieszczonym cytacie z mojego listu,
oznakowanym ">>#", słowa "konwencja" oraz słowa "systemy". Ta historyjka
dobrze ilustruje naukę, że należy czytać dokładnie, mam nadzieję?
> [...na temat młodzieży chowania rzeczy pospolite...]
>
>> Myślę, że posłucha argumentów. Wezwania nie poparte argumentami puste są.
>
> A jakeż tu można mieć argumenta? Są dwie szkoły na ten temat, ja z tej
> jestem, która mówi, że jak się uczyć nie zechce, to się uczyć nie będzie.
> Żaden argument tu na nic. Wezwania, prośby i groźby takoż.
Ani chybi.
> Taka to już ta (dzisiejsza) młodzież jest. Chyba żeby im przykładem
> w oczy zaświecić, wtedy to co innego.
Wiele nie pomoże. Łatwo bowiem znaleźć kontrprzykłady w oczy świecące,
jak niedouczeni dobrze się mają i pną się w górę, decydują, choćby
i nie najmądrzej, mimo że douczonych w okolicach nie brakuje.
Sądzę, że czytelnicy pl.hum.polszczyzna są znużeni tym wątkiem,
dopuszczalna pozatematyczność ma tutaj inne granice niż na pcoa
czy sf-f.
--
HQ
Maciek
Użytkownik "W.Kotwica" <wkot...@post.pl> napisał
w wiadomości news:cl80u2$qsq$1...@atlantis.news.tpi.pl...
> Maciek napisał:
>
>> Użytkownik "W.Kotwica" <wkot...@post.pl> napisał
>> w wiadomości news:cl7ljo$t8a$2...@atlantis.news.tpi.pl...
>>> Maćku... czyżbyśmy się gniewali?
>>
>> Ależ skąd. Próbowałem tylko błysnąć, jak pewien
>> piosenkarz-żartowniś, zapowiadając na koncercie swą
>> piosenkę o wkładzie straży pożarnej w historię opery...
>
> Nie słyszałem, możesz opowiedzieć?
W roku 1971, recital Wojciecha Młynarskiego - Internet
zeznaje, iż było to w Sali Kameralnej Filharmonii Narodowej.
Przedstawiając jednego z bohaterów "Ballady o strażaku
z opery" W.M. wtrącił (cytuję z nieco już dziurawej pamięci):
"....Giaccomo Puccini - tutaj może erudycją błysnę:
autor między innymi oper Madame Butterfly [pół
sekundy wahania]... Tosca [sekunda wahania]...
Cyganeria [półtorej]... et cetera [i teraz
szybciutko] (zawsze cztery tytuły wymieniłem!)
- otóż pan Puccini........."
Gdybym Ci to opowiedział na żywo, to już by straciło
połowę uroku, jaki miało w wykonaniu W.Młynarskiego.
A tak, przez usenet, z tymi didaskaliami, to nie wiem
czy się choć pięć procent ostało.
No ale starałem się, jak umiałem.
Maciek
PS
"Mało caszu, kruca bomba" się mi zrobiło z tego, jakmutam...
z Nienacka. Więc na resztę odpowiem osobno, troszkę później.
Jarosław Sokołowski
> Uważa Pan wysyłanie CR+LF do drukarki XYZ za przykład konwencji
> obowiązującej *wewnątrz* danego *systemu operacyjnego*? Jestem
> zdumiony.
W jeszcze większe zdumienie może wprawić pogląd, że sprawę występowania
czegoś bądź nie, można ograniczyć tylko do wewnętrznych spraw systemu.
> Argument szmargument.
[...o wiadomościach przekazywanych via SMTP...]
> Tak, ICTZ? Wiadomości tekstowe są zapisywane w danym systemie
> jako pliki tekstowe. Ze znacznikami końca wiersza właściwymi
> dla tego systemu, o ile zauważyłem.
Mało Pan spostrzegawczy. W czasie mojej ostatniej wizytacji systemu
XP zauważyłem, że do odbioru i odczytywania wiadomości uzywany jest
tam jakiś dziwaczny program, co się chyba Outlook nazywa. Zajrzałem
do pliku, w którym on owe wiadomości przechowuje. Gdyby maił Pan kiedyś
nastrój na samoumartwienie, polecam to samo.
>> A te wiadomości, o czym też już wspomniano, są teżpóźniej
>> pokazywane z <CRLF>.
>
> Doprawdy? No pacz Pan, a u mnie wiadomości są zapisywane albo
> z gołym LF na końcu, albo z CR+LF, w zależności od tego, czy
> odbiorę na Windows, czy na Linuksie.
...a gdy dochodzi do wyświetlenia ich na terminalu, to już niekoniecznie.
> Przykro, mi, ale Knuth nie jest dla mnie w sprawach językowych
> takim autorytetem, jak dla Pana.
E tam od razu autorytetem. Na pl.hum.polszczyzna też raczej nie
napisze, bo nasz język jest mu obcym. A tendencja do uwsteczniania
się niepotrzebnej kreseczki akurat mi się podoba. Proszę zauważyć,
że sprytnie udało nam się nawiązać do tematyki grupy.
> Perl dla DOS/Windows na 'print "foo\n"' wysyła na swoje wyjście
> "foo" plus parę znaków: CR i LF, podczas gdy na Linuksie wysyła
> "foo" plus jeden znak - LF. Coś nie tak?
> (Bardzo proszę o niewyciąganie $/).
Niczego wyciągał nie będę, zwłaszcza $$, bom człowiek oszczędny.
Perlistych skryptów w Windows nigdy nie używałem, więc pozostaje
mi tylkko przyjąć informację do wiadomości.
[...mcedit i Mandrake...]
>> Już się obawiałem, że i tam dotarli młodzi gniewni.
> Powinien Pan napisać "pryszczersi podniecający się kernelowaniem kompili".
Trzymałem się poprzednio przyjętej nomenklatury. A tu i tak lepiej by
paswało "grepowaniem gzipów".
>> Specjalnie poszedłem zobaczyć jak to jest w MS Office XP. Gdym mu kazał
>> zapisać coś w pliku tekstowym, to zaproponował kurtuazyjnie, by na
>> końcach każdego wiersza było gołe <LF>.
>
> Niemożliwe? Świat się kończy!
> (Na oczy nie widziałem MSO XP, ale skłonny jestem uwierzyć).
[...]
> Widać w M$ (nie jesteśmy na pcoa, więc nie muszę przydeptywać
> gardła...) za słabo weryfikują przyjmowanych ludzi.
Ha, powiem Panu jeszcze, że zaproponował mi aby plik był zakodowany
zgodnie z ISO-8858-2.
[...wyczyny programistów...]
> Pan wybaczy, ale czy nie można było od początku tego napisać?
A tak, w końcu sam sobie napisałem to od początku.
> Odnoszę też z Pańskich listów nieodparte wrażenie, że wlicza mnie Pan
> w nich w grono owych młodych gniewnych, dla których "Window$ ssie,
> Linux rulez!", i dlatego usiłuje wyprowadzać mnie z mniemanych błędów.
> (Och, wiem, jak w WO-dyskusji odpiera się zarzut o insynuowanie, nie
> musimy się w to bawić).
No to weźżesz je Pan i odeprzyj sobie wreszcie. Taki skory do
szufladkowania to ja nie jestem.
>> [...gusła, zabobony i podania ludowe...]
>>> Pisałem:
>>> # "Znakiem" końca akapitu, a właściwie - znakiem końca linii - NIE
>>> # jest "na PC" sekwencja #13+#10. Taka konwencja występuje *tylko*
>>> # w przypadku systemów DOS i Windows.
>>> Chyba nisko mnie Pan ceni, uważając, iżbym mógł twierdzić, że "*sekwencja*
>>> <CR><LF> *występuje* tylko w DOS/Windows". Jestem przekonany, że taka
>>> sekwencja występuje w naturze w wielu rozmaitych systemach, w plikach
>>> binarnych niemal na pewno gdzieś się trafi.
>>
>> To może trzeba było jasno i wyraźnie napisać, że konwencji i konwenansów
>> systemowych rzecz się tyczy.
>
> Bardzo proszę o dostrzeżenie w wyżej zamieszczonym cytacie z mojego listu,
> oznakowanym ">>#", słowa "konwencja" oraz słowa "systemy". Ta historyjka
> dobrze ilustruje naukę, że należy czytać dokładnie, mam nadzieję?
Nadzieję zawsze mieć warto. Warto też, tak jak i czytać, to i pisać
dokładnie. Bo skąd niby tu wiadomo, że o konwencję zapisu w plikach
chodzi, nie o co inne? Choćby o konwencję, jako się rzekło, wymiany
danych po drucie.
> Sądzę, że czytelnicy pl.hum.polszczyzna są znużeni tym wątkiem,
> dopuszczalna pozatematyczność ma tutaj inne granice niż na pcoa
> czy sf-f.
Znużeni? A to jakim sposobem? Ja to sobie myślałem, że nas wszyscy
już powsadzali na dno swoich kaefów i nic sobie z naszej pisaniny
nie robią. Ale może się mylę.
--
Jarek