Zakaj Linux

64202: waaaaaaaaa, full hvala! Printer spet dela bratu in je ze manj tecen :>

Odpri novo temo, ta tema je za filozofiranje ;)

>> Ker kreten je dal za UKAZ oklepaj ?
> Ukaz je v bistvu test, [ je ponavadi symlink na /usr/bin/test
> (dasiravno v mojem gentooju ni tako... Humm... cudno...)
> No [ JE test, moral bi biti :)

Bash ma to ze kar notri, ker si priparas en proces. Drugace pa lahko na BSD-jih vidis /usr/bin/[, sicer bolj zaradi backward kompatibilnosti se mi zdi (pa tudi /bin/sh je na NetBSDju en zelo oskubljen shell).

E, pa se en trik za printerje - ja, CUPS-u zna precej falit. Samo, ce je to kaksen PCL/PS printer imas veliko sans da bo "driver" iz winsev deloval. Namrec, zinstaliraj driver v winsih in potem poisci *.ppd fajle pod \windows\, potem pa to zadevo skopiraj v PPD direktorij of your distro's choice, restartaj CUPS in ga mas ze notr.

Nerdor: pa sej ne pisemo samo desktop sissy aplikacij za winse. Mas se en kup drugih (serverskih) stvari, pa embedded programiranja. Ceprav potem pri serverjih pogosto izpade, da more zadeva delovat na linuxu in winsih :).

> Ej res, svaka jim čast. Prihranki so taki, da bom mogu že kar en TRR odpret, da nekam nakažem viške...

> To je še ena od stvari, ki je bila mogoče pomembna v času PDP-11, danes je pa samo breme.

Mene resno skrbi... . Ce mas for zanko z 10000 loopi (recimo en malo vecji direktorij), se to lahko se kako pozna. Recimo namesto 5 sekund zadeva laufa par minut. Mislim, pa saj noben shell (ksh, tcsh, zsh, ...) nima vec tega kot zunanji program.

Al resno predlagas, da naj se if [ $a == $b ] poganja vsakic v novem procesu?

>> E, pa se en trik za printerje - ja, CUPS-u zna precej falit. Samo, ce je to kaksen PCL/PS printer imas veliko sans da bo "driver" iz winsev deloval. Namrec, zinstaliraj driver v winsih in potem poisci *.ppd fajle pod \windows\, potem pa to zadevo skopiraj v PPD direktorij of your distro's choice, restartaj CUPS in ga mas ze notr.

> To foro poznam, vendar tega ne rabim. Če imam v winsih dober driver za PS, potem v CUPSu vsebino samo eostavno skopiram na prinetr port in ga ne RIPam in predelujem v driverju.

PPD ni driver ampak opis lastnosti printerja. Zato "driver".

Ok, men se ne da vec :). Ajd, no, se en post.

>> Mene resno skrbi... . Ce mas for zanko z 10000 loopi (recimo en malo vecji direktorij), se to lahko se kako pozna. Recimo namesto 5 sekund zadeva laufa par minut. Mislim, pa saj noben shell (ksh, tcsh, zsh, ...) nima vec tega kot zunanji program.

> Zakaj pa rabiš shell za reševanje takih problemov ?

Jaz ne, ker znam perl. Ne znajo pa vsi perla.

>> Al resno predlagas, da naj se if [ $a == $b ] poganja vsakic v novem procesu?


> Pri bashu lahko uporabljaš tako zunanjo aplikacijo kot notranji ukaz pod istim imenom. Če je na razpolago notranji ukaz ali procedura, bo uporabljen ta, drugače bo bash poiskal zunanji ukaz. Če ti to ni všeč, lahko drugačno ravnanje izsiliš s posebnimi ukazi.

Ok.

> Resno ne vidim, kaj ima uporaba "[" kot ukaza za test skupnega z vsem tem.

Ne vem, mogoce sem narobe razumel, samo trdil si, da je [ kot notranji ukaz nepotrebna optimizacija.


>> PPD ni driver ampak opis lastnosti printerja. Zato "driver".

> Vem. "Postscript Printer Definition" ali nekaj takega. Poanta je v tem, da če imaš v Winsih recimo inštaliran 1200 PS z ustreznim driverjem, potem itak dobiš od stroja po reži PS, ki ga lahko direkt odneseš printerju.
Tudi ne rabiš se ukvarjat z lastnostmi printerja, ker jih Win mashina itak pozna.

Jih pa zato CUPS ne pozna. Uglavnem -> meni je ze enkrat ratalo s tem porihtat podporo za en HP-jev PCL printer v CUPS-u in to je meni dovolj :). Mogoce bi delalo tudi ce direkt pajpnem PS na printer, ok (> /dev/usb/lp0), pa bi delalo tudi to da naj se printa na Tray 2 ipd.?

> Zakaj pa rabiš shell za reševanje takih problemov ?

Ker je ponavadi najpreprostejsi nacin. Preden ti napises program, C/C++ ki nadomesti eno dokaj preprosto shell skripto, pretece kar nekaj vode. Pa se vec moznosti imas za napake.

