---

Jeg har et Bourne Shell script der kører i en "while true"-løkke, men
jeg vil gerne, at brugeren har en måde at afslutte det på. Ctrl+C virker
naturligvis, men jeg ville gerne lige have programmet til at rydde en
smule op, inden det afslutter. Hvad gør jeg?

while true
do
...
done

Hvis jeg starter et eksternt program fra et shell script, hvordan får
jeg så afsluttet det program igen? Kan jeg finde dets PID?

---

On Sat, 20 Dec 2008 02:12:38 +0100, Lars wrote:

> Jeg har et Bourne Shell script der kører i en "while true"-løkke, men
> jeg vil gerne, at brugeren har en måde at afslutte det på. Ctrl+C virker
> naturligvis, men jeg ville gerne lige have programmet til at rydde en
> smule op, inden det afslutter. Hvad gør jeg?

Google'r?

Første hit på bash trap example er:

"Bash Guide for Beginners
Chapter 12. Catching signals

[...]

Here is a very simple example, catching Ctrl+C from the user, upon
which a message is printed. When you try to kill this program without
specifying the KILL signal, nothing will happen:

#!/bin/bash
# traptest.sh

trap "echo Booh!" SIGINT SIGTERM
echo "pid is $$"

while : # This is the same as "while true".
do
sleep 60 # This script is not really doing anything.
done"

- http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_02.html

Længere nede på samme side er et eksempel på at rydde op via en trap på
når scriptet afsluttes (trap "blahblah" EXIT).


Mvh.

Adam

--
"We get our thursdays from a banana." Adam Sjøgren
asjo@koldfront.dk

---

Adam Sjøgren wrote:
>> Jeg har et Bourne Shell script der kører i en "while true"-løkke, men
>> jeg vil gerne, at brugeren har en måde at afslutte det på. Ctrl+C virker
>> naturligvis, men jeg ville gerne lige have programmet til at rydde en
>> smule op, inden det afslutter. Hvad gør jeg?
>
> Google'r?
>
> Første hit på bash trap example er:

Ja, nu nævnte jeg jo hverken "bash" eller "trap" - så er det knapt så
enkelt. Men det ser ud til at det virker i sh også. Så tak for svaret.

Nogen idéer til hvordan jeg får PID fra et eksternt program jeg kører
fra et script. Specifikt drejer det sig om et der hedder shell-fm, som
jeg bare kører sådan her:

#!/bin/sh

shell-fm

while true
do
...
done

Jeg vil gerne kunne dræbe shell-fm-processen fra mit script.

---

Lars Stokholm wrote:
> Adam Sjøgren wrote:
>>> Jeg har et Bourne Shell script der kører i en "while true"-løkke, men
>>> jeg vil gerne, at brugeren har en måde at afslutte det på. Ctrl+C virker
>>> naturligvis, men jeg ville gerne lige have programmet til at rydde en
>>> smule op, inden det afslutter. Hvad gør jeg?
>> Google'r?
>>
>> Første hit på bash trap example er:
>
> Ja, nu nævnte jeg jo hverken "bash" eller "trap" - så er det knapt så
> enkelt. Men det ser ud til at det virker i sh også. Så tak for svaret.
>
Selvom du har #!/bin/sh" i dit script er det sikkert aligevel bash du
bruger. Jeg mener ikke der er nogen linux-distrub. der har sh. /bin/sh
er et link til bash: /bin/sh -> bash*


> Nogen idéer til hvordan jeg får PID fra et eksternt program jeg kører
> fra et script. Specifikt drejer det sig om et der hedder shell-fm, som
> jeg bare kører sådan her:
>
> #!/bin/sh
>
> shell-fm
>
> while true
> do
> ...
> done
>
> Jeg vil gerne kunne dræbe shell-fm-processen fra mit script.
Process-id kan findes med pgrep og en process kan dræbes med pkill.
Se man pkill og man pgrep

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk

---

Jørgen Heesche skrev:

> Selvom du har #!/bin/sh" i dit script er det sikkert aligevel bash
> du bruger. Jeg mener ikke der er nogen linux-distrub. der har sh.
> /bin/sh er et link til bash: /bin/sh -> bash*

Nyere udgaver af Ubuntu bruger dash som sh, her på Hardy:

#v+

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 2007-12-16 11:57 /bin/sh -> dash
$

#v-

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

On Sat, 20 Dec 2008 11:31:14 +0100, Lars wrote:

> Adam Sjøgren wrote:

>>> Hvad gør jeg?

>> Google'r?

>> Første hit på bash trap example er:

> Ja, nu nævnte jeg jo hverken "bash" eller "trap" - så er det knapt så
> enkelt.

Nu spurgte du eksplicit om hvad du skulle gøre, og jeg kom med mit bud.
Beklager at det hjalp.

> Men det ser ud til at det virker i sh også. Så tak for svaret.

For mig er "Bourne Shell" et lidt løst begreb, derfor svarede jeg med et
konkret eksempel fra en shell der Bourne kompatibel og som mange bruger.

Hvilken shell er det du bruger, da? Det er normalt nemmere at hjælpe
hvis man ikke skal gætte.

> Nogen idéer til hvordan jeg får PID fra et eksternt program jeg kører
> fra et script.

Det tror jeg at jeg vil afholde mig fra at forsøge at svare på.


Mvh.

--
"Perl is a Shinto shrine." Adam Sjøgren
asjo@koldfront.dk

---

On 2008-12-20, Jørgen Heesche <heesche@webspeed.dk> wrote:
> Lars Stokholm wrote:
>> Adam Sjøgren wrote:
>>>> Jeg har et Bourne Shell script der kører i en "while true"-løkke, men
>>>> jeg vil gerne, at brugeren har en måde at afslutte det på. Ctrl+C virker
>>>> naturligvis, men jeg ville gerne lige have programmet til at rydde en
>>>> smule op, inden det afslutter. Hvad gør jeg?
>>> Google'r?
>>>
>>> Første hit på bash trap example er:
>>
>> Ja, nu nævnte jeg jo hverken "bash" eller "trap" - så er det knapt så
>> enkelt. Men det ser ud til at det virker i sh også. Så tak for svaret.
>>
> Selvom du har #!/bin/sh" i dit script er det sikkert aligevel bash du
> bruger. Jeg mener ikke der er nogen linux-distrub. der har sh. /bin/sh
> er et link til bash: /bin/sh -> bash*

