Hasznalsz-e kereskedelmi Unixon bash-t?

HUP

Gondoltam, mielott inditok egy szavazast, lehetoseget adok javaslattetelre es ertetlenkedesre.

Arrol szeretnem a szavazast inditani, hogy aki bash-t alaptelepitesben nem tartalmazo *kereskedelmi* Unixot hasznal, fel tud-e tenni, illetve egyaltalan akar/szokott-e bash-t hasznalni.

Az opciok meg nagyjabol ezek lennenek:

- nem elerheto/nem megengedett, de ha lenne is, akkor sem kellene
- nem elerheto/nem megengedett, pedig jo lenne
- elerheto, de nem hasznalom
- elerheto, es hasznalom is (mindegy, hogy allandoan vagy alkalmankent)
- nem dolgozom kereskedelmi Unixokkal/csak az eredmeny erdekel stb

A dolog apropoja az, hogy egyre inkabb a produktivitas novekedeset latom a bash mint interaktiv shell hasznalataban, barmennyire is 'korcs' megoldasnak tartjak sokan a tiszta Unix hivei kozul.

Scripteket a standard kedveert tovabbra is sh vagy ksh shellhez irok.

A *BSD pd/mksh-val es tarsaikkal ellentetben az AIX ksh88, de meg a ksh93 is eleg szegenyes, tehat nem ervenyes pl azzal jonni, hogy 'nalam OpenBSD-n ksh-ban is mukodik a case insensitive globbing'. Es pont ezek miatt korlatozodik a szavazas a kereskedelmi Unixokra (AIX, HP-UX, regi SunOS, esetleg Tru64, UnixWare stb). Linux, *BSD nem ervenyes.

Velemenyek?

--

ps. A cegnel en vagyok a hivatalos 'ksh nazi', szoval a 'tanuld meg hasznalni' tipusu flame-nek helye nincsen ;-)

  • 7080 megtekintés

( Zahy v | 2010. 06. 16., sze – 07:24 )

Tanuld meg hasznalni, b+ :-)

Ja, en mar most a "volna lehetoseg, de nem" -re szavazok.

Egyebkent az "interaktiv hasznalatra bash, scriptet meg ksh-hoz/posix-shellhez irok" hasznalat kisertetiesen emlekeztet a vagy 20 evvel ezelotti allapotra, amikoris jopar ember csh-t hasznalt, mert abban volt history, meg alias, meg hasonlo interaktiv hasznalatot megkonnyito parasztvakitas (mondjuk a maiak valoszinuleg vert hugyoznanak, a

!-3:4 !$ !s:8 !!:5-7

jellegu parancssoroktol), de a csh agybajai miatt scriptet sh-ban irtak. Egyebkent ha valakinek shell-scriptet kell irni, az tanulja meg a bash-ksh kulonbsegeket, es mivel 99%-ban lehet hordozhato kodot irni tegye ugy. Nyilvan erre az emberek tobbsege nem aldoz energiat, aki meg majdan karbantartja, az szopjon nyugodtan azert, mert (amugy kb ertheto okokbol) a GPL-vilagjarvany elterjesztesenek hivei (nyilvan) tudatosan igyekeznek nem nagy figyelmet szentelni azokra az aprosagokra, hogy ha ksh-ban van typedef, a bash-ban pedig declare, akkor jelezzek, hogy annyira ugyanarrol van szo, hogy declare helyett lehetne mindig typedef -et irni bash-ban is. Vagy a $[ kifejezes ] forma helyett is elfogadja a bash a ksh-ban (joval korabban) bevezetett $(( kifejezes )) format is. Termeszetesen a forditottjara is van pelda, boven eleg a ksh print-jere utalni. (Tovabbi kurvaanyazasokert tessek elolvasni a bash4 kapcsan tett megjegyzeseimet.)

Azt még mindig nem értem, mi köze a GUI-s BIOS-nak az én bash-NC párhuzamomhoz, de ez talán nem is baj.
A szánalmas pedig az, amikor valaki nem tud semmit sem csinálni egy számítógéppel, ha a kedvenc eszközei nincsenek rajta. Ahogy van élet nc nélkül, úgy van bash nélkül is.
Mondjuk nekem meg az ioscan szokott hiányozni a !HP-UX rendszerekből, de erre a problémára még nem találtam általánosan használható megoldást.

Ave, Saabi.

"nem értem, mi köze...": nem olvastam végig az egész szálat, nem vettem észre melyik végéről nézed a lusták köztes megoldását. Mindig ott találom magam, a kis kőkorszaki létem lenézésének a kellős közepén.

