Bash 4.0

Szerszám

Chet Ramey bejelentette a Bash (Bourne-Again Shell) negyedik nagyobb kiadását, amely javítja a 3-as ágból megmaradt komolyabb bugokat és emellett számos jelentős újdonságot, új szolgáltatást is hoz:

  • associative arrays
  • improvements to the programmable completion functionality
  • case-modifying word expansions
  • co-processes
  • support for the `**' special glob pattern
  • additions to the shell syntax and redirections
  • shell has been changed to be more rigorous about parsing commands inside command substitutions
  • fixing one piece of Posix non-compliance

A bejelentés elolvasható itt.

( budee | 2009. 02. 24., k – 18:25 )

Na vegre:
cc. There is a new &>> redirection operator, which appends the standard output
and standard error to the named file.

dd. The parser now understands `|&' as a synonym for `2>&1 |', which redirects
the standard error for a command through a pipe.

Lejjebb mar morogtam, de ez csak most jutott el az agyamig: |&
Ezek szerint nemcsak hogy mas szintaxist valasztottak a ko-processz kezeleshez, mint a mar kb 20 eve meglevo korn-shell-ben, de raadasul az ott hasznalt szintaxist teljesen masra kezdik el hasznalni. Eljenek azok, akik nem latnak tovabb az orruknal. Mi a hoher koteleert nem lehet kompatibilis lenni azokkal a dolgokkal, amik mashol (egy ugyanilyen funkcioju, altaluk mar ismert programban) mar letezik.

Gy.k:

akarmi |&

ez az "akarmi" parancs ko-processz-kenti inditas ksh-beli modja.

( bolond | 2009. 02. 24., k – 19:07 )