Selvom man har bash som /bin/sh, så bør man stadig bruge #! /bin/bash i
sit script hvis man ikke holder sig til ren bourne shell.

/Sune

---

Adam Sjøgren wrote:
> On Sat, 20 Dec 2008 11:31:14 +0100, Lars wrote:
>> Ja, nu nævnte jeg jo hverken "bash" eller "trap" - så er det knapt så
>> enkelt.
>
> Nu spurgte du eksplicit om hvad du skulle gøre, og jeg kom med mit bud.

Men du antyder at jeg kunne have fundet svaret, ved at Google på "bash
trap example" og det er lidt svært, når jeg slet ikke havde tænkt i
retning af hverken bash eller trap.

> Beklager at det hjalp.

Hvis du ikke svarer for at hjælpe, hvorfor svarer du så?

> Hvilken shell er det du bruger, da? Det er normalt nemmere at hjælpe
> hvis man ikke skal gætte.

Du behøver jo ikke gætte, når jeg siger det en Bourne Shell. Lad blot
være med at antyde, at min dovenskab har afholdt mig fra at lave en
simpel Google-søgning.

---

Jørgen Heesche wrote:
> Selvom du har #!/bin/sh" i dit script er det sikkert aligevel bash du
> bruger. Jeg mener ikke der er nogen linux-distrub. der har sh. /bin/sh
> er et link til bash: /bin/sh -> bash*

Jeg har det fra http://www.freebsd.org/doc/en/books/handbook/shells.html

Jeg ved i hvert fald, at det ikke er bash - for den har jeg slet ikke
installeret. Men jeg skriver et script der skal være Bourne Shell
kompatibelt, så det er egentlig ligemeget hvilken shell jeg bruger.

> Process-id kan findes med pgrep og en process kan dræbes med pkill.
> Se man pkill og man pgrep

Det vil jeg kigge på. Tak for svaret.

---

Lars Stokholm wrote:
> Jørgen Heesche wrote:
>> Selvom du har #!/bin/sh" i dit script er det sikkert aligevel bash du
>> bruger. Jeg mener ikke der er nogen linux-distrub. der har sh. /bin/sh
>> er et link til bash: /bin/sh -> bash*
>
> Jeg har det fra http://www.freebsd.org/doc/en/books/handbook/shells.html
>
> Jeg ved i hvert fald, at det ikke er bash - for den har jeg slet ikke
> installeret. Men jeg skriver et script der skal være Bourne Shell
> kompatibelt, så det er egentlig ligemeget hvilken shell jeg bruger.
>
Det er faktisk ikke ligegyldigt, der er mange shells og syntaksen
varierer. Du kan med 'ls -l /bin/sh se hvilken, men du har øjensynlig en
Bourne Shell kompatibel shell. Jeg mener ikke at Linux har den
oprindelige Bourne Shell,
>> Process-id kan findes med pgrep og en process kan dræbes med pkill.
>> Se man pkill og man pgrep
>
> Det vil jeg kigge på. Tak for svaret.


--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk

---

Lars Stokholm <lars.stokholm@gmail.com> writes:

> Nogen idéer til hvordan jeg får PID fra et eksternt program jeg kører
> fra et script. Specifikt drejer det sig om et der hedder shell-fm, som
> jeg bare kører sådan her:

Der er en speciel variabel der angiver PID'en for den sidste kommando
der er startet i baggrunden. I dit eksempel starter du godt nok ikke
shell-fm i baggrunden, men det betyder jo også at dit script ikke selv
kan udfære noget så lønge shell-fm processen ikke er termineret.

//Makholm

---

On Sat, 20 Dec 2008 14:27:37 +0100, Lars wrote:

> Adam Sjøgren wrote:

>> On Sat, 20 Dec 2008 11:31:14 +0100, Lars wrote:

>>> Ja, nu nævnte jeg jo hverken "bash" eller "trap" - så er det knapt
>>> så enkelt.

>> Nu spurgte du eksplicit om hvad du skulle gøre, og jeg kom med mit
>> bud.

> Men du antyder at jeg kunne have fundet svaret, ved at Google på "bash
> trap example"

Nej, jeg siger at det var sådan jeg fandt svaret. Hvis du havde søgt på
det samme havde du naturligvis også fundet det.

Der er ingen antydninger involveret fra min side, det må stå for din
helt egen regning.

> og det er lidt svært, når jeg slet ikke havde tænkt i retning af
> hverken bash eller trap.

Det siger sig selv.

Når du ikke skriver hvad du har søgt på uden held, er det svært at
kommentere den del af din jagt på en løsning.

>> Beklager at det hjalp.

> Hvis du ikke svarer for at hjælpe, hvorfor svarer du så?

Jeg tror du overhørte sarkasmen.

Jeg kunne ikke på forhånd vide at du ville fokusere på måden jeg fandt
svaret til dig frem for resultatet; den konkrete løsning på dit problem.

>> Hvilken shell er det du bruger, da? Det er normalt nemmere at hjælpe
>> hvis man ikke skal gætte.

> Du behøver jo ikke gætte, når jeg siger det en Bourne Shell.

Ville det ikke være lige så nemt at svare på hvilken shell det specifikt
er, i stedet for at sige "en Bourne Shell"?

Som jeg skrev er "en Bourne Shell" ikke et klart begreb for mig (om det
er korrekt eller ej skal jeg ikke kunne sige, for mig giver udtrykket et
billede af en klasse af shells, der er Bourne-agtige/kompatible), deraf
mit spørgsmål.

> Lad blot være med at antyde, at min dovenskab har afholdt mig fra at
> lave en simpel Google-søgning.

Du bad om bud på hvad du skulle gøre, jeg gav mit bud. Hvis du ikke
ønsker svar, hvorfor så spørge?


Mvh.

Adam

--
"Eternal evil Adam Sjøgren
Yeah it stares behind the desk" asjo@koldfront.dk

---

Peter Makholm wrote:
> Lars Stokholm <lars.stokholm@gmail.com> writes:
>> Nogen idéer til hvordan jeg får PID fra et eksternt program jeg kører
>> fra et script. Specifikt drejer det sig om et der hedder shell-fm, som
>> jeg bare kører sådan her:
>
> Der er en speciel variabel der angiver PID'en for den sidste kommando
> der er startet i baggrunden. I dit eksempel starter du godt nok ikke
> shell-fm i baggrunden, men det betyder jo også at dit script ikke selv
> kan udfære noget så lønge shell-fm processen ikke er termineret.

Jo, det er så tilfældigvis tilfældet, men det kunne du jo ikke vide. :)
Jeg starter den med en -d option (fork to background).

---

Lars Stokholm skrev:

> Jeg starter den med en -d option (fork to background).

Giver $! (skal nok høstes umiddelbart efter at programmet er startet)
mon en pid du kan bruge? Eller er det kun med bash, eller hvis man
starter programmet med '&'?

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Den Sat, 20 Dec 2008 18:10:13 +0000 (UTC) skrev Klaus Alexander Seistrup:
> Lars Stokholm skrev:
>
>> Jeg starter den med en -d option (fork to background).
>
> Giver $! (skal nok høstes umiddelbart efter at programmet er startet)
> mon en pid du kan bruge? Eller er det kun med bash, eller hvis man
> starter programmet med '&'?

$! *kan* kun give pid'en fra &. Hvad programmet starter af yderligere
processer får bash intet at vide om.

Men programmet bør have en /var/run/program.pid, hvor pid'en kan
findes.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis skrev:

> $! *kan* kun give pid'en fra &.

Så kan OP måske bare starte programmet uden -d og med &.

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Den Sat, 20 Dec 2008 19:27:11 +0000 (UTC) skrev Klaus Alexander Seistrup:
> Kent Friis skrev:
>
>> $! *kan* kun give pid'en fra &.
>
> Så kan OP måske bare starte programmet uden -d og med &.

Sandsynligvis, ja.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis wrote:
> Men programmet bør have en /var/run/program.pid, hvor pid'en kan
> findes.

Det har det desværre ikke, så jeg prøvede Klaus' forslag:

shell-fm -i ${IP} -p ${PORT} & > /dev/null 2>&1 || exit 69

Men det resulterer I, at output fra shell-fm ender i den terminal jeg
kører scriptet i. Desuden ser det nu også ud til at være shell-fm der
fanger min Ctrl-C og ikke mit script.

Før stod der:

shell-fm -d -i ${IP} -p ${PORT} > /dev/null 2>&1 || exit 69

Det virkede fint, bortset fra det med PIDet.

---

Lars Stokholm skrev:

> shell-fm -i ${IP} -p ${PORT} & > /dev/null 2>&1 || exit 69
>
> Men det resulterer I, at output fra shell-fm ender i den terminal
> jeg kører scriptet i.

Når du har omdirigeret både standard output og error?

> Desuden ser det nu også ud til at være shell-fm der fanger min
> Ctrl-C og ikke mit script.

Sker det osse hvis du omdirigerer standard input?

   shell-fm </dev/null >/dev/null 2>&1

> Før stod der:
>
> shell-fm -d -i ${IP} -p ${PORT} > /dev/null 2>&1 || exit 69
>
> Det virkede fint, bortset fra det med PIDet.

Jeg spekulerer på om det vil fungere hvis du kører shell-fm fra et
wrapper-script, der exec'er sig selv væk. På den måde vil du kunne
få pid'en af shell-fm. Fx noget i retning af:

#v+
   #!/bin/sh

   # Væk med stdin, stdout og stderr
   exec </dev/null >/dev/null 2>&1

   # Gem PID'en et passende sted
   echo $$ >/var/run/shell-fm.pid

   exec shell-fm -d

   # eof
#v-

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Den Sun, 21 Dec 2008 08:58:50 +0000 (UTC) skrev Klaus Alexander Seistrup:
>
> Jeg spekulerer på om det vil fungere hvis du kører shell-fm fra et
> wrapper-script, der exec'er sig selv væk. På den måde vil du kunne
> få pid'en af shell-fm. Fx noget i retning af:
>
> #v+
>    #!/bin/sh
>
>    # Væk med stdin, stdout og stderr
>    exec </dev/null >/dev/null 2>&1
>
>    # Gem PID'en et passende sted
>    echo $$ >/var/run/shell-fm.pid
>
>    exec shell-fm -d
>

Samme problem som det oprindelige script, du vil få pid'en på den
shell-fm der bliver startet fra scriptet, ikke den shell-fm
fork()'er senere.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis skrev:

>>    exec shell-fm -d
>
> Samme problem som det oprindelige script, du vil få pid'en
> på den shell-fm der bliver startet fra scriptet, ikke den
> shell-fm fork()'er senere.

Ok, måske har jeg vrøvlet i argumenterne, men meningen er god nok:
Det er ikke meningen at shell-fm skal fork()'e her, den skal blot
overtage wrapper-scriptets proces. Stryg -d, så virker det efter
hensigten.

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Den Sun, 21 Dec 2008 13:27:20 +0000 (UTC) skrev Klaus Alexander Seistrup:
> Kent Friis skrev:
>
>>>    exec shell-fm -d
>>
>> Samme problem som det oprindelige script, du vil få pid'en
>> på den shell-fm der bliver startet fra scriptet, ikke den
>> shell-fm fork()'er senere.
>
> Ok, måske har jeg vrøvlet i argumenterne, men meningen er god nok:
> Det er ikke meningen at shell-fm skal fork()'e her, den skal blot
> overtage wrapper-scriptets proces. Stryg -d, så virker det efter
> hensigten.

Lige så godt som det oprindelige script med & i stedet for -d.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis skrev:

> Lige så godt som det oprindelige script med & i stedet for -d.

Nej, der mangler man PID'en på shell-fm, gør man ikke? Det er dét
problem, og ikke noget andet, jeg har forsøgt at løse med wrapper-
scriptet.

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Den Sun, 21 Dec 2008 13:44:45 +0000 (UTC) skrev Klaus Alexander Seistrup:
> Kent Friis skrev:
>
>> Lige så godt som det oprindelige script med & i stedet for -d.
>
> Nej, der mangler man PID'en på shell-fm, gør man ikke?

$! indeholder PID'en på et program startet med &

Grunden til at han manglede PID'en var netop -d. At shell-fm fork'er
efter at være startet.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis skrev:

