Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Ohjelmointi, palvelimet ja muu edistyneempi käyttö => Aiheen aloitti: Snufkin - 19.03.22 - klo:15.27
-
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
-
gcc -o suoritettavan_tiedoston_nimi käännettävä_tiedosto.c
-
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.
gcc -o harjoitus harj1.c(kehote)$ harjoitus
ei toimi,
harjoitus: command not found.
Komentulkki bash.
-
./harjoitus
Komentotulkille täytyy kertoa, että haluaa käynnistää ohjelman tästä kansiosta eikä polusta - siksi sen alkuun tulee tuo ./
-
./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?
-
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.
-
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.
-
Jos haluaa ampua itseänsä jalkaan, niin voi lisätä seuraavan asetuksen esim. .bashrc:hen...
PATH="$PATH:."
Sen jälkeen se tutkii myös oletuskansiosta käskyjä.
-
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...
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
gcc ./ohjelma.c
./a.out
tässäkin nyt jo moneen kertaan tuo sama tullut esille.
-
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.
-
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.
-
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.
-
Tuo mainittu ./a.out on kylläkin suhteellinen polku. Absoluuttinen polku alkaisi /-merkillä. Molemmat ovat toki polkuja ja sellaisia ei etsitä PATH-muuttujan hakemistoista.
-
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.
-
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 :)
-
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).
-
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.
-
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.
-
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ä?
-
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.
-
Kun ohjelma on valmis siirrät/kopiot kääntäjän tuottaman binääritiedoston sellaiseen paikkaan joka on jossakin PATH muuttujassa määritellyissä poluissa.
Tuossa muuttujassa sellainen polku kuin /usr/local/bin. Onko tämä kansio sellainen, joka on käyttäjäkohtainen vai käytössä kaikkille koneen käyttäjille?
-
Tuossa muuttujassa sellainen polku kuin /usr/local/bin. Onko tämä kansio sellainen, joka on käyttäjäkohtainen vai käytössä kaikkille koneen käyttäjille?
Tuo /usr/local/bin -kansiohan sisältää ajettavia ohjelmia, joita normaali käyttäjä voi käyttää. Selvinnee ihan empiirisesti, jos katsot sen sisältoä, niin voit tehdä saman johtopäätoksen, eli se on käytossä kaikille koneen käyttäjille.
Jos kääntää tuolla gcc -kääntäjällä .c -ohjelman, niin siinähän käänetyssä tiedostossa tulee se +x -lupa, eikä sitä tarvitse erikseen chmodilla asettaa.
Muutoin, jos omia ohjelmia tai skriptejä tekee kaikille järjestelmän käyttäjille suunniteltavaksi, niin turvallisinta lienee määritellä
chmod ug+401 omaSkripti
eli lukuoikeudet käyttäjälle, ryhmän jäsenille, ei kirjoitusoikeutta, ja ajo-oikeus. En nyt muista, voiko tiedostoa ajaa, jos ei ole lukuoikeutta. Jos on ohjelmoinut skriptin, varmaan toivoo, että ei kukaan pysty kirjoittamaan tiedostoon. Tuohan vastaa lukuoikeudet, ei kirjoitusoikeutta ja ajo-oikeus
chmod ug+r-x omaSkripti
Tuo nyt lienee virheeton esitys.
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.
En muista, kummin päin DOSissa meni, kai senkin voisi tarkistaa jostain lähteestä, kun hakukoneella etsii oikeilla hakutermeillä, varmaan DOS-informaatiotakin on aika paljon saatavilla nykypäivänäkin, vaikka kyseistä järjestelmää ei olla enää pitkään aikaan käytettykään päätoimisesti.
-
Tuossa muuttujassa sellainen polku kuin /usr/local/bin. Onko tämä kansio sellainen, joka on käyttäjäkohtainen vai käytössä kaikkille koneen käyttäjille?
Tuo /usr/local/bin -kansiohan sisältää ajettavia ohjelmia, joita normaali käyttäjä voi käyttää. Selvinnee ihan empiirisesti, jos katsot sen sisältoä, niin voit tehdä saman johtopäätoksen, eli se on käytossä kaikille koneen käyttäjille.
Jos kääntää tuolla gcc -kääntäjällä .c -ohjelman, niin siinähän käänetyssä tiedostossa tulee se +x -lupa, eikä sitä tarvitse erikseen chmodilla asettaa.
Ok, kiitos. Ei ole nyt muita käyttäjiä koneella, joten työläs kokeilu. :)
Täytyy pitää mielessä nuo käyttöoikeudet.
-
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.
Mitä aiemmin kirjoitin, että varmaan voisi hakukoneella tarkistaa, mutta en tiedä, voiko sittenkään.
Katsoin hakutermillä
path environment variable linux versus ms dos
path environment variable linux versus dos
Tuossa ensin mainitussa tuli ainoastaan noin 1 360 000 hakutulosta, mutta ainut järkevin viittaus DOS-järjestelmän tuohon hakupolun kysymykseen yhdistettynä UNIX-järjestelmään oli lähteessä http://edutechwiki.unige.ch/en/Environment_variable#System_path_variables
Suora lainaus:
Lähde - [url]http://edutechwiki.unige.ch/en/Environment_variable#System_path_variables[/url]
Sitaatti - %PATH%
This variable contains a semicolon-delimited list of directories in which the command interpreter will search for executable files. Equivalent to the UNIX $PATH variable.
Equivalent viittaa sanatarkasti vastikkeeseen, samanarvoiseen tai yhtäpitävään, niin tuon perusteella se olisi ollut DOS:issa sama logiikka siinä, mitä tässä on nyt tullut esille tässä Linux-järjestelmän osalta.
Luulisi, että tuolla hakutermistollä loytyisi enemmän informaatiota, ja dokumentteja, joissa DOS ja Linux merkkijonot samassa dokumentissa mainittaisiin tuohon PATH -merkkijonoon, mutta ei.
-
Aitoa MS-DOSia ei minullakaan ole käsillä, mutta kokeilin DOSBoxissa, joka kuitenkin perustuu käsittääkseni FreeDOS-klooniin.
Tulos: ainakin DOSBoxissa tuntuu työkansio tarkistettavan ensimmäiseksi joka tapauksessa, PATH-ympäristömuuttujan arvosta riippumatta (ts. onko ”.” hakupolussa ja onko se siinä missä kohtaa). DOS siis ampuisi itseään jalkaan vakaasti ja varmasti.
-
...DOS siis ampuisi itseään jalkaan vakaasti ja varmasti.
Ei ainut harhalaaki tuo, mitä siinä vanhassa Disk Operating Systemissä oli tiedostonnimen maksimipituuskin 8 -merkkiä ja laajenne-osa 3 -merkkiä yhteensä maksimissaan 12 merkkiä, ja ainakin nykyäänkin Windowsien tuo komentokehoitteen maksimi merkkijonon pituus on yhä 8191 merkkiä, muista, oliko se noinkaan montaa merkkiä niissä vanhoissa MS Dos:eissa, niissä ja oli ihan älyton se komennon pituusrajoitus.
Windows 10:n powershellistä en tiedä, kun en ole asiantuntija siinä, onko siinäkin tuo 8191 merkin lyhyys maksimi, mitä siinä voi käyttäjä syottää.
No, tämä lienee tästä MS Dos -keskustelusta, turha tätä nyt lähteä enää tähän suuntaan ketjun alkuperäistä aihetta lähteä viemään keskustelua, millä kaikin tavoin DOS teloo itseään omaehtoisesti harhaan menneillä laakeilla.
-
Aitoa MS-DOSia ei minullakaan ole käsillä, mutta kokeilin DOSBoxissa, joka kuitenkin perustuu käsittääkseni FreeDOS-klooniin.
Tulos: ainakin DOSBoxissa tuntuu työkansio tarkistettavan ensimmäiseksi joka tapauksessa, PATH-ympäristömuuttujan arvosta riippumatta (ts. onko ”.” hakupolussa ja onko se siinä missä kohtaa). DOS siis ampuisi itseään jalkaan vakaasti ja varmasti.
Tuollainen huomio vielä, että itsellänikään millään medialla MS-DOSia saatavilla, kun ajat sitten olen hävittänyt DOSsin varmuuskopio-korputkin, eikä toisaalta missään koneessani ole 3.5 tuuman korppu-asemaakaan enää ollut pitkään aikaan.
Varmaan, jos viitsisi vähän vaivaa nähdä, niin tekisi alkuperäisestä esimerkiksi DOS 6.20, vaikka senkin jälkeen niitä on julkaistu vielä, niin tekisi virtuaalikoneen, niin näkisi natiivilla DOS:illa tuon, mutta tuo nyt lienee paras tietolähde tuo sinun SuperOscar -johtopäätelmä, mitä teit tuon DosBOXin kautta tähän hätään.
Se vain, että mitä käytin Google-hakua noilla hakutermeillä, mitä varmaan olisi löytynyt noilla hakutermeillä, jos jotain tarkempaa informaatiota jossain lähdedokumentissa netistä löytyy, kun Google on siinä määrin "älykäs" hakukone, että vaikka ei hakusanat nyt ihan täsmäisi suoraan lähteessä olevaa tekstiä, niin aika pitkälle "sinne päin" -mentelmällä löytyy usein myös.
Mutta sittenhän on näitä tilanteita, ei ole ainut kerta, kun jos tuo yksi lause, missä oli tuosta Dos PATH:istä tuolla edutechwikissä, minkä pistin tuohon aiemmin suoran lainauksen sieltä, niin siinä tapauksessa tuohan on virheellinen "tieto" siellä sitten, kun pidän sinun DosBoxilla tehtyä testitulosta luotettavampana, eli oikeammin Dosin ja UNIXin PATH lienevät ainakin osittain yhtä päteviä, eikä kaikissa tilanteissa tosiaan, niinkuin tuossa lähdeviittauksessani annetaan ymmärtää.
Ei täältä Internetin ihmemaailmasta nyt ihan kaikkea kuitenkaan pysty selvittämään, olen tullut siihen tulokseen aiemminkin.
-
Ei ainut harhalaaki tuo, mitä siinä vanhassa Disk Operating Systemissä oli tiedostonnimen maksimipituuskin 8 -merkkiä ja laajenne-osa 3 -merkkiä yhteensä maksimissaan 12 merkkiä,
Tosin eipä alkuperäisessä Unixissakaan tainnut paljon enempää olla, taisi olla 14 merkkiä (muttei jaettuna kahteen osaan; se on DECin käyttisten perintöä). MS-DOS tosiaan ei ole hirveän relevantti. Nostin sen vain esiin cdpathin takia, koska toisin kuin PATH, se toimii niin, ettei työkansiosta etsimistä voi millään tavalla estää.
-
DOS siis ampuisi itseään jalkaan vakaasti ja varmasti.
Se ei varmaankaan ole ainoa MikroSoft:in tuote, joka niin tekee. ;)
-
DOS siis ampuisi itseään jalkaan vakaasti ja varmasti.
Se ei varmaankaan ole ainoa MikroSoft:in tuote, joka niin tekee. ;)
Eihän bisnes perustukaan siihen, että yrittäjällä olisi täydellinen tuote.
Tässä maailmassa kaikki fyysinen, tai aineeton materiaali tai materia on ennen pitkää kaupan, joku tekee sillä gillaa.
Mitä varmaan olette katsoneet, seuraan Bill Gatesia Linkedinissä, mistä tulee sähköpostiin se Gatesin aika ajoin uutiskirje-artikkeli, niin mitä elämäni aikana olisi hienoa päästä käymään ainakin kerran elämässä Yhdysvalloissa, mutta varallisuus on este, se on todella kallis matkailumaa tavallisen Pii-laaksossa kävijän näkökulmasta, saati sitten siellä asuminen ja eläminen, jos aikoo siellä perheen esim. perustaa, jossa se positiivinen puoli, että sitten jälkeläisillä olisi Yhdysvaltojen natiivikansalaisuus, mitä perheessäkin jonkinlainen ja sen perustamisen yhteydessä tietty suvun jatkumisen ajatus.
Eurojackpotissa oli taas yksi oikein, eli Ei Voittoja, Veikkauksen ulostulona, niin vielä Amerikan Road Trip lottovoittajan näkökulmasta saa odottaa aikaansa.
Jos pääsen varoihini tässä matkumastaan Yhdysvaltoihin, mitä tosiaan sinne ei tyhjätaskuna kannnata lähteä ollenkan, niin Microsoftin Visitor's Centerissä tottakai tulisi käytyä, ja Silicon Valleyssa näin IT-ammattilaisena siellä Californiassa seikkailisin, niin tiedä, jos tapaan Bill Gatesin itse henkilökohtaisesti vielä elinaikanani, mitä mies on vielä elossa, vaikka on minua tovin vanhempi, niin totta kai ylistän tämän järjestelmää, "Bill Gatesilla hyvä järjestelmä", pistit hyvän järjestelmän aikoinaan pyörimään.
Tuo aiempi viite pitää paikkansa bines-näkökulmasta, eikä lainkaan tekniikan osalta, mitä Microsoft -omaisuuden lähteenä Bill Gates loi pitkään ihmisen tähän astisen historian merkittävimmän omaisuuden, vaikka enää ei olekaan maailman rikkain mies. Eli liiketalous- ja hallintopuolelta Bill Gates pisti tädellisen järjestelmän pyörimään, mutta sitten tekniikan kannalta ei ehkä niinkään koskaan? Tämä on kiistaton fakta.
-
Tämän säikeen ansiosta kokeilin ensimmäisen kerran
echo $PATH
ja, tosiaan, vaikuttaa siltä, että sillä saa polun näkyviin :)
-
Itse käytän komentoa:
alias epath='echo $PATH | sed "s/:/\n/g"'
-
Zsh:n käyttäjä tekisi yksinkertaisesti näin:
print -l $path
-
Minä olen tehnyt omia ohjelmia varten kotihakemistoon hakemiston bin
esim. /home/mina/bin ja lisännyt sen PATH polkuun
-
Minä olen tehnyt omia ohjelmia varten kotihakemistoon hakemiston bin
esim. /home/mina/bin ja lisännyt sen PATH polkuun
Voisi noinkin tehdä. Itse olen ollut arka muokaamaan mitään järjestelmätiedostoja, mutta pitää ehkä rohkaistua.
-
Minä olen tehnyt omia ohjelmia varten kotihakemistoon hakemiston bin
esim. /home/mina/bin ja lisännyt sen PATH polkuun
Voisi noinkin tehdä. Itse olen ollut arka muokaamaan mitään järjestelmätiedostoja, mutta pitää ehkä rohkaistua.
Minulla on kaksi Ubuntu 20.04 asennusta ja kummassakin on vakiona polussa hakemisto:
/home/<tunnus>/.local/bin
Ilman siis että on muuttanut mitään systemiasetusta. Eli tuonne hakiemistoon pistää omat tuotokset ne löytyvät polusta.
Perinteinen tapa laittaa itse käännetyt binäärit polkuun on pistää binäärit /usr/local/bin hakemistoon.
-
Minulla on kaksi Ubuntu 20.04 asennusta ja kummassakin on vakiona polussa hakemisto:
/home/<tunnus>/.local/bin
Ilman siis että on muuttanut mitään systemiasetusta. Eli tuonne hakiemistoon pistää omat tuotokset ne löytyvät polusta.
Perinteinen tapa laittaa itse käännetyt binäärit polkuun on pistää binäärit /usr/local/bin hakemistoon.
Minulla 2x Xubunutu, jossa taustalla sama Ubuntu 20.04. Mutta ei niissä ole tuollaista /home-kansiota $PATH:ssa.
jos haluaa, niin miten tuota $PATH -muuttujaa muutetaan turvallisesti sotkematta mitään?
-
Minulla on kaksi Ubuntu 20.04 asennusta ja kummassakin on vakiona polussa hakemisto:
/home/<tunnus>/.local/bin
Ilman siis että on muuttanut mitään systemiasetusta. Eli tuonne hakiemistoon pistää omat tuotokset ne löytyvät polusta.
Perinteinen tapa laittaa itse käännetyt binäärit polkuun on pistää binäärit /usr/local/bin hakemistoon.
Minulla 2x Xubunutu, jossa taustalla sama Ubuntu 20.04. Mutta ei niissä ole tuollaista /home-kansiota $PATH:ssa.
jos haluaa, niin miten tuota $PATH -muuttujaa muutetaan turvallisesti sotkematta mitään?
Jaa mistäköhän ovat ilmaantuneet PATHini sitten.
PATH voi muokata tämän ohjeen mukaan:
https://linuxize.com/post/how-to-add-directory-to-path-in-linux/
-
PATH voi muokata tämän ohjeen mukaan:
https://linuxize.com/post/how-to-add-directory-to-path-in-linux/
Kiitos, ei ollutkaan vaikeaa. Nyt toimii ja pysyy omat viritelmät omassa karsinassaan. :)
-
Itse en ole koskaan luonut omaan kotikansioon tuota bin -hakemistoa, kun järjestelmässäni kotikäytossä olevassa läppäri-Minti/Ubuntussani ole muita käyttäjiä, kuin itse olen ainoa käyttäjä.
En tiedä, onko tuossa mitään hyotyä muuta, paitsi se tietty, että jos järjestelmässä on useampi käyttäjä, niin voi luoda ryhmän tuosta $HOME -kansion alakansioista, muista käyttäjistä, ja sitten jos tekee omia ohjelmia myos yhteisen hyvän eteen, että järjestelmän muutkin käyttäjät voivat käyttää niitä, niin käytto-oikeudet sitten tuolle luodulle ryhmälle, ja sitten sen oman kotikansion bin -alihakemiston pistää tuonne ympäristomuuttujaan pathiin.
Onko siinä mitään muuta etua, mitä siinä saavuttaa.
-
Itse en ole koskaan luonut omaan kotikansioon tuota bin -hakemistoa, kun järjestelmässäni kotikäytossä olevassa läppäri-Minti/Ubuntussani ole muita käyttäjiä, kuin itse olen ainoa käyttäjä.
En tiedä, onko tuossa mitään hyotyä muuta, paitsi se tietty, että jos järjestelmässä on useampi käyttäjä, niin voi luoda ryhmän tuosta $HOME -kansion alakansioista, muista käyttäjistä, ja sitten jos tekee omia ohjelmia myos yhteisen hyvän eteen, että järjestelmän muutkin käyttäjät voivat käyttää niitä, niin käytto-oikeudet sitten tuolle luodulle ryhmälle, ja sitten sen oman kotikansion bin -alihakemiston pistää tuonne ympäristomuuttujaan pathiin.
Tuossa nyt ei ole hyvä tapa. Kuka nyt muutenkaan antaa omaan kotihakemistoonsa oikeuksia muille käyttäjille. Tuossa tapauksessa voi laittaa binäärit jo valmiiksi polussa olevaan /usr/local/bin/ hakemistoon ja sen jälkeen ne on kaikkien käyttäjien käytettävissä.
Onko siinä mitään muuta etua, mitä siinä saavuttaa.
Se etu että on omassa kotihakemistosa bin/ johon kopioiomalla/linkaamalla binäärit tulevat polkuun käytettäväksi.
-
Onko siinä mitään muuta etua, mitä siinä saavuttaa.
No testailun helppous, kun suoritettava koodi on kotihakemistossa. Etenkin graafisella tiedostonhallinnalla tuohon pääsee helposti käsiksi.
Ihan en ymmärrä näin laajaa pohdintaa siitä, miten tiedostonsa järjestelee, mutta kukin toki tyylillään. :) Ei tuosta kovin suurta haittaakaan ole.
-
Tuossa nyt ei ole hyvä tapa. Kuka nyt muutenkaan antaa omaan kotihakemistoonsa oikeuksia muille käyttäjille. Tuossa tapauksessa voi laittaa binäärit jo valmiiksi polussa olevaan /usr/local/bin/ hakemistoon ja sen jälkeen ne on kaikkien käyttäjien käytettävissä.
No juu, onhan noita vaihtoehtoja. Jos luo esimerkiksi alikansion public -$HOME -alikansioon "ohjelmat", niin sitten jos järjestelmän ylläpitäjä on määritellyt, niin ei liene kenenkään estettä päätteeltä ajaa sitten sitä minun ohjelmoimaani ja kääntämääni ohjelmaa sieltä verkon yli. Tämä siinä tapauksessa, että ei omaa itse pääkäyttäjän tunnuksia järjestelmään.
Sitten jos on pääkäyttäjä järjestelmässä, ja jos järjestelmässä on useita käyttäjiä, niin apachessahan on tuo mod_userdir, jonka avulla voi määritellä jonkin yhteisen polun, josta verkon yli saatavilla sitten käyttäjien omat ohjelmat yleiseen käyttoon yhteisen edun mukaisesti ja sen lisäämisen eteen.
Tuossa tapauksessa vain se täytyy tiedottaa ja ohjeistaa kaikille käyttäjille, että se on järjestelmän käyttäjien yleisessä tiedossa se kansio, johon ne tiedostot sijoitetaan.
https://httpd.apache.org/docs/2.4/mod/mod_userdir.html (https://httpd.apache.org/docs/2.4/mod/mod_userdir.html)
Tarkennus ja lisäys 11.04.2022 20:06
Mitä aamummalla kirjoitin tämän viimeisimmän vastaukseni, niin oli tarkoitus jo aamulla sanomani, mutta ajtus kiiri tekstissä ohitse, että nimenomaan tuo -ohjelmat -alikansio $HOME:n public_html -alikansioon, kun sehän on oletuksena 80-portista saatavilla verkkoselaimella järjestelmän kaikilla käyttäjillä. Ei siis $HOME:n juureen, vaan käyttäjän kotikansion public_html -aikansioksi tuo ohjelmat, niin ei liene sen suurempaa vaaraa, että kukaan ulkopuolinen nyt suoraan pääsisi ilman sen hämärämpiä tarkoitusperiä muuhun kotikansion sisältöön käsiksi?
-
No juu, onhan noita vaihtoehtoja. Jos luo esimerkiksi alikansion public -$HOME -alikansioon "ohjelmat", niin sitten jos järjestelmän ylläpitäjä on määritellyt, niin ei liene kenenkään estettä päätteeltä ajaa sitten sitä minun ohjelmoimaani ja kääntämääni ohjelmaa sieltä verkon yli. Tämä siinä tapauksessa, että ei omaa itse pääkäyttäjän tunnuksia järjestelmään.
Sitten jos on pääkäyttäjä järjestelmässä, ja jos järjestelmässä on useita käyttäjiä, niin apachessahan on tuo mod_userdir, jonka avulla voi määritellä jonkin yhteisen polun, josta verkon yli saatavilla sitten käyttäjien omat ohjelmat yleiseen käyttoon yhteisen edun mukaisesti ja sen lisäämisen eteen.
Tuossa tapauksessa vain se täytyy tiedottaa ja ohjeistaa kaikille käyttäjille, että se on järjestelmän käyttäjien yleisessä tiedossa se kansio, johon ne tiedostot sijoitetaan.
https://httpd.apache.org/docs/2.4/mod/mod_userdir.html (https://httpd.apache.org/docs/2.4/mod/mod_userdir.html)
Tarkennus ja lisäys 11.04.2022 20:06
Mitä aamummalla kirjoitin tämän viimeisimmän vastaukseni, niin oli tarkoitus jo aamulla sanomani, mutta ajtus kiiri tekstissä ohitse, että nimenomaan tuo -ohjelmat -alikansio $HOME:n public_html -alikansioon, kun sehän on oletuksena 80-portista saatavilla verkkoselaimella järjestelmän kaikilla käyttäjillä. Ei siis $HOME:n juureen, vaan käyttäjän kotikansion public_html -aikansioksi tuo ohjelmat, niin ei liene sen suurempaa vaaraa, että kukaan ulkopuolinen nyt suoraan pääsisi ilman sen hämärämpiä tarkoitusperiä muuhun kotikansion sisältöön käsiksi?
WWW/http kautta "jaettavat" jutut nyt ei enää millään tavalla liity siihen mikä on käyttäjän PATH tai ei.
-
Eihän ne liitykkään, mutta tämä kommenttini tuli siitä, että vaikka ei PATHissa olisi merkittynäkään mitään defaulttia kummempaa, niin aiemmin totesin, että jos haluaa yhteisen edun mukaisesti hyvää tehden oman ohjelman muiden järjestelmän käyttäjien ajomahdollisuuden piiriin, niin ei kai mikään estä juuri tuonne kotikansion Apachen palvelimen oletuksena 80 -portista liittää käännettyä tiedostoa, niin voihan sieltä sitten kuka tahansa ihminen tai kone maailmassa, jos se on ohjelmoitu, niin ajaa ohjelman, sama sitten päätteeltä tai graafisen tyopoytäympäriston kautta, ja samaten voi luoda linkattavan ajotiedoston johonkin paikalliseen omaan lähteeseen myohempää ajokertaa varten.
On totta, että tämä alkuperäinen keskustelunaihe, mitä tässä tuosta path -ympäristomuuttujasta puhetta oli, niin vähän haarautunut tämä keskustelu, mutta melko loyhä yhteys, kuten pete totesitkin, että tällä nyt mitään tekemistä enää ole tuon ympäristomuuttuja-asian kanssa, mutta keskustelun soljutessa ihan mielestäni huomioitava ja esiin tuomisen arvoinen asia.
Olet oikeassa, pete.
-
Näköjään varsin yksinkertaisestakin asiasta saa halutessaan melko monimutklaista. ;D
-
Näköjään varsin yksinkertaisestakin asiasta saa halutessaan melko monimutklaista. ;D
Vaikka jokin asia tuntuisi monimutkaiselta, ja voi ollakin sitä jossain kohtaa, niin ei se poissulje sitä, että ei se niin vaikeaakaan välttämättä olisi tai pitäisi olla lopulta sitä.
Sama se kitaran soitossa on, että jostain ihmisestä voi tuntua monimutkaiselta, ja vaikeaselkoiselta kuunella jopa sitä, mutta ei sen tarvitse välttämättä olla niin kovin vaikeaakaan.
Sama se vähän joka asiassa riippuen siitä, mihin ihminen on keskittänyt tarmonsa opiskella ja ottaa selvää jostain asiasta perehtynyt oikein.
-
Kannattaa muuten muistaa, ettei Un*xissa hakupolulla taida edes olla mitään oletusta eli se voi periaatteessa olla tyhjä. Käytännössä hakupolussa ovat yleensä vähintään /bin ja /usr/bin (jotka voivat olla yksi ja sama hakemisto) sekä ylläpitäjäkäyttäjälle /sbin ja /usr/sbin (jotka taas voivat keskenään olla yksi ja sama). Kaikki muu on enemmän tai vähemmän ylläpitäjän päätettävissä.
-
Onko näin todella alkuaikojen UNIX-järjestelmässä, että siellä ei todella olisi välttämättä mitään oletuksena annettu noissa PATH-ympäristömuuttujissa?
Sinä lienet paras lähteeni tähän, arvon arvostettuni pitkän humaanin elämän elänyt IT-ammattliainen (ent. ATK -ammattilainen), olitko jo 1970-luvun alkupuoliskolla alan hommissa tekemässä tuottavaa työtä ja rakentamassa tätä maata tuleville sukupolville?
Itse olen 1980-luun alussa syntynyt, ja joskus 1999-2000 tutustuin Red - Hat Linuxiin ensimmäisen kerran, niin koko elämäni ajan, vaikka tuokin ajankohta neitsyyden menetys Linus Torvaldsin järjestelmälle voi tuntua varmaan utopialta oman jälkeisteni sukupolvien myötä, ketä tätä palstaa lukee, mutta oman koko ihmisen elämäni ajan, mitä olen Linuxia koskaan käyttänyt, niin todella on niin, että siellä on käytännössä nuo polut, joita sinä arvon SuperOscar -tiedotit aiemmassa postauksessasi. En ole voinut valita vanhempiani ja syntymäajankohtaani, vaikka olisin halunut elääkin ehkä 1970-luvulla, mitä tulee tietojenkäsittelyyn ja musiikkibisnekseen, mutta se ei ollut minun valintani.
Näillä korteilla, jotka sain, on pelattava. Viimeiseen korttiin ja viimeiseen hengenvetoon olen yhteistä hyvää humaniisti edistävänä tässä maailmassa ihmisten tasa-arvon puolesta, vaikka se väline olisi tämä teknologinen orientoituminen.
-
En ole voinut valita vanhempiani ja syntymäajankohtaani, vaikka olisin halunut elääkin ehkä 1970-luvulla, mitä tulee tietojenkäsittelyyn ja musiikkibisnekseen, mutta se ei ollut minun valintani.
Itse taas toivoisin olevani nuorempi (olen myös 80-luvun kasvatteja). Sain kunnolla ensi kosketuksen tietokoneisiin ja internetiin vasta alakoulun viimeisellä, koska tuohon aikaan tietokoneet olivat harvinaisia ja köyhemmillä perheillä ei ollut varaa moisiin. Lisäksi internet oli tuolloin uusia asia. Koodaamaan opin yläkoulussa, joskus 14-15v vanhana. Tässäkin asiassa kävi mäihä, koska ainoastaan yksi opettajista osasi koodata tuolloin ja sai järjestetyksi pari Pascal-kurssia, joidenka pohjila etenin eteenpäin Javaan yms. muihin kieliin.
-
Meillä ei ollut 70-luvullä mitään "atk"-koulutusta, muuta kuin teekkareiden vetämä ylimääräinen kalvosulkeis-luentosarja lukiossa. Siihen kuului käynti TKK:n tiloissa katsomassa kun kone sylki ulos sellaista mikä se nyt oli, käyrää jota varten kerrottiin syntymäaika ja pari muuta juttua ja sitten siitä muka näki miten elämä luistaa. Myöhemmin kun aloitin opiskelun, törmäsin matikanmaikkaani, oli siellä hankkimassa täydennyskoulutusta. Kysyi minulta matskuja kuin kuka tahansa opiskelija, silti joku sivustaseuraaja kysyi jälkeenpäin oliko se mun ope. Kun ihmettelin, hän selitti että on itsekin ope.
-
Onko näin todella alkuaikojen UNIX-järjestelmässä, että siellä ei todella olisi välttämättä mitään oletuksena annettu noissa PATH-ympäristömuuttujissa?
Käsittääkseni kyllä, vaikka minäkin ensikosketukseni Un*xiin (tarkemmin SunOSiin) sain 1988 ja silloin keskuskoneen normikäyttäjänä. Tosin vain vuotta paria myöhemmin tietotekniikkaa Hesassa opiskellut kaverini asensi PC:lleni näytteeksi Minixin – luultavasti laittoman kopion –, mutta silläkään en mitään hyödyllistä pystynyt ohjelmien puutteessa tekemään.
Unixin – siis sen alkuperäisen – idea kuitenkin oli tietynlainen modulaarisuus ja muokattavuus, joten vapaasti asetettavissa oleva hakupolku oli luonnollinen osa kokonaisuutta.
-
Voisi se kuvitellakin, mitä uskon, että alunperin 1970-luvulla jo, mitä UNIX -julkaistiin, niin siinä pyrittiin jo toteuttamaan kovinkin abstraktilla tasolla noita ohjelmistokehityksen pääperiaatteita.
Varmaan aika pian kun se alunperin oli pelkästään hyvin suppean akateemisissa piireissä se järjestelmä mitä se lähti leviämään ja otettiin käyttöön viralisssa tutkimuslaitoksissa, niin aika pian varmaan vakiintui se käytäntö, että käytännössä siinä oli keskuskoneen peruskäyttöoikeuksen tunnuksen haltijalla mahdollisuus ajaa noita ainakin /bin -alihakemiston ohjelmia ilman tuota viittausta tuohon nimenomaiseen polkuun. Voisi humaanista lähestymistavasta ajatella näin.