Egy fájlban ott figyel mondjuk a valami="blabla". Amíg ez van, addig jó. De ha kikommentelik: (Ez a jó szó?) #valami="blabla" vagy # valami="blabla" akkor figyelmen kívül kéne hagyni. Eddig többek között azt próbáltam hogy grep -E '^#valami' file Ez jó akkor, ha a # jel után közvetlenül ott a szöveg. Viszont az hogy hány darab # jel van, illetve hogy mennyi szóköz van utána, az változhat. A lényeg hogy ebben az esetben a valami értéke a nagy semmi. Azt kell tudni hogyha az első karakter # akkor a valami="blabla" érvénytelen. Nem lehet feldolgozni. Ezt hogy tudnám megoldani? Egy szkriptből ellenőrizném ezt az értéket. Ha valaki esetleg megajándékozna egy megoldással kérem írja le hogy mi mit csinál, hogy meg is értsem, hogy a jövőben már ne zargassak senkit ilyen jellegű problémával. Köszönöm.
Hozzászólások
megforditod a grepet:
vagyis illeszkedik minden sorra, ami nem # kezdodik (ha nagyon akarod, akkor meg kiszurheted a kezdo whitespace-eket is)
utana ha kell, akkor pipe-olod a tovabbi grepelest.
A valami=blabla a sor elején kezdődik? Akkor nem egyszerűbb a grep "^valami="?
Másrészt: esetleg azt is lehet, hogy ezt a fájlt a szkriptedbe behúzod:
Persze ez csak akkor használható, ha a fájl szintaktikailag helyes, meg persze ha nem futtat olyat, amit nem szeretnél.
> A valami=blabla a sor elején kezdődik? Akkor nem egyszerűbb a grep "^valami="?
Egy tipikus config file sok "valamit" tartalmaz. Egyesével grepelni (greppelni?) nincs értelme szerintem.
A source-olás már jó lehet, persze ez is attól függ, mit csinál a program a különböző opciók esetén.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
A source-olás. Szép anyanyelvünk. Ajj. Ebben az esetben nem lehetséges, de a grep "^valami" lett a jó. Köszi. S igazából ezt már én is beírtam csak a ^ jel maradt ki előle. Mert akkor még nem állt össze a kép, hogy itt is alkalmazhatnám. Apró kis nüanszok... és lám.
Biztos, hog ez a jó? Nem teljesen tiszta, hogy mi van, de kommentek szűrésére kevésbé tűnik alkalmasnak, hogy csak a "valami" kezdetű sorokat akarod. Inkább eff megoldása felé menj, annyi, hogy még az elejére egy opciós whitspacet érdemes tenni, mert szokott úgy kikommentelve lenni sor: '^\s*#'
Nem lenne jobb esetleg megoldani, hogy az legyen? Nem hiszem, hogy a konfig részeket ne lehetne külön fájlban tartani.
Lehet úgy scriptet írni, én csináltam már, csak akarni kell. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Mi a pontos feladat? A # rengeteg helyen előfordulhat. Lehet comment eleje, lehet paraméterek darabszáma, de ha jól emlékszem, talán még tömb elemszáma is, meg részstring akár. Szóval igen nehéz parse-olni, jobb lenne ezt a shellre bízni ahogy ezt uzsolt is írta, tehát include-old be a scriptedbe a file-t, s automatikusan a comment-et commentnek veszi, meg a többi dolgot is annak, ami. Az más kérdés, hogy legyen biztonságos ez a file, mert bármilyen kód injektálható így.
Amikor ilyet csináltam, emlékeim szerint egyenlőségjelet kerestem, s attól jobbra és balra csak számokat, betűket és #, /, -, _, ", ', . karaktert engedtem meg, így nem lehet benne helyettesítés, subshell, meg egyéb rafinált kód. Tehát előbb erre teszteltem, ha nem volt jó, hibával megálltam, ha jó volt, include-oltam az egészet, oldja meg a parse-olást maga a shell. :)
Azon el kell gondolkodni, milyen karaktert engedj meg, s ez a paraméterekre korlátokat jelenthet, amivel együtt lehet élni. A $, (, ), <, >, \ megengedése mindenképp kerülendő szerintem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Én így szoktam: grep -Ev "^#|^$" akarmi.txt
Hosszú, kommentekkel telerakott config fileoknál baromi hasznos.
Sor végi komment ellen nem véd. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Sok minden ellen nem ved. De ahogy a feladatot leirtak, kb mindegy is. :)
En eloszor kideritenem, hogy valami szabvanyos formatumrol van-e szo, majd keresnek hozza egy preprocesszort. Ha meg nem szabvanyos, akkor megkerdeznem, hog ymiert is nem az.
De ugye senki se probal grep-pel nekiugrani pl. egy C++ kodnak ebben a kozossegben? ... ugye?
Annak talán nem, a multi line kommentek egy kicsit tényleg nehézkesebbek (bár azért nem annyival) de az inline komment azért nem egy nagy ördöngösség, kb "az első non whitespace char a marker" a teljes sort jelenti, egyébként meg az "első nem escapelt marker előtti rész" az érdekes, mindkettő stabilan megoldható nagyon egyszerű regexel.
Hát, nem udom. A # lehet comment, lehet string része aposztrofok illetve idézőjelek között, de lehet idézőjelben aposztrof, de akkor az nem határolója a #-nak, lehet here document típusú több soros stringben, lehet paraméterek darabszáma, s emlékeim szerint tömb elemszáma is. Meg persze lehet escape-elni például egy command literális paramétereként. Ja, és lehet például ${a##*.} típusú kifejezésben akár. Szóval szerintem cseppet sem triviális a probléma.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igazad van.
Nekem van egy ilyen aduászom:
Ezután csak xgrep config.conf
/*Ha valaki tud jobb megoldást, szívesen várom*/
"It took six days for the god creating this world and see how many bugs it contains! "
A végén minek a parancshoz hozzáfűzni egy szóközt? Nekem egyébként ezzel van bajom:
Ez kiszedi azokat a szóközzel kezdődő, amúgy érvényes sorokat, amelyeknek a végén van comment. Tehát pl. a
sort szerintem törli.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ha a címet figyelembe veszem: komment _sor_ - akkor ennyi kell neked:
$ grep -v '^[ \t]*#' filename
vagy épp
$ sed -e '/^[ \t]*#/d' filename
(Vagy fentiekhez hasonló módon magával a perl-lel megcsinálni - jelenleg nem tudjuk, hogy a használni kívánt környezetben milyen kvázi-sztenderd parancsok milyen implementációi érhetők el.)
a \t helyén egy valódi tabulátort kell ütni, amihez bizonyos shellekben (hint: bash) Ctrl-V TAB formában kell begépelni. Ha valami olyan OS-t használsz (hint: legtöbb Linux disztró), aminek a grep-je (vagy sed-je) valami opció hatására, vagy épp magától a BRE-nél ismer kicsit többet (mondjuk PCRE-t), akkor lehet a fent is emlegetett, némileg egyszerűbb regexp
'^\s*#'
formában írni.
De ugye a komment sor attól lesz az ami, hogy nincs benne más, szóval locsemege részletesen kifejtett magyarázata arról, hogy hol mindenhol szerepelhez # az hasznos, csak itt fölösleges (ha a a felvetés az lenne, hogy komment_et_ tartalmazó sor; vagy a kommenteket hagyjuk figyelmen kívül - no akkor lehet locsemege részletes listáját implementálni).
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Valóban nem olvastam figyelmesen a bevezetőt. Akkor ez így nem túl bonyolult probléma, mert neki csak az kell, hogy a valid sorok elé néha tesz egy komment jelet, s ez zavarja a tisztánlátásban, szeretne megszabadulni a látványtól.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Nos srácok. Vagy én nem tudok fogalmazni, vagy nektek vannak szövegértési problémáitok. Úgyhogy még egyszer szájbarágósan.
1 - Írtam egy szkriptet, mely magában minden gond nélkül működik.
2 - Van egy teljesen idegen fájl, semmi köze az előbb említett saját szkripthez. De ebbe az idegen fájlba beleírhatnak egy változót. Teszem azt legyen prompt="myPrompt1"
3 - Nos. Az általam írt szkript leellenőrizné hogy ebben a vad idegen fájlban van-e ilyen bejegyzés hogy prompt=
4 - Négy lehetőséget tudok elképzelni.
a, Nincs a fájlban ilyen sor
b, van ilyen sor de ennek 3 változata lehet. (Fossuk a szavakat!) hogy értsétek.
prompt="MyPropmpt1"
#prompt="MyPropmpt1"
# prompt="MyPropmpt1"
Persze lehetnek szélsőséges esetek is.
####### prompt="myPrompt2" - De ez már a hülyeség határa.
De a grep '^prompt' Nyizsa javaslata ezt is jól értelmezi. Még egyszer köszi. Vagyis érvénytelen. Nem kell figyelembe venni.
Tudtommal egy shell szkriptben, config fájlban ha valamit nem szeretnénk hogy egy futó szkript figyelembe vegyen, #-et teszünk elé. Szokás kérdése hogy ki mennyi #-et tesz, és hogy hagy-e szóközt utána. Ezt szeretném vizsgálni. S mivel szkript használná fel, így egyértelmű hogy ebből a három lehetőségből csak az első az érvényes a többit figyelmen kívül kell hagyni. Az olyan lenne mintha nem adtunk volna meg semmit.
MÁS
Offtopic
Soha nem írom le a tényleges dolgot, mert vannak akiknek ez hülyeség, mit kínlódok vele, stb. Sokkal egyszerűbb megoldás is van. stb. Nem tudhatják hogy mit és miért csinálok. Persze nem vagyok programozó, s ezért vannak kérdéseim. De igyekszem.
Nem üzemeltetek szervereket, nem vagyok rendszergazda, de Magyarországon nem találtam sima mezei felhasználóknak szánt vagy való fórumot. Valaha volt a linuxforum, volt a mandriva fórum, Mind eltűntek. Kezdeti nagy fellángolások, majd ellaposodnak a dolgok, végül megszűnnek, vagy tetszhalottak.
Az a helyzet ha esetleg ide tévedne egy tizenéves, akkor hamar eltűnne mert az itteni nagy guruk csak odavakkantanak valamit, mivel nekik a kisujjukban van minden, és mit képzel ez a taknyos még ezt sem tudja?
Ha kap az embert megoldást, akkor sincs leírva hogy mi mit csinál. Így nem is fogja megérteni. Hanem bemásolja azt jó napot. Ez így gáz.
Az itt lévő nagy tudású linuxosok igazán vehetnék a fáradtságot erre is. Példát lehetne venni a stackoverflow.com oldalról. Ott az is le van írva az is, hogy mi a fene az a hatványjel a prompt elején. Így lehet tanulni.
Persze mindjárt kapom az oltásokat, hogy akkor mit keresek itt? Elsősorban a származásom miatt vagyok magyar oldalon.
Lehet most egyesek szerint goromba voltam, elnézést mindenkitől, de akkor is ez az igazság. S az igazság fáj!
Ha az éppen most folyó topik címet nézem, amit én adtam. comment sor figyelmen kívül hagyása. Ha most így utólag megértettétek hogy mit akartam, akkor a cím nem fedi a valóságot?
Majd ezt írtam:
Szerintem teljesen érthetően leírtam. Igaz nem írtam a körülményeket de ebben az esetben nem is releváns. Most lehetnék nagyon bunkó is: (
tudjátok mi ez a szó?)És mivel utálom a sört, tehát még csak jó ember sem lehetek, iszok egy pohár vizet.
Na jó, de miért ez az érzékenység? Kaptál jól használható válaszokat. Szerintem még mindig uzsolt válasza adja a legcélszerűbb, legegyszerűbb megoldást:
Ekkor maga a shell rendezi ezt, az értékadásokat végrehajtja, a commenteket figyelmen kívül hagyja. Ha te írod a config file-t, nem kell semmiféle ellenőrzés. Ha nem, akkor óvatosan, mert a config file-ba írt rosszindulatú script is le fog futni, nem csak sima értékadások, tehát akkor kell valamiféle ellenőrzés. Erre írtam, hogy az egyenlőségjeltől jobbra és balra lévő karakterekre lehet megkötést alkalmazni, és akkor ez is megvan.
A grep és sed példák is jók, de ott nem lett kifejtve, hogy a grep-pel vagy sed-del leszűrt file-t hogyan teszed a shell számára végrehajthatóvá. Meg lehet csinálni, de ebbe azért nem megyek bele, mert nem is kell semmit szűrni, ha az egész configodat beszúrod a scriptedbe a source avagy . belső paranccsal.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Szia. Az érzékenység talán azért, mer úgy vettem észre hogy akárhogy fogalmazok, senki nem érti meg. S akkor a sommás vélemény: én vagyok a hülye mert vízöntő vagyok. S mint ilyen mindig más utakon járok más srófra jár az agyam. Kész. Ennyi.
A . "$CONFIG" dolgot ismerem, de most nem jó. Mert akkor a szkript az egész config állományt behúzza. Olyan dolgokat is amire semmi szükség. Ezért gondoltam arra hogy csak simán kiszűröm egy grep paranccsal a config fájlból az ominózus részt. S akkor elvileg semmi ártalmas dolog nem juthat be, mert kimondottan célirányosan egy dolgot keresek. És nem a fájlra van szükségem, hanem a fájlban egy megadott változóra. Illetve erre sincs szükség de ha létezik akkor felhasználjuk.
De legyen. Én Mageiát használok. S a Mageiában van egy /etc/profile.d könyvtár, mely tele van shell programokkal. Talán 2009-ben küldtem be egy javaslatot meg egy kis szkriptet, hogy tegyék elérhetővé a promptot színesben is. A felhasználó zöld, a root piros prompttal látszódjon. Nemsokára megjelent a colorprompt.rpm. Kicsit hozzáigazították a rendszerhez, de ott volt. Azóta is ott van. Az /etc/profile.d/92user-color.sh néven.
Úgy gondoltam hogy egy kicsit ráncfelvarrom. Teljesen újraírtam az egészet, és szubrutinokba szerveztem egyelőre 6 különböző prompt beállítást. Ok. No de hogyan lesz ebből a felhasználó számára látható dolog?
Hát úgy, gondoltam hogy megad egy változót a .bashrc fájljában. prompt="myPromptX" néven.Ahol az X egy szám egyelőre 1-9-ig. A 92user-color meg szépen beolvassa, és a megfelelő rutint megjeleníti. Ha a felhasználónak nincs a .bashrc fájljában ilyen prompt sor, akkor a 92user-color egy alapértelmezett promptot állít be.
Ha a felhasználó a. basrc fájljában # jelet rak a prompt="myPrompt2" elé, akkor azt figyelmen kívül kell hagyni. Ezt nem tudtam megoldani. S igen tisztában vagyok az ártalmas kódok bevitelével. Ezért gondoltam arra hogy nem sourcoljuk az egész .bashrc fájlt, mert az magában is lefuthat. S ha magában le is fut az így utólag beírt prompt="myPromt2" -vel ő nem tud mit kezdeni.
Vagyis én mint nem programozó úgy gondolkodtam hogy csakis és kizárólag a prompt szót fogom keresni a .bashrc fájlban. Ezzel előzve meg a nem kívánatos injekciókat. Ráadásul tovább is szűröm a dolgot.És csak egy számmal dolgozok. Most akkor a kérdés hogy ez így biztonságos-e? Értelmes-e? Fölösleges-e?
kereshetsz egyszerűbben is:
Na, így már világos. Lehet csak bash, vagy hordozhatónak kell lennie? Sokféleképpen meg lehet csinálni, de mivel épp betegen teázgatok itthon - vélelmezem, hogy COVID -, foglalkozom vele kicsit. Persze csak ötlet szinten, de írok demo scriptet, mert olyan sok helyen el lehet szúrni egy scriptet, hogy mindenképp ki kell próbálni, mielőtt itt a fórumban leírom.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Na várj, jól értem, hogy te a .bashrc-t akarod földolgozni?
Ha szerepel benne egy értékadás, pl. az általad említett prompt="myprompt1", akkor az a bash sessionben elérhető lesz. Neked csak annyit kell tenned, hogy használod a $prompt változót. Ha nincs ilyen sor, vagy ki van kommentezve, akkor üres lesz.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Ezen még én sem gondolkodtam, hogy minek, de a válogatáshoz egy case is elég, vagy akár egy string tömb, ahol a tömb elemei a promptok, s az index hivatkozik rájuk. Én is színezem a promtom, de egyszerű a megoldás. Kis híján scriptet írtam a promtba, így néz ki:
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Hát én most se értem, hogy mit akarsz.
Ha nem a . (vagy source) paranccsal olvasod be ezt az idegen fájlt, akkor hogyan dolgozod fel? No, akkor ezt a feldolgozást kell kiegészítened oly módon, hogy beleszúrod a folyamatba pl. a fent emlegetett sed / grep / perl parancsokat. ugyanis ezeknek az lesz az eredménye, hogy ha megjegyzésben van a te változód, akkor eltűnik, mintha egyáltalán nem lenne ott. Márpedig mintha azt írtad volna, hogy van ott változó, vagy nincs. (" ebbe az idegen fájlba beleírhatnak egy változót" - kiemelés tőlem)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Na, ámokfutottam. :)
main
main.conf
Output:
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Azért a fenti scripttel van néhény probléma. Ha azeredeti scriptben szerepel valami ilyesmi
akkor ezt feltétel nélkül elhiszi a script. Meg abból is lesz baj, ha a sor végén backslash van, s több sorból rakunk össze egyet.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Az nem jó, hogy ahogy feldolgozod soronként, ráhúzol egy
cut
-ot, szétvágod a # karakterek mentén és csak az első részt veszed?Így ha nincs benne # akkor az egészet kapod, ha meg van, akkor meg a legelső # előtti részt.
Oldschool Computer - http://oscomp.hu
Ha meg idézőjelek között van, akkor kap egy hibás sort. Meg egy ${var##.*} kifejezésnél is, és ilyenre rengeteg példát tudok még.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
locsemege Küldtem privát üzenetet. A kapcsolat fülön.
Én meg válaszoltam. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A kommenteket nem olvastam, a nyitó posztban nem volt róla szó, hogy shell scripteket akar kommenteleníteni. Esetleg ez?
Innen: https://blog.sleeplessbeastie.eu/2012/11/07/how-to-remove-comments-from-a-shell-script/
Oldschool Computer - http://oscomp.hu
Nem egészen ez kell neki. Valami olyasmit szeretne, hogy egyetlen változóra csillan fel a szeme, s annak értékadását szedje ki a scriptből.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ha a fájlban megjegyzések és értékadások lehetnek egyedül, akkor egyszerű.
$ grep 'valami1'=' config-file | grep '^[ \t]*#'
Ennek kétféle kimenete lehet. Üres sor, ha megjegyzésben van az értékadás. illetve
valami1=akármi
ha nincs kikommentelve. Ezek után ha mindezt parancshelyettesítéssel rakom be a scriptbe, akkor máris van egy értékadás. Sajnos ezt még egy eval-lal meg kell fejelni a kívánt hatáshoz, szóval
eval ` grep 'valami1'=' config-file | grep '^[ \t]*#' `
A ` ` helyett persze lehet írni $( ... ) formában is.
Abban a pillanatban, ha abból indulunk ki, hogy bármilyen shell konstrukció, no az zűrös.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Azért annyira nem, én ezt írtam elsőre. Jó, ha egy if belsejében van az értékadás, vagy a végén escape-elve van a sor végi LF, akkor nem jó a megoldás.
Nekem az egészben az a furcsa, miért kell a .bashrc-ből kiszedni egy értékadást egy másik script számára. Miért nem lehet ezt úgy, hogy az egészet beleírja a .bashrc-be, vagy, ha ez zavaró, akkor egy külön file-ba, s onnan húzza be source-szal? Kiválasztani hatféle promptból egyet az nem egyéb, mint egy tömb egyik elemére hivatkozni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Valami olyasmi... :)
Ennyi erővel futtassa le a szkriptet dottal, aztán máris be van lőve a változója.
Vagy ez sem? :)
Oldschool Computer - http://oscomp.hu
Ezt alkottam:
Ha a .bashrc fájl tartalmaz prompt="myPrompt" sort, akkor a számnak megfelelő PS1 aktiválódik.
Olvastad a levelem?
A promptok végein a \\$ nem jó. Az egész kód végén előbb csinálsz egy összehasonlítást, utólag még megnézed - azt sem minden esetre -, hogy egyáltalán az összehasonlítást mgcsinálhattad volna-e. Ha C-ben NULL pointer is lehet, nem a dereferálás után nézzük meg, hogy egyáltalán valid-e a pointer, hanem még azelőtt, hogy elszállna az egész NULL pointer dereference üzenettel. :) Meg a tail futtatása is felesleges. Nézd meg fentebb, hogyan csináltam, s miért úgy! :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Nem jó.
ha beletennék egy "rm -rf ~/"-et? Ne próbáld ki.
Persze, mert nem ellenőrzi, hogy a hat függvényének nevén kívüli paramétert adtál-e neki. Ezért kellene ott csak egy számnak lenni, a számságot és intervallumot ellenőrizni kell, majd ezt tömb indexként használva tömbből elő kell szedni a színes PS1-et. :)
Igen, remek security hole, code injection lehetőség.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Szerintem neked egy egyszerű case kell.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Vagy:
A prompt pedig a configból jön például
formában. Nyilván kell intervallum ellenőrzés, meg az, hogy egyáltalán szám-e az index.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
> Nyilván kell intervallum ellenőrzés, meg az, hogy egyáltalán szám-e az index.
Ezért jó a case-ben a *).
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Szeretem az általános megoldásokat. 10000 elemű tömbnél kicsit nyűgös már a case, de valóban, 6 eleműnél ez még megoldható így. Feladata válogatja, meg a programozó ízlése. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ha ez a feladat, akkor én lehet, másképp csinálnám. Mégpedig úgy, hogy minden egyes prompt-színezést fájlokba raknék egyesével (azaz az esetedben lenne 6+1 fájl, a prompt0-val), ezt nyilván valami beszédes és kezelhető fájlnevekkel. A beállított prompt változó pedig a fájlnevet tárolná, amit egyszerűen csak beolvasol (miután ellenőrzöd, hogy a megfelelő könyvtárban létezik-e ilyen nevű fájl).
Sőt, még egy kicsit továbbmenve: mivel úgyis mindegyik esetben külön kapja a root felhasználó, a promptos fájlokban pl. egy ps1_user="....", ps2_user="...", ps1_root="..." és ps2_root="..." sorok lennének, és a beolvasás után a fő program állítaná be az "igazi" PS1 és PS2 értékeket.
Tehát pl.:
És akkor nem kellene számokkal variálnod, ha új promptot találsz ki, akkor nem kell a maxnumbert átírni, új függvényt megírni, stb., hanem csak lerakod a fájlt, és kb. működik is.
Ja, és ha a .bashrc-ben tényleg nem használod a prompt változót, akkor ezt a prompt változót (azaz amivel beállítod, mi legyen a prompt) egy külön fájlba raknám (prompt=prompt_piros módon), és ezt olvasnám be, és nem kellene vergődni a fájl értelmezésével.
> ...nem kellene vergődni a fájl értelmezésével.
Még egyszer: nem kell vergődni a fájl értelmezésével, a .bashrc pont erre való.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Ezt én értem is, csak valami ok miatt akarja ezeket a topiknyitó külön állítgatni.
Ha teszem azt, külön programot akar indítani bizonyos esetekben (nekem pl. van egy "sandbox" szkriptem, ami egy eldobható könyvtárat hoz létre, és "abban" elindít egy shellt, amiben pl. a fórumokon feladott problémákat probálom, és a shellből való kilépéskor törli a könyvtárat), és ekkor akar különböző promptokat létrehozni, akkor akár elképzelhető is, hogy miért nem a bashrc-ből akarja - és ebben az esetben a bashrc-ben állított változót átraknám egy másik, különálló fájlba, hogy egy random (saját) program beállításai ne a bashrc-ben legyenek.
Néha javítgatok rajta, hogy szebb legyen.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A case jó ötlet. De amúgy is vannak még gondok. Ugyanis ha ebben a formában marad, akkor nem teljesen az lesz amit elvárunk. Ugyanis így most természetesen figyelembe veszi a root felhasználó .bashrc fájlját is. A Mageiában alapból nincs sudo. su van helyette.
S így ha megadom a felhasználó részéről az 5-öst, a root akkor is 1-es lesz. Holott azt szerettem volna hogy ugyanaz legyen a promptja csak pirosban. De ezt a path jobb megválasztásával orvosolni tudom. /home/$USER/.bashrc
Nem lehet, hogy amit csinálni akarsz, az a /etc/profile.d alkönyvtárba írandó file lenne? Szerintem tegyél le arról a koncepcióról, hogy egy script kiszed egy másik scriptben található értékadást, hogy felhasználja azt, noha a másik scriptben is megtörténik az értékadás - teljesen feleslegesen, s a kódot olvasó számára zavart okozva. Mert mit fog látni? - Nini, ez egy felesleges sor, nincs használva a változó, töröljük hát ki! Először azt gondold végig, hogan indulnak a shell init scriptjei, s azokkal önmagukban megoldható a színezés. Én is színezem a promptot, illetve beleteszem az előző parancs exit kódját, de sokkal egyszerűbben csinálom.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
És ha a felhasználók nem a /home-ban vannak? Van egy $HOME nevű változó is. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
~USER a keresett kifejzés. (Ami pl. root usernél elég sok esetben /root; más felhasználónál pedig /home/Joska meg /usr/home/Pista.)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Jogos, mert a HOME az aktuális user-é.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Mihez kell neked ez pontosan? Mert szerintem az egész problémát rosszul közelíted meg. Ha azt akarod megtudni, hogy létezik-e a valami nevű változó, és az értéke "blabla", azt meg lehet tudni kulturáltabban shell scriptnél, és nem kell ellenőrizni a kikommenteltséget. Azonban ehhez tudni kéne, hogy mit akarsz ezzel az egésszel, shell script, vagy valami saját config szintaxisú fájlt akarsz parse-olni, stb..
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Leírta. Választható színes promptot szeretne csinálni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Akkor az nem jó, hogy lefuttatja, majd simán használja a változót?
Oldschool Computer - http://oscomp.hu
Én is azt javasoltam, hogy de. Nem nagyon látom értelmét, hogy a .bashrc-ből egy másik script kiszedi a változót, minden mást ignorál, majd felhasználja, miközben a .bashrc-ben úgy tűnik, semmire sincs használva, felesleges, ezért előbb-utóbb valaki úgyis törli majd az egyszerűsítés jegyében. Szóval a nyakatekert megoldás olvashatatlan, félreérthető kódot eredményez. Ki gondolná, hogy van egy ebben a scriptben nem használt változó értékadás, de az mégis kell, mert valaki elolvassa ezt a scriptet? További probléma, hogy mi van, ha feltételesen adok neki értéket, vagy a sor el van törve a sorvégi LF escape-elésével, és a következő fizikai sorban folytatódik.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ha nyitok egy új terminál ablakot a .bashrc feldolgozásra kerül.
Tudom. Ezért sem értem a koncepciót.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Pontosan ezt írtam én is, szóval a topic kb. okafogyott.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Ja, hogy a tippemet már te korábban elsütötted neki? Sorry, nem olvastam végig az egész topicot, csak rákerestem a dot parancsra, azt senki nem mondta, gondoltam bedobom. Lehet máshogy fogalmaztad meg.
Oldschool Computer - http://oscomp.hu
Itt és itt.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ok, mondom, hogy nem olvastam el az összes kommentet, csak rákerestem a dot parancsra, hogy volt-e.
Oldschool Computer - http://oscomp.hu
Igen, volt, többször is.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
De azt egyikőtök se írta ki, hogy "dot". Úgy nem csoda, hogy a Ctrl+F nem találja.
Oldschool Computer - http://oscomp.hu
Azt nem, de akár azt is írhattuk volna, hogy pont. De leginkább azt, hogy source. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A ponttal pont nem vagyunk ki a vízből, gyakorta használt magyar szó. :P Source-ra nem kerestem rá, de tudtommal ennek ez a rendes neve, hogy dot command.
Oldschool Computer - http://oscomp.hu
Bash-ben a source a szinonimája a .-nak, amúgy meg valójában include. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Sajnos a bash-specifikus cuccokat nem ismerem, csak a POSIX-ot. :P
Oldschool Computer - http://oscomp.hu
Mit tanácsolnánk annak, aki egyszerű eszközökkel (pl. sed/grep/awk) akar egy bonyolult formátumú fájlt (pl. csv, xml, json, shell script, C-source) elemezni?
"Ne!"
LOL :D
De amúgy jogos. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
(A napokban jött szembe, ha jól rémlik valami JSON-t greppelhetővé tevő eszköz..)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Jq vagy jp