---

Fra et bash-script vil jeg gerne lave en fil.

Jeg prøver med
echo >/tmp/fil <<STOP
bla bla bla
STOP

men /tmp/fil er tom.

Andre varianter, der ikke virker:
echo <<STOP > /tmp/fil
bla bla
STOP

echo <<STOP
bla bla
STOP > /tmp/fil

Nogle ideer?

Leif

---

Leif Neland wrote:
> Fra et bash-script vil jeg gerne lave en fil.
>
> Jeg prøver med
> echo >/tmp/fil <<STOP
> bla bla bla
> STOP
>
Doh...

cat >/tmp/fil <<STOP
bla bla
STOP

fungerer...

Leif

---

Leif Neland wrote:

> cat >/tmp/fil <<STOP
> bla bla
> STOP

Useless use of cat:

while read;do echo $REPLY;done> /tmp/fil <<STOP
bla bla
STOP

(En mindre og formentlig ubetydelig forskel, ja. Der er dog nogle
situationer hvor det er bedst ikke at kalde eksterne programmer unødigt)

--
PeKaJe

"It may be that our role on this planet is not to worship God but to
create him." -- Arthur C. Clarke

---

Den 23 Sep 2005 14:11:08 GMT skrev Peter Jensen:
> Leif Neland wrote:
>
>> cat >/tmp/fil <<STOP
>> bla bla
>> STOP
>
> Useless use of cat:

Det er jeg nu ikke helt enig i, din løsning fylder dobbelt så meget,
og er meget mere kompliceret.

> while read;do echo $REPLY;done> /tmp/fil <<STOP

Hvor kommer $REPLY fra? Hmm, iflg. "help read" i Bash ryger input
faktisk over i den når man ikke angiver er variabel.

Der kan du se hvor meget mere kompliceret din løsning er, med cat er
det ikke nødvendigt at RTFM

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

---

Peter Jensen <usenet@pekajemaps.homeip.net> writes:

> Useless use of cat:
>
> while read;do echo $REPLY;done> /tmp/fil <<STOP
> bla bla
> STOP

Useless addition of complexity.

Flere tegn, brug af sideeffekt af indbygget funktion (hvilket vil sige
at det ligger begravet i en enorm manualside) og ingen forskel i
forhold til at bruge et standard program på den måde det er tiltænkt.

I min verden kan man lave rigtigt, rigtigt mange kald af cat i løbet
af den forskel i tid det tager for en vedligeholder at vedligeholde de
to versioner, og der er ingen grund - udove uvidenhed - til at
lave ovenstående.

Nu kan du jo så oplyse mig om en gyldig grund til at gøre det :)

--
Thorbjørn Ravn Andersen

---

Den 23 Sep 2005 19:15:21 +0200 skrev Thorbjoern Ravn Andersen:
> Peter Jensen <usenet@pekajemaps.homeip.net> writes:
>
>> Useless use of cat:
>>
>> while read;do echo $REPLY;done> /tmp/fil <<STOP
>> bla bla
>> STOP
>
> Useless addition of complexity.
>
> Flere tegn, brug af sideeffekt af indbygget funktion (hvilket vil sige
> at det ligger begravet i en enorm manualside) og ingen forskel i
> forhold til at bruge et standard program på den måde det er tiltænkt.
>
> I min verden kan man lave rigtigt, rigtigt mange kald af cat i løbet
> af den forskel i tid det tager for en vedligeholder at vedligeholde de
> to versioner, og der er ingen grund - udove uvidenhed - til at
> lave ovenstående.
>
> Nu kan du jo så oplyse mig om en gyldig grund til at gøre det :)

Jeg kan komme på en - at den også virker efter en eller anden knold
har lavet en # rm -rf / Men det er ikke relevant i et script, da
scriptet nok heller ikke vil overleve.

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

---

On Fri, 23 Sep 2005 17:25:41 +0000, Kent Friis wrote:

