---

Hej,

Hvordan finder man hurtigst/bedst/lettest ud af hvilke filer der
indeholder 0D 0A istedet for 0A line-endings på en linux-pc? Det kan man
vel gøre med bash på en eller anden måde...?


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

Martin Jørgensen skrev:

> Hvordan finder man hurtigst/bedst/lettest ud af hvilke filer der
> indeholder 0D 0A istedet for 0A line-endings på en linux-pc? Det
> kan man vel gøre med bash på en eller anden måde...?

Måske er der en smartere måde, men prøv om

   grep -lU "$(echo -e '\r')"

svarende til

   grep --files-with-matches --binary "$(echo -e '\r')"

kan klare det.

Mvh,

--
Klaus Alexander Seistrup
SubZeroNet, Copenhagen, Denmark
http://magnetic-ink.dk/

---

Og ellers kan man vel altid skrive en lille shell-wrapper:

#/bin/bash
# findcrlf

CRLF="$(echo -e '\r')"

for file in "${@}"; do
while read line; do
[ "${line: -1:1}" = "${CRLF}" ] && {
echo "${file}"
break
}
done < "${file}"
done

# eof

og så sige

   find /sti/til/mappe -type f -print0 | xargs -r0 findcrlf

Mvh,

--
Klaus Alexander Seistrup
SubZeroNet, Copenhagen, Denmark
http://magnetic-ink.dk/

---

Klaus Alexander Seistrup wrote:
> Og ellers kan man vel altid skrive en lille shell-wrapper:
>
> #/bin/bash
> # findcrlf
>
> CRLF="$(echo -e '\r')"

Hvad betyder "echo -e"? Jeg kunne ikke se det med "man echo"... Der stod
kun noget med -n...

> for file in "${@}"; do
> while read line; do
> [ "${line: -1:1}" = "${CRLF}" ] && {
> echo "${file}"
> break
> }
> done < "${file}"
> done
>
> # eof

Jeg er ikke så god til bash-programmering. Måske jeg kunne få nogen til
at forklare hvordan det virker?

> og så sige
>
>    find /sti/til/mappe -type f -print0 | xargs -r0 findcrlf

Jeg fandt ikke nogen -r0 forklaring med "man xargs". Ellers er jeg med
på find-kommandoen...

Men Morten Lund har selvfølgeligt givet den letteste løsning (jeg fandt
2 CRLF-filer i et bibliotek med ca. 30 filer)...


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

Martin Jørgensen skrev:

>> CRLF="$(echo -e '\r')"
>
> Hvad betyder "echo -e"?

#v+

$ help echo
echo: echo [-neE] [arg ...]
Output the ARGs. If -n is specified, the trailing newline is
suppressed. If the -e option is given, interpretation of the
following backslash-escaped characters is turned on:
:

#v-

>> for file in "${@}"; do
>> while read line; do
>> [ "${line: -1:1}" = "${CRLF}" ] && {
>> echo "${file}"
>> break
>> }
>> done < "${file}"
>> done
>>
>> # eof
>
> Jeg er ikke så god til bash-programmering. Måske jeg kunne få
> nogen til at forklare hvordan det virker?

for hvert filnavn givet på kommandolinjen
så længe vi kan læse en linje:
hvis linjen ender på CRLF:
sig filnavn
hop ud af løkken
gjort (idet der blev læst fra pågældende fil)
gjort

Se bash(1) for detaljer.

>>    find /sti/til/mappe -type f -print0 | xargs -r0 findcrlf
>
> Jeg fandt ikke nogen -r0 forklaring med "man xargs".

Sikker?

#v+

OPTIONS

--null, -0
Input filenames are terminated by a null character instead of by
whitespace, and the quotes and backslash are not special (every
character is taken literally). Disables the end of file string,
which is treated like any other argument. Useful when arguments
might contain white space, quote marks, or backslashes. The GNU
find -print0 option produces input suitable for this mode.

--no-run-if-empty, -r
If the standard input does not contain any nonblanks, do not run
the command. Normally, the command is run once even if there is
no input.

#v-

> Men Morten Lund har selvfølgeligt givet den letteste løsning (jeg
> fandt 2 CRLF-filer i et bibliotek med ca. 30 filer)...

Er grep-løsningen (grep -lU) mon ikke lisså let?

Mvh,

--
Klaus Alexander Seistrup
SubZeroNet, Copenhagen, Denmark
http://magnetic-ink.dk/

---

Klaus Alexander Seistrup wrote:
> Martin Jørgensen skrev:
>
>
>>>CRLF="$(echo -e '\r')"
>>
>>Hvad betyder "echo -e"?
>
>
> #v+
>
> $ help echo
> echo: echo [-neE] [arg ...]
> Output the ARGs. If -n is specified, the trailing newline is
> suppressed. If the -e option is given, interpretation of the
> following backslash-escaped characters is turned on:
> :
>
> #v-

Ok, tak. Jeg troede at det ville stå under "man echo" og der står den
ikke hos mig ihvertfald...

>>>for file in "${@}"; do
>>> while read line; do
>>> [ "${line: -1:1}" = "${CRLF}" ] && {
>>> echo "${file}"
>>> break
>>> }
>>> done < "${file}"
>>>done
>>>
>>># eof
>>
>>Jeg er ikke så god til bash-programmering. Måske jeg kunne få
>>nogen til at forklare hvordan det virker?
>
>
> for hvert filnavn givet på kommandolinjen
> så længe vi kan læse en linje:
> hvis linjen ender på CRLF:

Jeg syntes det er lidt ulogisk at [ "${line: -1:1}" = "${CRLF}" ] vel er
en logisk test (returnerer vel 1=true og 0=false) og dette bliver
åbenbart AND'et med { echo "${file}" break }, men det sidste er vel ikke
en logisk test?

Så det er bare &&-tegnene jeg ikke forstår...

> sig filnavn
> hop ud af løkken
> gjort (idet der blev læst fra pågældende fil)
> gjort
>
> Se bash(1) for detaljer.
>
>
>>>   find /sti/til/mappe -type f -print0 | xargs -r0 findcrlf
>>
>>Jeg fandt ikke nogen -r0 forklaring med "man xargs".
>
>
> Sikker?

Ja.

> #v+
>
> OPTIONS
>
> --null, -0
> Input filenames are terminated by a null character instead of by
> whitespace, and the quotes and backslash are not special (every
> character is taken literally). Disables the end of file string,
> which is treated like any other argument. Useful when arguments
> might contain white space, quote marks, or backslashes. The GNU
> find -print0 option produces input suitable for this mode.

Her er min -0:

The options are as follows:

-0 Change xargs to expect NUL (``\0'') characters as separators,
instead of spaces and newlines. This is expected to be used in
concert with the -print0 function in find(1).

Ikke noget --null nogen steder. Søgningen giver: "Pattern not found
(press RETURN)"

> --no-run-if-empty, -r
> If the standard input does not contain any nonblanks, do not run
> the command. Normally, the command is run once even if there is
> no input.

Og den står der slet ikke, som du kan se herunder...


XARGS(1) BSD General Commands Manual
XARGS(1)

NAME
xargs -- construct argument list(s) and execute utility

SYNOPSIS
xargs [-0pt] [-E eofstr] [-I replstr [-R replacements]] [-J replstr]
[-L number] [-n number [-x]] [-s size] [utility [argument ...]]


Jeg ved ikke om den hedder noget andet på mit system?

> #v-

Hvorfor skriver du #v- egentligt ? Jeg tror aldrig jeg har set den "syntax".

>>Men Morten Lund har selvfølgeligt givet den letteste løsning (jeg
>>fandt 2 CRLF-filer i et bibliotek med ca. 30 filer)...
>
>
> Er grep-løsningen (grep -lU) mon ikke lisså let?

Næææh (se mit andet indlæg)....

Prøv at se her:

mac$ cat findcrlf
#/bin/bash
# findcrlf

CRLF="$(echo -e '\r')"

for file in "${@}"; do
while read line; do
[ "${line: -1:1}" = "${CRLF}" ] && {
echo "${file}"
break
}
done < "${file}"
done

