---

Hej,

Jeg har et irriterende problem... Når jeg åbner nogle af mine filer som
jeg måske på et tidspunkt har gemt på en windows-pc (kan ikke huske), er
der en masse ^M'er i slutningen af linjen for "return".

SVJH er det noget med at man afslutter linjer med ascii-koder 10+ 13/14
i det ene operativsystem og kun med ascii kode 10 i det andet. Hvis
nogen lige kan forklare problemet og ridse det op, ville det være fint.

Dernæst har jeg søgt lidt på nettet - jeg mangler dos2unix og unix2dos
på mit system men det ser ud til at man kan:

http://kb.iu.edu/data/acux.html

http://www.macosxhints.com/article.php?story=20031018164326986

Jeg har ikke testet men hvad vil i foreslå og virker det som står på
begge links lige godt eller?

Grunden til at jeg spørger, er at jeg vil gerne finde den "bedste"
løsning på problemet, så jeg ved lige nøjagtigt hvad jeg skal gøre i
fremtiden og i øjeblikket er jeg lidt forvirret... Men Windows "notepad"
og "write"/"wordpad" de "æder" vist alt, vil jeg tro. Hvadenten der står
ascii kode 10 eller 10+13/14 - er det ikke korrekt?


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Sat, 25 Feb 2006 14:40:48 +0100 skrev Martin Jørgensen:
> Hej,
>
> Jeg har et irriterende problem... Når jeg åbner nogle af mine filer som
> jeg måske på et tidspunkt har gemt på en windows-pc (kan ikke huske), er
> der en masse ^M'er i slutningen af linjen for "return".
>
> SVJH er det noget med at man afslutter linjer med ascii-koder 10+ 13/14
> i det ene operativsystem og kun med ascii kode 10 i det andet. Hvis
> nogen lige kan forklare problemet og ridse det op, ville det være fint.

Windows bruger 13 + 10 (CR LF), *nix bruger 10 (LF) - og Mac[1] bruger
vistnok 13 (CR), for nu at få alle kombinationer med.

> Dernæst har jeg søgt lidt på nettet - jeg mangler dos2unix og unix2dos
> på mit system men det ser ud til at man kan:
>
> http://kb.iu.edu/data/acux.html
>
> http://www.macosxhints.com/article.php?story=20031018164326986
>
> Jeg har ikke testet men hvad vil i foreslå og virker det som står på
> begge links lige godt eller?

Alle metoderne gør det samme, de er bare ikke lige lange at skrive.

> Grunden til at jeg spørger, er at jeg vil gerne finde den "bedste"
> løsning på problemet, så jeg ved lige nøjagtigt hvad jeg skal gøre i
> fremtiden og i øjeblikket er jeg lidt forvirret... Men Windows "notepad"
> og "write"/"wordpad" de "æder" vist alt, vil jeg tro. Hvadenten der står
> ascii kode 10 eller 10+13/14 - er det ikke korrekt?

Nix. Åbnes en tekst-fil med unix-LF i Notepad, er teksten i en lang
linie, og hver gang der skulle have været et linieskift, viser notepad
en firkant. Write og Wordpad har jeg ikke forsøgt.

Personligt bruger jeg tr -d '^M' når jeg skal fjerne Windows CR (13)
fra en fil. Den anden vej har jeg sjældent brug for at flytte ting,
og når jeg endelig gør, er det typisk manuelt i notepad (cut'n'paste
en firkant ind i "søg", og bruge F3 til at finde den næste).

Mvh
Kent

[1] Er OSX så Mac eller Unix?
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Nix. Åbnes en tekst-fil med unix-LF i Notepad, er teksten i en lang
> linie, og hver gang der skulle have været et linieskift, viser notepad
> en firkant. Write og Wordpad har jeg ikke forsøgt.

Wordpad kan godt finde ud af at åbne filer med unix-linieskift. (Er
write ikke bare wordpad i en gammel Windows-version?)

/Andreas

---