>
> Jeg kan komme på en - at den også virker efter en eller anden knold har
> lavet en # rm -rf / Men det er ikke relevant i et script, da scriptet
> nok heller ikke vil overleve.
Øh, ikke forstået. Mig bekendt ligger sh og bash i /usr/bin, der vel
også vil være fjernet med ovenstående kommando?

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

---

Den Fri, 23 Sep 2005 19:56:47 +0200 skrev Michael Rasmussen:
> On Fri, 23 Sep 2005 17:25:41 +0000, Kent Friis wrote:
>
>>
>> Jeg kan komme på en - at den også virker efter en eller anden knold har
>> lavet en # rm -rf / Men det er ikke relevant i et script, da scriptet
>> nok heller ikke vil overleve.
> Øh, ikke forstået. Mig bekendt ligger sh og bash i /usr/bin, der vel
> også vil være fjernet med ovenstående kommando?

Ja, så man kan ikke starte en ny shell. Men den der allerede kører
vil faktisk virke fint, da filen først fjernes fysisk fra disken
når den terminerer.

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

---

Thorbjoern Ravn Andersen wrote:

>> Useless use of cat:
>>
>> while read;do echo $REPLY;done> /tmp/fil <<STOP
>> bla bla
>> STOP
>
> Useless addition of complexity.
>
> Flere tegn, brug af sideeffekt af indbygget funktion (hvilket vil sige
> at det ligger begravet i en enorm manualside) og ingen forskel i
> forhold til at bruge et standard program på den måde det er tiltænkt.
>
> I min verden kan man lave rigtigt, rigtigt mange kald af cat i løbet
> af den forskel i tid det tager for en vedligeholder at vedligeholde de
> to versioner, og der er ingen grund - udove uvidenhed - til at lave
> ovenstående.
>
> Nu kan du jo så oplyse mig om en gyldig grund til at gøre det :)

Så-gerne ... På et minimalt system hvor 'cat' ikke er installeret (ja,
jeg undrede mig også), men hvor en shell der implementerer read og here
documents på samme måde som bash, findes. Har engang arbejdet på sådan
et system, og det tog mig noget tid at finde ud af hvordan man kunne
gøre dette. Ovenstående er hvad jeg kom frem til, men der er muligvis
også andre og bedre metoder.

Det være sagt, så ville jeg nok også selv gøre det med 'cat' i 99.9% af
tilfældene, da det er noget nemmere at huske og vedligeholde. Jeg
betragter det som en intellektuel øvelse. Hvor mange eksterne
programkald kan egentligt hives ud af et typisk script, uden at miste
relevant funktionalitet?

--
PeKaJe

Oh, cruel fate. Why do you mock me?
      -- Homer Simpson, Bart the Daredevil

---

Peter Jensen <usenet@pekajemaps.homeip.net> writes:

> > Nu kan du jo så oplyse mig om en gyldig grund til at gøre det :)
>
> Så-gerne ... På et minimalt system hvor 'cat' ikke er installeret (ja,
> jeg undrede mig også), men hvor en shell der implementerer read og here
> documents på samme måde som bash, findes. Har engang arbejdet på sådan
> et system, og det tog mig noget tid at finde ud af hvordan man kunne
> gøre dette. Ovenstående er hvad jeg kom frem til, men der er muligvis
> også andre og bedre metoder.

Hvad i alverden er det dog for et system? Det lyder ikke særligt
Unixkompatibelt :)

Uanset hvad så ville en busybox vel kunne løse de fleste problemer, så
man kan lave pænere shellscripts.

> Det være sagt, så ville jeg nok også selv gøre det med 'cat' i 99.9% af
> tilfældene, da det er noget nemmere at huske og vedligeholde. Jeg
> betragter det som en intellektuel øvelse. Hvor mange eksterne
> programkald kan egentligt hives ud af et typisk script, uden at miste
> relevant funktionalitet?

Det afhænger jo meget af hvilken kommandofortolker man bruger.

Jeg blev engang brændt af en "shift 2" hvor argumentet ikke blev taget
i betragtning. Så selv /bin/sh er ikke altid /bin/sh.