>> Nej, der mangler man PID'en på shell-fm, gør man ikke?
>
> $! indeholder PID'en på et program startet med &
>
> Grunden til at han manglede PID'en var netop -d. At shell-fm
> fork'er efter at være startet.

Nå, så fred være med det.

/me finder på noget sjovere at lave...

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

On Sat, 20 Dec 2008 22:33:05 +0100, Lars wrote:

> Men det resulterer I, at output fra shell-fm ender i den terminal jeg
> kører scriptet i. Desuden ser det nu også ud til at være shell-fm der
> fanger min Ctrl-C og ikke mit script.

Måske kunne du sende "quit" til shell-fm når den skal lukke ned? Så
behøver du ikke kende dens PID:

echo quit | nc ${IP} ${PORT}

eller noget? (scripts/zcontrol eller unix.pl kan sikkert også bruges).


Bar' en tanke,

Adam

--
"Vegetarian progressive grindcore" Adam Sjøgren
asjo@koldfront.dk

---

Adam Sjøgren wrote:
> Måske kunne du sende "quit" til shell-fm når den skal lukke ned? Så
> behøver du ikke kende dens PID:
>
> echo quit | nc ${IP} ${PORT}
>
> eller noget? (scripts/zcontrol eller unix.pl kan sikkert også bruges).
>
> Bar' en tanke,

Og en god tanke. ;) Det gør jeg faktisk også nu i min cleanup funktion
og det virker fint - når det virker. Men jeg har oplevet et par gange at
shell-fm går i stå når den skal skifte nummer. Hverken skip, quit eller
andre kommandoer virker. Så jeg gav mig straks til at finde ud af
hvordan jeg skulle gennemtvinge en genstart, i det tilfælde.

Men det har faktisk kun teoretisk interesse nu, for jeg har ikke oplevet
det længe. Men oplever jeg det igen, vil jeg nok sætte mine kræfter på
at strikke en bug report sammen i stedet.

Nu har jeg imidlertid sat et problem til verden og så vil jeg gerne have
løst det - det kunne være jeg får brug for det til en anden gang. :)

---

Jørgen Heesche wrote:
> Det er faktisk ikke ligegyldigt, der er mange shells og syntaksen
> varierer. Du kan med 'ls -l /bin/sh se hvilken, men du har øjensynlig en
> Bourne Shell kompatibel shell. Jeg mener ikke at Linux har den
> oprindelige Bourne Shell,

%ls -l /bin/sh
-r-xr-xr-x 1 root wheel 113244 Sep 28 03:15 /bin/sh

Så vidt jeg kan se er den i FreeBSD baseret på ash:
http://en.wikipedia.org/wiki/Unix_shell#Bourne_shell_compatible

Men jeg holder stadig på at det er ligemeget. Jeg søgte et svar der var
Bourne Shell kompatibelt. Den udmelding burde være klar nok.

---

---

Michael Rasmussen wrote:
> PID=3D$(ps -C <programnavn> -o pid=3D | awk '{sub(/^[ \t]+/, ""); print}')
>
> kill -TERM $PID
>
> Da ovenst=E5ende er standard POSIX, burde det virke p=E5 enhver *BSD.

Det gør det ikke, må jeg desværre meddele.

$ ps -C slrn -o pid= | awk '{sub(/^[ \t]+/, ""); print}'
ps: illegal argument: slrn

I øvrigt ser dit indlæg f*cked up ud, i min slrn. Er det slrn der er
noget galt med eller dit indlæg? Jeg måtte bruge Google Groups for at se
hvad der egentlig stod.

---

On Sun, 21 Dec 2008 00:28:39 +0100
Lars Stokholm <lars.stokholm@gmail.com> wrote:

> $ ps -C slrn -o pid= | awk '{sub(/^[ \t]+/, ""); print}'
> ps: illegal argument: slrn
>
Så er FreeBSD's ps desværre ikke hverken POSIX eller IEEE kompatibel:-\
POSIX og IEEE angiver følgende for option -C
-C cmdlist Select by command name.
This selects the processes whose executable name
is given in cmdlist.

Prøv om du ikke kan finde tilsvarende mulig under ps i FreeBSD.

> I øvrigt ser dit indlæg f*cked up ud, i min slrn. Er det slrn der er
> noget galt med eller dit indlæg? Jeg måtte bruge Google Groups for at se
> hvad der egentlig stod.
Forstår slrn mime formatteret tekst og digitalt signerede indlæg?
Content-Type: multipart/signed; boundary="Sig_/19+zNpF4OC2qMEI_OZp9fPW";
protocol="application/pgp-signature"; micalg=PGP-SHA1

--
Hilsen/Regards
Michael Rasmussen
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

Lars Stokholm skrev:

> Jeg har et Bourne Shell script der kører i en "while true"-løkke, men
> jeg vil gerne, at brugeren har en måde at afslutte det på. Ctrl+C virker
> naturligvis, men jeg ville gerne lige have programmet til at rydde en
> smule op, inden det afslutter. Hvad gør jeg?
>
> while true
> do
> ...
> done
>
> Hvis jeg starter et eksternt program fra et shell script, hvordan får
> jeg så afsluttet det program igen? Kan jeg finde dets PID?

Hvad med
killall programnavn
det bruger jeg når jeg vil afslutte et kørende program, og ikke gider
interessere mig for des pid osv.

check dog lige hvad killall gør på DIT system, der er AFAIK nogle *nix'er
som lukker systemet ned når det får en killall.

--
Mvh

Ivar Madsen

---

Den Sun, 21 Dec 2008 07:58:17 +0100 skrev Ivar Madsen:
> Lars Stokholm skrev:
>
>> Jeg har et Bourne Shell script der kører i en "while true"-løkke, men
>> jeg vil gerne, at brugeren har en måde at afslutte det på. Ctrl+C virker
>> naturligvis, men jeg ville gerne lige have programmet til at rydde en
>> smule op, inden det afslutter. Hvad gør jeg?
>>
>> while true
>> do
>> ...
>> done
>>
>> Hvis jeg starter et eksternt program fra et shell script, hvordan får
>> jeg så afsluttet det program igen? Kan jeg finde dets PID?
>
> Hvad med
> killall programnavn
> det bruger jeg når jeg vil afslutte et kørende program, og ikke gider
> interessere mig for des pid osv.