Kent Friis wrote:
> Den Sat, 25 Feb 2006 14:40:48 +0100 skrev Martin Jørgensen:
-snip-

> Windows bruger 13 + 10 (CR LF), *nix bruger 10 (LF) - og Mac[1] bruger
> vistnok 13 (CR), for nu at få alle kombinationer med.

Kan i andre bekræfte eller afkræfte at dette er 100% korrekt?

Fordi så skriver jeg essensen af denne tråd ind i en "hjælpe-fil" til
mig selv, så jeg ikke glemmer hvad jeg skal gøre fremover...

-snip-
> Nix. Åbnes en tekst-fil med unix-LF i Notepad, er teksten i en lang
> linie, og hver gang der skulle have været et linieskift, viser notepad
> en firkant. Write og Wordpad har jeg ikke forsøgt.

Nåhja, det er vist rigtigt. Jeg har nogengange copy/pastet ind i wordpad
og bagefter ind i notepad for at undgå evt. formateringskoder, hvis jeg
vil have en ren tekstfil.

> Personligt bruger jeg tr -d '^M' når jeg skal fjerne Windows CR (13)
> fra en fil. Den anden vej har jeg sjældent brug for at flytte ting,
> og når jeg endelig gør, er det typisk manuelt i notepad (cut'n'paste
> en firkant ind i "søg", og bruge F3 til at finde den næste).
>
> Mvh
> Kent
>
> [1] Er OSX så Mac eller Unix?

Ja, hvem kan svare? Eller fortælle hvordan jeg finder ud af det? Kører
mest på en mac...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

On Sat, 25 Feb 2006 16:12:36 +0100, Martin Jørgensen wrote:

>
> Kan i andre bekræfte eller afkræfte at dette er 100% korrekt?
>
Det er det. Dog gælder Mac-udsagnet kun for old-world - altså MacOS < =
9. Husk også i den forbindelse: Mac old-world: 76 dpi, MS: 96dpi, X-old:
75 dpi

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen wrote:
> On Sat, 25 Feb 2006 16:12:36 +0100, Martin Jørgensen wrote:
>
>
>>Kan i andre bekræfte eller afkræfte at dette er 100% korrekt?
>>
>
> Det er det. Dog gælder Mac-udsagnet kun for old-world - altså MacOS < =
> 9. Husk også i den forbindelse: Mac old-world: 76 dpi, MS: 96dpi, X-old:
> 75 dpi

Hvorfor skriver du hvor mange dpi der bruges? Betyder det ikke dots per
inch og det kan da være bedøvende ligegyldigt eller hvad?


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

On Sun, 26 Feb 2006 10:42:29 +0100, Martin Jørgensen wrote:

>
> Hvorfor skriver du hvor mange dpi der bruges? Betyder det ikke dots per
> inch og det kan da være bedøvende ligegyldigt eller hvad?
>
jeg påpeger yderligere en anden væsentlig forskel, hvis man laver
hjemmesider.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Kent Friis wrote:
>
> Den Sat, 25 Feb 2006 14:40:48 +0100 skrev Martin Jørgensen:
> > Hej,
> >
> > Jeg har et irriterende problem... Når jeg åbner nogle af mine filer som
> > jeg måske på et tidspunkt har gemt på en windows-pc (kan ikke huske), er
> > der en masse ^M'er i slutningen af linjen for "return".
> >
> > SVJH er det noget med at man afslutter linjer med ascii-koder 10+ 13/14
> > i det ene operativsystem og kun med ascii kode 10 i det andet. Hvis
> > nogen lige kan forklare problemet og ridse det op, ville det være fint.
>
> Windows bruger 13 + 10 (CR LF), *nix bruger 10 (LF) - og Mac[1] bruger
> vistnok 13 (CR), for nu at få alle kombinationer med.

Det er korrekt. Og det bliver i øvrigt først rigtig sjovt når man
står med en fil med en kombination af alle tre slags linieskift.

Windows har arvet 13+10 fra DOS. Jeg ved ikke lige hvorfor de
ikke afskaffede den tåbelige konvention da tegnsættet alligevel
blev ændret ved overgangen fra DOS til Windows.

Der er i øvrigt nogle DOS programmer, der fejlagtigt har brugt
10+13 i stedet for 13+10. Den slags filer virkede i øvrigt
alligevel med nogle af de programmer, der var designet til 13+10.

>
> Nix. Åbnes en tekst-fil med unix-LF i Notepad, er teksten i en lang
> linie, og hver gang der skulle have været et linieskift, viser notepad
> en firkant. Write og Wordpad har jeg ikke forsøgt.

Der er i hvert fald en af standard editorerne på Windows, som automatisk
konverterer linieskift til Windows linieskift. Jeg tror det er Wordpad
som gør på den måde.

>
> [1] Er OSX så Mac eller Unix?

Ja, det er et godt spørgsmål. Mon ikke der er mange OSX programmer
der kan forstå begge formater.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Den Sun, 26 Feb 2006 12:09:58 +0100 skrev Kasper Dupont:
> Kent Friis wrote:
>>
>> Den Sat, 25 Feb 2006 14:40:48 +0100 skrev Martin Jørgensen:
>> > Hej,
>> >
>> > Jeg har et irriterende problem... Når jeg åbner nogle af mine filer som
>> > jeg måske på et tidspunkt har gemt på en windows-pc (kan ikke huske), er
>> > der en masse ^M'er i slutningen af linjen for "return".
>> >
>> > SVJH er det noget med at man afslutter linjer med ascii-koder 10+ 13/14
>> > i det ene operativsystem og kun med ascii kode 10 i det andet. Hvis
>> > nogen lige kan forklare problemet og ridse det op, ville det være fint.
>>
>> Windows bruger 13 + 10 (CR LF), *nix bruger 10 (LF) - og Mac[1] bruger
>> vistnok 13 (CR), for nu at få alle kombinationer med.
>
> Det er korrekt. Og det bliver i øvrigt først rigtig sjovt når man
> står med en fil med en kombination af alle tre slags linieskift.
>
> Windows har arvet 13+10 fra DOS. Jeg ved ikke lige hvorfor de
> ikke afskaffede den tåbelige konvention da tegnsættet alligevel
> blev ændret ved overgangen fra DOS til Windows.

Og DOS har arvet den fra printere. Iøvrigt siger mange RFC'er også
13+10 - og kun 10 virker som regel når man har en *nix maskine i den
anden ende, men ofte ikke hvis det er en Windows.

> Der er i øvrigt nogle DOS programmer, der fejlagtigt har brugt
> 10+13 i stedet for 13+10. Den slags filer virkede i øvrigt
> alligevel med nogle af de programmer, der var designet til 13+10.

Det burde det jo også, 13 = CR = retur til starten af linien, og 10
= LF = næste linie. Hvad rækkefølge man gør det i kan i princippet
være ligegyldigt.

>> Nix. Åbnes en tekst-fil med unix-LF i Notepad, er teksten i en lang
>> linie, og hver gang der skulle have været et linieskift, viser notepad
>> en firkant. Write og Wordpad har jeg ikke forsøgt.
>
> Der er i hvert fald en af standard editorerne på Windows, som automatisk
> konverterer linieskift til Windows linieskift. Jeg tror det er Wordpad
> som gør på den måde.

I gamle dage brugte jeg EDIT til det, men på WinXP kan jeg ikke få
tasterne til at virke (eneste vej ud af den er "end tasK")

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Martin Jørgensen <unoder.spam@spam.jay.net> writes:

