Fórumok
Hali!
Hogyan tudom azt megcsinálni, hogy van 3 user a rendszeren és 1 root, amikor kiadom az su parancsot, akkor automatikusan ". /home/aki_atvaltott/.bashrc" lefusson, hogy ha mondjuk ember1 felhasználó beírja, hogy su akkor a saját home mappájából töltődjön be a .bashrc és
1. ne a root bashrc-je?
2. root is betöltődhet, de utána mindenképp az adott előző user-é?
Üdv!
Hozzászólások
Ha 'su' volt, és nem 'su -', akkor az USERNAME változó az erdeti felhasználónevet tartalmazza, azzal játszadozhatsz a /root/.bashrc-ben.
De a "who am eye" (fura, de tenyleg) megmondja az eredeti nevedet is. Akar egy 'sudo su -' utan is.
--
"De a "who am eye" (fura, de tenyleg) megmondja "
sőt, a "who the hell" vagy a "who are you" is. :)
(Meg egyébként bármilyen két szó, mert ha két argumentuma van a who nak az a who -m -el egyenlő hatást vált ki.)
Ja, egyébként meg a login rekordokból (pl. utmp) dolgozik, ezért kapod sudo után is a login neved.
Na ezt igy nem tudtam, koszi :-)
--
Köszönöm a válaszokat mindenkinek, végül ez lett belőle beírva /root/.bashrc-be:
nev=$(who am eye | cut -f1 -d' ')
. /home/$nev/.bashrc
Csak hogy bonyolítsuk még:
Ne bizzunk a globbingban, az almoskonyvek szerint szivas jar vele.
--
Akkor te ne bízz. De amúgy érdekelne, hogy ebben az esetben miért is ne bízzunk benne?
Szivtam mar meg, hogy a ~usernev nem azt csinalta, amit szerettem volna. Nem nagy faradsag kiirni, hogy /home/$(logname), cserebe egeszen biztosan azt csinalja, amit szeretnel, nincs nem vart mellekhatasa.
--
Írhatnál többet arról a "nem azt csinálta amit akartál" problémádról, mert ez így semmit nem ér. Ráadásul most egy bash által futtatott .bashrc-ről beszélünk. És mi van ha az én home-om a /Users alatt van, vagy akárhol máshol? Ha már úgy kezded, hogy megmondod ki mit csináljon, akkor legalább támaszd alá valamivel.
Azt erdemes tudni, hogy a legtobbszor a user bashrc-je csak masodlagosan fut le, legeloszor a rendszer szintu bashrc fut le, ha van. Namost ha ebben valamiert ki van kapcsolva a globbing, akkor az mar a user szintu bashrc-ben is ki lesz kapcsolva. Es innentol nem azt csinalja, amit szeretnel.
Ha a sajat home-odrol van szo, akkor ${HOME}. Ha maserol, akkor meg a rendszerspecifikusat lehet hasznalni. Altalaban egy rendszeren a home konyvtarak (marmint az olyan userek home-jai, ahol a logname lehivasanak van ertelme) egy fix helyen vannak, a /Users vagy a /home alatt.
Nem egy bonyolult dolog, es egyel kevesebb hibalehetoseg.
--
Ha már tudod, hogy hol van a home, és tied a rendszer, akkor azt is tudod mi van a /etc/bash.bashrc -ben, tehát nem hinném, hogy ez probléma lenne, abban az esetben persze ha lefutna, mert nem fut le. Tehát a user .bashrc -je nem másodlagosan fut le. Ha már itt tartunk, akkor ez a sorrent: ~/.bash_profile ~/.bash_login ~/.profile ~/.bashrc. A /etc/bash.bashrc le sem fut, ha nincs source-olva. Az meg, hogy ha linux akkor /home a home, ha osx akkor /Users és akkor már tudod, hogy hol a home... akkora baromság, hogy iszom még egy felest. Egyel kevesebb hibalehetőség. Az... De semmi gond, cut-oljatok, pipe-oljaktok fölöslegesen, mert nehogy valami baj legyen. Meg ne használjunk semmit, amiből baj lehet. Sőt, akkor már ne is csináljunk semmit... Csak szóljunk be fogalom nélkül, mert nem bírjuk ki, hogy ne szóljunk be. Az fontos.
Igen, szar napom van.
"A /etc/bash.bashrc le sem fut, ha nincs source-olva."
Ezzel vigyazz, mert sok Linux az /etc/profile -ben sourcolja automatikusan, ha erzekeli, hogy bash hajtja vegre, tehat nem kell, hogy a sajat konfigod _barmelyike_ sourcolja a rendszerszintu bashrc-t.
--
Úgy tűnik, hogy ez attól függ. 12.04-es Ubuntu alatt ezt írja a man page, de látom, hogy pl. itt meg már nem ezt írja:
When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc.
(GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu))
Amúgy szerintem teljesen vállalható az a ~, ha nem megy majd úgyis hamar kiderül és ki lehet javítani...
-
Nem "globbing", hanem http://www.gnu.org/software/bash/manual/html_node/Tilde-Expansion.html
Valamint parancshelyettesítés. De hogy hasznos is legyen a hozzászólás: pénteken hívott egy ismerős, mert (nem-tom-milyen rendszeren, nem-tom-milyen shellel) abba futott bele, hogy egy szkript-ben ezt akarta használni:
cd ~$1
sejthetően az első paraméter egy usernév volt, viszont az ottani shell balról jobbra haladva előbb próbálta a tildét helyettesíteni, majd miután feladta, csak utána kezdte feldolgozni a $1-et. (A megoldás az volt, hogy kapott egy eval-t az egész parancs elé.)
Amúgy ezt most nem tudom fejből, hogy pontosan milyen sorrendben is kell POSIX szerint a ~- és $-alapú helyettesítéseket csinálni - azaz jogos volt-e a shell nyafogása, vagy nem.
Az eval jó megoldás:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.htm…
Ha jól értem, akkor különböző helyettesítések ( ~ és $ ) egymással azonos prioritásúak, és előlről hátra fele haladva kéne ezeket megcsinálni. Majd ha megtörténtek, akkor lépünk a következő pontban szereplő szavakra tördelésre.
Azaz a shell jól dolgozott. Akkor ez egy példa arra, mikor nem lehet szépen megoldani a dolgokat, lévén az eval viszont életveszélyes eszköz. (Főleg egy olyan esetben, amikor paramétert - azaz kívülről érkező adatot - dogozok fel.)