Portál AbcLinuxu, 14. května 2025 10:44
user1 a proces pod user2 z něj bude chtít číst.
24.1.2007 18:14
Josef Kufner | skóre: 70
někde ve var,/var/run, /tmp nebo /var/tmp. Jinde to nemá co dělat.
/var/spool/<jméno služby> když to budu považovat za systémovou službu, tak je to naprosto adekvátní místo.
25.1.2007 13:57
Josef Kufner | skóre: 70
Já osobně to mám takto:
mkfifo /tmp/alarm chmod 660 /tmp/alarm
A pod svou session startuji:
while true; do osd_cat ... < /tmp/alarm; done &
Jakýkoliv program pak může provést echo "zprava" > /tmp/alarm.
Nebo v čem jiném by ten váš druhý program byl než ve smyčce.Může být ve stavu čekání na signál. Kdyby běžel ve smyčce, bude zbytečně vytěžovat CPU.
Přiznávám se bez mučení, že mám asi dlouhé vedení, ale ten tvůj příspěvek nechápu...Jenže on právě v žádné smyčce běžet nebude, bude ve stavu S a čekat na vstup z té roury.Nebo v čem jiném by ten váš druhý program byl než ve smyčce.Může být ve stavu čekání na signál. Kdyby běžel ve smyčce, bude zbytečně vytěžovat CPU.
Pokud čte z roury tak v žádné smyčce není. Zkuste si to spustit jen tak v terminálu. Zjistíte, že se spustí a zastaví se na čtení a nepokračuje, dokud nemá načtena data, tj. dokud do roury jiný proces nepustí EOF. Když má načteno tak pokračuje, tj. zobrazí načtený text a ukončí se.
Smyčka jej znovu spustí a on se opět zastaví dokud nepřijde vstup. Je zcela lhostejné, zda čeká na vstup sekundu nebo 2 hodiny, po tu dobu se neprovádí žádné instrukce a program stojí.
26.1.2007 05:00
Josef Kufner | skóre: 70
while true
do
# čekání
while ! [ -f /tmp/baf ]
do
sleep 1
done
rm -f /tmp/baf
# reakce
echo Lek.
done
… je ukázkou aktivního čekání na událost:
touch /tmp/bafKdežto při pasivním čekání program prostě řekne operačnímu systému "Hele až se něco bude dít, tak mě vzbuď." a jde spát.
mkfifo /tmp/fifo while true do # čekání cat /tmp/fifo >/dev/null # reakce echo Lek. doneBude čekat na událost:
echo Baf >/tmp/fifoJak je vidět, oba programy mají nějakou hlavní smyčku, která však s vlastním čekáním nemá vůbec nic společného a v žádném z případů by tam nemusela být – program by pak počkal na jednu událost a skončil. Nicméně v případě aktivního čekání by bylo možné nahradit čekací cyklus jednoduchou konstrukcí if a nechat program běhat ve hlavní smyčce. To je vhodné, pokud by program měl provádět více věcí najednou. Pro pasivní čekání by bylo v takovém případě nutno využít něco jako select() či alarm(), což má své výhody i nevýhody. Tak snad už je jasné, kde který cyklus je a co dělá nebo spíš nedělá
write ?
Nebo talk, v komibnaci s pípáním to nelze ignorovat
trap 'echo dostal jsem' USR1a pres kill se mu z jineho procesu posle signal:
kill -USR1 [cislo processu]
25.1.2007 08:43
houska | skóre: 41
| blog: HW
shutdown -k now "zprava"
mkfifo /tmp/mojerouraa pak zpracovávací skript
while read promenna < /tmp/mojeroura; do
if [ $promenna == zpracuj ] then
#proved zpracovani
fi
#pripadne misto if nejaky case pro vic moznosti
done
Upřímě nechápu, proč se chceš vyhnout cyklům? Jasně, třeba cykly typu "while /bin/true; do if grep "akce" /tmp/ridicisoubor; then udelej_akci; fi; sleep 1; done" jsou trošku hloupý, ale když se cyklus postaví tak, jak jsem psal, při volání příkazu read se skript zastaví a bude čekat tak dlouho, dokud se v rouře neobjeví informace. Pokud informace bude EOF, cyklus se ukončí. Pokud bude něco jiného, řádek se uloží do proměnné "promenna" a dá se s ní pak v tělě cyklu pracovat...
-miky
PS. řešit to přes sudo? neni to drobet brutální?
PS. řešit to přes sudo? neni to drobet brutální?No ve srovnání s psaním nějakého scriptu, který musí jako proces běžet celou dobu a mít vyřešen případný respawn, protože spadnout to může vždycky atd, ... No tak sudo je teda fakt jednodužší a mnohem spolehlivější způsob.
26.1.2007 11:25
Josef Kufner | skóre: 70
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.