> Hej,
>
> Jeg har et irriterende problem... Når jeg åbner nogle af mine filer
> som jeg måske på et tidspunkt har gemt på en windows-pc (kan ikke
> huske), er der en masse ^M'er i slutningen af linjen for "return".
>
> SVJH er det noget med at man afslutter linjer med ascii-koder 10+
> 13/14 i det ene operativsystem og kun med ascii kode 10 i det andet.
> Hvis nogen lige kan forklare problemet og ridse det op, ville det være
> fint.
>
> Dernæst har jeg søgt lidt på nettet - jeg mangler dos2unix og unix2dos
> på mit system men det ser ud til at man kan:
>
> http://kb.iu.edu/data/acux.html
>
> http://www.macosxhints.com/article.php?story=20031018164326986
>
> Jeg har ikke testet men hvad vil i foreslå og virker det som står på
> begge links lige godt eller?

Formentlig.

"recode" skulle også virke, når ellers man får gravet sig dybt nok ned
i dokumentationen og fundet syntaksen... Fordelen ved det er at det
også løser dit *næste* problem, nemlig at konvertere mellem UTF-8 og
Latin-1 tegnsæt.



> Grunden til at jeg spørger, er at jeg vil gerne finde den "bedste"
> løsning på problemet, så jeg ved lige nøjagtigt hvad jeg skal gøre i
> fremtiden og i øjeblikket er jeg lidt forvirret... Men Windows
> "notepad" og "write"/"wordpad" de "æder" vist alt, vil jeg tro.
> Hvadenten der står ascii kode 10 eller 10+13/14 - er det ikke korrekt?

Nej. Notepad kræver CRLF (hvilket er noget af en plage). Wordpad læser
LF-filer fint.

--
O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Peter Dalgaard wrote:
> Martin Jørgensen <unoder.spam@spam.jay.net> writes:
-snip-

>>Jeg har ikke testet men hvad vil i foreslå og virker det som står på
>>begge links lige godt eller?
>
>
> Formentlig.

Nu har jeg kigget lidt på "man tr" og syntes det ser underligt ud:

Dette er mac2unix, f.eks.:

cat $1 | tr 'r' 'n' <- erstatter den ikke bare alle "r"'er i teksten med
"n"'er? Jeg syntes helt sikkert det ser ud til at der mangler en
backslash så der burde vel stå "cat $1 | tr '\r' '\n'" i det mindste?

Og tilsvarende mangler der vel backslash'er her: ?

To convert unix files to Mac files, here is "unix2mac":
cat $1 | tr 'n' 'r'

To convert DOS files to unix files, here is "dos2unix":
cat $1 | tr -d 'r'

> "recode" skulle også virke, når ellers man får gravet sig dybt nok ned
> i dokumentationen og fundet syntaksen... Fordelen ved det er at det
> også løser dit *næste* problem, nemlig at konvertere mellem UTF-8 og
> Latin-1 tegnsæt.

Lige nøjagtigt... Jeg har et problem med æ, ø og å nogengange... Men jeg
har prøvet "man recode" -> "No manual entry for recode". Er det noget
jeg skal downloade?