Pa shell skripta bo delala na 99% sistemov, program pa ne.

Brane2: kaj pa ce bi na bash gledal kot na se enega sorodnika perla in pythona? Zmogljiv je ze zadosti.

Doloceni ljudje uporabljajo tudi perl in python za shell.

BigWhale: a ni shell nadpomenka?

> V shellu IMHO ne bi smel ustvarjati ničesar, kjer bi se sekiral za hitrost izvajanja itd.

Zadeve niso tako crno bele. Vazno je, da je dovolj hiter za stvari, ki jih pocnes. Pa tudi sh je bolj primeren za mini stvari, ker se gre za interakcijo s shellom direktno. V perlu in pythonu je tole recimo konceptualno bolj zapleteno:

sh:
for file in *; do program $file; done

perl (dolga dolgocasna verzija)
for $file (glob("*")) { `program $file`; }

perl (l33t verzija:)
`program $_` for glob("*");

python verzijo naj pa kdo drug :)

Tukaj se vidi mentalni overhead, ker moras klicati funkcije, uporabiti operator (ali funkcijo) za klicanje externih programov, ...

Nocem pa, da mi v sh-ju if stavek nepotrebno upocasni zadevo za 50x.

64202:

Ne me hecat. Z "elegantno" perl verzijo si pršprau tolk da bi blo ziher za kako ozonsko luknjo pokrpat.

Ne pravim, da so te stvari slabo izvedljive, pravim da so nightmare za učenje. Vsako stvar lahko izvedeš na 50.000.000 načinov, mnoge poti so že dolgo nevzdrževane (brez opozoril) itd itd.

Kar se sed-a in awka tiče, bi se človek mogoče strinjal, čeprav ju Perl povozi na celi črti.

Vsaj se nihče ni spomnil, da bi šel sed&gawk tlačit v bash "zlu ne trebalo"...

Gawk naj bi bil v osnovi enostavno orodje, pa to v bistvu ni. Ko se spustiš v branje manuala ki je dolg ko poglavje v bibliji in obdelaš vse posebne primere, funkcije itd, potem to ni več simpl orodje.

Če smo že pri tem, v ta namen skoraj raje vidim Perl. Gawka razsuje ko staro kanto, je pa bloated, vendar je ta bloat v enem orodju in ne nasran vsepovsod po malem. Perl je pač namenjen takim zadevam.


Vsa branja manualov pri meni so zgodba z žalostnim koncem. Začnem s kakim "full simpl" orodjem, akterega manpage se kritično sklicuje na druga tri, ki jih nujno rabim za razumevanje prvega. Nato se vsak od teh treh manpageov sklicuje na svojih 7 referenc in tako dalje. Ponavadi obupam po ene par urah naporov nekje v manpage pragozdu in sem srečen če mi od prepotovane poti sploh kaj ostane. Ponavadi mi gozd postane malo bolj domač, ko se v njem milijontič zgubim in vidim, da so ena drevesa prav čudno poznana...

Se pa še spomnim kako me je kot totalnega začetnika bolela glava ob sed-u.

Začelo se je tako, da sem v nekem bash skriptu našel nekaj, še najbolj podobnega čipu ko pomotoma v temi delavnice stopim nanj. Nato sem zvedel, da gre za sed podskript.

Seveda je sledilo branje sed manuala. Kaj je sed ? Sed je praktično to kar je "ed" vendar je serijski. Kaj je ed ? Ed je linijski editor, ki ima dva načina delovanja, "command" in "input", praktično tako kot "vim", vendar vseeno drugače. Kaj je vim ? Vim je Vi Improved. Kaj je je Vi ? ...itd itd itd....

Enako je praktično s katerokoli drugo tematiko. Asembler mi je jasen, tudi vem nekaj o procesorjih, pa vendar je minilo da sem pokapiral kako dela dinamični linking in subtilnosti ELF formata. Pravzaprav tega do danes nisem do konca skapiral. Bom moral prebrati navodila še 10-tič...

V glavnem, problem info/man/helppageov etc je:

-pomanjkanje definitivnih dogovorov okrog formatov

- nepovezanost formatov (info, man, help, docbook etc)

-pomanjkanje izobrazbe piscev (tako poznavanja jezika kot samega pisanja manuala) manualov

Razlage so zelo velikokrat dvo_ali_več_umne in tip, ki je to pisal kar domneva da se vsem bralcem zdi samoumevna samo ena od možnih verzij. Take manuale je izjemno naporno brati, ker se moraš na takih kritičnih točkah ustaviti, dobro premisliti (v stilu "ziher sem kaj spregledal") in nato brati nekoliko naprej ter probati "ujeti zgodbo" v vseh možnih verzijah, ki ti padejo napamet in izsejati tapravo. To me RES ubija.

-pomanjkanje samih pageov na siteih razvijalcev. Tam redno lahko dobiš najnovejšo verzijo programa, manual pa samo za prastaro verzijo tri ali več verzij nazaj...

Se pridružujem mnenju 64202. Za učenje sed, awk, bash, itd. je bolje poiskati kak tutorial/howto/neko_daljše_besedilo z guglom.