- This topic has 36 hozzászólás, 7 résztvevő, and was last updated 17 years, 5 months telt el by
.
-
Bejegyzés
-
Code:# tput cols
97Ennek ellenére pont 80-nál vág. Tehát nem terminálszélesség. De nem is az a kérdés, hogy mennyinél vág le, hanem, hogy hogyan?
A ps kiírja, de kiíráskor még nem tudja, hogy pipe vagy terminál lesz az adat fogadója.
Vagy tudhatja valahonnan???
Hisz vágni csak akkor tudna, ha meg tudja különböztetni, hogy hova fog írni.Code:# tput cols
97Ennek ellenére pont 80-nál vág. Tehát nem terminálszélesség. De nem is az a kérdés, hogy mennyinél vág le, hanem, hogy hogyan?
A ps kiírja, de kiíráskor még nem tudja, hogy pipe vagy terminál lesz az adat fogadója.
Vagy tudhatja valahonnan???
Hisz vágni csak akkor tudna, ha meg tudja különböztetni, hogy hova fog írni.Amikor egy programot indítasz a paracssorból, és pipe-olsz vagy fájlba irányítasz, az stdout „át lesz írva”, és úgy örökli a program a fork-nál. Tehát ezesetben a ps stdout descriptorában vagy terminál, vagy pipe, vagy file lesz már megnyitva a felhívás idején.
Ennek tulajdonságait meg tudja nézni a program (ezesetben gondolom a ps). Gyalog C-ben:
ha csak arra kiváncsi, hogy terminál-e vagy sem, egyszerüen egy
isatty(int filedes);
felhívással, ha többre is, akkor
fstat(int filedes, struct stat *buf);
ahol a struktúrában sok minden benne van. Az stdout esetében a filedes értéke 1.
ld: man fstatSzerk: (a te példádban) pipe esetében az adott pipe-ot a ps részére irásra megnyitja az stdout helyén, a grep számára pedig ugyanezt a pipeot olvasásra az ö stdinje helyén. Ettöl „találkoznak össze”. Feltételezem, hogy a pipe esetén „malackodik” a legkevesebbet, mert azt már tényleg nem tudja (bár ha nagyon akarja, akár tudhatja is, de nem „helyböl”, mit az stdout tipusát) hogy ki fogja megkapni.
Amikor egy programot indítasz a paracssorból, és pipe-olsz vagy fájlba irányítasz, az stdout „át lesz írva”, és úgy örökli a program a fork-nál. Tehát ezesetben a ps stdout descriptorában vagy terminál, vagy pipe, vagy file lesz már megnyitva a felhívás idején.
Ennek tulajdonságait meg tudja nézni a program (ezesetben gondolom a ps). Gyalog C-ben:
ha csak arra kiváncsi, hogy terminál-e vagy sem, egyszerüen egy
isatty(int filedes);
felhívással, ha többre is, akkor
fstat(int filedes, struct stat *buf);
ahol a struktúrában sok minden benne van. Az stdout esetében a filedes értéke 1.
ld: man fstatSzerk: (a te példádban) pipe esetében az adott pipe-ot a ps részére irásra megnyitja az stdout helyén, a grep számára pedig ugyanezt a pipeot olvasásra az ö stdinje helyén. Ettöl „találkoznak össze”. Feltételezem, hogy a pipe esetén „malackodik” a legkevesebbet, mert azt már tényleg nem tudja (bár ha nagyon akarja, akár tudhatja is, de nem „helyböl”, mit az stdout tipusát) hogy ki fogja megkapni.
Kiadtam egy
Code:ps -xfa | grep qmail-smtpparancsot. És láttam a futó programok adatait, a végén az indítási parancsorral. Így egy program adatai csak 3 sorban fértek el a képernyőn.
De mivel érdekes volt, amit láttam, kiadtam aCode:ps -xfa > fileparancsot is, hogy minden programot végigézhessek.
És itt ért a DÖBBENET!
Ebben a listában az indítóparancsok a 80. karakternél levágásra kerültek.
Gondoltam, a fájlba irányítás levágta – bár nem tehetné meg -, ezért az első parancsot is kiküldtem fájlba.
Az eredmény: az indítási parancsok teljes egészében látszanak, nem csonkolódnak.
Erre kiadtam aCode:ps -xfa | grep ‘ ‘ > fileparancsot. Az eredmény: Az indítási parancsok nem csonkolódnak.
De ha grep nélkül adom ki a ps -xfa parancsot, az indítási parancsok kiírása csonkolódik.HOGY IS VAN EZ????
Nem értem! A ps program elvileg nem tudhatja, hogy az STDIN-re küldött adatai |-ra mennek-e vagy kéeprnyőre. Logikailag nem értem! A grep hozzáír?
Ez eléggé paradoxonnak tűnik … pedig létezik … próbáljátok ki! (Persze ehhez olyan parancsoknak kell futni, aminek sok-sok paramétere van.)
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz