Názory k článku Programování pod Linuxem pro všechny (2)

jeeee... ja jsem prvni :)

a koukam, ze tento serial zacina byt opravdu zajimavy.

a taky koukam, ze se ani neumim podepsat :)

Pepa.

Uz pri zbeznem prehlednuti jsem se ponekud zarazil, kdyz autor v resumé annoncoval praci s docasnymi soubory, a na konci ji odlozil na priste. Pokud by se pouze zmylil v nastinu dalsiho dilu, bylo by to samozrejme pochopitelne, ovsem clanek samotny se obvykle pise jako celek, a textovy editor autora jiste umozne pohyb v textu souboru.

Priznam se, ze oddil o getopt_long() jsem prilis pozorne necetl, zdrzim se tedy komentaru. Ale zato popis promnenych prostredi je natolik strucny, ze sel preletnout velmi snadno, a to je take jeho hlavni problem.

Myslim, ze je pomerne zasadni popsat zacinajicim programatorum, jak se vlastne environment v UNIXu dedi apod., nebo se jako mnozi pred nimi budou divit, proc se v shellu neupdatuji hodnoty promnenych, ktere meni. Kdyz uz take autor popsal setenv() a unsetenv(), stalo by snad za uvahu je zakomponovat do onoho pomerne kratkeho prikladu, treba misto tech vyteckovanych radku (nebo to znamena, ze je odstranila redakcni cenzura? ;-)).

Co se tyce setenv() a unsetenv()... je sice pravda, ze autor pise clanky o programovani _pod Linuxem_, nicmene by jiste stalo za uvahu rovnou ucit programatory psat i kod portabilni (pokud to samozrejme ma smysl). Proto by se jiste sluselo alespon velmi strucne (i kdyz to s ohledem k tomuto clanku znamena stejne strucne, jako k ostatnim funkcim) zminit o funkci putenv() a o tom, ze narozdil od *setenv() se sice pouziva priserne, ale zato ji mame garantovanou na kazdem POSIXovem systemu, a nikoliv pouze na BSD derivatives.

Treba by neuskodilo si na zacatku dalsiho pokracovani zkusit popis promnenych prostredi zopakovat znovu a poradne... vzdyt je to preci skoda. A muzeme se rovnou zminit o tretim parametru main()u, ci take hojneji pouzivat odkazy na rozsirujici zdroje (rozumnej manualove stranky), napriklad environ(5).

Ach jo, kdybych misto kritik psal radeji clanky, za ty me alespon nekdo plati ;-).

Pokud pozadujete vyssi rychlost i rozsah informaci, navstivte sveho knihkupce a za par korun si poridte knihu "Pokrocile programovani v operacnim systemu Linux" anebo anglicky original "Advanced Linux Programming". Nacerpate z ni podobne know-how.

To ze kazdej bezici proces ma svoji kopii environmentu je zakladni informace. A jediny komu to bude zpusobovat problemy sou prave zacatecnici, imho by to mela byt prvni veta ktera o env mluvi - ne ze kazdy program ma prirazeno jiste prostredi, ale to ze kazdy proces ma svoji kopii. Ted me zarazila dalsi vec, autor mluvi o procesech ale rika jim programy, nekonzistence v nazvech zacatecniky mate jeste vic. Z toho co autor napsal to vypada ze kdyz pustim ctyrikrat jeden a ten samej program tak budou mit jedno konkretni prostredi...

když se tak zamyslím nad články a komentáři v poslední době, mám takový pocit, že by zde spíš místo jednotlivých autorů měly vystupovat týmy: někdo méně pokročilý to napíše, ostatní mu to zdrbou, aby se to opravilo v souladu se všemi pravidly bezpečnosti, portability a pravopisu ;-) po opravě jim to zdrbe on, že to BFU nepochopí a zlidští to, guru opět opraví chyby ... a po několika takových cyklech máme dokonalý článek :-)

no nic, nechme snění a buďme rádi aspoň za to, co máme... děkuji všem autorům i jejich kritikům!

No to není tak zcestná myšlenka - nebylo by špatné, kdyby vedle roota byl ještě jakýsi root wiki :-)

Pri cteni kavolova prispevku jsem si pomyslel totez. Napad zridit RoOta neni vubec k zahozeni ...

No hej nebolo by to od veci.

Ono by stacilo dat clanky precist lidem ktery tomu rozumej a najdou v nich ty matouci nepresnosti pred tim nez se vyda...

Ja osobne nemam nic proti tomu, aby byl clanek jednoduchy a nezabihal do zbytecnych podrobnosti, stalo by vsak jiste za to alespon naznacit, ze "je za tim mnohem vic".

Ja tuto funkci vubec nepouzivam a to ze 2 duvodu, je neportabilni (zbezna zkouska pod SUNem nebo BSD to odhali) a znacne omezuje tvar a pouziti parametru. Mozna by stalo za to udelat par poznamek kvuli porabilite a predevsim ze zacatku se omezit spise na dobre prenositelne funkce zvlast kdyz getopt je POSIX korektni a getopt_long ne.

Nazdar.

Sam jiz nejakou dobu programuji pod linuxem, ale o tehle funkci (getopt) jsem nevedel. Dekuji tedy autorovi, za jeji popsani. Me diky patri ale take vsem krtikum, protoze jsem mel v umyslu tuto funkci pouzit (na zaklade prezentace v clanku). Jelikoz ale muj program by mel bezet i pod systemy Solaris, jevi se jeji pouziti jaksi problematicke.

Cau, Bernos

Neportabilni je (mozna, nevim) getopt_long(), naopak getopt() je portabilni a POSIXova. Ale obyc. getopt() neumi dluhe prepinace, zvladne -p, ale uz ne --print, to me osobne ale nevadi. Zrovna vcera jsem na Solarisu8 kompiloval pod gcc2.95 svuj (na Linuxu vyvinuty) program, zadny problem, getopt() jede jak vino.

Mohl by mi někdo prosím vysvětlit, rozdíl mezi datovým typem char a u_char v linuxu se docela dost často vyskytuje. Hledal jsem to ve vyhledávači, ale nic moc nenašel.

A odpovím si sám u_char je usignet char a nenabývá záporných hodnot.

char také na některých architekturách je od 0 do 255 a nenabývá záporných hodnot. Zda je char znaménkový nebo neznaménkový není v normě definováno.

getopt_long je zrovna ten typ funkce, o ktere by mel zacatecnik slyset co nejpozdeji. Funkcim s vedlejsimi efekty (pouziva statickou enumeracni promenou) se kazdy moderni programator obloukem vyhne. Takhle se programovalo v minulem stoleti !

Navic takova strojovna pro tak jednoduchou akci jako je parsing parametru ? Citim za tim ducha tech, co zplodili X server. A to je moc smutna kapitola. Uvidime jestli se k tomu autor v nekterem dilu dostane.