--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen <nospam0000@gmail.com> writes:

> Peter Jensen <usenet@pekajemaps.homeip.net> writes:
>
> > > Nu kan du jo så oplyse mig om en gyldig grund til at gøre det :)
> >
> > Så-gerne ... På et minimalt system hvor 'cat' ikke er installeret (ja,
> > jeg undrede mig også), men hvor en shell der implementerer read og here
> > documents på samme måde som bash, findes. Har engang arbejdet på sådan
> > et system, og det tog mig noget tid at finde ud af hvordan man kunne
> > gøre dette. Ovenstående er hvad jeg kom frem til, men der er muligvis
> > også andre og bedre metoder.
>
> Hvad i alverden er det dog for et system? Det lyder ikke særligt
> Unixkompatibelt :)

SVJH kan en SunOS3 (~BSD) med en fejl tilstrækkelig tidligt i sine
boot scripts gøre det.

--
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

---

Thorbjoern Ravn Andersen wrote:

>> Så-gerne ... På et minimalt system hvor 'cat' ikke er installeret
>> (ja, jeg undrede mig også), men hvor en shell der implementerer read
>> og here documents på samme måde som bash, findes. Har engang
>> arbejdet på sådan et system, og det tog mig noget tid at finde ud af
>> hvordan man kunne gøre dette. Ovenstående er hvad jeg kom frem til,
>> men der er muligvis også andre og bedre metoder.
>
> Hvad i alverden er det dog for et system? Det lyder ikke særligt
> Unixkompatibelt :)

Nøh, men det var småt og embedded. Til det formål er 'cat' ikke altid
lille nok, specielt hvis den egentlig ikke bliver brugt til så meget
andet.

> Uanset hvad så ville en busybox vel kunne løse de fleste problemer, så
> man kan lave pænere shellscripts.

Men igen, så praktisk som busybox er, så fylder den pænt godt (omtrent
så meget som bash). Det betyder nok ikke det store i dag, men der er
dog situationer hvor et minimalt disk/RAM footprint er ønskeligt. Det
skal nok også nævnes at busybox ikke var helt så udviklet for nogle år
siden. At den så i dag nok ville være mit første valg til systemer med
mere end 2-3 MB plads er så noget helt andet.

>> Det være sagt, så ville jeg nok også selv gøre det med 'cat' i 99.9%
>> af tilfældene, da det er noget nemmere at huske og vedligeholde. Jeg
>> betragter det som en intellektuel øvelse. Hvor mange eksterne
>> programkald kan egentligt hives ud af et typisk script, uden at miste
>> relevant funktionalitet?
>
> Det afhænger jo meget af hvilken kommandofortolker man bruger.
>
> Jeg blev engang brændt af en "shift 2" hvor argumentet ikke blev taget
> i betragtning. Så selv /bin/sh er ikke altid /bin/sh.

Hmm ... Så er det vist heller ikke POSIX kompatibelt længere. Hvor
oplevede du dette, og hvornår?

--
PeKaJe

Everybody likes a kidder, but nobody lends him money.
      -- Arthur Miller

---

Peter Jensen <usenet@pekajemaps.homeip.net> writes:

> > Jeg blev engang brændt af en "shift 2" hvor argumentet ikke blev taget
> > i betragtning. Så selv /bin/sh er ikke altid /bin/sh.
>
> Hmm ... Så er det vist heller ikke POSIX kompatibelt længere. Hvor
> oplevede du dette, og hvornår?

En Sony NEWS maskine i starten af 90'erne.

Det er den eneste maskine jeg har set med en skærm der var højere end
den var bred.
--
Thorbjørn Ravn Andersen

---

Peter Jensen wrote:
>
> Leif Neland wrote:
>
> > cat >/tmp/fil <<STOP
> > bla bla
> > STOP
>
> Useless use of cat:

