( Zahy | 2024. 06. 01., szo – 09:44 )

Azt érzem, hogy nem ment át amit mondani akarok,

Nem a a cél, hogy tessen ksh-scripteket (inkább: POSIX-shell nyelven)  írni. Nem azt mondom, hogy ne használjuk ki a bash specialitásait akkor, ha annak van értelme. Azt mondom, hogy ha van a bash-ban 2 (3 -4 - ...)  - egymással kompatibilis megoldás, akkor hosszú távon több értelme egy csepp odafigyeléssel azt a formáját használni, amit a világon sok más helyen meglevő eszközök is natívan megértenek, nem csak a bash. És a hangsúly azon van, hogy ha van kompatibilis forma, akkor azt használd (nem pedig azon, hogy ha van egy senki más által implementált egyedi dolog, azt ne használd, ha segít megoldani a feladatodat).

Pont erre volt példa a declare. Nyilván magamból indulok ki, de a typeset -i j és a declare -i j között nem látok érdemi különbséget Ránézésre mind a kettő homályos hogy mire is jó, de a második forma egy másik parancsértelmező (ksh) számára is ugyanúgy érthető, nem csak a bash számára - én ezért ezt preferálom, és ennek használatára buzdítok mindenkit. Ha pedig felhasználói szemmel nézem, akkor meg mind a kettőt kenterbe veri az integer j, mert ránézésre látszik, hogy mit takar. Mondjuk ennek meg az a nagy hátránya, hogy csak a ksh érti, de a bash (meg a yash) nem.

Egy lépéssel továbbmenve:

Fent emlegetett .sig -emben nem azért van typeset -i, mert ez hordozható, hanem mert be akartam mutatni a Korn-shell egyedi funkcióját - ott ugyanis lehet alapértelmezett számrendszert is beállítani a (z integer tipusú) változókra, és ezt kihasználva játszottam a számrendszerek közti konverzióval - 8-as és 40-es alapú számrendszereket használva.

Konklúzió: ha az a célom, hogy egy kódot *erőszakosan* hozzákössek egy környezethez, akkor ha integer j -t írok, akkor ettől ksh-hoz lesz kötve, ha meg declare -i j -t, akkor a bash-hoz. Ha pedig az a cél, hogy kevesebb legyen a portolási szopás, akkor azt, hogy typeset -i j.

Kérdés: egy Linux-only környezetben mit izgasson a portolhatóság? Mivel keveseknek van varázsgömbjük, ezért a következő - múltban egyszer vagy többször már megtörtént események alapján - nem kizárható dolgok miatt *nekem* ésszerűnek tűnik a portolást nem igénylő forma:

- olyan rendszer szintű váltás, mint volt a Debian bash-dash. Ha nincs bashizm, csak "POSIXizm", akkor 0 költsége van a váltásnak.

- a Linux-only környezetbe bekerül egy-két cél-BSD (BSD-alapú tűzfal, BSD-re épített NAS pl.), vagy épp egy dinoszaUNIX. Lehet, hogy telepíthető ugyan a bash, de nem biztos hogy célszerű - mondjuk egy tűzfal esetén inkább minimalizáljuk a fent levő szoftvereket, mint bővítsük a listát (csak a kényelem / megszokás lrdekében).

- megváltozó gondolkodás. Sok ember váltott már OS-t, Win - Linux - Win - Linux. Nem nagyon sokan,. de Linux - BSD váltás is történt, és milyen egyszerű is, az évek alatt - odafigyeléssel előállított vackaink vihetők, és semmit nem kell módosítani.

(Funfact: a shellshock nem működött ksh alatt, mert azt a baromságot amit a bash-fejlesztők kiagyaltak az exportált függvények *megvalósíthatósága* érdekében, azt ksh-ban egyszerűen nem implementálták. Holott akit érdekel, megfigyelheti, hogy a ksh93-ban rendszeresen jelennek meg olyan funkciók, amik nincsenek POSIX-ban, de bash-ban igen - és hasznosnak is tűnik.)