Den tager så alle instanser af programmet, ikke kun den scriptet selv
har startet. Det kan virke fint på en enkelt-bruger PC, hvis man ved
at man aldrig vil køre mere end en instans.

> check dog lige hvad killall gør på DIT system, der er AFAIK nogle *nix'er
> som lukker systemet ned når det får en killall.

Ikke decideret lukker systemet ned, de mener bare "kill all"
bogstaveligt. Den kill'er alt undtagen init, der vil starte de ting op
igen der står i inittab - primært getty. Så man kan faktisk stadig logge
ind, ikke bare på konsollen, men også samtlige (direkte forbundne)
serielle terminaler.

telnetd og sshd er normalt ikke i inittab, xdm kan være.

(Ja, jeg har prøvet. Jeg nåede dog at trykke ctrl-c, så det kun var
omkring halvdelen af brugerne der blev smidt af systemet).

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis wrote:
> Den Sun, 21 Dec 2008 07:58:17 +0100 skrev Ivar Madsen:
>> Hvad med
>> killall programnavn
>> det bruger jeg når jeg vil afslutte et kørende program, og ikke gider
>> interessere mig for des pid osv.
>
> Den tager så alle instanser af programmet, ikke kun den scriptet selv
> har startet. Det kan virke fint på en enkelt-bruger PC, hvis man ved
> at man aldrig vil køre mere end en instans.

Ja, jeg bryder mig principielt heller ikke om løsningen.

---

Klaus Alexander Seistrup wrote:
> Lars Stokholm skrev:
>> shell-fm -i ${IP} -p ${PORT} & > /dev/null 2>&1 || exit 69
>>
>> Men det resulterer I, at output fra shell-fm ender i den terminal
>> jeg kører scriptet i.
>
> Når du har omdirigeret både standard output og error?

Var det et retorisk spørgsmål? :) Med mindre jeg har misforstået noget,
så er det det jeg har prøvet at gøre ovenfor. Men jeg var i tvivl hvor &
skulle stå. Nu satte jeg den før omdirigeringen og det virkede så ikke.

>> Desuden ser det nu også ud til at være shell-fm der fanger min
>> Ctrl-C og ikke mit script.
>
> Sker det osse hvis du omdirigerer standard input?
>
>    shell-fm </dev/null >/dev/null 2>&1

Hvor skal jeg sætte mit & i den? Hvis ikke jeg sætter den, holder mit
script vel bare "pause" når shell-fm startes.

> Jeg spekulerer på om det vil fungere hvis du kører shell-fm fra et
> wrapper-script, der exec'er sig selv væk. På den måde vil du kunne
> få pid'en af shell-fm. Fx noget i retning af:
>
> #v+
>    #!/bin/sh
>
>    # Væk med stdin, stdout og stderr
>    exec </dev/null >/dev/null 2>&1
>
>    # Gem PID'en et passende sted
>    echo $$ >/var/run/shell-fm.pid
>
>    exec shell-fm -d
>
>    # eof
> #v-

Uha, så er vi derude hvor jeg ikke kan bunde, som du måske kan høre
allerede. Jeg ville ikke have nogen idé om hvad det var jeg lavede, men
jeg sætter pris på dit forsøg på at hjælpe.

---

Lars Stokholm skrev:

>>> Men det resulterer I, at output fra shell-fm ender i den terminal
>>> jeg kører scriptet i.
>>
>> Når du har omdirigeret både standard output og error?
>
> Var det et retorisk spørgsmål? :)

Nej, det var et reelt spørgsmål. Sædvanligvis kommer der ingen uddata
hvis både stdout og stderr bliver omdirigeret til /dev/null, men du skrev
at uddata ender i din shell.

>> Sker det osse hvis du omdirigerer standard input?
>>
>>    shell-fm </dev/null >/dev/null 2>&1
>
> Hvor skal jeg sætte mit & i den? Hvis ikke jeg sætter den, holder
> mit script vel bare "pause" når shell-fm startes.

Der læses fra venstre mod højre, så hvis du sætter &'et før omdirigeringen,
bliver shell-fm startet før I/O bliver omdirigeret, så

   shell-fm [...] </dev/null >/dev/null 2>&1 &

> Uha, så er vi derude hvor jeg ikke kan bunde, som du måske kan
> høre allerede.

Ok, fidusen er at du starter wrapper-scriptet fra dit sædvanlige script,
i stedet for at starte shell-fm direkte. Wrapper-scriptet sørger for at
gemme det der bliver shell-fm's PID i en fil før shell-fm startes. Så
kan PID'en læses fra dit sædvanlige script med fx 'read FMPID < $PIDFIL',
hvorefter shell-fm kan dræbes med 'kill $FMPID'.

Altså:

#!/bin/sh

# Kør wrapper-scriptet i baggrunden
shell-fm-wrapper &

# Gør et eller andet, hele tiden
while :
do
[...]
done

# Vent på at wrapper-scriptet afslutter
wait

# eof

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Lars Stokholm wrote:
> Jeg har et Bourne Shell script [...]

....og har lige et spørgmål til, til det.

Jeg laver en test, der i sin grundform ser sådan ud:

1) if [ ${REMAINS} -eq ${REMAINED} ]

Men første gang testen køres er ingen af dem sat. Derfor skrev jeg:

2) if [ ${REMAINS-0} -eq ${REMAINED-0} ]

Det var bare ikke nok.¹ Jeg fandt dog ud af at dette virkede:

3) if [ ${REMAINS:-0} -eq ${REMAINED:-0} ]

Så vidt jeg har forstået, betyder det, at hvis de er sat og ikke 'null'
bruges værdien - ellers bruges 0. Jeg forstår bare ikke, hvorfor 2) ikke
virker - for de er jo netop ikke sat forud for første test.

Ud fra det kan jeg kun tolke, at de MÅ være sat men at de er null.
Hvad har jeg ikke forstået?

¹) [: -eq: argument expected

---

Klaus Alexander Seistrup wrote:
>>> Når du har omdirigeret både standard output og error?
>>
>> Var det et retorisk spørgsmål? :)
>
> Nej, det var et reelt spørgsmål. Sædvanligvis kommer der ingen uddata
> hvis både stdout og stderr bliver omdirigeret til /dev/null, men du skrev
> at uddata ender i din shell.