`'

Kérlek, ne másoljatok ilyeneket!

:)

Hat mivel a yes vegtelen sokaig mond y-t, en mondjuk egy "Arg list too long"-ot varnek, vagy plane azt, hogy meg idaig se jut el, hanem szepen teleirja azt a fajlrendszert, ahol a backtick kozotti parancs kimenetet orzi meg. (Vagy ha azt memoriaban tarolja, akkor meg valami memory full jellegu eredmenyt - de ezt kb shell-tol teljesen fuggetlen modon.

Ehh. Debian unstable. Kiadtam a parancsot, amitöl belassult a gép anyira, hogy nyomtam egy resetet. Azóta DISK BOOT FAILURE, INSERT SYSTEM DISC AND PRESS ENTER :S:S:S
Kár hogy nem olvastam tovább hogy mit csinál, most jöhet a sys rescue, így jár aki rtfm...

Érdekes, megjavult magátol:D Noh, akkor mégse olyan veszélye a tehénke:D, lehet maxtor vinyó haldoklik:s

Ezt most ugy gondolod, hogy epitsek bele, hogy ha `yes` van, akkor az szar ugy es el se kezdje? Mar csak az a kerdes, hogy ha holnap jon egy hasonlo parancs xyz neven, akkor annak a kezeleset is be kene epiteni? Na ne ma! Mint tudjuk a *X rendszerekben az a jo, hogy nem neznek gyereknek akinek fogni kell a kezet, hanem igenis hagynak labonloni magadat. Aki parancssort hasznal, az tanuljon meg alapveto dolgokat. Ez pl. ilyen.

(A hasonlo "inteligencia" mar a gnu-tar /dev/null kezelese kapcsan is elegge megosztotta a kozvelemenyt, szoval nem kene.)

Már miért kérdezném meg? Tudom mi az, és azt is tudom mikor kell egyiket vagy másikat használni.

Mindazonáltal fenntartom a bash ne akarjon okosabb lenni a kelleténél - abban egyébként egyetértek, hogy pl. ez egy megfontolandó megoldás lehet, kérdés azért van:
- az elejét tartsa meg, vagy a végét (noha nyilván egyiket se kell, hisz úgyis Arg list too long -ot fog visszadobni)
- mit csináljon a processzel? Mert mondjuk a kilövés nem ildomos tőle, ha meg hagyja futni, akkor ott vagyunk ahol a part szakad. Sose derül ki, hogy mennyire okos a bash :-)
- amúgy pedig véleményem szerint az ilyesmit ulimittel kell korlátozni, nem shell-lel. Mert az általánosabb (tehát több helyen működő) megoldás.

- Az elejet tartsa meg, igen igy is too long lesz a vege
- Tartsa meg processt alapertelmezes szerint, de atallithato dolog legyen a viselkedes ilyen esetben (kill,warn,none)
- ulimit -et valoban erdemes hasznalni mindig. De nem baj, ha egy shell vedekezik.

Ha megtartja a processt felvetodik, hogy mit csinaljon az onnan kapott szemettel:
- close
- read es megy a levesbe (ilyenkor latszik kompatibilisnek a regi dolgokkal)
- nem readel

szerk:
Ja es van ilyen is a=`print_3_magabyte`, amit sajnos engedni kell. A beepitett parancsok tudnak csak ekkora valtozoval dolgozni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Fasza. Mint emlitik is, ezt a Korn-shell tudja mar a ksh88-as verzioja ota (tehat mondjuk 15-20 eve biztosan). Vegre bevezettek. De nehogy mar az ott megismert (neadjisten hasznalt) szintaxist kelljen mar ra bevezetni, meg a vegen lehetne irni kompatibilis shell-szkripteket. Grrr. Mar megint az agyatlansag.

És el is olvastad amit írtam? Nem az a bajom, hogy tud olyat, amit a Korn-shell nem. Hanem az, hogy beépítenek
- egy olyan funkciót, amit az tud, de tök más szintaxissal (miközben tudtommal nincs másik, elterjedt, *X rendszeren futó shell, amely tudna co-process-t - de a ksh ilyen)
- és beépítenek erre egy olyan szintaxist, amit a másik már sok-sok-sok éve használ - másra.

Szerintem az se normális, hogy 'declare'-nek szereti hívni a 'typeset' -et, de mivel mind a két formát elfogadja, hát üsse kő. Én nem szeretem, hogy:

function f {
akarmi
}

és ezen kívül

f() {
akarmi
}

formában is lehet írni - de ezt David Korn kefélte el, mivel ő döntött így anno. Ellenben azt végképp hülyeségnek tartom, hogy a "kényelem" kedvéért bash alatt ugyanezt elfogadja így is (néhány esetben meg eleve így tanítják)

function f() {
akarmi
}

De hogy tudatosan ellene dolgozik a másiknak, az marhaság, csőlátás. Főleg, mert a keresztbe tevésen kívül más értelme nincs. Ettől - mint mondtam - csak még nehezebb lesz multiplatform shell-szkriptet írni. Holott ez egy fontos cél. (Mintha Debian kapcsán olvastam volna gyönyörű anyázásokat, amikor átálltak az alapértelmezett bash-ról a dash-ra - merthogy van kismillió progi, amelyik
#!/bin/sh
sorral indul, de bash és nem sh-specifikus dolgokat használ.)

Nem értem igazán, mi fáj.

Ha platformfüggetlen shell szkripteket akarsz írni, akkor az a célszerű, ha nem használsz nemsztenderd fícsöröket egyáltalán, tehát koprocesszeket sem.

Az általad felvetett probléma akkor lenne valós, ha arra lenne szüksége valakinek, hogy pont bash-sel és ksh-val menjen a szkriptje. Én elhiszem, hogy létezik ilyen (esetleg h. pont te jársz ebben a cipőben), de azért ez eléggé marginális esetnek tűnik ahhoz, hogy megértsem a bash fejlesztőit, amiért a saját esztétikájuk szerint választottak szintakszist, és nem a ksh-val való egyezés volt a fő szempontjuk.

Ha valaki elkefélt itt valamit, az az, hogy a POSIX/SUSv3 sh specifikáció elég alap, ezért egy feature gazdag shell implementációt kénytelen extra-sztenderd dolgokkal telerakni a fejlesztője. (A Scheme folkok azok még, akik pont ugyanezen a vonalon szívnak...)

> Nem értem igazán, mi fáj.

Akkor olvasd el még egyszer az utolsó bekezdést. Ennél érthetőbben nem tudom írni. Egy új ficsorhoz használjon új szintaxist. De egy meglevőhöz ne, ott akár még alkalmazkodhat is, nem fáj senkinek, még neki se. Speciel amikor csontra *ugyanezt* elmondja valaki Microsoft és Windows kapcsán, hogy nagy ívben szarik/nak a fejlesztők a meglevő eszközökkel/rendszerekkel való kompatibilitásra, no azt mindenki érti. Amikor ezt egy "Linux"-fejlesztőre mondom, az meg nem érthető??? (Nem válasz - csak maszatolás -, hogy a bash nem "Linux"-eszköz.)

jav: most esett le, hogy asszociatív tömbök is vannak új ficsorként. Tekintve, hogy már a normál (számmal indexelt) tömböknél se használták ki a ksh-kompatibilitási lehetőséget, nyilván itt is arra kell számítani, hogy ezt is másként csinálták meg, mint a ksh93-ban, amiben - mint a neve is mutatja, immár 16 éve létezik ez a funkció.

Miert pont korn shellt ? Miert nem mondjuk zsh -t kene kovetni ? Miota lett kovetendo standard a ksh legujabb valtozata?
Ki mondta, hogy az atjarhatosag cel ? Ha megis megegyzne ez a szintaxis akkor kompatibilis lenne a ket shell ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Senki nem mondta, hogy kovetendo standard. Es mint latszik, le se szarjak az ilyesmit. Csak sajnalkozom azon, hogy ennyire szuklatokoruek a fejlesztoi. (Mikozben tudnak rola, h mi van a ksh-ban, ezt a co-processes fent linkelt oldal is bizonyitja.)
Amugy mutass kereskedelmi rendszert, ahol van alapbol zsh. Ellenben: AIX, HP-UX, Solaris, IRIX, Tru64 - no ezek mindegyike alapbol rendelkezik ksh-val (igaz, a tobbseguk ksh neven csak ksh88-cal es nem ksh93-mal, de ahol van Motif - marpedig a tobbsegen van - ott van dtksh, ami viszont ksh93 - szoval van az uj verzio is.) Mivel FOSS szoftver, ksh93 meg Linuxra es *BSD-re is van, igaz, nem hiszem, hogy sok (vagy akar 1) disztro telepitene alapbol. Ha pedig szabad ksh88-verziora van szukseg, van pdksh, az egy eleg jo kompromisszum.

> Ki mondta, hogy az atjarhatosag cel ?

Ezt most ugye nem kerdezed komolyan? Lathatoan nem az, es en lathatoan azon faradozok, hogy a sok szuklatokorunek megprobalom elmagyarazni, hogy ez *baj*. Ha egyszer mindenki/sokan tapsikol attol, hogy van windowsos portja a GTK-nak/Qt-nek/anyamkinjanak - amelyek sok esetben kepesek megkonnyiteni egy multiplatform fejlesztest; ha pozitivumnak lehet tekinteni, hogy pl. Java, Perl, Python segitsegevel konnyebb multiplatform alkalmazast irni, akkor ugyanezt mi a francert nem lehet belatni a *X rendszerek egyik legalapvetobb eszkozerol, a shell-rol? En eleg sok shell-scripttel talalkozom, es elegge katasztrofa, mennyire nem tudjak meg a meglevo eszkozoket se hasznalni, de ezt pluszban neheziteni az ilyen tudatosan elkeszitett inkompatibilitassal ... Azt kene eszrevenni, hogy lehet, hogy a Linux minden egyeb *X rendszert lemos, de az is lehet, hogy jo darabig nem - no akkor pedig jol johet egy hordozhato tudas.

Nem ertettel meg valamit:
Jelenleg nem csak a Bash es a KSH nem kompatibilis egymassal, hanem pl. a ZSH es a KSH es a Bash meg a TCSH sem kompatibilis. Oke, legyen egy meglevo funkcio implementalasa. Szerinted milyen alapon kellene kivalasztani a szintaxist? Ha KSH kompatibilis lesz, akkor a ZSH userek fognak anyazni, ha TCSH kompatibilis lesz, akkor meg a KSH userek. Nem tudsz jot tenni senkinek sem.

Mas dolog, amikor van egy jol speciifkalt szabvany, es azt valositjak meg kulonbozo vendorok elteroen, es megint mas az, amikor van egy funkcio, es azt implementaljak sokan sokfelekeppen. Mivel mindegyik shell minden oprendszerre elerheto, igy szerintem nem tud gond lenni, ha extraspecialis dolgokat akarsz megvalositani.

Kulonben meg amennyire tudom, a co-process kezeles a legkisebb, amiben a bash meg a KSH elter egymastol. Innentol kezdve valahogy az alma narancsositasara kezd hajazni a vita.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A TCSH nem er, leven az eleve nem SH, hanem CSH szintaxist hasznal (pl:
"a=5" vs "set a=5" "export a" vs "setenv a 5" , for vs foreach, es i. t. lehet ragozni). A ZSH mar jobb, kar, hogy noha a doksija szerint lehet pl. KSH-kompatibilis modba kapcsolni, amikor en utoljara teszteltem, a .sig-emmel nem tudott mit kezdeni.

A bash vs ksh kapcsan pedig: 99%-ban le lehet irni a dolgokat bash-ban ksh-kompatibilis modon *is*, csak epp tudni kene, hogy miert pont azt a format javasolt hasznalni. Maris kozelebb lennenk egy lepessel a hordozhatosaghoz.

zsh@OSX
Ha alapbol nem is tartalmazzak a bash-t a felhasznalok jelentos resze ragaszkodik hozza.
Altalban bash telpitese 0.01% szabad hely vesztes mellekhatassal jar.
Minden shellen mukodo kod irasanak koltsege ettol magasabb.
Itt volna az ideje belatni, hogy defacto standard shell a bash lett, ezt valasztottak tobben es semmilyen trend nem latszik mas iranyba.

Hat bash -nak is van windowsos portja. De windowson '\' jelekkel mar alapbol sok a szivas ami eszkoz fuggetlenul jelentkezik.
GTK is csak olyan feltetlek mellett hordozhato, ha felteszed a masik gepre is.

C-nek leszarmazottja D es majdan C++0x is. Te elvarod, hogy a D kod leforduljon majd C++0x -el vagy forditva ?
Kulonbozo shell script nyelveket hasonloan kulon nyelvnek kell tekinteni.

Ha hordozhatonak tekintheto scripteket akkarsz irni akkor nem a shell-script a te baratod, sokkal inkabb a perl script.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

OSX: meghajlok. Van ilyen kereskedelmi rendszer.

> Ha alapbol nem is tartalmazzak a bash-t a felhasznalok jelentos resze ragaszkodik hozza.

A felhasznalok jelentos reszenek fingja nincs arrol, hogy mit tud a tobbi elerheto shell, csak epp a legtobb Linux-disztro azt adja, tehat az a jo es ahhoz ragaszkodik :-) Es ha megkapja ugyanazt (jobb esetben ugyanugy, rosszabb esetben majdnem ugyanugy), akkor mar nem is ragaszkodik hozza. (Lasd az itteni orok vita: kivalthato-e az MSO az OOo-val.) A felhasznalok jelentos resze a bash olyan funkcioihoz ragaszkodik, amit a ksh is tud. Van amit ugyanugy tud: pl. kurzorle/fel (kulonbseg, ksh-ban be kell kapcsolni, mig bash-ban be van kapcsolva -> ha en kikapcsolom neki bash-ban, nem tudja miert nem megy); van olyan amit hasonloan tud: fajlnevkiegeszites/listazas: TAB vs ESC-ESC. Es valoban van olyan, amit nem tud, pl. ugyanez a kiegeszites csak epp parancsokra - ezt a ksh nem tudja. tehat a felhasznalok jelentos tobbsege aki ehhez ragaszkodik, annak a ksh nem jo. De aki max a kurzornyilakat hasznalja (sztem ez a tobbseg), annak tok mindegy, ha a masik alatt is mukodik.

En ellenben nem annyira az interaktiv, mint a script oldalarol kozelitettem meg a problemat folyamatosan, ott pedig (mint egyel fentebb irtam) bash-ban majdnem mindent lehet ksh-kompatibilis modon is csinalni, kb 85-90% az egyezes. De most jott egy (ket, harom) nagy lepes, hogy ettol meg tavolabb keruljunk. No ezt fajlalom.

A kompatibilis perl-script nem rossz, csak eppen nem termeszetes - leven terminalban a felhasznalok 99,999(sok9) %-a nem perlsh -t hasznal, hanem valamilyen egyeb (SH-, vagy CSH-szintaxisu) parancsertelmezovel dolgozik. Azaz napi (interaktiv) munkara hasznalja a (mondjuk) bash-t, de amikor ugyanezt a feladatot mar nem 1x/2x akarja interaktivan futtatni hanem script-bol, akkor valtson nyelvet? Nem logikus, nem kenyelmes, nem termeszetes. Marpedig ha valamit meg lehet es meg is tud(ott) oldani grep|sed|awk|find formaban, akkor nem fogja ujra kitalalni, hogy ezt perl-ben hogy irna meg, hanem history > fajl, vi fajl (nano fajl, mcedit fajl, stb) kigyomlalja a felesleget, jobb esetben ele irja hogy she-bang-/bin/bash (rosszabb esetben /bin/sh) es keszen is van.

jav:
> GTK is csak olyan feltetlek mellett hordozhato, ha felteszed a masik gepre is.

No es, most mi a kulonbseg a kozott, hogy a Vizsual Baszik rantajmot igenyli/telepiti a progi vagy a gtk.dll-t?

jav2:
olvasgatom a bejelentest figyelmesebben is, es sirni tamad kedvem:

NEWS:
c. There is a new variable, $BASHPID, which always returns the process id of
the current shell.

Es az eredetileg meglevo $$ ugyan mi a francert nem jo? (hint, compatibility)

h. If creation of a child process fails due to insufficient resources, bash
will try again several times before reporting failure.

Hm, elso ranezesre ez pl. meg problemasabba teheti azt az insufficient reszorszot. (hint: proc table is full)

k. ... When the read builtin times out,
it returns an exit status greater than 128.

Bravo, ellentmondas azzal az ezer eve letezo szaballyal, hogy:

if (exitstatus > 128)
then (exitstatus - 128) azonosan egyenlo a programot kigyilkolo szignal szamaval

dd. The parser now understands `|&' as a synonym for `2>&1 |', which redirects
the standard error for a command through a pipe.