Nekem kellenek azok a kedvenceim, amit nálam sokkal okosabbak azért találtak ki, hogy nekem könnyebb legyen.

Ha váratlanul valahol szeget kell verni valahova, nem akaródzik kalapácshelyettesítésen is gondolkoznom - mert azzal kényelmesebb. Hogy van az, hogy ezeknél nincs otthon egy rohadt kalapács?
Másnap persze már arról suttognak a népek az utcában a hátam mögött, hogy egy lépést sem tudtam tenni kalapács nélkül.
Szerintem viszont nem akartam - az szeg persze ettől függetlenül be lett verve.
:-)
Van élet minden nélkül is, de élet az?

Ezért FreeNAS/FreeBSD-re mc-t és mysql-t is raktam fel - utf8-at is raktam volna, de az még nem megy mc alatt normálisan.
(WebGUI-n vagy kliensként persze nincs ez az utf8 probléma, csak egyfelhasználós rootként.)

Van sokféle kalapács, van, ahol ki van téve az asztalra, mint egyedüli szerszám, és van,a hol a szerszámos ládában kell megtalálnod a kalapácsként, vagy helyette használatos eszközt, ami lehet pl. egy szögbelövő pisztoly is akár, sőt van, ahol a szöget nem egyszerűen megfogod, odateszed, és ráütsz egy picit, hogy megálljon, majd sitty-sutty, bekalapálod, hanem kezedbe nyomnak egy szögbeverő kézi készüléket (van ilyen: műanyag nyél, benne egy fém tüske, a végén vékony cső, amiben elfér a szög, és a fém tüskét ütod - pl. lambéria felrakásakor, hogy ne üsd le a léc szélét), és azt is kell használni.

Nem a kalapácsot kell ismerned, hanem meg kell tanulnod beverni a szöget.

( Fisher v | 2010. 06. 16., sze – 08:14 )

Ahol kereskedelmi unixot használnak, az valszeg nem az otthoni médiaszerver, hanem valami cég. Esetleg nagy cég. Mármint úgy nagy, mint a GE nem úgy mint szomszéd téesz. Ez ilyesmi helyen vannak előírások, pl. arra nézve, hogy mit lehet a gépekre feltelepíteni, és sokszor e miatt nem lehet feltenni az amúgy létező csomagot. Pl. volt ahol csak azt tehettük fel, ami a hivatalos telepítőcd-n megtalálható. Akkor ez szúrta a szememet, azóta megértettem.

Namost. A napi munkánál - szerintem - nem a shell képességei a korlátozóak (bár hiányzik pl. az aix alatt megszokott trükk ("cd /backup/12/data/local/etc/bind9/zones" után a "cd 12 13"), amit valószínűleg meg lehetne tanítani a bash-nak is, de annyira nem érdekel. Részemről nem az szokott a gond lenni, hogy lassan gépelek, hanem az idő, mire kitalálom, hogy mit írjak be.

Ha pedig rendszeresen ismétlődő dologról van szó, akkor arra megírom a scripteket. Meg azokra a dolgokra is, amiket várhatóan kettőnél többször kell megcsinálni. Itt nem szoktam azon agyalni, hogy mindenképpen fusson mindenféle shellből, de ha nem muszáj, akkor nem írok bele shellspecifikus dolgokat - hacsak a sebesség miatt nem indokolt, de a shellscriptek esetében ez viszonylag ritka.

A szavazásra pedig úgy tudnék válaszolni, hogy amikor fel akartam tenni, akkor nem lehetett, ezért kénytelen voltam megtanulni a ksh-t, és amikor már végül is feltehettem volna, akkor meg már nem akartam (viszont rászoktam a vi módra, és sokat őszültem, amikor kaptunk red6-okat is, amin bash volt és az esc egész mást csinált :D), most meg nem dolgozom kereskedelmi unixon :D

( zsoltt | 2010. 06. 16., sze – 09:42 )

Ha jól értem ez ellentétes-e azzal amire kíváncsi vagy, ezért a tisztánlátás kedvéért megjegyzem: A Mac (power)userek 95%a igennel fog válaszolni (a Mac OS X kereskedelmi is, UNIX is). Ha ez nem tetszik, fogalmazd át a kérdést.

( tomi66 | 2010. 06. 16., sze – 09:50 )

Én az mc-t tettem fel annó SCO UNIX-ra :) A shell jó volt, amit szállítottak vele. :)

( lx | 2010. 06. 16., sze – 10:48 )