Apple/Desktop/bachelor2006/c_programming/2D_full_implicit mac$ find .
-type f -print0 | xargs -r0 findcrlf
xargs: illegal option -- r
usage: xargs [-0pt] [-E eofstr] [-I replstr [-R replacements]] [-J replstr]
[-L number] [-n number [-x] [-s size] [utility [argument ...]]



Best regards / Med venlig hilsen
Martin Jørgensen

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

---

Martin Jørgensen skrev:

> Jeg syntes det er lidt ulogisk at [ "${line: -1:1}" = "${CRLF}" ]
> vel er en logisk test (returnerer vel 1=true og 0=false) og dette
> bliver åbenbart AND'et med { echo "${file}" break }, men det
> sidste er vel ikke en logisk test?
>
> Så det er bare &&-tegnene jeg ikke forstår...

I stedet for at gætte, så:

>> Se bash(1) for detaljer.

Dvs. "man 1 bash".

> Her er min -0:
>
> The options are as follows:
>
> -0 Change xargs to expect NUL (``\0'') characters as separators,
> instead of spaces and newlines. This is expected to be used in
> concert with the -print0 function in find(1).
>
> Ikke noget --null nogen steder. Søgningen giver: "Pattern not found
> (press RETURN)"
>
>> --no-run-if-empty, -r
>> If the standard input does not contain any nonblanks, do not run
>> the command. Normally, the command is run once even if there is
>> no input.
>
> Og den står der slet ikke, som du kan se herunder...
>
>
> XARGS(1) BSD General Commands Manual
> XARGS(1)

Du startede tråden med at efterlyse en løsning på en "linux-pc", og
det fik du. Måske skulle du ha' været mere specifik?

> Jeg ved ikke om den hedder noget andet på mit system?

Du skal formodentlig ha' fat i GNU-udgaverne af programmerne...

> Hvorfor skriver du #v- egentligt ?

I slrn bliver alt text mellem '#v+' og '#v-' gengivet 'verbatim', og
evt. i en afvigende farve.

Mvh,

--
Klaus Alexander Seistrup
SubZeroNet, Copenhagen, Denmark
http://magnetic-ink.dk/

---

Klaus Alexander Seistrup wrote:
> Martin Jørgensen skrev:
-snip-

> Du startede tråden med at efterlyse en løsning på en "linux-pc", og
> det fik du. Måske skulle du ha' været mere specifik?

Nå, det tænkte jeg ikke over. Jeg bruger cvs til at hente et projekt ned
på mac/windows/linux-pc'ere... Sådan er det når der er flere forskellige
pc'ere at vælge imellem og jeg sad faktisk og skulle bruge det på en
linux-pc men jeg afprøvede bare scriptet på min macintosh da den booter
på 0,5 sek istedet for +1 min.

>>Jeg ved ikke om den hedder noget andet på mit system?
>
>
> Du skal formodentlig ha' fat i GNU-udgaverne af programmerne...
>
>
>>Hvorfor skriver du #v- egentligt ?
>
>
> I slrn bliver alt text mellem '#v+' og '#v-' gengivet 'verbatim', og
> evt. i en afvigende farve.

Ok.


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

Martin Jørgensen wrote:
> Klaus Alexander Seistrup wrote:

Nå, det var det script vi kom fra...

-snip-

>>>> for file in "${@}"; do
>>>> while read line; do
>>>> [ "${line: -1:1}" = "${CRLF}" ] && {
>>>> echo "${file}"
>>>> break
>>>> }
>>>> done < "${file}"
>>>> done
>>>>
>>>> # eof
>>>
>>>
>>> Jeg er ikke så god til bash-programmering. Måske jeg kunne få nogen
>>> til at forklare hvordan det virker?
>>
>>
>>
>> for hvert filnavn givet på kommandolinjen
>> så længe vi kan læse en linje:
>> hvis linjen ender på CRLF:
>
>
> Jeg syntes det er lidt ulogisk at [ "${line: -1:1}" = "${CRLF}" ] vel er
> en logisk test (returnerer vel 1=true og 0=false) og dette bliver
> åbenbart AND'et med { echo "${file}" break }, men det sidste er vel ikke
> en logisk test?
>
> Så det er bare &&-tegnene jeg ikke forstår...

Jeg fik vist ikke noget svar på && (and) tegnene, gjorde jeg?

Derudover har jeg et nyt lille spørgsmål til de kloge, men så tror jeg
vist også at det skulle køre derudaf bagefter...:

mac$ file *.c
array_functions.c: ASCII C program text
band_solve.c: ASCII C program text
check_errors.c: ASCII C program text
import_data.c: ASCII Java program text
main.c: UTF-8 Unicode C program text
memory_functions.c: ASCII C program text
mesh_functions.c: ASCII C program text
read_materials.c: ASCII C program text
result_output.c: ASCII C program text


Hvad er det som gør at ikke alle tekst-filerne er "ASCII C program
text"? Jeg ville sove bedre om natten, hvis jeg vidste at de alle var
skrevet i samme "format" eller "standard".... Frygten går selvfølgeligt
på, hvis der pludseligt skulle være sneget sig underlige tegn ind et
sted... ?

UTF lyder f.eks. ikke rart...


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

Martin Jørgensen skrev:

>> Så det er bare &&-tegnene jeg ikke forstår...
>
> Jeg fik vist ikke noget svar på && (and) tegnene, gjorde jeg?

Stod der ikke noget du kunne i bash(1)? Den har jeg henvist til
to gange...

> UTF lyder f.eks. ikke rart...

Nej, uha!!

Mvh,

--
Klaus Alexander Seistrup
SubZeroNet, Copenhagen, Denmark
http://magnetic-ink.dk/

---

Klaus Alexander Seistrup wrote:
> Martin Jørgensen skrev:
>
>
>>Hvordan finder man hurtigst/bedst/lettest ud af hvilke filer der
>>indeholder 0D 0A istedet for 0A line-endings på en linux-pc? Det
>>kan man vel gøre med bash på en eller anden måde...?
>
>
> Måske er der en smartere måde, men prøv om
>
>    grep -lU "$(echo -e '\r')"
>
> svarende til
>
>    grep --files-with-matches --binary "$(echo -e '\r')"
>
> kan klare det.

Du mener vel sådan her:

find . | grep --files-with-matches --binary "$(echo -e '\r')"


?

Det virker ikke - har prøvet begge muligheder. Den finder ingen
CRLF-filer på mit system (mac os 10.4). Det gør file tilgengæld...

Samme resultat giver:
find . -type f -print0 | grep --files-with-matches --binary "$(echo -e
'\r')"


Finder den noget på dit system? Du kan vel hurtigt bruge unix2dos eller
lignende, blot for lige at konstatere om det kun er på mit system at
fejlen eksisterer?


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

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

> Det virker ikke - har prøvet begge muligheder. Den finder ingen
> CRLF-filer på mit system (mac os 10.4). Det gør file tilgengæld...

OS X er ikke et GNU system, men BSD.

--
Thorbjørn Ravn Andersen

---

Martin Jørgensen skrev:

>> Måske er der en smartere måde, men prøv om
>>
>>    grep -lU "$(echo -e '\r')"
>>
>> svarende til
>>
>>    grep --files-with-matches --binary "$(echo -e '\r')"
>>
>> kan klare det.
>
> Du mener vel sådan her:
>
> find . | grep --files-with-matches --binary "$(echo -e '\r')"
>
>
> ?
>
> Det virker ikke - har prøvet begge muligheder.

#v+

$ echo -e 'a\nb\nc' > lflf.txt
$ echo -e 'a\r\nb\r\nc\r' > crlf.txt
$ grep -lU "$(echo -e '\r')" ??lf.txt
crlf.txt
$ $ find . -type f -print0 | xargs -r0 grep -lU "$(echo -e '\r')"
../crlf.txt
$

#v-

> Finder den noget på dit system?

Jada.

Mvh,

--
Klaus Alexander Seistrup
SubZeroNet, Copenhagen, Denmark
http://magnetic-ink.dk/

---

Klaus Alexander Seistrup wrote:
> Martin Jørgensen skrev:
-snip-

>>Finder den noget på dit system?
>
>
> Jada.

Som sagt havde jeg egentligt ikke tænkt over at jeg oprindeligt skulle
bruge det på en linux-pc og afprøvede det på den forkerte pc.


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

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

