C-kieli

[Snufkin]

Moi!

Millä komennolla käännetyn C-kielisen ohjelman pitäisi käynnistyä Xubuntun komentoriviltä? gcc tuottaa a.out nimisen filen, mutta miten se ajetaan komentoriviltä? Pelkkä a.out tuottaa virheimoituksen: file:command not found

Aloin siis opettelemaan c-kieltä ja olisi kiva päästä ajamaa sitä suoraan komentotulkista

[Lepotila zZ]

Koodia: [Valitse]

gcc -o suoritettavan_tiedoston_nimi käännettävä_tiedosto.c

[Snufkin]

Koodia: [Valitse]

gcc -o suoritettavan_tiedoston_nimi käännettävä_tiedosto.c

Juu, noin tein. Mutta millä saan sen käännetyn ohjelman käyntiin? Mulla yksi vanha C-kielen opas, joka neuvoo vain kirjoittamaan tuon suoritettavan_tiedoston nimen komentoriville, mutta sillä tulee virhe ilmoitus.

Koodia: [Valitse]

gcc -o harjoitus harj1.c

Koodia: [Valitse]

(kehote)$ harjoitus
ei toimi,

Koodia: [Valitse]

harjoitus: command not found.
Komentulkki bash.

[Lepotila zZ]

Koodia: [Valitse]

./harjoitus
Komentotulkille täytyy kertoa, että haluaa käynnistää ohjelman tästä kansiosta eikä polusta - siksi sen alkuun tulee tuo ./

[Snufkin]

Koodia: [Valitse]

./harjoitus
Komentotulkille täytyy kertoa, että haluaa käynnistää ohjelman tästä kansiosta eikä polusta - siksi sen alkuun tulee tuo ./

Kiitos, nyt toimii.

Eli ilman tuota ./ se yrittää löytää ohjelman sieltä, missä muutkin tulkin komennot?

[Lepotila zZ]

Joo, se etsii ohjelmaa polusta (PATH). Luulisin, että kyse on turvallisuudesta: Jos kansioon on jostain syystä päätynyt suoritettava tiedosto nimeltään ls, ls komennon käyttö ei suorita tuota tiedostoa, vaan oikean ls-komennon, joka löytyy polusta.

[SuperOscar]

Ja turvallisuudesta nimenomaan siinä mielessä, ettei joku muu pääse jekuttamaan sijoittamalla komentoja ympäri tiedostopuuta. Itsehän voi helposti luoda järjestelmäkomennon nimellä funktion tai aliaksen, joka käynnistää mitä ikinä haluaa.

[kamara]

Jos haluaa ampua itseänsä jalkaan, niin voi lisätä seuraavan asetuksen esim. .bashrc:hen...

Koodia: [Valitse]

PATH="$PATH:."

Sen jälkeen se tutkii myös oletuskansiosta käskyjä.

[Jere Sumell]

Kummin päin se nyt menee, jos komento on määritelty path-saantipolussa ympäristomuuttuja se nykytermi on, ja jos ajettava ohjelma on myos samassa kansiossa, jossa ohjelma ajetaan ilman tuota tarkennusta ./a.out esimerkiksi, eli nimenomaan halutaan suorittaa tuo aktiivisen tyokansiossa sijaitsevan tiedoston ajo, niin ajaako järjestelmä ensisijaisesti ympäristomuuttujassa ilmoitetussa kansiossa sijaitsevan samannimisen ohjelman.

Loogisesti ajateltuna itselläni se käsitys todella, että ensisijaisena järjestelmä hakee sen suoritettavan tiedoston path-polusta, onko se todella niin, tähän voisi joku kirjoittaa vielä vastauksena varmistuksen.

Jos haluaa ampua itseänsä jalkaan, niin voi lisätä seuraavan asetuksen esim. .bashrc:hen...

Koodia: [Valitse]

PATH="$PATH:."

Sen jälkeen se tutkii myös oletuskansiosta käskyjä.

Tosiaan tuo PATH="$PATH:." on siinä tapauksessa käytännossä käyttokelvoton, jos tuolta path-muuttujasta ensisijaisesti järjestelmä ajaa sen tiedoston, tosiaan omasta mielestäni suuremmat haitat, eli vähän vähätellysti todettu "jos haluaa ampua itseänsä jalkaan", no asia on todella noin, jos haluaa ilmaista aseen liittäen tuohon viestin perille menemiseen.

Itse olen noita C-lähdekoodeja tosiaan ja parhaiten ajanut

Koodia: [Valitse]

gcc ./ohjelma.c
./a.out
tässäkin nyt jo moneen kertaan tuo sama tullut esille.

[_Pete_]

Loogisesti ajateltuna itselläni se käsitys todella, että ensisijaisena järjestelmä hakee sen suoritettavan tiedoston path-polusta, onko se todella niin, tähän voisi joku kirjoittaa vielä vastauksena varmistuksen.