Eleinte mániákusan a bash dialektusában dolgoztam, és puffogtam, hogy külön köröket kell futni ahhoz, hogy fenn legyen AIX-on.
Aztán annyi Zahyt olvastam (komolyan), hogy szép lassan úgy kezdtem indítani a szkripteket, hogy !#/usr/bin/ksh vagy még inkább #!/usr/bin/sh.

Ami megmaradt, az az, hogy az 1. kiadott parancs majdnem minden esetben az mc -b.

( blackberry | 2010. 06. 17., cs – 09:18 )

Én AIX-on teljesen jól elvagyok ksh88-al. Valahogy még soha nem jutott eszembe, hogy bash-t kéne feltenni :)

Valoszinuleg nem tul gyakran talalkozol a '/usr/IBM/WebSphere/ProcServer/profiles/myCustomProfile1/' es hasonlo utvonalakkal ;-)

Az esetek 95%-aban en is elvagyok vele (pl sajat hobbigepeimen soha nem hasznalok bash-t), de az ilyen elbaszott telepiteseknel egyszeruen ketszer annyi ido csak a konyvtarstrukturan beluli navigacio, es sajnos tul sok a rendszer, hogy aliasokat vagy egyeb trukkoket erdemes legyen hasznalni.

Jo pelda pl egy 8-10 WebSphere JVM instance-t futtato host, ahol valamiert a logokat kell nezni.

Kicsit off: az NFC/NFD kettősség nem okoz problémát? Például létrehozol egy árvíztűrő tükörfúrógép nevű file-t, majd ls -l árvíztű után TAB-ot nyomsz: ki tudja egészíteni?

(Persze, persze, "ugyan ki hozna létre ilyen nevű file-okat", de ettől a költői kérdéstől nem esik messze az sem, hogy "ugyan ki tenne nagybetűket file-nevekbe".)

Mindenesetre ha a shell a tab completion kedvéért beépített NFC/NFD konverziót tartalmaz, akkor teljesen jogos elvárás, hogy case insensitive is tudjon lenni. Vagy izé.

Már csak azt áruld el, hogy miért nem használod a kurzormozgató billentyűket :-) Konkrétan ha jól rémlik, utoljára 3-s AIX-ben láttam, hogy azt nem lehetett felmap-pelni, de gondolom azért nálatok annál újabb verziók vannak.
$ENV file-ba (hagyományosan: ~/.kshrc) : 


set -o emacs
alias __A=^P
alias __B=^N
alias __C=^F
alias __D=^B

Két apróság:
- a Ctrl-izé helyén fizikailag kontrol-karaktert kell bevinni - azt, ami amúgy emacs-módban lenne a mozgató parancs
- bizonyos terminálok(emulátorok) esetén esetleg az __X aliasok helyett _OX (nagy-O, nem nulla), vagy _X aliasokat kell létrehozni. Persze ezek benne vannak a manualban, így nyilván ismered - csak azt nem tudom, miért nem használod. (Én személy szerint imádom a vi-t, de azért parancssorban mindenütt beállítom a fentieket, ha ott 10 percnél többet kell dolgoznom.)

Ja, és fájlnévkiegészítéshez: ESC * :-)

> Már csak azt áruld el, hogy miért nem használod a kurzormozgató billentyűket :-)

Ezt ki mondta? Hasznalom, de vi moddal + Esc hjklbw0$...-lel teljesen jol elvagyok az esetek tobbsegeben. A tobbseg a cegnel a vi-hoz szokott, ezert alapbol a rootnak az van beallitva. Igy a 'kisebb ellenallas' elv alapjan egyszerubb vi modban maradni.

Osszefoglalva:

- ceges root shell: ksh88 + vi mod, bonyolult utvonalak, hosszas lognezegetes, stb eseten bash.
- ceges sajat shell: nagyon ritkan hasznalom (kb 2 hoston dolgozom sajat userrel is), ksh88 + emacs mod, illetve most a bash_completion-nal valo kiserletezes miatt bash-t is hasznalok
- ceges technikai/app user shell: fejlesztok stb miatt alapbol bash
- home root/sajat shell: ksh88 + emacs mod

Utobbi esetben azonban jellemzoen max 3-4 dir melysegben cd-zek, a hasznalt parancsok meg tobbnyire a default AIX telepitesbol valok, amik rendszerint a PATH-ben vannak, es amiket ismerek, nem holmi elkefelt '/opt/ibm/edge/servers/bin/goInOp'...

Persze ez csak AIX-en tema, mindenhol mashol jo a default shell.