>>> Hvad betyder "echo -e"?
>> #v+
>> $ help echo
>> echo: echo [-neE] [arg ...]
>> Output the ARGs. If -n is specified, the trailing newline is
>> suppressed. If the -e option is given, interpretation of the
>> following backslash-escaped characters is turned on:
>> :
>> #v-
>
> Ok, tak. Jeg troede at det ville stå under "man echo" og der står den
> ikke hos mig ihvertfald...

Nej, 'man echo' beskriver kommandoen /bin/echo, men de fleste shells
har deres egen indbyggede version af echo.

--
Peter Makholm | I laugh in the face of danger. Then I hide until
peter@makholm.net | it goes away
http://hacking.dk | -- Xander

---

Klaus Alexander Seistrup <klaus@seistrup.dk> writes:

> Måske er der en smartere måde, men prøv om
>
>    grep -lU "$(echo -e '\r')"

Måske:

grep -lU $'\r'

--
Peter Makholm | I laugh in the face of danger. Then I hide until
peter@makholm.net | it goes away
http://hacking.dk | -- Xander

---

Peter Makholm skrev:

> Måske:
>
> grep -lU $'\r'

Det fanger vel osse filer som har '\r' i anden sammenhæng en '\r\n'?

Mvh,

--
Klaus Alexander Seistrup
SubZeroNet, Copenhagen, Denmark
http://magnetic-ink.dk/

---

Klaus Alexander Seistrup <klaus@seistrup.dk> writes:

> Peter Makholm skrev:
>
>> Måske:
>>
>> grep -lU $'\r'
>
> Det fanger vel osse filer som har '\r' i anden sammenhæng en '\r\n'?

Så "grep -lU $'\r\n'" da. Hele pointen var at bruge $'' og ikke skulle
kalde echo.

--
Peter Makholm | 'Cause suicide is painless
peter@makholm.net | It brings on many changes
http://hacking.dk | And I can take or leave it if I please
| -- Suicide is painless

---

On Sat, 13 May 2006 14:57:10 +0000 (UTC), Klaus wrote:

> I slrn bliver alt text mellem '#v+' og '#v-' gengivet 'verbatim', og
> evt. i en afvigende farve.

(Ditto i Gnus).


,

--
"Lef ma nine imma Jeep" Adam Sjøgren
asjo@koldfront.dk

---

asjo@koldfront.dk (Adam Sjøgren) writes:

> (Ditto i Gnus).

Ikke i min gnus - jeg kører 5.9.0 (fulgte vist med den emacs jeg
kører). Er det umagen værd at opgradere?

--
Thorbjørn Ravn Andersen

---

On 13 May 2006 23:29:12 +0200, Thorbjørn wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>> (Ditto i Gnus).

> Ikke i min gnus - jeg kører 5.9.0 (fulgte vist med den emacs jeg
> kører). Er det umagen værd at opgradere?

Det er ved at være en gammel svend (~2001?)

Nyeste ikke-udviklingsudgave er 5.10.8 og nyeste udviklingsudgave er
No Gnus 0.5 (traditionen tro pakket 1. maj).


Om det kan betale sig at opgradere, tjah, GNUS-NEWS fra 5.9.0 til
5.10.8 er ~480 linier lang.

Jeg kører med et cvs-udcheck af udviklingsudgaven; den er jeg godt
tilfreds med.


slrns verbatim marks er ikke med i 5.10.8; support for dem blev
tilføjet til udviklingsudgaven 2005-09-22.


Mvh.

Adam

--
"It's kind of important to have peace on earth." Adam Sjøgren
asjo@koldfront.dk

---

On Sun, 14 May 2006 12:42:13 +0200, Martin wrote:

> Jeg fik vist ikke noget svar på && (and) tegnene, gjorde jeg?

Gjorde du ikke?