Jeg har f.eks. en signaturfil som jeg på et tidspunkt rodede lidt rundt
i mht. hvordan jeg ændrer i med "vi" (jeg har jo nogen ø'er i den)? Men
efter at jeg ikke længere kan skriver æ, ø og å i min bash-prompt ser
problemet ud til at være forsvundet...

Prøv f.eks. at se nedenstående (fra bash):

Apple mac$ \303\246
-bash: æ: command not found
Apple mac$ \303\270
-bash: ø: command not found
Apple mac$ \303\245
-bash: å: command not found

Det er *SKIDE*-provokerende at den ikke vil lade mig skrive bogstaverne
på kommando-linjen, men i dens "svar" vil den jo gerne skrive æ, ø og å

Provo-computer...

-snip resten-


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Sat, 25 Feb 2006 16:22:14 +0100 skrev Martin Jørgensen:
> Peter Dalgaard wrote:
>> Martin Jørgensen <unoder.spam@spam.jay.net> writes:
> -snip-
>
>>>Jeg har ikke testet men hvad vil i foreslå og virker det som står på
>>>begge links lige godt eller?
>>
>>
>> Formentlig.
>
> Nu har jeg kigget lidt på "man tr" og syntes det ser underligt ud:
>
> Dette er mac2unix, f.eks.:
>
> cat $1 | tr 'r' 'n' <- erstatter den ikke bare alle "r"'er i teksten med
> "n"'er? Jeg syntes helt sikkert det ser ud til at der mangler en
> backslash så der burde vel stå "cat $1 | tr '\r' '\n'" i det mindste?

Det har du ret i.

> Og tilsvarende mangler der vel backslash'er her: ?

Nemlig.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Martin Jørgensen wrote:
> Hej,
>
> Jeg har et irriterende problem... Når jeg åbner nogle af mine filer som
> jeg måske på et tidspunkt har gemt på en windows-pc (kan ikke huske), er
> der en masse ^M'er i slutningen af linjen for "return".

vi/vim plejer at genkende DOS filer.

Man kan så lave en ":ff=unix" før man gemmer igen, så
bliver crlf lavet om til lf.

Hvis man skal lave DOS filer i vi skriver man så ":ff=dos"
inden man gemmer.

Mogens

--
Mogens Kjær, Dataarkæolog
Email: mk@datamuseum.dk
Homepage: http://www.datamuseum.dk

---

Den Sat, 25 Feb 2006 15:44:36 +0100 skrev Mogens Kjaer:
> Martin Jørgensen wrote:
>> Hej,
>>
>> Jeg har et irriterende problem... Når jeg åbner nogle af mine filer som
>> jeg måske på et tidspunkt har gemt på en windows-pc (kan ikke huske), er
>> der en masse ^M'er i slutningen af linjen for "return".
>
> vi/vim plejer at genkende DOS filer.

Det gælder vist kun Vim.

> Man kan så lave en ":ff=unix" før man gemmer igen, så
> bliver crlf lavet om til lf.
>
> Hvis man skal lave DOS filer i vi skriver man så ":ff=dos"
> inden man gemmer.

The ff command is unknown.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis <nospam@nospam.invalid> writes:

> Den Sat, 25 Feb 2006 15:44:36 +0100 skrev Mogens Kjaer:
> > Martin Jørgensen wrote:
> >> Hej,
> >>
> >> Jeg har et irriterende problem... Når jeg åbner nogle af mine filer som
> >> jeg måske på et tidspunkt har gemt på en windows-pc (kan ikke huske), er
> >> der en masse ^M'er i slutningen af linjen for "return".
> >

OP skrev, at han manglede d2u og u2d. For mange år siden fik jeg disse her
i gruppen:

--- d2u ---
#!/bin/sh
perl -lpe 's/\r//g' $1
-----------

--- u2d ---
#!/bin/sh
perl -lpe '$_.="\r"' $1
-----------

Læg dem i /usr/local/bin.

--
Mogens Dybæk Christensen
e-mail mdc at mail dot tele dot dk

---

Kent Friis wrote:
-snip-

>>Man kan så lave en ":ff=unix" før man gemmer igen, så
>>bliver crlf lavet om til lf.
>>
>>Hvis man skal lave DOS filer i vi skriver man så ":ff=dos"
>>inden man gemmer.
>
>
> The ff command is unknown.

Min vi skriver (med rødt): E492: Not an editor command: ff=dos


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Sat, 25 Feb 2006 16:24:28 +0100 skrev Martin Jørgensen:
> Kent Friis wrote:
> -snip-
>
>>>Man kan så lave en ":ff=unix" før man gemmer igen, så
>>>bliver crlf lavet om til lf.
>>>
>>>Hvis man skal lave DOS filer i vi skriver man så ":ff=dos"
>>>inden man gemmer.
>>
>>
>> The ff command is unknown.
>
> Min vi skriver (med rødt): E492: Not an editor command: ff=dos

Så vil jeg næsten gætte på det er Elvis. Når der er farver involveret
plejer det altid at være enten Vim eller Elvis, og kommandoen skulle
efter sigende virke i Vim.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:

>> Hvis man skal lave DOS filer i vi skriver man så ":ff=dos" inden man
>> gemmer.
>
> The ff command is unknown.

Prøv med ':set ff=dos'. ff er en option, ikke en kommando.

--
PeKaJe

We are Pentium of Borg. Division is futile. You will be approximated.

---

Peter Jensen wrote:
> Kent Friis wrote:
>
>
>>>Hvis man skal lave DOS filer i vi skriver man så ":ff=dos" inden man
>>>gemmer.
>>
>>The ff command is unknown.
>
>
> Prøv med ':set ff=dos'. ff er en option, ikke en kommando.

Den brokker sig ikke men tilgengæld ser det ikke ud til at have nogen
effekt... Ingen ^M tegn...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Martin Jørgensen wrote:

>> Prøv med ':set ff=dos'. ff er en option, ikke en kommando.
>
> Den brokker sig ikke men tilgengæld ser det ikke ud til at have nogen
> effekt... Ingen ^M tegn...

Huh? Hvorfor skulle der være det? Hvis jeg laver en tekstfil med vim
og skriver ':set ff=dos' før jeg gemmer, så siger 'file':

ASCII text, with CRLF line terminators

Hvis jeg åbner den i vim igen, så opdager den automatisk at det er en
DOS format fil (den siger [dos] i statuslinjen). Man burde så ikke
kunne se nogle ^M tegn i vim. Hvis man så skriver ':set ff=unix' før
man gemmer igen, så gemmes den som Unix format og 'file' siger:

ASCII text

Denne type filer har Windows programmer af og til problemer med at åbne.

Hvori ligger problemet egentligt?

--
PeKaJe

BOFH Excuse #356:
The daemons! The daemons! The terrible daemons!

---

Peter Jensen wrote:
> Martin Jørgensen wrote:
>
>
>>>Prøv med ':set ff=dos'. ff er en option, ikke en kommando.
>>
>>Den brokker sig ikke men tilgengæld ser det ikke ud til at have nogen
>>effekt... Ingen ^M tegn...
>
>
> Huh? Hvorfor skulle der være det? Hvis jeg laver en tekstfil med vim
> og skriver ':set ff=dos' før jeg gemmer, så siger 'file':

Hmm... Jeg troede at vi og vim var to forskellige programmer. Men når
jeg skriver vi ser det ud til at det samme program som når jeg skriver
vim dukker op?

> ASCII text, with CRLF line terminators

Det ville da være rart hvis min gad at skrive, for min siger bare:

"test.txt" [dos] 12L, 71C written

Med :set ff=unix skriver den bare:

"test.txt" 11L, 33C written

Men jeg har lige lavet en test og downloadet en hex-editor og der sker
rent faktisk det forventede:

:set ff=dos (giver CR LF/0D 0A endelser), ff=unix (giver LF/0A) eller
ff=mac (giver CR/0D endelser). Så det var da fantastisk... Nu kan jeg
bruge vi til at konvertere i mellem de forskellige måder, men jeg vil da
selvfølgeligt gerne lære nogle flere måder.

> Hvis jeg åbner den i vim igen, så opdager den automatisk at det er en
> DOS format fil (den siger [dos] i statuslinjen). Man burde så ikke
> kunne se nogle ^M tegn i vim. Hvis man så skriver ':set ff=unix' før
> man gemmer igen, så gemmes den som Unix format og 'file' siger:
>
> ASCII text

Tjah, din vi er mere informativ end min. Min skrev vist bare [dos] eller
lignende men det er også ok.

> Denne type filer har Windows programmer af og til problemer med at åbne.
>
> Hvori ligger problemet egentligt?

Problemet lå i at jeg troede at det var windows-filer der gav problemer
med ^M.......... Men problemet har sørme ligget et fuldstændigt andet
sted: Nemlig med mac-filer. Windows filer giver *ingen* problemer som du
selv skriver...

Men hvis du åbner en mac-fil så skriver på min pc: ~

"test.txt" [noeol] 1L, 22C

Jeg tolker det: "no end of line" og *DET* giver anledning til en masse
^M^M^M^M^M^M'er istedet for linjeskift, så nu har jeg vist isoleret
problemet... Og hurra for det


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Martin Jørgensen wrote:
>> Hvis man så skriver ':set ff=unix' før
>> man gemmer igen, så gemmes den som Unix format og 'file' siger:
>>
>> ASCII text
>
>
> Tjah, din vi er mere informativ end min. Min skrev vist bare [dos] eller
> lignende men det er også ok.

Det er programmet "file", som skriver ASCII tekst, ikke vi/vim.

Mogens

--
Mogens Kjær, Dataarkæolog
Email: mk@datamuseum.dk
Homepage: http://www.datamuseum.dk

---

Den Sun, 26 Feb 2006 11:02:23 +0100 skrev Martin Jørgensen:
> Peter Jensen wrote:
>> Martin Jørgensen wrote:
>>
>>
>>>>Prøv med ':set ff=dos'. ff er en option, ikke en kommando.
>>>
>>>Den brokker sig ikke men tilgengæld ser det ikke ud til at have nogen
>>>effekt... Ingen ^M tegn...
>>
>>
>> Huh? Hvorfor skulle der være det? Hvis jeg laver en tekstfil med vim
>> og skriver ':set ff=dos' før jeg gemmer, så siger 'file':
>
> Hmm... Jeg troede at vi og vim var to forskellige programmer. Men når
> jeg skriver vi ser det ud til at det samme program som når jeg skriver
> vim dukker op?

vi var den oprindelige vi editor. vim og elvis er to vi-kloner, som
har taget det grundlæggende system (insert vs command mode, taste-
kombinationerne) og hældt en masse ekstra ovenpå, bl.a. farver.

Så er der nvi, som går mere på at være en rigtig vi, og undgå alt
det ekstra pjat.

Normalt er der kun installeret en vi på systemet, enten vim, elvis eller
nvi. Og /usr/bin/vi er så et symlink til en af dem.

>> Denne type filer har Windows programmer af og til problemer med at åbne.
>>
>> Hvori ligger problemet egentligt?
>
> Problemet lå i at jeg troede at det var windows-filer der gav problemer
> med ^M.......... Men problemet har sørme ligget et fuldstændigt andet
> sted: Nemlig med mac-filer. Windows filer giver *ingen* problemer som du
> selv skriver...
>
> Men hvis du åbner en mac-fil så skriver på min pc: ~
>
> "test.txt" [noeol] 1L, 22C
>
> Jeg tolker det: "no end of line" og *DET* giver anledning til en masse
> ^M^M^M^M^M^M'er istedet for linjeskift, så nu har jeg vist isoleret
> problemet... Og hurra for det

Hvis den ikke autodetecter tekst-formatet, vil de forskellige formater
se sådan her ud:

Unix:

linie 1
linie 2

Windows:

linie1^M
linie2^M

Mac:

linie1^Mlinie2^M

^M er den visuelle repræsentation af 13 / CR (M er det 13. bogstav
i alfabetet), og 10 / LF bliver vist som linieskift.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Den 25 Feb 2006 19:45:17 GMT skrev Peter Jensen:
> Kent Friis wrote:
>
>>> Hvis man skal lave DOS filer i vi skriver man så ":ff=dos" inden man
>>> gemmer.
>>
>> The ff command is unknown.
>
> Prøv med ':set ff=dos'. ff er en option, ikke en kommando.

set: no ff option: 'set all' gives all option values.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
....
>>Prøv med ':set ff=dos'. ff er en option, ikke en kommando.
>
>
> set: no ff option: 'set all' gives all option values.

Det virker i vim. Det var mig, der havde skrevet forkert
og udeladt "set ".

Mogens

--
Mogens Kjær, Dataarkæolog
Email: mk@datamuseum.dk
Homepage: http://www.datamuseum.dk