Okay, men svaret var så ja. :)

> Der læses fra venstre mod højre, så hvis du sætter &'et før omdirigeringen,
> bliver shell-fm startet før I/O bliver omdirigeret, så
>
>    shell-fm [...] </dev/null >/dev/null 2>&1 &

Så er det også på plads.

>> Uha, så er vi derude hvor jeg ikke kan bunde, som du måske kan
>> høre allerede.
>
> Ok, fidusen er at du starter wrapper-scriptet fra dit sædvanlige script,
> i stedet for at starte shell-fm direkte. Wrapper-scriptet sørger for at
> gemme det der bliver shell-fm's PID i en fil før shell-fm startes. Så
> kan PID'en læses fra dit sædvanlige script med fx 'read FMPID < $PIDFIL',
> hvorefter shell-fm kan dræbes med 'kill $FMPID'.

Det vil jeg kigge på, når jeg får overskud til det. Tak skal du ha'.

---

Lars Stokholm wrote:
> Ud fra det kan jeg kun tolke, at de MÅ være sat men at de er null.
> Hvad har jeg ikke forstået?

Sorry. Jeg var kommet til at sætte dem til null alligevel. :)

---

---

Klaus Alexander Seistrup wrote:
> /me finder på noget sjovere at lave...

Jamen I kan da få et spørgsmål til. :)

