Kedvenc UNIX(-like) shell-em mindennapi használatra a

Címkék

ash
0% (0 szavazat)
bash
81% (331 szavazat)
busybox
1% (3 szavazat)
csh
0% (1 szavazat)
esh
0% (0 szavazat)
ksh
3% (12 szavazat)
rc
0% (0 szavazat)
sh
0% (2 szavazat)
tcsh
2% (8 szavazat)
zsh
6% (25 szavazat)
egyéb, leírom
2% (7 szavazat)
csak az eredmény érdekel
4% (18 szavazat)
Összes szavazat: 407

Hozzászólások

Nekem jó az, amit alapból feltesz a Debian, bármi is legyen az. Most épp bash+dash.

--

Háhh, busyboxra szavaztam, mert csak androidon használom naponta :)

Nehezítő tényezőként el lehetne várni, hogy csak olyanok válaszoljanak, akik legalább 3-félét kipróbáltak már, esetleg különbséget is tudnak tenni közöttük?

Ha arra gondolsz, gond eseten a Busybox jon be (es nagyon ...nem tul hasznalhato), mig ha az "sh" fut "bash" helyett, akkor par dolog nem/nem ugy mukodik, ahogy megszoktam, akkor igen, ismerek harmat.
Ha arra, hogy csh/ksh es hasonlo dolgokat probaltam-e , akkor nem

--
http://www.micros~1

mksh hogy maradhatott ki? (android default, btw)

--
NetBSD - Simplicity is prerequisite for reliability

Linuxon bash-t használok, bár van egy csomó minden, amit zsh-ban egyszerűbb megcsinálni. De az ilyan típusú problémákat Python-ban még egyszerűbb megoldani :-)

Windowson a PowerShell-t kedvelem, sok feladatra nagyon kényelmes.

ksh93-ban van float tipusú változó, valamint szögfüggvényig bezárólag elég sok minden. Részlet a man ksh93 -ból.

"Any of the following math library functions that are in the C math
library can be used within an arithmetic expression:

abs acos acosh asin asinh atan atan2 atanh cbrt ceil copysign cos cosh erf erfc exp exp2 expm1 fabs fpclassify fdim finite floor fma fmax fmin fmod hypot ilogb int isfinite sinf isnan isnormal issubnormal issubordered iszero j0 j1 jn lgamma log log10 log2 logb nearbyint nextafter nexttoward pow remainder rint round scanb signbit sin sinh sqrt tan tanh tgamma trunc y0 y1 yn."

Fenti $(( ... )) pedig pont egy aritmetikai kifejezés (amit egyébként pontosan ugyanebben a formában le lehet írni bash-ban is, bár ott a dokumentáció sokkal inkább hangsúlyozza a $[ .. ] formát).

A sajat gepemen, mindennapos hasznalatra a Fish ( http://fishshell.com/ ), amit hasznalok. Interaktiv shellnek nagyon okos, ugyes, attekintheto, szoval csudajo!
Szervereken viszont termeszetesen a bash a nyero, mert azokat nem csak en hasznalom, masreszt 14-15 ev bash szkripteles utan, nem hasznalok mas shellt.

Kedvenc? Az AIX-on rászoktam a ksh-ra, az lenne a kedvenc, de linuxon kb. csak bash-t használok, de csak azért, mert épp az volt a default.

csh-tcsh párost nem lett volna érdemes összevonni?

ipython shell a kedvencem, de persze basht használok a legtöbb helyen.

Alapvetően a POSIX shell, de Mac OS-en most a zsh-val ismerkedem. A bashsal úgy vagyok, mint húsz éve a Norton Commanderrel. Csak szánakozom azokon, akik nem bírnak nélküle semmit sem csinálni. (hányszor hallottam a siránkozást, hogy HP-UX-on miért nincs bash?)

Ave, Saabi.

Te is érdekes vagy ám! :)

Közben jössz itt azzal, hogy te már nem szeretsz bűvészkedni, neked az OS X, meg az iPhone adja, mert az aztán a kényelmes.

Nem feltétlen azért használnak az emberek bash-t mondjuk csh helyett, mert a másikat nem tudnák, hanem azért, mert a bash kényelmes.

Ennek okán baszták ki a Solaris-ból is a régi shell-t és kapott bash-t, illetve gondolom, hogy ezért lett az OS X-ben is az alapértelmezett a bash.

--
trey @ gépház

:-D Lehet, hogy a kényelemre törekszem, de arra ügyelek, hogy eközben ne kényelmesedjek el túlzottan. Valóban a Mac OS X kényelmesebb nekem bármi másnál, de azért nem zuhanok össze akkor sem, ha egy szál terminál áll rendelkezésre. Még akkor se, ha nincsenek is rajta kurzormozgató gombok. :-)

Ave, Saabi.

> Nem feltétlen azért használnak az emberek bash-t mondjuk csh helyett, mert a másikat nem tudnák, hanem azért, mert a bash kényelmes.

A bash-t hasznalo emberek 99%-a a kenyelembol a TAB-hasznalatot es a kurzormozgato nyilak mukodeset erzi. Egyeb kenyelmi funkcioirol nem is tud a bash-nak.

