Mihin sitä tarvitaan, miten, milloin ja missä sitä voi käyttää ?
Mitä exec tekee
Sudottelija
9416
0Äänestä
Muut lukivat myös
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Turvaa tilisi vahvistamalla puhelinnumerosi. Voit silloin palauttaa unohtuneen salasanan tekstiviestillä.
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 9
Vanhimmat
"man exec" voi auttaa kummasti. Käytännössä voit käynnistää omasta ohjelmassasi käsin toisen ohjelman. Eli kun vaikka klikkaat käynnistysikonia ruudullasi, tuo komento saa aikaan sen, että ohjelma tulee ajoon eli luodaan oma prosessi sitä varten.
Eikös se mene niinpäin että execillä heitetään vanha ohjelma tunkiolle ja aletaan ajaa uutta ohjelmaa samassa prosessissa. Normaalistihan forkataan uusi prosessi.
Miksi et kokeile?
sillähän se selviää parhaiten? sen kun avaat komentotulkin ja komentotulkilla avaat seuraavan komentotulkin kirjoittaen aina ensin ton exec...
ja ero silminhavaittava verrattuna jos ei käytä alussa tota exec "lisää"?
(ja mihin kaikkeen sitä voikaan hyödyntää lienee seuraava kysymys?
Exec on "sääntö" käynnistää ohjelma Säännöt on hyvii autokouluu käyvälle hyvä opettaa et liikenteenjakaja pitää ohittaa oikeelta nuolen osoittamalta puolelta?
Sitten kun kokemusta kertyy niin voi itse päättää käyttääkö (exec:ii) tai kummalta puolelta liikenteenjakajan ohittaa (sen voi oikeesti ohittaa kummalta puolelta tahansa jos määrätytyt säännöt täyttyy Ilman mitään seuraamuksia.)
𝗲𝘅𝗲𝗰+komennon+suoritusta+ohjailevana+valitsimena.
𝗲𝘅𝗲𝗰 -komento itsenäisenä komentona.
Tässä esimerkissä up on järjestelmän päivittävä Bash script, joka käynnistetään xfce4-terminal emulaattorissa bach -komentotulkin suoritettavaksi.
Kun sinä nyt aloitat tuon komennon suorittamisen painamalla Ctrl Alt T saat sillä aikaan sen xfce4-terminal emulaattori käynnistyy, josta käsin voit suorittaa bash -tulkin ymmärtämiä komentoja.
exec xfce4-terminal -e /bin/bash -e up
Tuossa tuo komento avaa uuden xfce4-terminal emulaattorin jonka sisällä suoritetaan tuojärjestelmän päivittävä up -script . exec -komento saa aikaan että tuo terminaali josta uusi käynistettiin sulkeutuu välittömästi kun komento on käynnistetty, se ei vaikuta tuohon toiseen terminaaliin jossa tuo päivitys suoritetaan. Eli lyhyesti exec sulkee sen prosessin jossa se suoritetaan.
Kannattaa vilkaista vähän manuaalisivulta system() -komentoa myös. Ja fork()/waitpid(). Eli system() on wrapperi tavallaan useammalle funktiolle. Jos noita joutuu käyttämään paljon, kannattaa miettiä, josko voisi opetella samalla jotain IPC-protokollaa(inter-process communication) - on nimittäin jossakin määrin hidasta luoda prosessi - teoria sanoo, että aika on nolla, mutta koodin määrän kasvu aiheuttaa jatkuvan purun/latailun prosessin init/destroy-funktioissa vuoksi sen, että todelliset nopeushyödyt saa pystyttämällä pysyväisprosessin, jolloin softat parhaassa tapauksessa on ajossa eri core:lla ja hoidetaan taustalla.
Toisaalta shell-tasolta noita pyörittäessä voi pyöritettävät asiat olla niin isoja, ettei tuolle yllä mainitulle ole mitään tarvetta, vaikka exec-overheadia olisikin. Optimointi hukkuisi muuhun hitauteen kuitenkin. Ja c-tasolta asian hoitaminen taas voi mennä niin monimutkaiseksi, ettei sitä saisi ikinä toimintakuntoon - ainakaan ajoissa!
"Ja c-tasolta asian hoitaminen taas voi mennä niin monimutkaiseksi, ettei sitä saisi ikinä toimintakuntoon - ainakaan ajoissa!"
Mutta: samaa matalan tason koodia voi kirjoittaa myös FreePascalilla kuin C:lläkin, mutta on helpompaa ja vähemmän virhealtista kuin C.
Tosin: jos nopeutta yrittää maksimoida välttelemällä uuden prosessin luomista, se voi osoittautua mahdottomaksi.
Miksikö?
No: omatekoinen apuohjelmasi voi helposti ajaa toisen ohjelman samassa prosessissa linuxissa.
Mutta, kun se toinen ohjelma päättyy, mikään EI palauta omaa ohjelmaasi ajoon samaan prosessiin, vaan silloin koko prosessi päättyy, jolloin seuraavaa tehtävää varten joudutaan taas luomaan uusi prosessi.
Linux -teoreetikot väittävät, että linuxin erilliset fork / exec olisivat jotenkin parempia kuin windowsin Createprocess.
Mutta: yllämainitusta syystä tämä väite ei pidä paikkaansa.
Toki, jos patchaisit käynnistämääsi ohjelmaa siten, että se Exit:in sijasta tekisikin: Exec("OmaKaynnistysApuohjelma") niin sitten...
Mutta: olisiko se vaivan arvoista?
Hieman nopeampi: kyllä
Mutta: joutuisit patchaamaan jokaisen käynnistämäksesi aikomasi ohjelman erikseen, ja toistamaan työsi aina, kun ko. ohjelmasta tulee uusi versio.
Liian vaivalloista, eikö?
Ehkäpä juuri tästä syystä Windowsissa ei edes ole erillistä fork/exec -funktiota, vaan niiden sijasta tuo mainittu Createprocess.
Prosessia ei ole mikään pakko päättää. Esim. firefox:n plugin-container toimii tällä tavalla: Jos containeria ei ole ajossa, se käynnistetään, muussa tapauksessa lähetetään viesti em. prosessille. Optimitapauksessa prosessi luodaan vain kerran - mikäli mikään plugin ei käytön seurauksena satu kaatumaan, jolloin jälkien korjaamisen asemasta tapahtuu uudelleen käynnistys ja firefox selviää kaatumatta!
Fork on nopea, koska se oletuksena ei tee mitään! Huonosti toteutettua prosessien välistä kommunikaatiota ei mikään pelasta - jos joka kerta joutuu prosessin luomaan alusta, kun edellinen on lopetettu, niin se on hidasta. OTO prosessit(One-Time-Only) eivät tästä hidastu, mutta multithreading prosessit kyllä kärsivät.
Helppo esimerkki, missä hyödyn näkee silmällä on levyn kopiointi-prosessi: On prosessi joka osaa lukea levyltä dataa ja kirjoittaa sitä takaisin toiseen paikkaan. Tätä se tekee vuoron perään. Nyt jos tälle prosessille tehdään rinnakkainen(identtinen) prosessi ja prosessit lähettelevät toisilleen dataa - on fork() mitä parhain toimintatapa. Prosessien pitää jakaa luku/kirjoitus puskuri. Lukeminen ja kirjoittaminen voidaan synkronoida _samassa_ koodissa. Tämä tarkoittaa sitä, että virhealttius vähenee. Se, lukeeko vai kirjoittaako prosessi on oikeastaan sivuseikka - se tekee aina sitä, mikä kulloinkin on järkevintä tehdä. Nopeusetu tulee selkeästi esiin siinä vaiheessa kun aletaan kopioida tiedostoja kahden eri levyn välillä - tai kun prosessit päätyvät eri ytimille ajoon. Esimerkin "järkevyyden" kumoaa tietysti levyn kirjoituspuskuri, koska synkroninen koodikin toimii tällöin maksiminopeudella eli levyjen kirjoitusnopeudella. Eikä tuollaista toteutettaisi eri prosesseihin - eri threadeihin korkeintaan.
Monessa paikassa mahdollisuus tällaisiin "dobbel-gangereihin" tekee asioista nopeampia nykyisin kun coreja ja väylää riittää: Yhden coren koneissa se onkin sitten ohrasempi juttu.