Ebben az a szep, hogy ez speciel a teljesen mas szintaxist hasznalo C-shellbol jott (mig ugye a bash definiten: Bourne-Again-shell)

Es. i. t.

Script oldalrol megkozelitve semmilyen shellnek sincs eselye perl -el szemben, ha felteszuk, hogy az iro mindkettot ismeri.
A perl fegyvernek minosul. Csoda, hogy nem kell -ra engedely :)

Ertem mit fajlalsz. De nekem ugy tunik, hogy olyan igenyeid vannak nehany eszkozzel szemben amit soha nem fognak kiellegiteni es soha nem is tettek.

A felhasznalo nem tol if-eket es case -eket csak ugy parancssorba, shell scriptben ez fura lesz neki elsore, es masodjara is.
`` -nem lesz tul ismeretlen szamara igy ez sem lesz fura: print `ls -l`
perl -e ' print `ls -l` '
perl szintaxisa eleg C szeru sok helyen, nem nehez elmagyarazni hova kell mondjuk ';' .

GTK:
Baszik runtime kevesebb platformra elerheto. Ha portolhato kodot akarsz irni nem hasznalod.
Ha hordozhato shell kodot akarsz irni adod hozza a shellt is :) , De meg ez sem garancia, mivel shell scriptek gyakran kulso dolgok megletere es viselkedesukre epitenek.
Vagy hasznalsz valami olyat ami szinten sok platformon elerheto, ugyan azt szintaxist eszi mindegyiken, kevesbe van rautalva kulso dolgokra.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.