Szerintem azért esett a választás, mert kényelmesebb, könnyebben kezelhetőbb, mint a csh/tcsh.
A kényelmesség, könnyebben kezelhetőség nem azt jelenti (most), hogy tab-ra van-e kiegészítés, működnek-e a felfele-lefele nyilak, stb.
Amikre gondolok: egy for(each)-ciklust (trükközés nélkül) nem lehet írni egy sorba (első sor a for-rész, utána enter, majd a for ciklus blokkja, majd enter, és végül end - a pontosvesszőzés nem megy ebben az esetben). Ez persze leginkább akkor szívás, ha egy korábban lefuttatott ciklust még egyszer le akarsz futtatni, és a history-ból csak külön tudod kiszedni a for-részt, és egyesével kell a ciklusmag sorait is visszahívni.
A dollárjel használata nemigen triviális (pl. regexpekben a sorvége jel esetén is változónév kezdeteként akarja értelmezni a tcsh).
Nincsenek függvények, csak alias-ok.

Stb., ld. még http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

Fentiekkel egyetertek, kiveve a dollarjelet. Mind a *sh, mind a *csh (tudom, ez utobbi reszhalmaza az elobbinek) megprobalja ertelmezni, ha nem takarod.

> grep gin$ /etc/passwd
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5:System &:/:/usr/sbin/nologin

Fenti egy FreeBSD-s csh (ami amugy eleg regota tcsh) kimenet reszlete, rohadtul nem nyafog a csh se.

Ez nem a C-shell hibája, hanem a tied. :-)

Ha aposztrófok közé teszel valamit, akkor sem a csh, sem a sh/ksh/bash nem kezd el semmiféle helyettesítést. Ellenben idézőjelek között például a változóhelyettesítést midegyik megpróbálja. Az már egyedi pech, hogy a sh-szerűekben a $,-re a shell vállat von, és ott hagyja, míg a csh hibát ad (és ha jól tudom ezt ki se lehet kapcsolni).

Szóval használd aposztrófot amikor csak lehet, idézőjelet pedig amikor a helyettesítésre szükséged van.

Anno a bash azert terjedt el, mert klasszikus SH-szintaxist nyujtott, *es* megvoltak benne a csh kenyelmi funkcioi. Pont. Es gyarilag be is voltak kapcsolva - nem ugy, mint pl. a Korn-shellben, ami mar akkor is tudta ezeket, es mar akkor (1988-ban, nem veletlenul hivjak ksh88-nak pl. a kereskedelmi Unixok Korn-shelljet) tobbet tudott, mint a bash kb 5 evvel ezelott. (A ksh93 pedig bizonyos dolgokban a mai napig tobbet tud.) Csak eppen a Linux terhoditasanak kezdeten eleg furmanyos licence volt, igy kevesen adtak, valamiert a pdksh-t meg nem ismertek. Kb ennyi. Itt sem a tudas, hanem a jokor volt jo helyen effektus jatszik szerepet. Ha valamelyik disztributor rendesen bekonfiguralna egy Korn-shellt (ahogy megteszik ezt a KDE-vel, Gnome-mal, Xfce4-gyel), akkor a tobbsegnek pont ugyanugy jo lenne az is.
Persze szerintem.

Pedig csak a programozo volt trehany :-) Egyebkent erdemes odafigyelni hogy az ember tenyleg hordozhato kodot irjon shell-scriptkent, es nem is olyan eszementul bonyolult. Pl. vagy azt irom, hogy function ize { ... } , vagy azt, hogy ize() { ... }, de nem function ize() { ... }. Nem source fnev, hanem heleyette . fnev. Nem $[ aritmetikai kifejezes ], hanem $(( aritmetikai kifejezes )). Nem declare, hanem typeset. Es igy tovabb, meg par hasonlo.

Engem érdekelne, hogy aki nem azért választotta az adott shellt, mert az a default, az milyen megfontolásból (pl. kényelmi funkciók amik máshol nincsenek). Nálam leginkább azért bash, mert sok script érhető el hozzá, amik más shellekben vagy futnak vagy nem és más shellekre vagy portolták vagy nem. Ez pont egy rossz példa lesz, de pl. ez nálam musthave.

Ezt azért elég sok esetben meg lehet csinálni.

De hogy a kérdésedre válaszoljak: tcsh (bár FreeBSD-ben az az alap). Azért, mert az sh és a tcsh az alaptelepítés része (tehát legfeljebb csak a rendszer frissülésekor frissülnek, nem pedig csomagok frissítésekor). Aztán azért lett tcsh, mert az más :) Megbánni nem bántam meg, nem rosszabb shellnek, mint bármelyik másik, amiket használtam. Szkriptelésre már határeset, a függvények hiánya elég nagy érvágás.

Valamikor réges-régen megtettem azt az erőfeszítést, hogy pár napig megpróbáltam két másik shellt (az alapértelmezetten kívül). Azt ellensúlyozandó, hogy (nyilván) nehezebben boldogultam velük, mert nem működtek a megszokott dolgok, nem láttam olyan jelentős előnyt, amiért az én felhasználási módomnál érdemes lett volna váltani. Ami egy kicsit is komplexebb mint egy-két for ciklus, azt már úgyis valami tisztességes scriptnyelven írtam (awk-perl-python átmenet az idők változását követve).
Hasonló kísérletben "végeztem el" a vimtutort, ami bizonyult annyival jobbnak az addig használt aztsemtudomminél, hogy megmaradt.