( uid_2716 | 2010. 06. 17., cs – 14:07 )

Interaktív munkára kizárólag bash (Solaris, Tru64). Ha nincs fenn helyből, megkérem a rendszergazdát, hogy tegye fel csomagból, vagy fordítok magamnak.

Ad-hoc script-eket, amelyek a munkámat könnyítik és amelyeket nincs is miért terjeszteni, minden további nélkül bash-ban írok.

Bármilyen terjesztésre ill. hordozhatónak szánt script-et kizárólag SUS szerinti shell-ben írok. Linkek: v2, v3, v4.

Az ilyen hordozható script-eket aztán GNU/Linux-on nem könnyű futtatni, mert a felhasználóknak fogalmuk sincs, hogyan tudnák SUS-kompatibilisre pofozni a rendszerüket. Debian-ra egy jó közelítés, ha az ember felteszi a dash-t (Debian Almquist Shell-t), és hozzá minimum a gtime-ot.

Azért jó ennek fényében ragaszkodni a SUS-hoz, mert a GNU/Linux csak egy rendszer a sok közül (már amennyire a GNU/Linux disztribúciókat illethetjük egyáltalán az "egy(etlen) rendszer" névvel). Hogy mekkora része van a tortából, az teljesen lényegtelen. Legalábbis számomra. Ha a tortaszelet nagysága érdekelne, akkor windows-ra programoznék, meg iPhone-ra.

Az, hogy a tömeg zöme egyetlen irányba tart, nem ad felmentést a hordozható program írása alól. Volt idő, hogy GNU/Linux-tól eltérő, tanúsított UNIX platformon dolgoztam; próbáltam lefordítani rá a sok linuxos szutykot a freshmeat-ről, amire szükségem lett volna. A sok szutyok azonban pont az volt: platformfüggő, GNU extension-öket ész nélkül használó, kényelemorientált szutyok. Ugyanaz a hozzáállás, mintha csak a legújabb DirectX-en futó játékot fejlesztene az ember, vagy csak a legújabb Windows-on futó segédprogramot. Megvan persze ezeknek a helye is, a létjogosultságuk megkérdőjelezhetetlen, csak nem az én világom, és általában nem a shell script "alkalmazások" (segédprogramok, telepítők stb.) világa.

Az említett hordozható script-ek egyébként tökéletesen futnak GNU/Linux disztrók alatt is, megfelelő környezeti beállítások és telepített csomagok mellett, csak a rendszerszállító (a disztribúció fejlesztői) sohasem veszik a fáradságot, hogy dokumentálják (vagy közvetlenül támogassák) a "SUS mód" bekapcsolását. Így a felhasználó magára marad, aztán panaszkodik.

( vl v | 2010. 06. 18., p – 17:51 )

Akkor "kereskedelmi unix vendor" oldalról nézve: a mi unixonkon ~11-12 éve van gyárban felrakott bash a default OS telepítésben.
A kollegák 90%-a ezt használja saját, belső gépeken, ha pedig nincs kifejezett ellentétes kérés az ügyféltől, akkor az esetek döntő többségében (ebben egyes kollegák konzervatívabbak) bash-ra állítjuk az eladott gépeken is a root shelljét telepítéskor.
Még nem találkoztam olyan programmal, aminek ezzel gondja lett volna.

Én személy szerint tcsh-t használok szinte minden privát accountomon, >15 éve. A tcsh root shellként való használata már húzósabb, mivel ugye nem sh-kompatibilis a scriptelése. Tipikus szívási pont: /etc/init.d script, amiben felül nincs hash-bang sor: így nem lehet a scriptet direktben futtatni inkompatibilis shellből.

> az esetek döntő többségében (ebben egyes kollegák konzervatívabbak) bash-ra állítjuk az eladott gépeken is a root shelljét telepítéskor.

Remélem statikusan linkelt bash-t tesztek oda, mert bizonyos rendszerhibáknál nagyot fogtok szerintem szopni. (*)

> Még nem találkoztam olyan programmal, aminek ezzel gondja lett volna.

Hát a kérdés az, hogy a meg nem nevezett kerjunikszban mi a default: Bourne-shell, vagy Korn-alapú POSIX-shell. Azért van különbség azok és a bash között. guglizd ki a .sig -emet, és mutasd meg azt a bash-verziót, amelyik képes lefuttatni.

Szerk:
(*)

Mondjuk ha én lennék a rendszergazda, menne is vissza a /bin/sh. (Speciel sose értettem a dolgot: az ember nem loginel root-ként, ha meg su/sudo, akkor azt a plusz exec bash-t mán be tudja gépelni.)