Loogisesti ajateltuna tämä on niin että JOS komennossa ei ole valmiina mukana absoluuttista polkua komentoon (eism. ./a.out) niin siloin yritetään etsiä se poluista jotka on määritelty PATH avulla.

[Jere Sumell]

Loogisesti ajateltuna itselläni se käsitys todella, että ensisijaisena järjestelmä hakee sen suoritettavan tiedoston path-polusta, onko se todella niin, tähän voisi joku kirjoittaa vielä vastauksena varmistuksen.

Loogisesti ajateltuna tämä on niin että JOS komennossa ei ole valmiina mukana absoluuttista polkua komentoon (eism. ./a.out) niin siloin yritetään etsiä se poluista jotka on määritelty PATH avulla.

Olemme ehdottomasti samoilla alltopituuksilla, mitä Pete sinä myös!

Tuota tarkoitin juuri aluperin loogisimpana johtopäätöksenä premisseinä, että loogisempana todellisuudessa voisi ajatella niin, että path-ympäristömuuttujan parametrit olisi se ensisijainen lähde, mistä Linux-järjestelmässä lähdetään hakemaan suoritukseen sitä ajettavaa ohjelmista.

Samaan päädyttiin, mutta meissä lienee myös paljon muuta yhteistä! Hyvä, että tämä tuli nyt varmistettua kirjallisestikin näin tätä kautta.

[_Pete_]

Tuota tarkoitin juuri aluperin loogisimpana johtopäätöksenä premisseinä, että loogisempana todellisuudessa voisi ajatella niin, että path-ympäristömuuttujan parametrit olisi se ensisijainen lähde, mistä Linux-järjestelmässä lähdetään hakemaan suoritukseen sitä ajettavaa ohjelmista.

Ei vaan se olisi toisisijaninen. Ensisijainen on se onko mukana absoluuttinen polku.

[Tomin]

Tuo mainittu ./a.out on kylläkin suhteellinen polku. Absoluuttinen polku alkaisi /-merkillä. Molemmat ovat toki polkuja ja sellaisia ei etsitä PATH-muuttujan hakemistoista.

[SuperOscar]

Yksinkertaistettuna siis logiikka menee näin:

• jos komentona annetaan polkunimi (eli /-merkki esiintyy jossakin kohtaa), yritetään suorittaa sen määrittämä tiedosto eikä $PATHiin päin vilkaistakaan, mutta
• jos komennossa ei ole yhtään vinoviivaa, etsitään $PATHista tiedostonimeä ja suoritetaan se sitten.

Aliakset ja funktiot hieman mutkistavat kuviota.

[_Pete_]

Tuo mainittu ./a.out on kylläkin suhteellinen polku. Absoluuttinen polku alkaisi /-merkillä. Molemmat ovat toki polkuja ja sellaisia ei etsitä PATH-muuttujan hakemistoista.

Tätä juurikin hain takaa 

[kuutio]

Täydennyksenä lisäisin, että $PATH-muuttujassa asetetut polut on etusijajärjestyksessä, eli jos työhakemisto (.) on muuttujassa viimeisenä, se on myös viimeinen paikka mistä komentoa etsitään, mikä kyllä pienentää riskiä ajaa "väärää" komentoa vahingossa (vaikkei poistakaan sitä kokonaan).

[Jere Sumell]

Jos tuohon $PATH:iin määrittelee ensimmäiseksi muuttujaksi ".", en tiedä onko siinä mitään käytännön järkeä, mutta tuossa tapauksessaa sitten ajettaisiin se työhakemiston tiedosto ilman sitä työpolku-määritelmää siinä komentoa annettaessa.

[SuperOscar]

Jos tuohon $PATH:iin määrittelee ensimmäiseksi muuttujaksi ".", en tiedä onko siinä mitään käytännön järkeä, mutta tuossa tapauksessaa sitten ajettaisiin se työhakemiston tiedosto ilman sitä työpolku-määritelmää siinä komentoa annettaessa.

Eikös MS-DOSissa tuo ollut oletus, jollei ”.” ollut hakupolussa? Ja näinhän toimii Un*xissakin cdpath: ”.” etsitään ensin, jollei sen paikkaa ole muualle määritetty, eikä sitä voi jättää hausta kokonaan pois.

[Snufkin]

Jos haluan tehdä oman käskyn, vaikkapa pienen C-ohjelman, joka käynnistyy ikään kuin komento komentotulkissa (pelkällä ohjelman nimellä), niin miten se kannattaa tehdä?

[_Pete_]

Jos haluan tehdä oman käskyn, vaikkapa pienen C-ohjelman, joka käynnistyy ikään kuin komento komentotulkissa (pelkällä ohjelman nimellä), niin miten se kannattaa tehdä?

Kun ohjelma on valmis siirrät/kopiot kääntäjän tuottaman binääritiedoston sellaiseen paikkaan joka on jossakin PATH muuttujassa määritellyissä poluissa.