,----
| On Sat, 13 May 2006 14:57:10 +0000 (UTC), Klaus wrote:
|
| > Martin Jørgensen skrev:
|
| >> Så det er bare &&-tegnene jeg ikke forstår...
|
| > I stedet for at gætte, så:
|
| >>> Se bash(1) for detaljer.
|
| > Dvs. "man 1 bash".
`----

> array_functions.c: ASCII C program text
> band_solve.c: ASCII C program text
> check_errors.c: ASCII C program text
> import_data.c: ASCII Java program text
> main.c: UTF-8 Unicode C program text
> memory_functions.c: ASCII C program text
> mesh_functions.c: ASCII C program text
> read_materials.c: ASCII C program text
> result_output.c: ASCII C program text

> Hvad er det som gør at ikke alle tekst-filerne er "ASCII C program
> text"?

file(1) gætter, så nogle gange gætter den forkert.

> Jeg ville sove bedre om natten, hvis jeg vidste at de alle var
> skrevet i samme "format" eller "standard"....

Så må du åbne filerne og kigge på dem. Du er forhåbentlig bedre til at
gætte end file(1).

> Frygten går selvfølgeligt på, hvis der pludseligt skulle være sneget
> sig underlige tegn ind et sted... ?

> UTF lyder f.eks. ikke rart...

Hvorfor ikke? Hvis du har skrevet f.eks. "Jørgensen" i en fil, så skal
den jo gemmes med noget andet end ascii; det kunne f.eks. være utf-8.


Mvh.

--
"Yeah, well, that's just, like, your opinion, man." Adam Sjøgren
asjo@koldfront.dk

---

Adam Sjøgren wrote:
> On Sun, 14 May 2006 12:42:13 +0200, Martin wrote:
>
>
>>Jeg fik vist ikke noget svar på && (and) tegnene, gjorde jeg?
>
>
> Gjorde du ikke?

Næ det tror jeg ikke.

> ,----
> | On Sat, 13 May 2006 14:57:10 +0000 (UTC), Klaus wrote:
> |
> | > Martin Jørgensen skrev:
> |
> | >> Så det er bare &&-tegnene jeg ikke forstår...
> |
> | > I stedet for at gætte, så:
> |
> | >>> Se bash(1) for detaljer.
> |
> | > Dvs. "man 1 bash".

Der står bl.a.:
expression1 && expression2
True if both expression1 and expression2 are true.

The && and || operators do not evaluate expression2 if the value
of expression1 is sufficient to determine the return
value of the entire conditional expression.

Men jeg tror ikke du forstod spørgsmålet, fordi det er let at forstå at
2 udtryk kan AND'es men det er ikke let at forstå at udtryk1 AND'es med
en højre-side som ikke er en logisk test. Det strider ihvertfald mod
hvad jeg har lært.

Ellers hvad mener du jeg skulle kunne se med man 1 bash?

>>array_functions.c: ASCII C program text
>>band_solve.c: ASCII C program text
>>check_errors.c: ASCII C program text
>>import_data.c: ASCII Java program text
>>main.c: UTF-8 Unicode C program text
>>memory_functions.c: ASCII C program text
>>mesh_functions.c: ASCII C program text
>>read_materials.c: ASCII C program text
>>result_output.c: ASCII C program text
>
>
>>Hvad er det som gør at ikke alle tekst-filerne er "ASCII C program
>>text"?
>
>
> file(1) gætter, så nogle gange gætter den forkert.

Jeg burde nok hellere have spurgt om hvad forskellen er på:

check_errors.c: ASCII C program text
import_data.c: ASCII Java program text
main.c: UTF-8 Unicode C program text

3 forskellige "fil-formater".

>>Jeg ville sove bedre om natten, hvis jeg vidste at de alle var
>>skrevet i samme "format" eller "standard"....
>
>
> Så må du åbne filerne og kigge på dem. Du er forhåbentlig bedre til at
> gætte end file(1).

Jeg kan ikke se de usynlige tegn og jeg orker ikke at bruge en
hex-editor til at gå igennem hver enkelt byte i alle filerne, hvis det
er det du forestiller dig.

>>Frygten går selvfølgeligt på, hvis der pludseligt skulle være sneget
>>sig underlige tegn ind et sted... ?
>
>
>>UTF lyder f.eks. ikke rart...
>
>
> Hvorfor ikke? Hvis du har skrevet f.eks. "Jørgensen" i en fil, så skal
> den jo gemmes med noget andet end ascii; det kunne f.eks. være utf-8.

Alting i filerne er på engelsk, så jeg har ikke umiddelbart nogen gode
bud...


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

Den Sun, 14 May 2006 14:59:59 +0200 skrev Martin Jørgensen:

>
> Der står bl.a.:
> expression1 && expression2
> True if both expression1 and expression2 are true.
>
> The && and || operators do not evaluate expression2 if the value
> of expression1 is sufficient to determine the return
> value of the entire conditional expression.
>
> Men jeg tror ikke du forstod spørgsmålet, fordi det er let at forstå at
> 2 udtryk kan AND'es men det er ikke let at forstå at udtryk1 AND'es med
> en højre-side som ikke er en logisk test. Det strider ihvertfald mod
> hvad jeg har lært.

I en shell er enhver kommando et udtryk. En kommando eller et
program har en exit-status, entel 0 (success, true) eller >0 (fejl,
false). Bemærk at det er modsat de fleste programmeringssprog der
arbjeder med 0=false og 1=true.

Og det er faktisk det samme med "test" kommandoen, som også forkortes
[ ... ].

Altså:

"test 1 = 1" returnerer 0 (true)
"[ 1 = 1 ]" returnerer 0 (true)
"ls" returnerer 0 (true)

og

"test 1 = 2" returnerer 1 (false)
"[ 1 = 2 ]" returnerer 1 (false)
"rm /" returnerer 1 (false).

> Jeg burde nok hellere have spurgt om hvad forskellen er på:
>
> check_errors.c: ASCII C program text
> import_data.c: ASCII Java program text
> main.c: UTF-8 Unicode C program text
>
> 3 forskellige "fil-formater".

Den sidste indeholder danske bogstaver, det gør de første to ikke
(i hvert fald ikke i de første par linier, hvor "file" kigger).

Den første indeholder ord der kunne tyde på at det er C-kode,
det kunne måske være "#include" (jeg ved ikke præcis hvilke ord "file"
kigger efter). Nummer to indeholder ord der tyder mere på Java
end på C. Men det er kun et gæt "file" kommer med, der er ikke
nogen måde med sikkerhed at se forskel.

>> Så må du åbne filerne og kigge på dem. Du er forhåbentlig bedre til at
>> gætte end file(1).
>
> Jeg kan ikke se de usynlige tegn og jeg orker ikke at bruge en
> hex-editor til at gå igennem hver enkelt byte i alle filerne, hvis det
> er det du forestiller dig.

Hvilke usynlige tegn?

>> Hvorfor ikke? Hvis du har skrevet f.eks. "Jørgensen" i en fil, så skal
>> den jo gemmes med noget andet end ascii; det kunne f.eks. være utf-8.
>
> Alting i filerne er på engelsk, så jeg har ikke umiddelbart nogen gode
> bud...

Der skal nok være et eller andet. Hvis det ikke er æøå, så er
det nok en umlaut, accent eller lignende der har sneget sig ind.

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

---

Kent Friis wrote:
> Den Sun, 14 May 2006 14:59:59 +0200 skrev Martin Jørgensen:
-snip-

> I en shell er enhver kommando et udtryk. En kommando eller et
> program har en exit-status, entel 0 (success, true) eller >0 (fejl,
> false). Bemærk at det er modsat de fleste programmeringssprog der
> arbjeder med 0=false og 1=true.
>
> Og det er faktisk det samme med "test" kommandoen, som også forkortes
> [ ... ].
>
> Altså:
>
> "test 1 = 1" returnerer 0 (true)
> "[ 1 = 1 ]" returnerer 0 (true)
> "ls" returnerer 0 (true)
>
> og
>
> "test 1 = 2" returnerer 1 (false)
> "[ 1 = 2 ]" returnerer 1 (false)
> "rm /" returnerer 1 (false).

Man skal altså bare lige forstå at && ikke bruges som en logisk test,
men nærmere som en if-konstruktion.

>>Jeg burde nok hellere have spurgt om hvad forskellen er på:
>>
>>check_errors.c: ASCII C program text
>>import_data.c: ASCII Java program text
>>main.c: UTF-8 Unicode C program text
>>
>>3 forskellige "fil-formater".
>
>
> Den sidste indeholder danske bogstaver, det gør de første to ikke
> (i hvert fald ikke i de første par linier, hvor "file" kigger).

Jeg tror jeg fandt 2 firkanter i main.c som ikke var ascii-tegn. Hvis du
kan forestille dig [] trukket sammen til ét tegn. Hvordan de er kommet
er mig en gåde. Muligvis noget med anjuta, er mit eneste bud.

> Den første indeholder ord der kunne tyde på at det er C-kode,
> det kunne måske være "#include" (jeg ved ikke præcis hvilke ord "file"
> kigger efter). Nummer to indeholder ord der tyder mere på Java
> end på C. Men det er kun et gæt "file" kommer med, der er ikke
> nogen måde med sikkerhed at se forskel.

"Java-filen" starter sådan her:


/***********************************************************************
* *
* functions to import data from files to memory *
* *
***********************************************************************/

#include "import_data.h"


Og jeg har lige lavet en test ( >test_fil.c ) og ovenstående er åbenbart
tiltrækkeligt til at den mener at programmeringssproget er java. Jeg
syntes så at man kan undre sig over at den her fil åbenbart skulle
adskille sig så meget at det ikke længere er "java", men C:

/***********************************************************************
* *
* various error-checking functions (validates input) *
* *
***********************************************************************/

#include "check_errors.h"


>>>Så må du åbne filerne og kigge på dem. Du er forhåbentlig bedre til at
>>>gætte end file(1).

Der er ikke meget "gæt" over det. Virker nærmere helt tilfældigt hvad
den gør. Man kunne forestille sig at den automatisk kendte
stdio-biblioteket og lignende, men jeg har selv programmeret,
deklareret/defineret og oprettet både import_data.h og check_errors.h,
så det at den ene fil skulle være anderledes end den anden er
fuldstændigt godnat, når den ikke kender nogen af header-filerne.

>>Jeg kan ikke se de usynlige tegn og jeg orker ikke at bruge en
>>hex-editor til at gå igennem hver enkelt byte i alle filerne, hvis det
>>er det du forestiller dig.
>
>
> Hvilke usynlige tegn?
>
>
>>>Hvorfor ikke? Hvis du har skrevet f.eks. "Jørgensen" i en fil, så skal
>>>den jo gemmes med noget andet end ascii; det kunne f.eks. være utf-8.
>>
>>Alting i filerne er på engelsk, så jeg har ikke umiddelbart nogen gode
>>bud...
>
>
> Der skal nok være et eller andet. Hvis det ikke er æøå, så er
> det nok en umlaut, accent eller lignende der har sneget sig ind.

2 firkanter...


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

Den Mon, 15 May 2006 21:23:36 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
>> Den Sun, 14 May 2006 14:59:59 +0200 skrev Martin Jørgensen:
> -snip-
>
>> I en shell er enhver kommando et udtryk. En kommando eller et
>> program har en exit-status, entel 0 (success, true) eller >0 (fejl,
>> false). Bemærk at det er modsat de fleste programmeringssprog der
>> arbjeder med 0=false og 1=true.
>>
>> Og det er faktisk det samme med "test" kommandoen, som også forkortes
>> [ ... ].
>>
>
> Man skal altså bare lige forstå at && ikke bruges som en logisk test,
> men nærmere som en if-konstruktion.

Normalt ja. Den kan også bruges sammen med if, så ser det nok mere
ud som du ville forvente:

if [ $a = 2 ] && [ $b = 3 ]
then

>>>Jeg burde nok hellere have spurgt om hvad forskellen er på:
>>>
>>>check_errors.c: ASCII C program text
>>>import_data.c: ASCII Java program text
>>>main.c: UTF-8 Unicode C program text
>>>
>>>3 forskellige "fil-formater".
>>
>>
>> Den sidste indeholder danske bogstaver, det gør de første to ikke
>> (i hvert fald ikke i de første par linier, hvor "file" kigger).
>
> Jeg tror jeg fandt 2 firkanter i main.c som ikke var ascii-tegn. Hvis du
> kan forestille dig [] trukket sammen til ét tegn. Hvordan de er kommet
> er mig en gåde. Muligvis noget med anjuta, er mit eneste bud.

Det er helt normalt at tegn der ikke findes i den aktuelle font
vises som en firkant. Notepad.exe gør det samme

Men når de ikke findes i fonten, er de helt sikkert heller ikke
ascii. Mit umiddelbare gæt er også anjuta eller tilsvarende
program. Hvis du henter den derind igen, inden du sletter firkanterne
(hvis du ikke har gjort det) dukker der sikkert et tegn/bogstav
op som du har ramt ved et uheld.

> "Java-filen" starter sådan her:
[...]
> #include "import_data.h"
>
>
> Og jeg har lige lavet en test ( >test_fil.c ) og ovenstående er åbenbart
> tiltrækkeligt til at den mener at programmeringssproget er java. Jeg
> syntes så at man kan undre sig over at den her fil åbenbart skulle
> adskille sig så meget at det ikke længere er "java", men C:
>
[...]
> #include "check_errors.h"

Det er sandsynligvis ordet "import" der får den til at gætte forkert.
Hvis jeg ikke husker galt, er det "import" man bruger i Java til
at hente et namespace ind.

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

---

Kent Friis wrote:
> Den Mon, 15 May 2006 21:23:36 +0200 skrev Martin Jørgensen:
-snip-

>>>Den sidste indeholder danske bogstaver, det gør de første to ikke
>>>(i hvert fald ikke i de første par linier, hvor "file" kigger).
>>
>>Jeg tror jeg fandt 2 firkanter i main.c som ikke var ascii-tegn. Hvis du
>>kan forestille dig [] trukket sammen til ét tegn. Hvordan de er kommet
>>er mig en gåde. Muligvis noget med anjuta, er mit eneste bud.
>
>
> Det er helt normalt at tegn der ikke findes i den aktuelle font
> vises som en firkant. Notepad.exe gør det samme
>
> Men når de ikke findes i fonten, er de helt sikkert heller ikke
> ascii. Mit umiddelbare gæt er også anjuta eller tilsvarende
> program. Hvis du henter den derind igen, inden du sletter firkanterne
> (hvis du ikke har gjort det) dukker der sikkert et tegn/bogstav
> op som du har ramt ved et uheld.

Tjaah, jeg har slettet det og jeg syntes ikke rigtigt at jeg har tid til
at finde en gammel kopi frem og undersøge sagen yderligere.

>>"Java-filen" starter sådan her:
>
> [...]
>
>>#include "import_data.h"
>>
>>
>>Og jeg har lige lavet en test ( >test_fil.c ) og ovenstående er åbenbart
>>tiltrækkeligt til at den mener at programmeringssproget er java. Jeg
>>syntes så at man kan undre sig over at den her fil åbenbart skulle
>>adskille sig så meget at det ikke længere er "java", men C:
>>
>
> [...]
>
>>#include "check_errors.h"
>
>
> Det er sandsynligvis ordet "import" der får den til at gætte forkert.
> Hvis jeg ikke husker galt, er det "import" man bruger i Java til
> at hente et namespace ind.

Ok.... Jeg takker.



Best regards / Med venlig hilsen
Martin Jørgensen

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

---

Martin Jørgensen skrev:

> Der står bl.a.:
> expression1 && expression2
> True if both expression1 and expression2 are true.
>
> The && and || operators do not evaluate expression2 if the value
> of expression1 is sufficient to determine the return
> value of the entire conditional expression.
>
> Men jeg tror ikke du forstod spørgsmålet, fordi det er let at forstå at
> 2 udtryk kan AND'es men det er ikke let at forstå at udtryk1 AND'es med
> en højre-side som ikke er en logisk test. Det strider ihvertfald mod
> hvad jeg har lært.
>
> Ellers hvad mener du jeg skulle kunne se med man 1 bash?

#v+

The control operators && and || denote AND lists and OR lists, respec-
tively. An AND list has the form

command1 && command2

command2 is executed if, and only if, command1 returns an exit status
of zero.

An OR list has the form

command1 || command2

command2 is executed if and only if command1 returns a non-zero exit
status. The return status of AND and OR lists is the exit status of
the last command executed in the list.

#v-

Mvh,

--
Klaus Alexander Seistrup
SubZeroNet, Copenhagen, Denmark
http://magnetic-ink.dk/

---

On Mon, 15 May 2006 21:27:49 +0200, Martin wrote:

> Hvis du ikke har noget fornuftigt at skrive, må jeg så have lov at
> foreslå dig at lukke røven og blande dig udenom diskussionen eller
> iøvrigt måske prøve at snakke mere fornuftigt og ordentligt, i et
> rimeligt civiliseret toneleje?

Det kan du have en god pointe i - selvom du har fået at vide at svaret
står i manualen tre gange behøver jeg ikke at opføre mig som en idiot
og bruge grimt sprog; beklager.

[Bemærk i øvrigt at jeg sendte en Cancel på min artikel i morges; jeg
antager den ikke er nået frem til din news-server].

(Sjovt nok fulgte du faktisk mit råd, kan jeg se andetsteds i tråden,
og det *var* ikke usynlige tegn - som du gik ud fra at jeg var dum nok
til at foreslå dig at kigge efter - men et helt synligt tegn...

Skægt nok brugte du samme metode på den fil file(1) troede var Java
kildekode).

Nu er dette jo usenet, så alle de dumme, irriterende og kværulerende
idioter må man lære at leve med.

>> Igen: hvilket svar forventer du at vi skal give dig, uden at kigge i
>> dine filer for dig?

> Ihvertfald ikke sådan noget bræk du lukker ud.

Det ærgrer mig lidt at min dårlige stil fik dig til ikke at svare på
spørgsmålet - det var såmænd ærligt ment, selvom det var formuleret
unødigt provokerende.

> Du kan lære noget ved at læse de andres skribenters indlæg, men jeg
> ville nok foreslå dig helt at blande dig udenom med henvisning til
> "... Nu behøver du ikke gøre dig dummere end du er".

Ork, jeg kan opføre mig mange gange dummere.


Mvh.

--
"I hope you're not going to ask me to explain a title." Adam Sjøgren
asjo@koldfront.dk

---

Martin Jørgensen wrote:
> Hvordan finder man hurtigst/bedst/lettest ud af hvilke filer der
> indeholder 0D 0A istedet for 0A line-endings på en linux-pc? Det kan man
> vel gøre med bash på en eller anden måde...?

"file" rapporterer hvis der bruges CRLF som linjeskift i en ascii-fil.

/Morten Lund

---

---

---

---

---

---

Adam Sjøgren wrote:
> On Sun, 14 May 2006 14:59:59 +0200, Martin wrote:
-snip-

>>Alting i filerne er på engelsk, så jeg har ikke umiddelbart nogen gode
>>bud...
>
>
> Nu behøver du ikke gøre dig dummere end du er - måske står er der et
> euro-tegn eller et ©-tegn eller et £-tegn eller et §-tegn eller...
> mulighederne er mange, det behøver ikke lige være "Jørgensen" der
> står.

Hvis du ikke har noget fornuftigt at skrive, må jeg så have lov at
foreslå dig at lukke røven og blande dig udenom diskussionen eller
iøvrigt måske prøve at snakke mere fornuftigt og ordentligt, i et
rimeligt civiliseret toneleje?

> Igen: hvilket svar forventer du at vi skal give dig, uden at kigge i
> dine filer for dig?

Ihvertfald ikke sådan noget bræk du lukker ud. Du kan lære noget ved at
læse de andres skribenters indlæg, men jeg ville nok foreslå dig helt at
blande dig udenom med henvisning til "... Nu behøver du ikke gøre dig
dummere end du er".


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

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

> Hvis du ikke har noget fornuftigt at skrive, må jeg så have lov at
> foreslå dig at lukke røven og blande dig udenom diskussionen eller
> iøvrigt måske prøve at snakke mere fornuftigt og ordentligt, i et
> rimeligt civiliseret toneleje?

Kunne man ulejlige dig med at holde det samme niveau du ønsker af
andre?

Får du svar du synes er dumme, er det måske fordi dem der svarer dig
synes spørgsmålene er dumme. Personligt synes jeg du vil have stor
glæde af at sætte dig ned og lære hvad man kan i et sh-program - det
er ret kraftfuldt.

--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen wrote:
> Martin Jørgensen <unoder.spam@spam.jay.net> writes:
>
>
>>Hvis du ikke har noget fornuftigt at skrive, må jeg så have lov at
>>foreslå dig at lukke røven og blande dig udenom diskussionen eller
>>iøvrigt måske prøve at snakke mere fornuftigt og ordentligt, i et
>>rimeligt civiliseret toneleje?
>
>
> Kunne man ulejlige dig med at holde det samme niveau du ønsker af
> andre?

Jeg aner ikke hvad du mener med det ævl.

> Får du svar du synes er dumme, er det måske fordi dem der svarer dig
> synes spørgsmålene er dumme. Personligt synes jeg du vil have stor

Hvis folk syntes at spørgsmålene er dumme, så har jeg jo netop foreslået
dem at blande sig udenom og overlade diskussionen til de fornuftige,
istedet for at udstille deres tåbeligheder. Man behøves ikke ligefrem at
reklamerer med det.

> glæde af at sætte dig ned og lære hvad man kan i et sh-program - det
> er ret kraftfuldt.

Hvis du ikke kan tåle eller iøvrigt har et problem med at nogen stiller
nogen spørgsmål som du mener "er dumme", så er det ikke mig der har et
problem. Så er det dig der skal ændre din opfattelse af hvordan tingene
hænger sammen.


Best regards / Med venlig hilsen
Martin Jørgensen

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

---

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

> Hvis du ikke kan tåle eller iøvrigt har et problem med at nogen
> stiller nogen spørgsmål som du mener "er dumme", så er det ikke mig
> der har et problem.

Lær at læse. Det var nemlig ikke det jeg skrev, men snarere en
vurdering af hvorfor du synes du får dumme svar.

Emnet er behandlet i
http://www.catb.org/~esr/faqs/smart-questions.html

Hvis du ikke forstår hvad det har med sagen at gøre, så sig til.
--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen wrote:
> Martin Jørgensen <unoder.spam@spam.jay.net> writes:
>
>
>>Hvis du ikke kan tåle eller iøvrigt har et problem med at nogen
>>stiller nogen spørgsmål som du mener "er dumme", så er det ikke mig
>>der har et problem.
>
>
> Lær at læse. Det var nemlig ikke det jeg skrev, men snarere en
> vurdering af hvorfor du synes du får dumme svar.

Lær at læse. Jeg har ikke skrevet det du vrøvler om. Og generelt set har
jeg fået nogen udmærkede svar, når man lige sletter det sidste du skrev
om at jeg skulle sige til, hvis der var noget jeg ikke forstod.


Best regards / Med venlig hilsen
Martin Jørgensen

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