Nej, useless use of cat dækker over tilfælde, der
kunne være lavet simplere uden cat. F.eks. er
cat fil | kommando
for det meste overflødig brug af cat. Dog skal
man være opmærksom på, at nogle kommandoer faktisk
kan finde på at opføre sig forskelligt alt efter
om stdin er en fil eller en pipe, så selv den brug
kan være relevant.

>
> while read;do echo $REPLY;done> /tmp/fil <<STOP
> bla bla
> STOP

Jeg sad for et par dage siden og havde så mange
problemer med read, at jeg måtte give op. Der er
så mange tegn, som read ikke håndterede som jeg
ville have den til. En -r option løste nogle af
mine problemer, men jeg fik den blev ved med at
smide whitespace i slutningen af linierne væk.

Desuden er read nødt til at læse bytes ind en ad
gangen for at være sikker på ikke at læse for
mange. Dermed giver cat væsentligt bedre
performance.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Desuden er read nødt til at læse bytes ind en ad
> gangen for at være sikker på ikke at læse for
> mange. Dermed giver cat væsentligt bedre
> performance.

Det er lige meget. Operativsystemet buffer det.

--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen <nospam0000@gmail.com> writes:

> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Desuden er read nødt til at læse bytes ind en ad
> > gangen for at være sikker på ikke at læse for
> > mange. Dermed giver cat væsentligt bedre
> > performance.
>
> Det er lige meget. Operativsystemet buffer det.

En fortolket shell-løkke i stedet for en helt naturlig brug af cat på
et here-document forekommer mig nu ikke desto mindre at være et ret
skidt eksempel på "useless use"....

(Husk: En ægte hacker skriver device drivere med "cat >")

--
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

---

Thorbjoern Ravn Andersen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Desuden er read nødt til at læse bytes ind en ad
> > gangen for at være sikker på ikke at læse for
> > mange. Dermed giver cat væsentligt bedre
> > performance.
>
> Det er lige meget. Operativsystemet buffer det.

Et kontekstskift per byte koster CPU tid.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> > Det er lige meget. Operativsystemet buffer det.
>
> Et kontekstskift per byte koster CPU tid.

Jada, og det gør interrupts og diskaktivitet også.

Spørgsmålet er om det er målbart?
--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > > Det er lige meget. Operativsystemet buffer det.
> >
> > Et kontekstskift per byte koster CPU tid.
>
> Jada, og det gør interrupts og diskaktivitet også.
>
> Spørgsmålet er om det er målbart?

En faktor 20 er nemt at måle.

[root@hactar:pts/23] date ; cat </dev/hda5 | md5sum ; date ; while read -r LINE ; do echo "$LINE" ; done </dev/hda5 | md5sum ; date
Sat Sep 24 15:19:33 CEST 2005
e46846a7055a630c69fc530073196d34 -
Sat Sep 24 15:19:41 CEST 2005
ca94c85f7581cab0192d1f08298adcce -
Sat Sep 24 15:22:11 CEST 2005
[root@hactar:pts/23]

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Peter Jensen <usenet@pekajemaps.homeip.net> writes:

> (En mindre og formentlig ubetydelig forskel, ja. Der er dog nogle
> situationer hvor det er bedst ikke at kalde eksterne programmer unødigt)

Bruger man så ikke også minimale shell hvor echo ikke er en indbygget
kommando?

--
Peter Makholm | What if:
peter@makholm.net | IBM bought Xenix from Microsoft instead of buying
http://hacking.dk | DOS?

---

"Leif Neland" <leifn@neland.dk> writes:

> Jeg prøver med
> echo >/tmp/fil <<STOP
> bla bla bla
> STOP

Echo læser ikke data fra stdin, brug cat istedet:

brother@pma-linux$ cat > /tmp/fil << STOP
> foo
> bar
> baz
> STOP
brother@pma-linux$ cat /tmp/fil
foo
bar
baz
brother@pma-linux$

--
Peter Makholm | According to the hacker ethic, the meaning of life
peter@makholm.net | is not Friday, but it is not Sunday either
http://hacking.dk | -- Pekka Himanen