> az esetek döntő többségében (ebben egyes kollegák konzervatívabbak) bash-ra állítjuk az eladott gépeken is a root shelljét telepítéskor.

Remélem statikusan linkelt bash-t tesztek oda, mert bizonyos rendszerhibáknál nagyot fogtok szerintem szopni. (*)

Szerintem nem ;-)

Azon helyzetek száma, amikor a /sbin/sh, a /bin/ls meg a /bin/cp működik, de a /bin/bash nem, közelít a nullához - nyilván mesterségesen tudnék ilyen szituációt kreálni, de való életben ez nem életszerű.

Ha pedig nincs ls meg cp, akkor úgyis megette a fene az egészet, nem éri meg erőlködni -> boot cdrom vagy boot net.

> Még nem találkoztam olyan programmal, aminek ezzel gondja lett volna.

Hát a kérdés az, hogy a meg nem nevezett kerjunikszban mi a default: Bourne-shell, vagy Korn-alapú POSIX-shell. Azért van különbség azok és a bash között. guglizd ki a .sig -emet, és mutasd meg azt a bash-verziót, amelyik képes lefuttatni.

/sbin/sh, ami tudásban a ksh tudásának a tört részét sem éri el, valami 1.0-as bourne lesz az...
Nincs pl. PS1 escape-kezelés, ergó nem tudsz olyan promptot csinálni benne, ami megmondja, hogy melyik könyvtárban állsz. A command historyról ne is álmodjunk.

Speciel sose értettem a dolgot: az ember nem loginel root-ként, ha meg su/sudo, akkor azt a plusz exec bash-t mán be tudja gépelni.

Hát, ha _mindig_ beírod, akkor egyszerűbb, ha fixen ez jön be...
Mellesleg, ha ismernéd a bash /etc/profile, /etc/login kezelését, tudnád, hogy ez nehezen kezelhető így. Konkrétabban: oldd meg, hogy a /sbin/sh is emberi promptot írjon ki (pl. ne \u@\h:\w # legyen a prompt), de amikor beindítod a bash-t, abban is jó prompt legyen (legyen benne path). Nem lehetetlen, de küzdős a dolog. Ez persze a bash faszsága, hogy egy nem login shellben nem hajt végre semmilyen központi scriptet, az exec bash meg nem lesz login shell.

Mondjuk ha én lennék a rendszergazda, menne is vissza a /bin/sh.

Nem véletlenül írtam: ahol a rendszergazdának nincs ellenvetése.

> nyilván mesterségesen tudnék ilyen szituációt kreálni, de való életben ez nem életszerű.

Ezt elhiszem, hogy nem életszerű bár anno SCO-n éltem át hasonlót.

Az, hgy nincs "rendes" PS1, meg history, az ismerős, ez a standard Bourne-shell funkciógazdagsága, használtam elég sokáig olyat.

A mindig beírt exec-ről csak az a véleményem, hogy az ilyesmit jobb szeretem beírni kézzel akkor ha akarom. Nem mindig.

Bash-t meg láttam már, úgyhogy mit szólsz pl. a következőkhöz:

- a bash-nak van -l opciója (ellentétben a legtöbb shell-lel), így az exec bash helyett lehet "exec bash -l" és máris végrehajtja a /etc/profile-t is, nem csak a bashrc-t

- a "rendes" promptbeállítást pedig én így oldanám megy a /etc/profile -ban: 


if [ -n "$BASH_VERSION" ] # ezt normálisan csak a bash állítja be
then
 PS1=bash-prompt
else
 PS1=normal-sh-prompt
fi

természetesen lehet "id -u" -ra is tesztelni abban a /etc/profile-ban, és ezzel $ és # között váltani; és í. t. Nem olyan ördöngösség az, még csak nem is küzdős, csak ismerni kell a használt shellt.

> Azon helyzetek száma, amikor a /sbin/sh, a /bin/ls meg a /bin/cp működik, de a /bin/bash nem, közelít a nullához - nyilván mesterségesen tudnék ilyen szituációt kreálni, de való életben ez nem életszerű.

Pedig de. Akkor tértem át zsh-ra.

[ #FreedomFlotilla ] [ hupexpertize© ] [ hupdiploma ]

( GoRien | 2010. 06. 19., szo – 06:01 )

egyszerű a válasz. Nem.
===================================================
Ubuntu 8.04.4, AIX, Windows XP Home, Windows XP Pro