Jeg kører en 'read CMD' og vil efterfølgende gerne have slettet hvad
brugeren har skrevet. Jeg tænker jeg kan bruge ${#CMD} til det - men
hvordan? Det må være noget med at skrive ${#CMD} \b'er med 'echo -e'
eller noget, men det kan jeg ikke lige finde en smart måde (om nogen
overhovedet) at gøre på.

---

Den Sun, 21 Dec 2008 18:01:52 +0100 skrev Lars Stokholm:
> Klaus Alexander Seistrup wrote:
>> /me finder på noget sjovere at lave...
>
> Jamen I kan da få et spørgsmål til. :)
>
> Jeg kører en 'read CMD' og vil efterfølgende gerne have slettet hvad
> brugeren har skrevet. Jeg tænker jeg kan bruge ${#CMD} til det - men
> hvordan? Det må være noget med at skrive ${#CMD} \b'er med 'echo -e'
> eller noget, men det kan jeg ikke lige finde en smart måde (om nogen
> overhovedet) at gøre på.

Brugeren har trykket enter, så cursoren står ikke længere på den
linje det er skrevet på.

Du skal derfor til at rode med termcap/terminfo for at finde koderne
til at flytte markøren.

Hvis du absolut vil, så kig på tput(1) og terminfo(5).

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Lars Stokholm wrote:
> Klaus Alexander Seistrup wrote:
>> /me finder på noget sjovere at lave...
>
> Jamen I kan da få et spørgsmål til. :)
>
> Jeg kører en 'read CMD' og vil efterfølgende gerne have slettet hvad
> brugeren har skrevet. Jeg tænker jeg kan bruge ${#CMD} til det - men
> hvordan? Det må være noget med at skrive ${#CMD} \b'er med 'echo -e'
> eller noget, men det kan jeg ikke lige finde en smart måde (om nogen
> overhovedet) at gøre på.

slet hele skærmen med clear
eller brug programmet dialog

Mvh
Martin

---

Klaus Alexander Seistrup wrote:
> Lars Stokholm skrev:
>> Desuden ser det nu også ud til at være shell-fm der fanger min
>> Ctrl-C og ikke mit script.
>
> Sker det osse hvis du omdirigerer standard input?
>
>    shell-fm </dev/null >/dev/null 2>&1

Hmm! Det ser sgu ud til både at være shell-fm OG mit scripts trap, der
fanger Ctrl-C.

trap sendcmd SIGINT
shell-fm -d -i ${IP} -p ${PORT} < /dev/null || exit ${EX_UNAVAILABLE

Jeg kommer godt nok ind i sendcmd-funktionen, men samtidigt brokker
shell-fm sig (og dør): "Try to press Q next time you want to quit."

Hvordan undgå jeg at shell-fm også fanger Ctrl-C? Kan det være fordi jeg
sender flere signaler end blot SIGINT - at mit script fanger det ene og
shell-fm fanger det andet?

---

Den Sun, 21 Dec 2008 19:08:12 +0100 skrev Lars Stokholm:
> Klaus Alexander Seistrup wrote:
>> Lars Stokholm skrev:
>>> Desuden ser det nu også ud til at være shell-fm der fanger min
>>> Ctrl-C og ikke mit script.
>>
>> Sker det osse hvis du omdirigerer standard input?
>>
>>    shell-fm </dev/null >/dev/null 2>&1
>
> Hmm! Det ser sgu ud til både at være shell-fm OG mit scripts trap, der
> fanger Ctrl-C.
>
> trap sendcmd SIGINT
> shell-fm -d -i ${IP} -p ${PORT} < /dev/null || exit ${EX_UNAVAILABLE
>
> Jeg kommer godt nok ind i sendcmd-funktionen, men samtidigt brokker
> shell-fm sig (og dør): "Try to press Q next time you want to quit."
>
> Hvordan undgå jeg at shell-fm også fanger Ctrl-C? Kan det være fordi jeg
> sender flere signaler end blot SIGINT - at mit script fanger det ene og
> shell-fm fanger det andet?

Fra terminalens synspunkt er der ikke noget der hedder forgrunds-
og baggrunds-programmer. Din scriptet og shell-fm er ligestillede.

Så den har reelt kun to muligheder. Enten sendes ctrl-c til dem
begge, og så må de selv finde ud af resten, eller også sendes
ctrl-c til en tilfældig.

Tilfældigheder kommer der sjældent noget godt ud af, så man har
af logiske grunde valgt at ctrl-c sendes til dem begge.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis wrote:
> Fra terminalens synspunkt er der ikke noget der hedder forgrunds-
> og baggrunds-programmer. Din scriptet og shell-fm er ligestillede.
>
> Så den har reelt kun to muligheder. Enten sendes ctrl-c til dem
> begge, og så må de selv finde ud af resten, eller også sendes
> ctrl-c til en tilfældig.
>
> Tilfældigheder kommer der sjældent noget godt ud af, så man har
> af logiske grunde valgt at ctrl-c sendes til dem begge.

Det er da en forklaring man kan forstå. Men hvad skal jeg så gøre, hvis
jeg som bruger vil afbryde min evige while-løkke, uden at shell-fm dør?

Jeg har før haft erstattet mit 'sleep' i while-løkken med en 'read' med
timeout på. Men så skal man satme holde nalderne fra tastaturet, for
kommer man til at trykke på en tast, sættes read's timeout ud af
funktion og så holder løkken bare evig pause (til man har opdaget fejlen
og trykket enter, naturligvis).

---

Lars Stokholm skrev:

> Men hvad skal jeg så gøre, hvis jeg som bruger vil afbryde
> min evige while-løkke, uden at shell-fm dør?

Start shell-fm med nohup.

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Den Sun, 21 Dec 2008 19:51:24 +0100 skrev Lars Stokholm:
> Kent Friis wrote:
>> Fra terminalens synspunkt er der ikke noget der hedder forgrunds-
>> og baggrunds-programmer. Din scriptet og shell-fm er ligestillede.
>>
>> Så den har reelt kun to muligheder. Enten sendes ctrl-c til dem
>> begge, og så må de selv finde ud af resten, eller også sendes
>> ctrl-c til en tilfældig.
>>
>> Tilfældigheder kommer der sjældent noget godt ud af, så man har
>> af logiske grunde valgt at ctrl-c sendes til dem begge.
>
> Det er da en forklaring man kan forstå. Men hvad skal jeg så gøre, hvis
> jeg som bruger vil afbryde min evige while-løkke, uden at shell-fm dør?
>
> Jeg har før haft erstattet mit 'sleep' i while-løkken med en 'read' med
> timeout på. Men så skal man satme holde nalderne fra tastaturet, for
> kommer man til at trykke på en tast, sættes read's timeout ud af
> funktion og så holder løkken bare evig pause (til man har opdaget fejlen
> og trykket enter, naturligvis).

Måske det ville være nemmere hvis du skriver lidt om hvad det er
du forsøger på at lave.

(Og hvad er shell-fm i det hele taget?)

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis wrote:
> Den Sun, 21 Dec 2008 19:51:24 +0100 skrev Lars Stokholm:
>> Kent Friis wrote:
>>> Fra terminalens synspunkt er der ikke noget der hedder forgrunds-
>>> og baggrunds-programmer. Din scriptet og shell-fm er ligestillede.
>>>
>>> Så den har reelt kun to muligheder. Enten sendes ctrl-c til dem
>>> begge, og så må de selv finde ud af resten, eller også sendes
>>> ctrl-c til en tilfældig.
>>>
>>> Tilfældigheder kommer der sjældent noget godt ud af, så man har
>>> af logiske grunde valgt at ctrl-c sendes til dem begge.
>> Det er da en forklaring man kan forstå. Men hvad skal jeg så gøre, hvis
>> jeg som bruger vil afbryde min evige while-løkke, uden at shell-fm dør?
>>
>> Jeg har før haft erstattet mit 'sleep' i while-løkken med en 'read' med
>> timeout på. Men så skal man satme holde nalderne fra tastaturet, for
>> kommer man til at trykke på en tast, sættes read's timeout ud af
>> funktion og så holder løkken bare evig pause (til man har opdaget fejlen
>> og trykket enter, naturligvis).
>
> Måske det ville være nemmere hvis du skriver lidt om hvad det er
> du forsøger på at lave.
>
> (Og hvad er shell-fm i det hele taget?)
>
Jeg har fundet denne hjemmeside:
http://www.ohloh.net/p/shell-fm
Lightweight, console-based radio player for Last.FM radio streams.

Det er formentlig et interaktivt program, hvorfor skal shell-fm kaldes i
et script?.
Det er på høje tid Lars siger, hvad han har gang i.


--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk

---

Klaus Alexander Seistrup wrote:
> Lars Stokholm skrev:
>> Men hvad skal jeg så gøre, hvis jeg som bruger vil afbryde
>> min evige while-løkke, uden at shell-fm dør?
>
> Start shell-fm med nohup.

Det virker desværre ikke.

%cat shell-fm-script
#!/bin/sh
trap 'echo Vi fangede den!' SIGINT
nohup shell-fm > /dev/null &
while true
do
sleep 10
done

%./shell-fm-script
^CVi fangede den!

Men i et andet terminalvindue...

Før Ctrl-C:
%ps | grep shell-fm
63571 p5 S+ 0:00.00 /bin/sh ./shell-fm-script
63572 p5 R+ 0:05.02 shell-fm

Efter Ctrl-C:
%ps | grep shell-fm
63571 p5 S+ 0:00.01 /bin/sh ./shell-fm-script

shell-fm er altså død ved Ctrl-C.

---

Lars Stokholm skrev:

>> Start shell-fm med nohup.
>
> Det virker desværre ikke.

Det virker til gengæld efter hensigten her. Jeg kan sende ^C til
shell'en eller jeg kan helt lukket terminalvinduet - scriptet der
er startet med nohup bliver hængende.

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Kent Friis wrote:
> Måske det ville være nemmere hvis du skriver lidt om hvad det er
> du forsøger på at lave.

Jeg skal prøve. :) Lad os starte med shell-fm. Det er en klient til
http://last.fm/ der kører på kommandolinjen. Men nogle gange, mens man
hører radio, mister den forbindelsen til serveren eller også sker der
noget andet (som at den "går i stå" - læs videre).

Det med den mistede forbindelse kan løses, hvis man bare sender en
play-kommando til programmet. Så starter den bare radiokanalen påny.

Det andet er lidt mere vanskeligt at komme sig over, for programmet
reagerer i det tilfælde ikke på play, skip og quit. Den svarer vist nok
på info, så man kan se hvor mange sekunder der er igen af et nummer.
Denne "remaining time" har jeg i øvrigt observeret til at være -1, én af
de gange programmet er gået i stå.

Jeg har så tolket, at programmet har sine fejl og http://last.fm/ sine
(for jeg oplever lignende fejl i andre klienter). Derfor har jeg forsøgt
at skrive et wrapper-script, der gennemtvinger en genstart af shell-fm,
i tilfælde af, at den går i stå (hvad det så end skyldes). Det holder så
at sige hele tiden øje med shell-fm. Det virker fint i sig selv.

Nu kommer "problemet" så.

For for det første, vil jeg gerne afslutte shell-fm med en
quit-kommando, hvis det kan lade sig gøre. I stedet for bare at dræbe
wrapper-scriptet med Ctrl-C (og dermed også shell-fm).

For det andet vil jeg godt, at brugeren kan skrive nogle kommandoer
under kørsel af scriptet, som så bliver sendt til den kørende shell-fm
med netcat. love, for at markerer nummeret som særligt godt. skip, for
at springe videre til næste nummer.

Derfor er jeg nødt til at kunne afbryde while-løkken på en måde. Det
lader sig fint gøre med read og en timeout, men med førnævnte ulempe.

Nogle andre ting mit script klarer er:
- At registrere når et nyt musiknummer begynder og at...
- sætte min status i Pidgin med purple-remote (DBUS).
- skrive information om det i terminalen, i et pænt format.

Jeg håber det forklarer det. :) Du må også gerne få mit script, men i
den nuværende tilstand kan det vist hverken gøre fra eller til.

---

Lars Stokholm wrote:
> Kent Friis wrote:
>> Måske det ville være nemmere hvis du skriver lidt om hvad det er
>> du forsøger på at lave.
>
> Jeg skal prøve. :) Lad os starte med shell-fm. Det er en klient til
> http://last.fm/ der kører på kommandolinjen. Men nogle gange, mens man
> hører radio, mister den forbindelsen til serveren eller også sker der
> noget andet (som at den "går i stå" - læs videre).
>
> Det med den mistede forbindelse kan løses, hvis man bare sender en
> play-kommando til programmet. Så starter den bare radiokanalen påny.
>
> Det andet er lidt mere vanskeligt at komme sig over, for programmet
> reagerer i det tilfælde ikke på play, skip og quit. Den svarer vist nok
> på info, så man kan se hvor mange sekunder der er igen af et nummer.
> Denne "remaining time" har jeg i øvrigt observeret til at være -1, én af
> de gange programmet er gået i stå.
>
> Jeg har så tolket, at programmet har sine fejl og http://last.fm/ sine
> (for jeg oplever lignende fejl i andre klienter). Derfor har jeg forsøgt
> at skrive et wrapper-script, der gennemtvinger en genstart af shell-fm,
> i tilfælde af, at den går i stå (hvad det så end skyldes). Det holder så
> at sige hele tiden øje med shell-fm. Det virker fint i sig selv.
>
> Nu kommer "problemet" så.
>
> For for det første, vil jeg gerne afslutte shell-fm med en
> quit-kommando, hvis det kan lade sig gøre. I stedet for bare at dræbe
> wrapper-scriptet med Ctrl-C (og dermed også shell-fm).
>
> For det andet vil jeg godt, at brugeren kan skrive nogle kommandoer
> under kørsel af scriptet, som så bliver sendt til den kørende shell-fm
> med netcat. love, for at markerer nummeret som særligt godt. skip, for
> at springe videre til næste nummer.
>
> Derfor er jeg nødt til at kunne afbryde while-løkken på en måde. Det
> lader sig fint gøre med read og en timeout, men med førnævnte ulempe.
>
> Nogle andre ting mit script klarer er:
> - At registrere når et nyt musiknummer begynder og at...
> - sætte min status i Pidgin med purple-remote (DBUS).
> - skrive information om det i terminalen, i et pænt format.
>
> Jeg håber det forklarer det. :) Du må også gerne få mit script, men i
> den nuværende tilstand kan det vist hverken gøre fra eller til.

En client siger du?, hvor køre den fra et script?, hvorfor åbner den
ikke sit eget vindue?.
Nå, men glem det, det er alligevel uden for min interressesfære.

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk

---

Den Sun, 21 Dec 2008 22:04:42 +0100 skrev Lars Stokholm:
>
> For for det første, vil jeg gerne afslutte shell-fm med en
> quit-kommando, hvis det kan lade sig gøre. I stedet for bare at dræbe
> wrapper-scriptet med Ctrl-C (og dermed også shell-fm).
>
> For det andet vil jeg godt, at brugeren kan skrive nogle kommandoer
> under kørsel af scriptet, som så bliver sendt til den kørende shell-fm
> med netcat. love, for at markerer nummeret som særligt godt. skip, for
> at springe videre til næste nummer.

Så du skal både have konstant overvågning, og scriptet skal lave en
read for at læse næste kommando... Det lyder som noget der er nemmest
at lave i to scripts - et til overvågningen og et til bruger-delen.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Klaus Alexander Seistrup wrote:
> Lars Stokholm skrev:
>
>>> Start shell-fm med nohup.
>>
>> Det virker desværre ikke.
>
> Det virker til gengæld efter hensigten her. Jeg kan sende ^C til
> shell'en eller jeg kan helt lukket terminalvinduet - scriptet der
> er startet med nohup bliver hængende.

Det er sgu godt nok mærkeligt!

---

Lars Stokholm wrote:
> Kent Friis wrote:
>> Måske det ville være nemmere hvis du skriver lidt om hvad det er
>> du forsøger på at lave.
>
> Jeg skal prøve. :)

Lad mig lige for god ordens skyld sige, inden nogen påpeger på hvor
mange andre måder jeg kan komme til at høre Last.fm-radio, at det her
ligeså meget er et hobbyprojekt som det er af egentlig nød. Det er mit
første "større" sh-script og jeg har lært en del allerede. :)

---

Lars Stokholm wrote:
> Jeg håber det forklarer det. :) Du må også gerne få mit script, men i
> den nuværende tilstand kan det vist hverken gøre fra eller til.

Beklager de mange svar til mig selv, men jeg fik lige fjernet det værste
rod i scriptet og uploadet det til pastebin.

http://pastebin.com/m71563f76

Det virker tilsyneladende nogenlunde alligevel - på overfladen
alligevel. sendcmd og quit bliver ikke brugt pt.

Der er ingen kommentarer så I må leve med min lange forklaring i det
indlæg jeg svarer på - hvis det da overhovedet har interesse.

Har jeg lavet fejl og mærkværdigheder, hører jeg gerne om det. :)