Szoktad-e használni kedvenc unix/linux shelled programok írására?

Közösségi kerekasztal

Szavazásként akartam beküldeni, de azt hiszem, úgy még kevesebb értelme lenne.
Mióta linuxokkal, unixokkal kezdetem foglalkozni, a shellt mindig csak arra használtam, hogy programokat indítsak belőle, programozni max. olyan szinten, mint windows-on a .bat fájlok készítése.
Tudom, hogy léteznek különböző C-shell klónok, amiket kifejezetten szkriptelésre találtak ki, meg azt is, hogy pl. a bash rendelkezik rengeteg "rejtett" érdekességgel, de sohasem jutott eszembe, hogy pár soros ciklusokon és exit code ellenőrzésen túl másra is használjam. Ilyen feladványokra inkább awk, perl, újabban python szkripteket gyártok, a bash helyett meg szinte bármilyen Bourne-shell jellegű, primitív shell is megfelel (Bourne-t azért említem, mert a C, tcsh valahogy sohasem álltak kézre)
Ti hogy vagytok ezzel?
Láttam, hogy vannak, legalábbis voltak páran itt a hupon, akik komolyabban elmélyültek benne. Mostanság mi a "divat" e téren?

( banyek | 2018. 02. 21., sze – 16:37 )

Igazabol kerdes, hogy mit akar az ember megoldani.
Nalam altalaban az a palya, hogy ha olyan dologgal talalom magam szemben, ami siman, clibol kulonosebb buveszkedes soran megoldhato, akkor mindig, minden korulmeny kozott bash szkriptet irok ra.
Ha olyan dolgom van, ami ennel egy fokkal komplexebb (jellemzoen tarolok valami allapotot, vagy adatbazisbol kell valami, ilyesmi) akkor mostanaban pythonban irom meg (regebben perlben)
Ha meg valami olyan dolog jon szembe, amire kell valami hatterben futo demont csinalni, vagy kenyelmetlen a sok python libet elvinni, akkor go-ban irok.

Nem sikerült pontosan megfogalmaznom. Arra gondoltam, hogy olyan programozási feladatokra, amiket meg lehetne oldani shellből, mennyire hajlamosak az emberek mégis más eszközt használni?

Ha belegondolsz, hogy pl. a bash képes asszociatív tömböket kezelni, mindenféle mintaillesztésekre alkalmazható, van benne lehetőség fájlok soronkénti olvasására, feldolgozására stb.
Ilyen eszközöket igénylő feladatoknál automatikusan szkriptnyelvekhez nyúlok, holott könnyen lehet, hogy feleslegesen.

Php-ben írok szinte mindent script-et, mert abban dolgozom, és azt ismerem. Biztos van amit lehetne bash-el is, pl. tömbök, de eszembe se jut. Fájl listázást és azon végrehajtást is egyszerűbben oldom meg php-ben, és univerzálisabban. Bash-ben nem tudom lehet-e lib-eket kezelni, alapok alapjáig jutottam csak.

Jelenleg egy végtelenített while ami fut a gépemen, és pure bash, a többi mind .php. Ha viszont nem tudnék most php-zni, akkor...is a php-t vagy pythont javasolnám inkább, mert korlátosnak látom a shell script-eket, de ez inkább vélemény, mint konkrét hiba alapján állítás.

Egy dologgal tudnátok megfogni: erőforrásigény oldalról a .php pazarlás lehet némelyik feladatra, de annyira nem zavart ez még, hogy meg is nézzem, mennyire igaz ez.

Hát, szerintem érezni, hogy meddig hatékony, és jó valamit megírni shellben, és mikortól jár jobban az ember, ha valami mást használ rá.
Nem tudnám megmondani.
Vannak dolgok, amiket szép, és hatékony megfogalmazni shellszkriptben, ami csak pár sor ott, arra felesleges osszetettebb megoldást keresni.
Aztán vannak olyan dolgok, is, amiket egyszerűen kényelmetlen shellszkriptben csinálni, mert egy idő után a kód kezd átláthatatlan lenni.
Azt hiszem válik el, hogy mi végzi el a főfeladatát a programnak.
Ha van olyan komplex program, ami adott körülmények között kell nekem (pár példa: rsync, xtrabackup, pt-archiver, mysqlbinlog) amivel valamit valahol csinálni akarok, akkor azt a programot körbeszkriptelem, és beillesztem a rendszerembe.
Pár példa:
- A Jenkins job, ami elintézte a MySQL szerverek backupját, xtrabackupot használ, de a felparaméterezéséhez, mittomén mihez, eldönteni, hogy futhat-e, stb. shellszkriptet használtam.)
- Csinálni egy master failovert, amihez kicsit bűvészkedni kellett MySQLben, és rugdosni egy HAProxyit szintúgy
- Rsynccel átmásolni 2TB képet két külön gépre, más struktúrában: perl, mert sokkal kényelmesebb, és rövidebben kifejezhető regex-szel a honnan-hova
- AWS alatt aurora szervert rugdosni nyílván pythont fogok használni, mert a boto3 sokkal kényelmesebben (tömörebben) használható mint az aws cli
stb.

Szóval nem tudom megfogalmazni. Nekem az a tapasztalatom, hogy egyszerű dolgokat sokkal kevesebb sorban, sokkal áttekinthetőbben meg lehet írni shellszkriptben, mint más, általam használt nyelvekben, de amikor a dolog komplexebbé kezd válni, akkor egy idő után megfordul ez, és sokkal nehezebb kifejezni magad bashben vagy sh-ban, mint pythonban, vagy más nyelven.
Van egy olyan mondás, hogy akinek csak kalapácsa van, az mindent szögnek néz. :)

Mi relative sokat programozunk bashban. Sokszor azert mert az a legalkalmasabb, sokszor meg csak azert, mert az kb mindenhol van. Nekem az a tapasztalatom, hogy kevesen ertenek annyira a bashhoz, hogy production ready, jol tesztelheto kodot irjanak benne (aka konnyu elrontani, mert semmi sem ugy mukodik mint mashol, nem mindegy egy space, vagy egy idezojel, mer tmondjuk a cat/for maris mashogy mukodik). Sok tekintetben egyaltalan nem hasonlit a tobbi scriptnyelvre, es nem egyszeru raallni, szerintem jobban beleszol az implementacio apro reszleteibe, mint mas nyelvek. Meg aztan rogton a dependencia kezelessel talalod magd szembe. Mi pl raszoktunk, hogy minden dependenciat leszedunk azt a konkret verziot, amivel irtuk/teszteltuk. Szerintem ketfele dolgot jo bahsben fejleszteni, apro scripteket, tipikusan valami automatizalashoz, vagy nagyobb projektet, ahol megvan oldva, hogy az minden gepen ugyanugy fusson.

-
Kiterjesztések írása Go nyelvi környezetben

( sigellef | 2018. 02. 21., sze – 19:28 )

Ha egy feladatot meg lehet oldani parancssori programok futtatásával, paraméterezésével, be/ki meneteik feldolgozásával, akkor a shell-script a nyerő.
Ha nem, akkor választok valami mást, amit a feladat megoldásához jobban tudok használni.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Használtál valaha tömböt shell-ben?
Vagy az új kedvencem: mintaillesztést?
:)

Nézegetem a manualt és van egy olyanom, hogy amit anno gawk segítségével csináltam meg, azt - igaz, egy elég rosszul olvasható kóddal - megírhattam volna bash beépített eszközökkel is.

Ilyesmikre gondoltam, csak tévézés közben próbáltam megfogalmazni és nagyon nem az jött ki belőle, amit akartam.

man bash 4000+ sor...

A tömbkezelés az elég érdekes, valójában mintha nem tömbindexek lennének, hanem tömbindex helyett akármit be lehet írni, nemcsak számot. Olyan mint a php-ben.
Egyszer szórakoztam vele, többdimenziós táblázatkezelés meg lehetett vele valósítani (pontosan hogy, már nem tudom, valahonnan majd előkorom egyszer). Nagyon nem foglalkoztam vele, mert úgy kutyafuttában jöttem rá, de lényegében kapásból lehetett táblázatként kezelni ilyen formájú szövegfájlokat:

d1\td2\t...dn\t[adat|parancs]

pl.

tomb.txt:
1 1 12
1 2 14
1 3 cmd:expr `tabla tomb.txt 1 1` + `tabla tomb.txt 1 2`
1 4 cmd:expr `tabla tomb.txt 1 1` * `tabla tomb.txt 1 3`

persze, így akár végtelen ciklusba is lehetett kergetni, aminek az lett az eretménye, hogy telerakta a memóriát, és lefagyott a gép :D

a mintaillesztés azt pontosan nem tudom mi... azt nem a grep csinálja?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

egypárhoz vissza kellett nézni a mant, hogy mit csinál :p

kiragadott példák: 


BOX_SIZE=$(( ${#BOX[@]} - 1 ))
for i in ${!BOX[@]} ; do printf "%2s %s\n" "$i" "- ${BOX[$i]}" ; done
[ "${1//[0-9]}" != "" ]
CHECK $1 ${2:-${BOX_SIZE}}
${BOX[$i]%/*}

BASE0=$(basename $0)
BASE=$(echo ${BASE0} | cut -d_ -f2)  #hopp egy cuttal kevesebb eval BASE=${BASE0#*_}
DEST_A=/mnt/backup/
DEST_B=/run/media/
eval DEST=\$DEST_${BASE}

"Ha egy feladatot meg lehet oldani parancssori programok futtatásával, paraméterezésével, be/ki meneteik feldolgozásával, akkor a shell-script a nyerő."

Ez duplán hülyeség :). Egyrészt a Bash Turing-teljes, tehát minden feladatot meg lehet benne oldani, mégsem Bash-ben állnék neki hypervisort vagy üzleti szoftvert írni. Másrészt evvel az erővel a többi programnyelven történő fejlesztést is lehet scriptelésnek hívni, mert a forráskódok szerkesztése, fordítása, futtatása is shellben végezhető feladat. Bocs :).

Szerintem nem értetted meg, mit akart mondani. :-)

Én teljes programcsomagot (többrétegű neurális háló) írtam úgy, hogy a számolás dandárját UNIX-stílusban paraméterezhető C programok csinálták, a "kötőanyag" köztük viszont egy rakás shellszkript volt.

Ilyesmire gondolhatott az előttem szóló is.

---
Science for fun...

Valóban, ilyesmire gondoltam. Sokmindent meg lehet csinálni shell-ben, de nem mindent érdemes.
Másrészt meg vannak olyan feladatok, amikor meg a legoptimálisabb választás a shell, pl. boot-script, init-script, installscript... Bonyolultabb feladatokra/aritmetikára sokkal jobb saját programot készíteni, viszont pl. egy *tar.xz kicsomagolására nem állok neki c/c++ programot írni.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Abban igazad van, hogy nem mindig a shell script a nyerő, meg abban is, hogy a Bash Turing-teljes. De! Az utóbbi nem jelenti azt, hogy mindent meg lehet benne oldani 100%-ban Bashsal, lehet valami olyan eszközt kell elérni, amire a Bash képtelen, vagy valami olyan reszponzív GUI-s a feladat, hogy GUI eseményt kell feldolgozni, amit a Bash-nak sehogy sem tudsz átadni.

A szavazás nem világos számomra. Most a kérdés arra vonatkozik, hogy szoktunk-e shell scriptet írni? Valahogy ez a programok írása ködös. Vagy úgy érti, hogy kifejezetten Bash-fejlesztők vagyunk-e?

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Nem szavazás, csak kíváncsiskodás.
És igazából arra lettem volna kíváncsi, hogy az egészen alap shell eszközökön szokott-e valaki mélyebbre hatolni a shell programozásának szépségeibe, amikor nem csak egy futtató keret a shell, ahol beállítasz pár változót, esetleg ellenőrzöd egyes fájlok állapotát, aztán indítod belőle a feladatot valóban ellátó programot, hanem tényleges adatfeldolgozást is végeztetsz-e vele?
Elég nehéz érthetően megfogalmazni a dolgot...

Nem csak a megfogalmazás sántít - bár értem. Inkább az van, hogy a sok sorból álló script már általában használ külső és/vagy saját programokat is. Ekkor meg van olyan sapkád, ami szerint a shell csak futtató környezetnek minősül.
Valahol már írtam korábban, hogy shellben nem érdemes nagyobb mennyiségű adatot feldolgozni. Viszont komplex feladatot meg lehet oldani vele, bár ez bármelyik programnyelvről elmondható.
Én azért döntöttem shell mellett, mert a klasszikus unix programok kifejezetten szövegfeldolgozásra készültek. Így aztán könnyen összelegózható az adatfeldolgozás, illetve könnyen lehet igazítani, ha kell. A párhuzamos futtatáshoz azért kell némi lock meg queue kezelés, de utána minden akadály elhárul.

Ez a "bármelyik programnyelvről elmondható" indította be a fantáziámat.
Sajnos igazad van, ezt esélytelen úgy megfogalmazni, hogy precízen körülhatárolható legyen, mikortól shell program...
Kicsit bonyolultabb a feladat esetében azt hiszem, nem csak én nyúlok a legközelebbi szkriptnyelv felé. Akkor meg jön a gondolat: minek erőlködni a shellben?
Valahol itt emlegettem, hogy anno volt egy perl szkriptem, ami eredendően vms-en futott. Na ott az eredeti felállás az volt, hogy amit lehet, azt DCL-ben (VMS "shell"), amit nem, azt perlben. Amikor átment linuxra, akkor nem a perlt igazítottam hozzá, hanem a DCL eljárást ültettem bash 1.x-re...
És akkor sem gondoltam rá, hogy esetleg az egész perl programot áttehetném shellbe... pedig jó eséllyel lehetett volna.

Azért csak kell egy kicsit erőlködni. A rutin következő lépése az, amikor el tudod dönteni, hogy egy rendszer melyik részét, mikor (!), miben érdemes elkészíteni.
A shell egy interfész a rendszerhez és a programokhoz, míg a programok interfész jelentenek az adatokhoz. Aztán néha a specifikus programokat is meg kell írni.

Az áttételről egy példa. A barátomnak egy problémáját megoldandó alakítottam át egy C programot. A végén kiderült, hogy nem csak AIX-en kell futnia. A program viszont big endian-ra volt hegyezve. Mivel csak kisebb adatmennyiségről volt szó (sok millió rekord helyett csak néhány ezer), pár óra alatt átraktam awk-ba. Persze az új programot körbe kellett keríteni egy shell scripttel, mert így volt az egyszerűbb. A játék kedvéért az awk feldolgozást vissza lehetett volna írni C-be. :)

A "shell művészetét" - ha meglátnád egy-két programomat, bizony nem találnád meg. Esetleg később derülne ki, hogy pár dologról meg nem is hallottál. Értem a topic célját, de csak egyet mondhatok: Ha egy valódi feladat adódik, akkor van értelme a mindentudáson gondolkodni. Vagy akkor sem, mert a feladat megoldásához pontosan annyi tudás elegendő, amivel optimálisan meg lehet oldani.

Remélem, nem értesz félre: nem akarok új rdbms-t írni shellben, csak piszkálja a fantáziámat a dolog. Pl. az is, hogy mennyire használják ki a bash képességeit a userek?
Régi tapasztalataim alapján úgy tűnt, egy bourne shell is bőven elég lenne defaultként, ha tudná a history-t/sorszerkesztést kezelni olyan szinten, hogy kurzor gombok és ctrl-r... :)

( locsemege v | 2018. 02. 21., sze – 20:13 )

Én szoktam shell scripteket írni. Egyes bugokra workaround-ot is shell scriptben írok meg, de a backup scriptem is bash-ben íródott, az automatikus frissítések visszajelzése szintén, továbbá a gép adott idő múlva történő automatikus leállítását is bash script intézi. A build szerverről való frissítést is bash-ben írtam, s van néhány bash-ben írt daemon-om, amelyeket systemd-vel indítok.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Marharépa! :D Minimális GUI például, meg védelem, hogy frissítéskor ne álljon le, meg buborék, hogy hol tart... Ez az:

#!/bin/bash

LOCK="/tmp/timoff.$USER"

if read <"$LOCK"; then
    kill "$REPLY"
fi
echo $$ >"$LOCK"
a="`zenity --title='Időzített kikapcsolás' --height=300 \
    --list --text='Válaszd ki a kikapcsolási időt!' \
    --column='Leállítási' --column='idő' --radiolist \
    FALSE '0:15' \
    TRUE '0:30' \
    FALSE '0:45' \
    FALSE '1:00' \
    FALSE '1:15' \
    FALSE '1:30' \
    FALSE '1:45' \
    FALSE '2:00'`"
if [ -z "$a" ]; then
    zenity --title='Időzített kikapcsolás' --info --text='A számítógép nem áll le magától!'
    rm -f "$LOCK"
    exit 0
fi
BASE=`date '+%s'`
ifs_backup="$IFS"
IFS=':'
read h m <<<"$a"
IFS="$ifs_backup"
((m+=60*h))
while [ "$m" -gt 0 ]; do
    level='normal'
    [ "$m" -lt 6 ] && level='critical'
    notify-send -u "$level" 'Automatikus leállítás' "$m perc múlva"
    ((BASE+=60))
    CURRENT=`date '+%s'`
    sleep $((BASE-CURRENT))
    ((--m == 0)) && pgrep '^dnf' &>/dev/null && ((m++))
done
rm -f "$LOCK"
systemctl -i poweroff
exit 0

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( gyu v | 2018. 02. 21., sze – 21:25 )

shell scriptben sok mindent meg lehet oldani.

sőtt sok mindent meg lehet benne jól is oldani. Ez kicsit nehezebb.

Nagyon sokan pl. egyszerű mintaillesztés-manipulálás miatt már rögtön grep-ért awk-ért, sed-ért, cut-ért nyúlnak.

Lehet úgy is.
De a Netburst óta tudjuk, hogy a fork() lassú :D

Amúgy meg, már csak azokkal az eszközökkel, amiket a posix ad, elég sok szükségletet le lehet fedni!

Ha nincs szükséged bash-specifikus tudásra, akkor próbáld kerülni és sh-val shabang-olj. Hordozhatóbb lesz a kód. Már ha szempont, hogy ne csak egy adott rendszeren / környezetben fusson.
Ha mégis egy hangyabokányit komplexebb, és valami olyan kell, amire a posix-ban nincs eszközöd, akkor shabang-olj bash-ra, és használd a bash-t.
Néhány régi motoros ksh-ra esküszik.

Ami meg szinte már mindenütt elérhető, és közel hasonlóan jó, sött valószínűleg a bash-nál mind interaktív módban, mint scriptelés oldalon többet tud: zsh.

De eddig nekem még nem volt semmi olyan, ami miatt a bash kevés lett volna.
Ahol meg igen, akkor ott perl/python izlés szerint.

Néhány régi motoros ksh-ra esküszik.
Természetesen! Hiszen a bash szinte semmit nem tudott, amikor a ksh már mindent. ;)

A shell programozás nem arról szól, hogy melyik mit tud. Egy normális unix általában mindent tud, és ezek a képességek könnyedén előcsalhatók. Ezért a minden shellben megoldani vágyás csak l'art pour l'art tevékenység lehet.

Éppen most vagyok szopóágon egy python programmal. Nem volt elég a python2, mert így nem tudta megállapítani, hogy van-e egy dir avagy nincsen. ;) Felraktam 110MB python3-at. Ekkor fájlt nem tudott írni. No, egy ilyen bughalmazt shellben megírni már-már művészet lenne. Éppen ezért kerülendő a sok-sok mindentudó script nyelv! Nem a hordozhatóság, hanem az időtállóság miatt.

Részemről az apró C utilityk híve vagyok. Persze kell némi rutin, hogy a megfelelő eszközt ki tudja választani a ember. Sokszor nem érdemes az alap programokat kiváltani. Pl. így készült olyan program is, ami a fork()-ot a find és gzip futtatására használja. A végeredmény egy univerzális filter, amit már jól lehet a shell képességeihez integrálni. Shellben semmiképpen nem használnék tömböket, mert adott esetben ott az awk. Kb. ekkora eszközkészlettel készült 4-5000 sornyi script is, ami adatgyűjtésre és feldolgozásra alkalmas.

Bughalmaz? Biztos, hogy a python hibája? Néha teli a tököm vele nekem is, de pont a python esetében nem emlékszem olyan durva hibákra, amikkel ezt kiérdemelte volna. (Ruby-val már jártam úgy, hogy a netes tutorial nem működött, míg a gems segítségével fel nem raktam az újabb gtk környezetet, pedig semmi extra nem volt benne)
Szóval nem lehet, hogy nálad a selinux/apparmor kavart be? Esetleg virtualenv használata? Valami pip telepítés?

Leírom mégegyszer. Lassan, hogy jól értsed. ;) (Mint a Wasabi-ban. :)) 

[ -e $dir ] && [ -d $dir ] && echo "Van dir"

Igaz, ez a /bin/test, vagy a test shell builtin-t használja. Ha helyette fel kell raknom 110MB python3-at, és még hibás is, akkor nem én vagyok a hülye. Ha két python verzió között egy dir meglétének a vizsgálata nem hordozható, - ugyebár ez valami NASA űrtecnológia, - akkor ott nagyon nagy baj van. Ezért nem szabad használni.
Szóval nem lehet, hogy nálad a selinux/apparmor kavart be? Esetleg virtualenv használata? Valami pip telepítés?
Nem. Ez egy FreeBSD és töredelmesen bevallom: root-ként futtattam.
Viszont a fenti kód tetszőleges shellben hibátlanul fut az idők kezdete óta. Ezekkel a dependenciákkal nyugodtan kijelenthető, hogy a python kódot dilettáns programozó készitette.

Nem szabad olyan kódot írni, ami csak a Te pécéden fut jól! Nem csak másokkal, de magaddal is kiszúrsz.

A shell script "hordozhatóságánál" a legfontosabb side effect a következő módon írható le - ami nem igazán manapság keletkezett:
Vajon milyen rendszer előtt ülünk? Csak el kell indítani egy programot!
- Ha kiírja: "kopirájtpítörnorton" == DOS
- Nem ír ki semmit == UNIX
- Valami marhaságot ír ki == GNU

Bammeg, wasabit ne emlegess! Most fejeztem be az ebédet: sushi... mit árthat nekem az a pici wasabi??? Annyira nem erős, ettem már. Csak egy picit nyeltem félre. Ne tudd meg... :DDD

BSD számomra ismeretlen terep. Az apparmort azért emlegettem, mert elcseszett profile-lal az tud ilyet. És miután a profile a binárisra van ráhúzva, az is megeshet, hogy a 2.7 alatt más hibát látsz, mint 3.x alatt. És ha jól tudom, ezek a root elől is el tudnak rejteni fájlokat. Sikerült más környezetben reprodukálni? Roppant kíváncsi lennék, mi lehetett a konkrét oka...

Szerk: megnéztem, ilyesmi van freebsd-n is, MAC néven. :)
Ez így nekem még mindig szaglik...

Akkor igen, de a tapló leveleid esetében meg nem mutatkoztál be - bár nem is érdekel, milyen nevet adtak a HUP momentán legtaplóbb nick-je mögötti humanoidnak. Rajtad kívül ennyire taplóbunkóállat módon viselkedő huppert nagyon keveset látott a világ, ha az életben is ilyen vagy, akkor nagyon sajnálom a környezetedet.

Vicces, hogy a világegyetem legbüdösebb, legostobább gyökere itt hisztizik.
Tudod te seggfej, ha egy fokkal is jobb lennél annál, mint amiket rólam mondasz itt és úgymond a hátam mögött, akkor eleve nem is szóltál volna hozzám soha.
De te csak egy büdös, penészes gyökér vagy, ami még a kínaiak macskalevesébe se jó.
Egy szánalomra méltó, kivénhedt hülye...
Ha nem tűnt volna fel, egyikőtökhöz sem szóltam, amíg nem kezdtetek baszogatni és egy-két ritka alkalmat kivéve kizárólag válaszoltam a magadfajta söpredéknek. :D

Amit írsz, az nevezhető szándékos rongálásnak.
Én meg láttam ilyet programhiba miatt létrejönni...
A levesgyökér arra célozhatott, hogy kellőképp zárt környezetben "lehetetlen", hogy váratlan nevű fájl keletkezzen.
Csakhát a másik oldal, hogy ha valaki gyakorlott szkriptelő, az optimális esetben reflexszerűen "$a"-t ír $a helyett...

Nem. Amit írok, az PoC. Bemutatandó, hogy bele tud kerülni könnyedén egy szóköz egy változó tartalmába.
Ebben a hsz-ben sehol nem volt "szándékos rongálás".

A másik esetben, hogy a ] és ; jelek, hogyan és miért kerülnek a fájlnévbe...
Az egy másik történet.

De részemről, szeretek úgy megírni shell scriptet, hogy abban, ha elkövetek valamit, akkor az a megoldási módszer mindenféle további review nélkül újrafelhasználható legyen másutt is. Ebbe így nekem nem fér bele az olyan trehányság, hogy nem védjük meg a változó tartalmát amikor azt argumentumként továbbadjuk.

Ha hülyeséget csinál valamilyen hiba miatt a küldő...
Mintha nem te arcoskodtál volna amikor pár hete a blogomban írtam a hibakezelés szükségességéről egy kb tízsoros C program (https://github.com/haa-zee/proc_speedtest/blob/master/proc_speed_test_C…) kapcsán, amit úgy tákoltam össze, hogy húsz éve a közelében sem jártam C-nek és korábban sem használtam -> ergo csak magamon röhögtem. :D
Te meg jöttél nagyképűsködni, hogy milyen alapvető dolgokat nem tudok. Ugye... erre itt jössz védeni a védhetetlent.

Magam is törekszem arra, hogy minél védetebb, jobb minőségű legyen a kódom, legalább is addig, amíg a védelem nem jár extra nagy erőforrás igénnyel. Assembly-ben vektoros vezérlésátadásnál szoktam maszkolni az inputot, majd a maszknak megfelelő mennyiségű elemmel feltölteni a táblázatot. Például 7-tel maszkolok, mondjuk 6 elem értelmes, de a maradék 2-t is kitöltöm, így semmiképp sem fog elszállni a kód.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tiltakozom, óvást nyújtok be! :D Tudniillik szoktam azt, hogy ls -1 paranccsal filelistát kérek, végigmegyek rajta, s vizsgálom, vajon directory, vagy sem. Ha az, belemegyek, ha nem, akkor feldolgozom file-ként. És itt bizony lehet szóköz a nevében. Mondjuk én nem vacakolok a teszteléssel:

if cd "$dir" &>/dev/null; then
  ...
  cd ..
else
  # nem könyvtár
fi

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

<kötekedés mode on>

és ha soremelés van a nevében...? :-D

Ne 

ls -1

-gyel kérj file-listát, hanem így: 

for name in /path/to/dir/*; do valamit; done

(arról már nem is beszélve, hogy fölöslegesen indítasz egy processzt)

Demo: 

$ mkdir abc$'\n'def ghi

$ ls -l
total 0
drwxr-xr-x   2 muszi    muszi          72 Feb 23 20:47 abc?def
drwxr-xr-x   2 muszi    muszi          72 Feb 23 20:47 ghi

$ ls -l --show-control-chars
total 0
drwxr-xr-x   2 muszi    muszi          72 Feb 23 20:47 abc
def
drwxr-xr-x   2 muszi    muszi          72 Feb 23 20:47 ghi

$ for dir in $(ls -1d *); do touch "$dir/test"; done
touch: cannot touch `abc/test': No such file or directory
touch: cannot touch `def/test': No such file or directory

$ for dir in *; do touch "$dir/test"; done

$ ls -l --show-control-chars -R
.:
total 0
drwxr-xr-x   2 muszi    muszi          72 Feb 23 20:47 abc
def
drwxr-xr-x   2 muszi    muszi          72 Feb 23 20:47 ghi

./abc
def:
total 0
-rw-r--r--   1 muszi    muszi           0 Feb 23 20:52 test

./ghi:
total 0
-rw-r--r--   1 muszi    muszi           0 Feb 23 20:52 test

Na, az ilyen elvetemült dolgokra már nem szoktam felkészülni. Mint ahogyan néha csinálok olyat, hogy konfig fileban

változó=érték

szerkezetet használok, az egészet pedig include-olom a scriptben. Viszont így a konfig file tartalmazhat szintaktikai hibát, meg akár futtatható kódot is. Ha jó kedvem van, leellenőrzöm, hogy csak értékadás lehet benne, de rafinált kifejezések, $ jelek, eval, s effélék már nem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha az én hozzászólásomra gondolsz, szorozd meg mínusz eggyel! Szerintem van ő olyan tapasztalt róka, hogy tudja, hogy a szóköz semmit nem ad hozzá a nevek olvashatóságához (csak a sírást és fogaknak tsikorgatását, amikor gyorsan kell lépni), ezért nem használ ilyesmit, vagyis tudja, hogy nem kell ellene védekezni.
Azaz szerintem egészségesen konzervatív - ha ez előítélet, akkor a részemről pozitív előítéletnek van szánva.

Ja, O.K., akkor ezt benéztem (csakhát, ahol felbukkan egy Gizike által is írható samba share... ott lehetsz te bármilyen konzerv, szóval mégis gáz, ha nem vagy felkészülve egy véletlenül bekerülő szóközre ;))) )

A kérdés viszont ettől függetlenül áll, mert túl sűrűn látok lekezelő hozzászólásokat olyankor, amikor... hát nem igazán indokolt.

Amikor az ember scriptet ír, akkor fel kell készülni a legrosszabbra.
Főleg, hogy shell script esetén nincs nagyon "unit testelni" lehetőséged, és vér és verejték néha egy-egy szarabbul megírt shell scriptben a hibát megtalálni.

Megesik, hogy emberi tényező, vagy bármi megtörténik... vagy egy véletlen folytán megcsúszik az ember a keze, és a vágólapról valami szemét bemásolódik a terminálba, aztán nem takarítódik ki egy fájl, aminek a nevében szóköz van!

Az egyik, hogy szépen megtervezi az ember a struktúrát.
A másik, hogy a kódban ettől függetlenül felkészül a "szemétre", validálja az inputot, de minumum nem hagy lehetőséget "userinputnak" kódként futatásra kerülni!
pl. elég egy "blah ] ; rm -rf .. ;" nevű fájlt odatouch-ni -> a test false -ra fut, csak ; majd lefut egy rm -rf ..
majd meg tovább a kiértékelés, mert egy ; is bekerült, így szintaktikailag sem töri el a scriptet.

Elméletileg igazad van, és azt sem állíthatom, hogy nem úgy írom beidegződésből, ahogyan te és a nagy könyv is elvárod.

De nem tartom akkora csapásnak, hogy felemlegessem, ha olyan gépen crontabba vés egy ilyen nem foolproof szkriptet valamelyik kolléga, ahol összesen hárman fordulhatunk meg shellel, mindenki más csak egy db-nek vagy egy szolgáltatásnak a vendége.

Pedig ez triviális! Ha valamit nem tudsz megcsinálni, azt más sem. Így tehát nem is létezhet. :-D

Ne mondd, hogy önző vagyok, ezért elárulom mit lehet tenni. A probléma két osztályba sorolható.
1) Automatikus működésű zárt rendszer.
Ekkor a rendszer konstansok vagy algoritmusok alapján képzi a neveket. Tehát nem fordulhat elő sem ismeretlen karakter, sem ismeretlen név. További megszorítások alapján csak ASCII karakterek fordulhatnak elő, de unicode és speciális karakterek kizárva. Régen, amikor még ftp+modem alapú adatküldés volt, akkor csak adott nevű fájlt lehetett küldeni a megengedett időben. (Akkoriban ezt linuxon sem lehetett egyszerűen megoldani. Amikor meg átvertek, akkor kénytelen voltam SCO-ra egy acl emulációt írni. :))

2) Idegen területen levő, bárki/mi által készített fájlok kezelése.
Ez majdnem mindent lefed, ami a fenti specifikációnak nem felel meg. Az ilyeneket a (fenti specifikációnak megfelelő) rendszer nem képes hibátlanul kezelni. A fájlnevek semmi szín alatt nem jelenhetnek meg a shell változók között! Ha lehetséges, a használandó LANG mellett kell futatni az egyes programokat. Pl. find, tar. Ilyen munkaterületen legfeljebb tar-t szoktam futtatni backup céljából.

A második eset kivételével sosem dolgozunk * nevű fájlokkal. Ha a LANG beállítása problematikus, esetleg nem is lehet a diszkre másolni a hibás nevű dolgokat.

Csak kérdés, nem kötözködés: az 1) esetben nem érdemes mégis felkészülni arra, hogy pl. diszkhiba miatt létrejön egy krixkraxokat tartalmazó filenév? Nem lehet kellemetlen, ha egy kis hiba miatt egy szkript nagy pusztítást végez, pl. mert lérejött ez "xx\n;su -;rm -rf /;QrX302!*" nevű file.

Méghozzá egy nagyon jó kérdés!

Bizony hardverfüggő vagyok, ezért két részre osztom:
1) AIX alatt nem igazán tartom elképzelhetőnek. Persze, ha villám vág a gépbe, az meghaladja a képzeletemet. Pl.:

- Vihar volt, és a házunk előtt az erős szél rendszeresen összecsapta a vezetékeket, amitől elment a villany. A gép naplózta a tükörből kiesett partíciókat. Egy paranccsal újra lehetett szinkronizálni.

- Nagyobb rendszerben a szünetmentes tápban elfüstölt nullvezető miatt pulzáló 380V feszültséget kaptak a gépek. A pécék 30 százaléka megsemmisült. Kisebb szervereknek leégett a tápja. A nagyobb szerverek kiírták: 001 (==hibás hálózati feszültség).

- Az IBM által nem támogatott diszkek esetén a naplóba került:
-- Hibás szektorok a ...
-- Parancsot adtam a diszknek a hiba kihelyettesítésére.
-- Nem sikerült, kihelyettesítettem én.
Aztán megyünk tovább...

- Egy SSA loop-on eltérő firmware verzió került az egyik diszkre, ami szigorúan tilos. (Az SSA olyasmi volt, mint a SATA, csak itt két gép és 7 diszk volt egy loop-on) Ugyan a gép írt marhaságokat a naplóba, de az összes fs sértetlen maradt. A fw frissítése után hibátlanul működött.

2) Volt szerencsém az általad leírt hibához, méghozzá egy meghibásodott RAID csatoló jóvoltából. Nem kis hiba volt és nem kis szkript, hanem egy mail server. A csatoló dadogott, hibátlan területekre io errort adott, a mélek meg csak jöttek! A végeredmény elképesztő lett: Jóformán megállapíhatatlan volt, hogy egy fájl hol, milyen néven és milyen tartalommal jött létre. ;-D
Az már nem derült ki, hogy a tükör másik példánya hova tűnt...

No, jókat sztoriztam, de a diszk nem így működik. Írás hiba esetén megpróbálja kihelyettesíteni a sérült részt és hibát ad, ha nem sikerült. Olvasási hiba esetén is hibát ad. Mindkét eset java részében a device driver szintjén és az oprendszernek kell kezelnie a hibát. Ha megnézel néhány rendszehívást, az EIO hiba csak elvétve szerepel. Ott, ahol a felhasználó szinjére kerülhet a hiba - és ez esetünkben a shell - meg kell szakítani a programot. Bonyolultabb esetben, több task/job futtatása esetén persze a programozó dolga, hogy megakadályozza a hibát, ha valamelyik ág kiszáll.
Tehát script szintjén közvetlenül nem kell IO error-t kezelni.

Szerintem valamiféle önző bizonyítási kényszer, büszkeség: _én_ jobban értek ehhez, az _én_ f.rkam a nagyobb,
|<---------------- eeekkora halat fogtam ---------------->|
meg ilyenek. A macska is borzolja a szőrét, hogy nagyobbnak látszódjon. Szerintem innen jön. Ettől függetlenül többeket - engem is - irritál, ha adott minőség alá megyünk, pongyolák vagyunk. Szakemberek megengednek maguknak olyan pongyolaságot, pontatlanságot, felületességet itt sokszor, amit még amatőrök is precízebben fogalmaznak meg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem is az a bosszantó, hogy olyanok fikáznak egy példasort, akiknél - akár együttvéve is - több sor scriptet írtam! :)
De ott fent a pythont (és annak a kompatibilitását) és egy meg nem nevezett python programozót szidtam. Erre alig van reakció, miközben mindenféle baromságról elég részletesen értekezünk. :(

Pillcsike, csak fél éjjel debúgtunk, meg ma délelőtt van a piac nap. :) 

#!/usr//bin/env python3
helyett
#!/usr//bin/env python

Traceback (most recent call last):
  File "/root/bin/ROSbackup.py", line 379, in <module>
    main()
  File "/root/bin/ROSbackup.py", line 372, in main
    unpack(args.input, args.directory)
  File "/root/bin/ROSbackup.py", line 271, in unpack
    files_num = unpack_files(input_file, length, unpack_directory)
  File "/root/bin/ROSbackup.py", line 145, in unpack_files
    create_write_file(path + name + '.idx', idx)
  File "/root/bin/ROSbackup.py", line 64, in create_write_file
    os.makedirs(os.path.dirname(path), exist_ok=True)
TypeError: makedirs() got an unexpected keyword argument 'exist_ok'

A program: https://github.com/BigNerd95/RouterOS-Backup-Tools

Részvétem az éccakáért... ;)
Később bekapcsolom a gépem, ránézek, hogy mi ez amit mutattál. (Sacc/kb a python2-3 közti eltéréshez lehet valami köze, az meg erősen kérdéses, hogy kinek a sara)
Persze nem akarom megszakérteni, nem vagyok programozó, csak egy kíváncsiskodó külsős, aki még reménykedik, hogy a python mégsincs annyira elcseszve :)

Bár az érveimet itt felsorakoztattam, lényegében igen.
Mint kívülálló annyit látok, hogy a legtöbb rendszeren a 2.7 van. Lényegében felraktam 110MB programot, mert az 50 éve jól működő vizsgálat helyett python-ban megfogalmazott vizsgálat helyett készült egy újabb vizsgálat, ami nem kompatibilis az előzővel.
Ha most kínaiul folytatnám ezt a sort, bizonyára hülyén bámulnál magad elé.

Azért ott sántít az érvelésed, hogy te nem verziók közti inkompatibilitásról írtál, hanem kijelentetted, hogy nem képes ellenőrizni egy directory létét/nemlétét a python.
Ez eddig csak annyinak látszik, hogy a python3 csak részlegesen kompatibilis felülről a 2-vel.
2->3 irányhoz van egy úgy-ahogy működő konvertere a hármasnak.

Sokszor elolvastam, de továbbra sem látom úgy, hogy itt a python fejlesztőinek dilettantizmusa lenne a kiváltó ok.
A python2 és a python3 esetében jobb elfogadni, hogy ez két hasonló programnyelv, de nem azonosak. (Jó, ez túlzás, de így egyszerűbb)
Ha 2.x-re írt programot használsz, az 2.x-2.7 közt működik.
3.x-3.5 (asszem, 3.5 a legújabb stabil) esetében szintén.
De te eredetileg egészen mást írtál: azt, hogy nem működik.
Ez meg így nem stimmel.

Éppen most vagyok szopóágon egy python programmal. Nem volt elég a python2, mert így nem tudta megállapítani, hogy van-e egy dir avagy nincsen. ;)
Kiskezitcsókolom: a program
Ezen belül Nem volt elég a python2, ..., és ott a szmájli is. Azért, nehogy az egyszerű lelkű olvasó arra asszociáljon, hogy hátha-mégis a python2 a ludas.
Magyarázom tovább: úgy volt megírva, hogy python3 kellett ehhez a bonyolult feladathoz.

Tudod, én ahhoz szoktam hozzá, hogy a 25 évvel ezelőtt AIX-re megírt programjaim ma futnak/fordulnak linuxon. Vagy esetleg két tökegyforma linuxon másképp kell fordítani. :-)
Az természetes, ha AIX főverzió váltásnál, sőt 32->64 bit, feltettük a kérdést, hogy futni fog-e egy 1500MFt árú rendszer. A válasz: Tulajdonképpen open(), close(), seek(), stb. amit használunk. Miért ne futna? (Adhatsz jó választ: a vita tárgyát képező python program jóval olcsóbb volt. :)) Régen csak VMS alatt volt természetes, hogy ha valaki programot hozott volna, akkor rögtön felsorolt 3 verziót.

Úgy volt megírva, hogy 1-2 éven belül megszűnik a 2-es supportja (eredetileg úgy rémlik, már idén megszűnt volna)

Amit leírtál az első hozzászólásban, abból meg tényleg az jött le, hogy a pythonnal van bajod, nem a programoddal.
Akkor meg miről beszélünk? Rossz programot bármiben lehet írni.

Az a baj, hogy
- egyrészt fingod nincs a pythonhoz, de megengeded magadnak, hogy kijelentsd, szar, míg ha valaki az általad jól ismert eszközökkel teszi ezt, akkor természetesen csak meg kéne ismernie
-meg hogy ordas nagyot ferdítesz, mikor azt állítod, hogy a python2ben ez nem ment jól, vagy megváltozott.

Természetesen python2ben is meg lehetett nézni, hogy egy file létezik-e, directory-e, meg egyéb ilyeneket. Többféle módon is egyébként, le lehet nyúlkálni a posixig, és nézegetheted ugyan azt kedvedre, amit shellből, vagy használhatod pl os.path-ot, ami ezek fölé húz egy vékony réteget, és az abban levő isfile(), isdir() és hasonlókat. Amik egyébként baromira nem változtak python 2 és 3 között (illetve de, de nem backward incompatible módon).

Ellenben az általad használt tool használt egy új shortcutot az os.makedirsben, ami kényelmesebbé teszi python3ban, hogy ne álljon meg hibával, ha létezik az adott könyvtár.

Természetesen, ha ennek bevezetése előtt a programozó úr kézzel csinálta volna az

if not (os.path.exist(path) and os.path.isdir(path)):
os.path.makedirs(path)

csodát, ami kb ugyanazt éri el, az ugyanúgy működött volna a python3 interpéterben is.

Szóval az van, hogy te válaszottál egy toolt, ami deklaráltan python3-at kér, majd csodálkozol, hogy szeretné használni annak a featurejit, de nem te vagy a hülye, hogy ezt választottad, hanem a python.

Ki ferdít és mit?
Szóval az van, hogy te válaszottál egy toolt...
Helyesen: letöltöttem egy programot.
egyrészt fingod nincs a pythonhoz
Igaz, ezért töltöttem le a programot.
meg hogy ordas nagyot ferdítesz, mikor azt állítod, hogy a python2ben ez nem ment jól, vagy megváltozott
Semmi ilyet nem állítottam.

Azt viszont igen, hogy egy dir elkészítéséhez teljesen felesleges a python tetszőleges verziója. (Értsd nincs előnye, viszont hátránya van.)
Abban az esetben, ha a stat() és mkdir() cifrázódik ennyire, akkor nem jó ez a nyelv, vagy fiatal volt a program írója.

Szóval.
- Találtál egy programot
- A program kifejezetten deklarálja, hogy neki python3 kell
- A python3ról lehet tudni, hogy kifejezetten vannak benne mind breaking changek, illetve új featureök
- Szerinted ez nem fontos, mert izé.

Ezzel eddig nagy baj nincs, viszont mikor előadod, hogy ha ezek után nem megy, mert olyasmit használ, amihez python3 kell, akkor nem te vagy a hülye, azzal már akad. Főleg, ha a mindenhez nagyon mélyen értek, és tudni kell mi történik mentalitás helyi főpapja mondja :)

Ha van egy script, aminek a shebangja deklarálja, hogy neki tcsh vagy ksh kell, aztán sima shval futtatod, és szar lesz, akkor is természetesen a script a hülye, még csak véletlen sem te.

Úgy vélem mindenben igazad van.
Megszületett a tanulság is. A python és a pearl továbbra is kerülendő!
- Nem értek hozzá.
- Nem időtálló.
- Nincs minden rendszeren fenn az összes verzió.
- Továbbra is megírható minden bármilyen nyelven, már amihez értek.
- Nincs szükségem mindent is tudó programokra.
- Tényleg hülye vagyok, mert egyáltalán nekiálltam ilyennel foglalkozni.
Magyarázom: Tudatlanság az, ha nem veszem figyelembe a dependenciákat. A felesleges meg az, ha egyedi megoldású programot próbálok felasználni egy részfeladat megoldására.
Tehát a végső megoldás a know-how felhasználása és a teljes feladat megoldása: Egy adott struktúrát ki kell bontani, majd később összehasonlítani egy másikkal. És ebből pattant ki az ötlet is, hogy minderre semmi szükség.

És az utolsó mondatodban is ott az igazság. Ha a default shell ksh, akkor nem fogok csh scriptet használni. (Na jó, ez egy eléggé elfogult példa, mert éppen egy pfSense rendszeren fut, de azért az sh-t még eltűri.)

És bocsánat, erre a hozzászólásodra is itt válaszolok: https://hup.hu/node/158046?comments_per_page=9999#comment-2201700

Pl ezt ferdíted. A program, amit letöltöttél, nem csak egy dirt csinál. Az írója valószínűleg egyéb okokból választotta a python3at, és ha már ezt választotta,
A program semmi olyasmit nem csinál, amihez ne lennének meg a modulok a 2.7-ben. (Ezt azért megnéztem.) Az írója meg egyetemista, tán ezért dolgozott a legfrissebb verzióval.
Főleg, ha a mindenhez nagyon mélyen értek, és tudni kell mi történik mentalitás helyi főpapja mondja :)
Ez egy övön aluli megállapítás. Igaz, egy egyetemista mentalitását kiritizálni is övön aluli. Nekem eddig 200 évnyi automata rendszerem futott - általában hibátlanul. Nyilvánvalóan akit kritizáltam, annak meg még egy perc se - miért is törődne olyannal, amikor időtállónak kell lenie egy rendszernek. És itt csak egy szempontom van: Az általam használt különböző rendszereken csak python 2.7 van. Más is felrakható, de minek?

Kit kritizáltál? A program szerzőjét, aki python3+ -compat-ra írta a programját?

Akkor miért használtad a szoftvert?

Ha oda volt írva, hogy python3+, és állításod szerint nem értesz a python3-hoz, miért köpködöd a pythont (főleg így ismeretlenül!), ahelyett, hogy megkértél volna egy olyan kollégát, aki ért python-ul?
Az se baj, ha valaki olyat, akinek nem csak 200 évnyi automata rendszeren futott.

Miért használtam? Ezt dobta ki a kereső.
Bár a használat kicsi túlzás, csak kipróbáltam.
Mivel ismerem a magic fogalmát, rögtön megállapítottam, hogy nem a megfelelő verzióval futtatom. Ehhez nem feltétlenül kellett tudóst igénbevenni. ;)
Mivel felrakható mindkét python verzió, ezért felraktam a másikat is.
Ennyike.

Az egész csak arról szólt, hogy az atomkutatásnál is bonyolultabb dir meglétének a vizsgálata mi a rossebért változott.

Mantrázhatod tovább ezt a badarságot, de ezt már egyszer leírták mi történt:

Volt pofájuk a python fejlesztőinek egy újabb főverzióban, egy újabb, kibövített és a programfejlesztést megkönnyítő módozatát bevezetni a funkciónak a fejlesztőknek a repertorába.

Ezt így ráadásul pofátlan módon, a semantic versioning szabályainak betartásával tették. Ld. még http://semver.org/

A scriptet fejlesztő ember, meg galád módon elkövette azt, hogy a haladósabb fejlesztés érdekében már a 3-as python-t volt pofája használni, hallgatva arra a számottevő szakmai többségre, akik már évek óta mantrázzák, hogy a 2-es pyton-t már rég el kellett volna felejteni, és ha legalább új kód fejlesztésébe fogsz, akkor használj 3-ast.
Nem is tudom, hogy lehetett ennyire galád, hogy követte a szakmai mainstream által mutatott irányt.

Szerintem, kár ezt a szálat tovább feszegetned, mert avval csak tovább ásod a reputációd!

Hagyjuk is a pythont, hiszen csak felraktam egy újabb felesleges csomagot és már futott is.
Az alap probléma csak az, hogy ez is egy program, amihez egy másik programot kell írnom. Ettől lesz használható valamire.
Egy struktúra szétdobásához meg sokkal jobb a C, amiben mkdir nélkül ;) röptében megoldható a feladat. (Ne feldd, hogy a python szidása vagy dícsérése ellenére ez a program csak egy darabka a feladatból.)

A szakmai mainstream+gnu+systemd. Ez az, amin már kínosan röhögni sincs kedvem.
Valahol alább említetted, hogy nekem nem jó, ha a default config-gal nem jön valami. Ha már a mainstream-re hivatkozol, akkor a CentOS győzött. Úgy átszik, ők még nem tudják Pistike Pécéjén mi a divi. ;) Nyugodtam mondhatok én is olyat, hogy barátunk nem szerver környezetre írta a programot. Az igazság meg lehet a két véglet között, de lehet ízlés kérdése is. Kevesebb dependenciával mindenképpen stabilabb és könnyebben kezelhető bármilyen rendszer.

Ezt a gondolatmenetet nem tudom hogy sikerült idekavard?
Illetve, a gondolatmenetet se értem.

Hogy jön most ide a mainstream-hez a gnu + systemd?
Bocs, elfelejtettem leírni, mekkora szemétnek tartom a systemd-t?

A gnu-val konkrétan nem tudom mi bajod. Vannak benne szarul sikerült dolgok. És vannak benne újító ötletek is, olyan dolgok, amik a maguk korában pioneer-nek számítottak.

Az, hogy a centos egy az egyben rhel, oda meg valami oknál fogva szépen felülről tolják le a nép arcán Pöttering agyfosását a nép torkán... Azt még ne hívjuk szakmai mainstream véleménynek!
Amúgy meg... Van pozitív hozadéka is a dolognak: Egyre több a systemd refugee más rendszereken. Szépen újra színesedik a unix ökoszisztéma és lendül a többi rendszer fejlődése is!

A default konfigos említésnél, lehetnél kicsit konkrétabb mire gondolsz, mert így homályosan célozva valamire... megintcsak nem jön át a gondolat.
De azt valahol már talán kifejtettem, hogy függően attól, hogy mi a cél:
* ha hordozhatóság, akkor jó az, ha csak olyan eszközöket használ az ember, ami oob működik minden célrendszeren. Ilyen esetekre pl. jó, ha pl. egy shell scriptnél még a tool-okból is csak olyan feature-öket használunk fel, amik a posixban definiálva vannak. Lásd alant pl. a find-os megjegyzésem.
* ha a gyors (uram bocsá a szóért: agilis) fejlesztés, hogy más is hozzá tudjon nyúlni a kódhoz, stb. akkor viszont be kell lőni a célterületet, meg a lehetőségeket, és letolni az "ops"-ra, hogy az előfeltételek rendelkezésre álljanak. Erre is van már rengeteg szerszám. Lehet automatikusan tesztelni, ci/cd-zni, van openshift, kubernetes, ...

Nem tagadom, kissé elfogult vagyok. Nálam a követendő mainstream az a disztró, ami POWER-en is fut. Ez jó ideig a RHEL és SLES volt - újabban az ubuntunak is van ilyen verziója.
Ennek ellenére a CentOS (amit most tekintsünk RHEL-nak) megérdemli az "ipari" jelzőt, és nyugodta kiindulhatunk egy minimal install-ból. Tehát egyrészt mérvadó, de a hardvergyártók szerint is csak akkor jár a support, ha valami ilyesfélét raktál fel. Úgy érzem, nem vagyok egyedül a véleményemmel. ;)
Ez csak egy vélemény, de talán könnyebb az élet, ha ehhez tartom magam.

A default konfig: https://hup.hu/node/158046?comments_per_page=9999#comment-2202354
A POSIX - állítólag a Windows is az. :-D Bocccs! Ez egy occcsó poén vót.
A gnu túlságosan gyorsan és szerteágazóan fejlődik. A bőség és sokrétűség zavara gyakran instabilitáshoz vezet.

A systemd meg a unix és a józan ész megcsúfolása. Szerintem a unix egy filozófia. Meg a FreeBSD is, csak az egy kicsit más. :-) (Itt kifejezetten az rc.*-ra gondolok.)
Szóval a systemd egy trehány katyvasz, az rc/init.d rendszer kicsit elavult. Ami régi, az az AIX - viszont elegáns, és adatbázisból jön. Ugyan finoman írják: Ha primitív vagy, választhatsz rc konfigot is, de nem javasoljuk. Az ő megoldásuk pl.: /etc/methods/cfginet (Itt vége.)

Ezt kicsit nem értem. Kijelölöd a RH-et mint követendő irányt, miközben meg te magad is látod, hogy a systemd mekkora egy rakás sz..r.

Erről a klasszikus vicc jut eszembe, minél a csattanú ugye úgy kezdődik, hogy: Vadász, vadász, ...

Miközben ha megnézed a teljes szoftver-szolgáltatás-* ökoszisztémát, akkor látszik, hogy a RH/bármelyik disztrókészítők szintén csak követik a fejlődést. Na jó, van némi minimális kontribúciójük is. Az ilyen abominációk/blaszfémiák mint a systemd.
A kernelhez talán csak értelmes embert hagynak hozzányúlni. Pillanatra most el is gondolkodtam rajta, hogy nem-e a linux védelmében hagyják Pöteringet systemdz-ni: Addig se nyúl a linux kernelhez, aztán mikor már elég gáz a cucc, akkor kihajítják az egészet és csinálnak egy gpl-es smf-szerű rendszert.

Az irányt nem ők írják. Az olyan cégek írják, mint a Google, Amazon, ... esetleg még Facebook.
Ahol ahhoz, hogy piacvezetők tudjanak maradni, folyamatosan kell újdonságokkal, valódi új szolgáltatásokkal kijönni.
A google-nek ott egy Google I/O, Az Amazonnak pl. az Innovate, stb.
Vagy nézz meg egy Lisát, Fosdemet, stb. hogy honnan jönnek nagyon sokan előadni, részt venni, stb.

Meg nézd meg aztán ezeknek a szofterfejlesztési módszertanait, hogyan tudnak jó minőségű szoftvert, sokat, gyorsan önteni ki a nagyvilágba, illetve szolgáltatásokat, meg azokhoz a szoftvereket fejleszteni!

Már kb. a RedHat is belátta, hogy képtelen a disztrót értelmes sebességgel frissen tartani. (Debiantól meg soha nem is vártunk ilyet.)
Igény meg lenne rá, hogy modern eszközök legyenek! Mert ha folyamatosan a backward compatibilityn kell embernek törpölnie, akkor nem halad a fejlesztés! Lásd a múltkori linkem a semver.org-ra, verziószámozást illetően.
Ma már a klasszikus "sysadmin"ság kihaló szakma. Automatizálod a telepítést is. Mindegy, hogy kayak-kal, kickstarttal, seedfile-al, vagy mivel. A lényeg, hogy ahogy új node-okat tolsz be a rendszerbe, a gép használatbaállításáig ne kelljen embernek hozzányúlnia, max pár configot átütsz egy file-on, aztán git commit.
Ha gyorsan, fenntarthatóan akarsz platformot építeni, akkor nem telepítgetsz ma már linuxokat, unixokat, stb.
Fogsz pl. egy openshiftet, és használsz more ore less minőségbiztosított image-ket. Vagy megcsinálod a saját pipelinejaid.
Írsz teszteket, hogy mit vársz a rendszertől. Ha nem megy valami, akkor nem deployolod productionbe. De még ezt a döntést se kell embernek meghoznia. A fejlesztő max egy zöld vagy piros visszajelzést lát a Jenkinsében, aztán majd oknyomoz, hogy miért nem deployolódott a micsoda.

Egy ekkora ökoszisztémában most egy systemd... Jah. Gáz. Egy erős technical debt. Az openshift node managelésére úgyis kb mindegy, mert max az LB oda nem küld terhelést ahol a systemd miatt elborult a node, a scaling érdekében meg majd másik node-okon spinupol néhány új pod-ot, és mehet minden tovább.

Megnézed, mire épül az egész?
Kubernetes.
Google.

A redhat már csak annyit tesz, hogy csomagolja neked azokat a technikákat, amiket a google, meg a többi nagy ont magából.

hwgyártó + support kérdés is ma már egyszerű: eldöntöd milyen szolgáltatást szeretnél: valamit, ami skálázódik, és akkor Amazon, Microsoft meg talán még a Google felhő, amik nagypályások.
Vagy szenvedsz magadnak avval, hogy az alapoktól felépíts mindent, amihez a nagyok már rég kínálnak neked profin összerakott szolgáltatást és akkor csak VM-eket bérelsz az 2jegyű Óceánból, vagy a *Rack*-től, ...
<szerk>és újra feltalálod a spanyolviaszt, amit a Google, meg Amazon már megcsinált és kb. a szolgáltatás része</szerk>

Egyébként, meg ha init rendszerben kell a személyes kedvencet említeni: Ennyire mélyen az AIX-ot nem ismerem, úgyhogy a saját személyes kedvencem az SMF. CDDL. Mélyen nem kell gyökerezzen a kernellel, vagy mással legjobb tudásom szerint. Szóval, még a licenc nácik se találnának rajta kifogást, mint a ZFS esetén. Szóval, a legtöbb kifogást, amit az SMF-el kapcsolatban hallottam: xml-ben kell neki a manifest fájlokat megírni.
De alternatívát eddig még nem hallottam, hogy mit javasolna bárki, az xml kiváltására. Lehet jönni json, meg yaml és hasonló agymenésekkel. De ez egy kötött fogású birkózás! Az xml-t lehet validálni, van rá szabványos megoldás. A többinél a validáció kb. kimerül annyiban, hogy be tudod-e tölteni parserrel.

Ezt nem ismerem. Tudsz egy linket dobni?

Szerk: Hülye kérdés. Akár rá is guglizhattam volna.
Felteszem erre céloztál: http://json-schema.org/

Szerk2: Rövid tanulmányozás után:
- Már a 6. draftnál tartanak, de final verzió még egy sincs
- Python implementációt látok 2 félét is. Az egyik LGPL-es és 2-es draftot tud. A másik MIT-es és 3-as meg 4-es draftot tud.

A kedvencem a JS. Ott szemmelveréssel 17 különböző implementációt sikerült összeszámoljak. Az ilyen számomra rendszerint annak a jele, hogy mindegyik másképp szar.

Kicsit csoportosítok, bocs :)

> Szerk: Hülye kérdés. Akár rá is guglizhattam volna.

Igen, ez az.

> - Már a 6. draftnál tartanak, de final verzió még egy sincs
> A kedvencem a JS. Ott szemmelveréssel 17 különböző implementációt sikerült összeszámoljak. Az ilyen számomra rendszerint annak a jele, hogy mindegyik másképp szar.

Valóban még csak draftok vannak, de ezt én nem érzem annyira fájónak. Illetve valahol de, csak ez nem a json schema szintjén baj, hanem egyszerűen a web környéke ilyen, lásd még html5, running standard vagy mi a fasz, effektív kb. a chromium HEADje a szabvány :) Az meg, hogy a jsben leftpadból is van 12, az inkább a javascript ökoszisztéma, mintsem a json schema milyenségének jellemzője.

(Mellékszálon hozzáteszem, hogy ezt legalább tartják, a hibákat, hiányokat a draftokban igyekeznek javítani, míg láttunk már nem egy rendes szabványt, ami mire az lett, már mindenki máshol járt, volt neki belőle majdnem pont ugyanolyan házi szaabványa, vagy vendor extensionökkel baszták szét az egészet. Vagy ugyan szabvány lett, de kb az összes szerzőt, aki áldását adta rá, el kéne tiltani minden billentyűzet 5 méteres körzetéből (hello snmp v3) )

> - Python implementációt látok 2 félét is. Az egyik LGPL-es és 2-es draftot tud. A másik MIT-es és 3-as meg 4-es draftot tud.

Az valóban fájó kicsit, hogy nincs még, de az igazság az, hogy 5 nem volt, a 6-7 meg nem nagyon tartalmaz semmit, ami miatt nagyon kaparnának vele szerintem (bár erősen nyugtalanító), ha jól rémlik a 8ban lesz talán olyan, ahol megpróbálják a legnagyobb fost kiüszöbölni, majd akkor talán :)

Maga a cucc egyébként használható, bár van neki néhány durván agyfasz dolga. Nyilván kb dictet, meg listát tud (lévén ugye json :) ), de pl. van megoldás mind változó hosszú listára, mind fix sorrendű elemekre, van mindenféle format meg type validáció, tud oneOf, anyOf, allOf kapcsolatokat, tud dependenciát (ha van foo, lenni kell barnak meg baznak is), ezekkel azért egy konfig filet le lehet validálni.

Az xml nagyon jó, mert sok mindent tud, viszont baromira nagyot esik pofára a "make easy things easy-n". Írni is szar, olvasni is szar, és parsolni is szar.

A követendő irány nem egy pontos definíció. Inkább a kevesebb szívás a cél, azaz csak egy stabil platform az igény. A systemd - nem kis ellenálás után meggyőztek. No, nem a systemd mellett, hanem "ez van" alapon. Számomra egy rendszernél a dokumentáció megléte és minősége a fontos, és abban a CentOS verhetetlen.

Ökoszisztéma - bla, bla. Persze az irányvonalban igazad van, de itt nem a világ szoftverének megírásáról van szó. Egy kis cégnél nincs kapacitás a multik által preferált fejlesztőeszközök használatához. Egyszerűen csak picike, szarköszörülő dolgok, meg házi használat forog fenn. Ahhoz meg elégséges, ha legalább az oprendszert nem nekem kell összetákolni. Ugye itt a hupon is van néhány társunk, aki esküszik a saját rendszerére, sőt egyedi rendszer fényezget. De amikor csak egy sokadlagos munkaeszközről van szó, akkor ilyen játékokra nincs lehetőség.

A többinél a validáció kb. kimerül annyiban, hogy be tudod-e tölteni parserrel.
Pontosan tudom miről beszélsz. Az xml egy nagyon jó dolog lehetne, ha rendesen használnák.
A legújabb eszközökkel pont az a bajom, hogy a szabványosság felkiáltással nem kellene mindent mindig használni. Gyakorlati péda: Egy műszer beállításához készítettem pontosan 2db nyomásmérőt. A végén interneten keresztül lehet elérni. Természetesen json-ba-ből. ;) Pedig azt az egyetlen számot rengeteg egyszerű formátumban át lehetne adni. Ok. Ilyen a rendszer. Csak nem én szívok órákat, néha napokat ezeknek a rendszereknek a hibáival. Az meg a munkát hátráltatja. Tán érted miről beszélek.

A kevesebb szívással egyetértünk. Talán csak az eszközkészletben látjuk másképp a dolgokat. Ha szőrszálhasogatni akarnék, akkor azt mondanám, dokumentáció terén számomra a FreeBSD a kedvenc eddig. Bár tény, a centos doksijait nagyon nem bújtam.

A systemd-ről még a könyvesbótban dógozva győztek meg a kollégák, hogy tetszik vagy nem, ez van. Szerencsére legalább a "saját" linux ezesetben ami ugyan rhel alapokra épült nem volt annyira szar, sőtt kifejezetten használható volt. De amennyire sejtem a customereik jó része is inkább az ő linuxukat használja, mint a redhat-ét.
És legutóbbi infóim szerint meg a felhőtortából még mindig ők szakítják a legnagyobb szeletet. Ez így együtt már picit túl van a hobbilinux szinten! ;-)
Nade ott meg minden apró "mütyűrre" volt külön csapat. Megtehetik.
Ugyanitt volt nagyon fasza CI/CD pipeline szoftvertesztelésre. Ugyanitt ha from scratch új projektet kezdtél, és pl. python-ban, akkor alap volt, hogy 3-as python. Meg akkor már az is illett, hogy legalább 70%-nyi tesztlefedettséged legyen. Azt se nézték jó szemmel, ha csak azért írod a unit teszteket, hogy a test coverage nőjjön. Legyen értelme a tesztnek.
Ha meg máshol bukik el a dolog: olyan fasza CI/CD rendszert azóta se láttam, mint amivel ott dolgoztunk.
Amikor látom egyesek mennyire ekézik és mennyire fölösleges lőcsnek tartják a teszt-írást, mindig mosolygok magamban egy jót.
-> Láttam már ahol tudják ezt jól csinálni! ;-)
Mondjul, valószínűleg ugyanez az oka, amiért nem félek haladni előre a technológiákkal: ha az tesztelhetőbb, jobb minőségű kódot eredményez, kisebb fejlesztési idő alatt, átláthatóbbat, stb. akkor miért is ne?

Ha valami fontos eltörik az api-n, vagy "belül", az még a devdeskeden kiderül. Ha integrációban törne el valami, akkor meg a pipeline-on fog a béta-gamma-akármilyen integrációs játszós környezet eltörni és nem fog továbbmenni a kód production version set-be.
-> lehet ezt jól csinálni.

Persze: félre ne értsd: nem kell "mindig mindent". Mielőtt kódot írsz, el kell végezni a házi feladatot. Ha elkezdesz értelmetlenül egy halom libet, meg minden szart behúzni, akkor a builded is lassabb lesz helyben. Aztán a pipeline-on is lassabban fogsz visszajelzést látni, hogy mi történik integrációban.
Mondanám, hogy a common sense egy jó mérce tud lenni. De ez is emberfüggő, hogy kinek milyen szinten van a common sense.

Az xml-es példára amit hozdtál... Sejtem miről beszélsz.
Lásd még: common sense.

Bár próbálsz úgy csinálni, mintha nem te lettél volna tufa hozzá, de azért csak sikerült beismerni, hogy bár szeretsz mindent alaposan megtervezni, most valamiért ehelyett r=1 módba kapcsoltál, basztál végiggondolni a requirementjeidet, és semmivel nem voltál alaposabb, mint a kritizált egyetemista, sőt, nagy egóval feltételezted, hogy az mégsem úgy van, ahogy le lett írva.

Úgyhogy már csak ezt az időtálló dolgot fogom még felhozni, mert ezzel továbbra is csúsztatsz, és mivel egyébként úgy nézel ki, mint aki ért ehhez a szakmához, még a végén valaki elhiszi neked.

Szóval de, a python eléggé időtálló. Valóban nem annyira mint az sh (?), de a python2 valamikor 2000ben jelent meg, 2020ig támogatott. A python2re írt kódok ebben a húsz évben változtatás nélkül kell fussanak (mert ha nem teszik, az bug). A python3 deklearáltan azért 3, mert meg akartak szabadulni némi 20 éves szeméttől. Python3 kb 10 éve van, szóval nem mondhatni, hogy lenyomnák a népek torkán a változtatást. Emiatt egyébként meglehetős nagy tételben van tooling a mindkét irányú átjárhatósághoz, illetve nem változott meg a nyelv teljesen, mindkettőn futó kódot lehet írni, szerintem (figyelj, ez egy személyes vélemény) bőven egyszerűbben, mint normálisan portolható shell scriptet.

Ehhez képest te abból vezeted le a nem időtállóságot, hogy találtál egy frissen írt programot, amit a szerzője deklaráltan python3ra írt, és ezért a te régi rendszereden az új program nem futott. (Elnézést, alapból nem futott, mert egy interpreter installnyira voltál tőle.) És amit valószínűleg azért írt python3ban, hogy mondjuk a tendenciákat tekintve még úgy 20 évig időt álljon. Szóval csúsztatsz, mint a franc.

Szóval a "Éppen most vagyok szopóágon egy python programmal. " helyesen úgy hangzik, hogy "Éppen most szopatom magam egy python programmal" ;)

Hogy nem annyira sikerült lenyomni a népek torkán a e-ast, azt valahol egyre jobban megértem. A hiányzó eszközök (amibe legutóbb botlottam: RRD hiánya) pl.

De van olyan eset, amikor a mindkét verzióval futtatható a kód, csak épp a 3-as alatt pontosan kétszer annyi idő kell neki. Annyi magyarázatot találtam, hogy megváltozott az integer változók kezelése és ez okozza a lassulást. Illusztrálva mindezt egy olyan példával, ahol a 2-est lebutították a 3-as működésére valamilyen "trükkel" és úgy már a 3-as volt picit gyorsabb. :)

Ha gyors scriptnyelv kell, használj perl-t!

Pythonban nem azért írunk scriptet, hogy maga a script gyors legyen, hanem azért, hogy maga a fejlesztési folyamat gyors legyen!
Pythonban könnyú olyan kódot írni és betartani olyan szabályokat, ami aztán könnyen olvasható utólag a kód.
Pl.: doksizás: python-nál egy függvény dokumentációja, egyből a fv elején van. Így könnyű utána a dokumentációt legenerálni a kódhoz, illetve, ha egy fv. dokumentációját keresed kód írása közben, akkor az ott lesz, ahol maga a kód is.
Sok kis apróság van, ami miatt pythonban könnyű olyan kódot írni, amihez akár ha te magad nyúlsz fél évvel később, akkor sokkal gyorsabban és hatékonyabban fogsz tudni hozzányúlni. Mint ahogy bárki más is, akinek hozzá kell nyúlnia fejlesztés, vagy épp hibajavítás céljából.

Sajnos már nincs meg: volt olyan feldolgozásom, ami pár soros mintaillesztés volt és bizonyos mintáknál a python2 ~50%-kal volt gyorsabb mind a perl-nél, mind a C-ben írt változatnál. A mai napig nem értem, miért. A regex motorja valahol annyira más volt, hogy ez lett a vége. :)
De mondom, a python3-nak van egy még nagyobb baja: sok, 2-re írt csomagot nem hoztak át alá.

Ha gyors scriptnyelv kell, akkor C-t szoktam használni. ;)
Jelen esetben a doksi maga a struktúra definíciója. Az ilyen bonyolult feladatot bármilyer csúnyán is programozok, a struktúra alapján könnyedén meg lehet érteni. Szóval az előny sehol.
Ha egy program fél évig működik, de utána hibát kell javítani...az olyan furi. ;)

Azt hiszem, mást értünk olvasható kódon és dokumentáción. :)
(egyébként nem szeretem a pythonos megközelítést sem, miszerint írd a kódba, mert ha tisztességesen dokumentálok, akkor sok esetben több a doksi által okozott "zaj", mint az érdemi kód - ezt persze egy normális IDE használatával el lehet tüntetni, de ha csak egy less az az "IDE"...)

Egy bonyolultabb feladatnál a program dokumentáció teljesen más lehet, mint a feladat leírása. Az előbbit már elég nagy assembler programnál is sikerült megvédenem, amikor azzal vádoltak, hogy kevés a comment. ;) A programot meg hiába érted, ha nem tudod mit kell csinálni. Erre is létezik védelem. ;) Konkrétan, néha azért nem volt dokumentáció, mert helyette ott volt a két cég közötti adatátadási szerződés és specifikáció. A program PONT annak megfelelően működött. :)
Vannak forráskódból dokumentációt előállító programok is. Az output általában megegyezik azzal, amit a fejlesztés megkezdése előtt a kezedbe kellett volna kapni. Hiába, sehol sincs igazság! :-D

Leírtam, nem értek hozzá. Most miért állítod, hogy nem ismertem el?
Neked is idemásolom: Az egész csak arról szólt, hogy az atomkutatásnál is bonyolultabb dir meglétének a vizsgálata mi a rossebért változott.
Az én régi rendszereim: CentOS 7.1 (naprakész) és FreeBSD 10.3. Mindegyiken a python 2.7 az alap.
És itt látszik a régies szemléletem is. Egy struktúra végigolvasásához bizonyára megfelelő az ojjektumorientált programnyelv, de szerintem ebben az esetben felesleges.
Elismerem, van olyan trend, amikor a 2x2 kiszámításához mindig a legújabb akármit kell felrakni. Sajnos igen gyöpös, vaskalapos, stb. vagyok, ezért az ilyeneknek nem dőlök be. ;)

Leírom akkor mégegyszer, mert nem érted: Nem változott. Egy dir meglétét pontosan ugyan úgy lehet vizsgálni python3ban, mint lehetett azt python2ben.

Ami változott, hogy a python3ban az 

os.makedirs(path[, mode])

(ami az 

mkdir -p [-m valami]

megfelelője egyébként (kb, mert a mode kicsit másképp működik), nem pedig a 

-d

teszté) kiegészült egy új opcionális paraméterrel: 

os.makedirs(path[, mode, exist_ok])

. Ez az új paraméter arra jó, hogy ha bekapcsolod, akkor nem kezd el hibát dobálni ha nem sikerült létrehozni a könyvtárat*, mivel ez egy viszonylag sűrű use-case. Ez egy opcionális paraméter, régi kódot nem érint, a viselkedés defaultja a régi viselkedés, a régi kódok működnek így, ráadásul pont ugyanez volt python2ben is. (Ok, itt csúsztatok egy kicsit, mert python2ben úgy látom, hogy még nem named paraméter volt, valószínűleg kompatibilitási okokból a 2.nagyonrégi, esetleg 1.mégrégebbi működéssel).

*És egyébként kretén módon nem tesz különbséget a "meg tudtam volna csinálni", csak már volt, "és a nem tudtam létrehozni" között, ami miatt egy kicsit kevésbé lesz használható

Annak azért örülök, hogy miután többen a földbe döngöltetek, és én vagyok a hülye, meg nem értek semmihez, de végül leírod ugyanazt, amit már leírtam. ;) Igaz, szerinted én nem értem. :-D
Mindössze arról van szó, hogy a script nyelvekben megpróbálják a kezedbe adni a rendszerhívást, de ezidáig sikertelenül, akár shell, akár php, akár javascript a tettes. Ezért látszik, hogy egyik esetben a program által megállapított hiba, a másik esetben gyakorlatilag a rendszerhívás hibája kerül elő.
Ráadásul olyannal is találkoztam, amikor a rendszerhívásnak megfelelő utasítás hiányosan paraméterezhető. Nem is marad más lehetőség, mint gondosan körbeprogramozni a hiányt.
Amit "egy viszonylag sűrű use-case-nek" tartasz, arra csak annyit tudok mondani, hogy lehetne pontosabban is programozni. Pl. először egy stat() meghívásával.
Éppen ezért nem "kretén módon" nem tesz különbséget. Csak nézd meg az mkdir(2) és a stat(2) mant-t, és rögtön megérted. Teljesen logikusan az eltérő tevékenységekhez eltérő értékkészletű ERRNO tartozik, miközben a stat() sikeres lefutása esetén az st.mode alapján kideríthető, hogy mi az az ojjektum, ami miatt sikertelen lehet az mkdir.
De hát ez az, amit bármilyen script nyelvben - hogy kényelmeses scriptelhessél ;) - nem lehet egyetlen utasításban elintézni.

Nem. Te még mindig azt állítottad, hogy az az ellenőrzés a python3ban másképp van, mint python kettőben, miközben össze vissza kevered az almát a körtével.

Aztán meg össze vissza terelsz már megint, meg előadod, hogy szerinted hogy kellene működnie, meg kinek mit kéne leprogramozni, meg már megint felülsz a magas lóra, hogy és elkezded megmagyarázni, hogy mit csinál a stat meg az mkdir, mert azt mi bizonyára nem tudjuk, ami biztos nagyon érdekes, csak semmi köze nincs a témához.

Elismerem a tévedést. A vizsgálatot a python3 és python2 tökegyformán, inkorrekt módon és hiba esetén inkonzisztens üzenetekkel valósítja meg.
Nekem ez nem tetszik, de azt, hogy erről miért ne lehetne véleményem, azt végépp nem értem.
Bizonyára ismerted az összes rendszerhívást, csak ebben az esetben nem tudtad értelmezni. ;) Különben miért írtad volna, hogy "kretén módon nem tesz különbséget". Ha elmagyarázom a magas lovamról, akkor meg az a baj. Ezt sem értem.

Látom, még mindig képtelen vagy felfogni, hogy az a függvény a pythonban mi, és mire való.

Meg egyébként azt is, hogy ennek azon a szinten semmi köze nincs a rendszerhívásokhoz, meg azoknak az atomic voltához. Ha van egy kapcsoló, ami azt mondja, hogy exist_ok, akkor az akkor ne fusson hibára, ha exist, akkor meg továbbra is fusson, ha más miatt nem sikerült, és keresztbe leszarom, hogy mit kellett ehhez megnézni a statból meg az E_-kből. Ugyanis baszottul nem érdekel, azért használok ilyen kényelmi metódusokat, hogy ne kelljen ezzel szenvedni. Majd ha szükségem lesz rá, akkor kitúrom a pythonból a baromi inkonzisztens módon egy az egyben feltolt errnokat :)

> Helyesen: letöltöttem egy programot.
Mi a különbség?

> Semmi ilyet nem állítottam.
Aha.

> Azt viszont igen, hogy egy dir elkészítéséhez teljesen felesleges a python tetszőleges verziója. (Értsd nincs előnye, viszont hátránya van.)

Pl ezt ferdíted. A program, amit letöltöttél, nem csak egy dirt csinál. Az írója valószínűleg egyéb okokból választotta a python3at, és ha már ezt választotta, akkor használta a vele elérhető eszközöket, és nem írta ki kicsi kezével azt, amit a már valaki más leírt. Ettől természetesen még a régen megírt programok működtek volna.

> Abban az esetben, ha a stat() és mkdir() cifrázódik ennyire, akkor nem jó ez a nyelv, vagy fiatal volt a program írója.

Vagy nem lelte perverzióját abban, hogy kézzel írja le ezeket, mikor valaki már megtette azt a szívességet neki, hogy csinált egy legyenittegydirhamégnincs() függvényt. Pl mert inkább a valódi feladatán dolgozott volna.

továbbá igazán édes, hogy a python kompatibilitás részét, amit úgy hiányoltál elegánsan ignorálod.

Mellesleg hozzátenném, hogy aztán máshol a szálban, meg azon siránkozik, hogy " Sajnos az mkdir nem rendelkezik force opcióval.", de a hülye python programozó használni merte, mert neki volt. Igaz, nem (annyira) elbaszott volt a neve. :)

Kicsit következetlenek az érveid.
Leírnád kérlek, mert már nem tudom követni: SZERINTED hogyan kellene a scriptnyelveknek működniük? Egy az egyben a programozó kezébe adni a rendszerhívást (de akkor miért jösz folyamatosan úgy a stat()-al, mintha még senki nem hallott volna róla?), vagy egy lépéssel a programozó előtt járni, és a programfejlesztést segítő módon kialakítani az api-t?

Itt aztán már lehet a részleteken vitatkozni, hogy a "felturbózott" mkdir()-wrappernek kell-e statolnia, vagy milyen módon kell a hibát visszaadnia, vagy a hibakezelésnek hogyan kellene történnie. De az ilyen dolgokban, meg Bob bácsit veszem mércének vélemény szempontjából, ha nem bánod. Ezen a területen úgy vélem, elég nagy a neve a szakmában ahhoz, hogy az ő szava legyen a mérce.

Bár néhány rendszerhívást már elég régen kivezettem scriptben használhatóra, de úgy nézem a gnu fejlesztői szép lassan felzárkóztak, majd jócskán túltettek rajtam. :-D Szerintem ők a hülyék. ;)
Bárkit is tartasz mércének, az sosem árt, ha a hibaüzenet megjelenése egységes. De ezt is megbeszéltük már...

Ize.. altalaban akkor van baj, ha a _visszafele_ kompatibilitast torik, nem az, amikor elorefele.
Ez a legtobb nyelvnel/OS-nel egyebkent igy van. Ha fogsz egy 9-es Javat kihasznalo programot, az nem fog 1.4 alatt fordulni/futni. Egy C++11-es kod nem fog 2-es GCC-n fordulni. Illetve ha bejott valami uj API Win10-en, az 3.1-en nem fog mukodni.

Nagyon sokszor a fejlesztok nem kepesek elore megmondani, hogy nehany verzioval kesobb milyen feature-ok fognak megjelenni az adott rendszerben, es erre nem tudjak felkesziteni a korabbi verziot. Ha fel tudnak kesziteni, akkor mar a korabbi verzioban is kiadhatnak azt a feature-t (es akkor az az elottinel torne).

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Én sem szeretnék olyan magas felkészültségű szakemberrel dolgozni, aki egy script és egy példa között nem képes különbséget tenni.
A gyengébbek kedvéért a script ún. magic number-rel kezdődik.
Pl. "#!/bin/sh", vagy régebben ":" (true).

Olyan rendszerhez amit én írtam nem igazán tudnál hozzányúlni, mivel teljesen automata módon szoktak működni. Az meg végképp megengedhetetlen, hogy egy olyan ember nyúljon bele egy 4-6000 soros scriptbe, aki egy sort sem képes felismerni. :-D

Akkor maradjunk abban, hogy a szemléletőteszközöket is gyengén választod meg.

Első körben még csak && echo "Van dir." volt a példád vége.

Aztán mikor számonkérték, akkor hirtelen || mkdir $dir lett a vége.

Azt hiszem, no offense, megállapíthatjuk, hogy nem vagyunk kompatibilisek.

Ettől még lehet, hogy tudnánk érdekes war story-kat mesélni egymásnak egy-egy sör mellett.
De ilyen pongyola / slendirán script-stílussal nem szeretek találkozni. Legalábbis olyan esetben nem, ha az elkövető "fő-nagymegmondóember fejleszőnek" van a teoretikusan közös munkahelyen kikiáltva, akinek a szava ott dolgokat dönt el.

Barátom! Bizonyára borzasztóan jól szkriptelsz, de valami buta megmondóembert a fejedre ültettek. Ezért talán lelkileg is sérült vagy. :(
Nilvánvalóan, ha odaírom: "Ez nem egy auditált szoftverrendszer, csak egy fél sor péda. Kéretik NEM belekötni!" - nos, akkor is belekötnél. Sajnos túllépted nem az ésszerűség, hanem az értelem határát is.
Ha lennél szíves visszanézni: 

[ -e $dir ] && [ -d $dir ] && echo "Van dir"

https://hup.hu/node/158046?comments_per_page=9999#comment-2201092

Ez a dir meglétének megállapítása. Nem program, csak a szerintem elégséges műveletek.
Nem "számonkérték", hanem a következő volt a kérdés: Szerinted van olyan directory, amelyik ugyan directory, de nem létezik? Kell oda az a -e?
https://hup.hu/node/158046?comments_per_page=9999#comment-2201222

Erre írtam egy olyan (másik) példát, ahol hiányzik a -e vizsgálat, ezért hibát okoz. Ez sem program, hanem csak a lehetséges hiba szemléltetése.
https://hup.hu/node/158046?comments_per_page=9999#comment-2201506

Ahhoz, hogy megértsed az első példát, ismerned kell a stat(2)rendszerhívást.
- A -e vizsgálat true eredménye azt jelenti, hogy a stat() nem futott az error ágra, amikor errno=ENOENT.
- Ezek után meg lehet vizsgálni a stat.st_mode értékét, hogy az értéke S_ISDIR makróval.
Ezért ez a precíz megállapítása egy dir meglétének.

Egy másik példával magyarázod az eredetileg redundáns vizsgálatodat. A

[ -e "$dir" ] && [ -d "$dir" ]

pontosan akkor lesz igaz, amikor önmagában a [ -d "$dir" ] igaz. Létező file esetén az első vizsgálat ugyan igaz, de a második hamis, így ez ugyanazt eredményezi, mintha az első vizsgálat meg sem történt volna. Arról nem is beszélve, ami shell scriptekben mindig probléma, hogy a műveletek nem atomikusak: mi van, ha a két vizsgálat között jön létre az adott nevű file, vagy könyvtár, vagy múlik el onnan?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hátha örülsz neki, ezért egy harmadik példával fogom magyarázni. ;)
Az előző példához hozzátartozik: "Ez nem egy auditált szoftverrendszer, csak egy fél sor péda. Kéretik NEM belekötni!"

Íme, az thread indító program működése: 

/var/mikrotik: touch out2
/var/mikrotik: ROSbackup.py unpack -i MikroTik180223140500.backup -d /var/mikrotik/out2
** Unpack Backup **
RouterOS Plaintext Backup
Length: 31338 bytes
Extracting backup...
Traceback (most recent call last):
  File "/root/bin/ROSbackup.py", line 379, in <module>
    main()
  File "/root/bin/ROSbackup.py", line 372, in main
    unpack(args.input, args.directory)
  File "/root/bin/ROSbackup.py", line 271, in unpack
    files_num = unpack_files(input_file, length, unpack_directory)
  File "/root/bin/ROSbackup.py", line 145, in unpack_files
    create_write_file(path + name + '.idx', idx)
  File "/root/bin/ROSbackup.py", line 64, in create_write_file
    os.makedirs(os.path.dirname(path), exist_ok = True)
  File "/usr/local/lib/python3.6/os.py", line 220, in makedirs
    mkdir(name, mode)
FileExistsError: [Errno 17] File exists: '/var/mikrotik/out2'

/var/mikrotik: rm out2
/var/mikrotik: mkdir out2
/var/mikrotik: ROSbackup.py unpack -i MikroTik180223140500.backup -d /var/mikrotik/out2
** Unpack Backup **
RouterOS Plaintext Backup
Length: 31338 bytes
Extracting backup...
Directory  already exists, cannot extract!

Ennek alapjan - hibaüzenetek nélkül a lehetséges kód (szerinted): 

[ -d out2 ] && exit

Ezzel csak azt tudod meg, hogy már van ilyen dir. Vagy file. Vagy valami egyéb. :-D

Az olyan kódot sem szeretem, amikor meg lehetne valamit vizsgálni, de helyette engedem hibára futni a kódot: 

[ -d out2 ] || mkdir out2 || echo "Elfelejtettem megvizsgálni a -e lehetőséget."
mkdir: out2: File exists
Elfelejtettem megvizsgálni a -e lehetőséget.

Tehát a fél sor példa a hivatkozott python programmal megegyezően a dir és nem más meglétének vizsgálatához elégséges feltételeket tartalmazza, de nem tér ki az egyéb lehetőségekre. Ha a példából production code készül, akkor az oskolában tanultak szerint (asszociatív, kommutatív és disztributív tulajdonságok), no meg a kívánt működés szerint szépen megírhatod a programot. Amely tartalmazni fogja mindkét vizsgálatot ahhoz, hogy az mkdir parancsot hiba nélkül futtathasd, avagy kiírhasd pontosan a hiba okát.

Erre egy lehetséges példa: 

[ -e out2 ] && [ -d out2 ] &&
{
	echo "Directory  already exists"
	exit
}

[ -e out2 ] && [ -d out2 ] ||
{
	echo FileExistsError
	exit
}
mkdir out2

Ezzel sikerült előállítani az eredeti program logikáját. Bár a trehány hibavizsgálatot nem teljesen, hiszen az eredetiben az egyik hibát a python dobja, a másikat meg a programozó. ;)

És igen! Van olyan eset, amikor van létjogosultsága az igazságtábládnak. De csak az első vizsgálatnál. Ennek ellenére a fenti kódot olvashatóbnak tartom.

Igaz, kivételesen nem teszteltem.
De sajnos a második hibás. :-D

Helyesen: 

#!/bin/sh

[ -e out2 ] && [ -d out2 ] &&
{
        echo "Directory  already exists"
        exit
}

[ -e out2 ] && [ ! -d out2 ] &&
{
        echo FileExistsError
        exit
}
mkdir out2

rövidebben

#!/bin/sh

[ -e out2 ] &&
{
        if [ -d out2 ]
        then
                echo "Directory  already exists"
        else
                echo FileExistsError
        fi
        exit
}
mkdir out2

Megengedve, hogy a "File" bármi más, csak nem dir.

Hááát...
Ha root-ként részegen szétcsapod a rendszer, akkor arra senki nem tud megfelelő védelmet kialakítani. ;)
Megint egy kis rutin mese következik. Egy programnál az sem mindegy, milyen hardveren fut. Vagy sok olyat írtál, amikor nem a symlinket, hanem az io errort kezelted. És ha hiba lép fel diszk íráskor, akkor mit kell tenni? Különösen akkor, amikor egy több száz processzt futtató, éjjel-nappal üzemelő daemon a program. Avagy jártam már úgy, hogy az előbbi program 120db diszk irás/olvasás közben, vfs driver hiba miatt megállt a kernelben. (Halkan közlöm: Azt a gépet NEM én üzemeltettem. :)) Vagy arra mit lépnél, amikor a kolléga - egy félreértés folytán - kölcsönadta a külső diszk kábelét. Azon a diszken volt az összes munkaterület. :-D
Azért tudok 25 éve megbízható rendszereket készíteni, mert a hibalehetőségek jó részét lekezelem.(Hardverfejlesztő voltam (és már megint!) és elektromechanika vezérléssel foglalkoztam, így a hibakezelés akár a program 70%-a is lehetett!) A rendszerállapot a megfelelő checkpointokon kiírható, így bármikor elmehet a villany is, mind az 1000 job visszaállítható egyetlen paranccsal egy ismert állapotba. Egy ilyen felhasználói interakciókkal, vagy mi van ha symlink, soha nem találkozom, mert megtervezett, megfelelő jogosultságokkal és hierarchiával kialakított rendszert készítek. Még a munkaterületeket is a program csinálja, hiszen egy ember úgy is eltévesztené. Na, ezért sokkal könnyebb automatikus működésű rendszert készíteni.
De a hardverrel kezdtem. 20 év AIX után nehéz volt pécére átállni! Ott hardver felügyelet VAN, és teljesen más szinten, mint amit ki lehet alakítani egy linuxos - szervernek nevezett - pécén. Nem szép dolog, de kihasználtam azt, hogy egy diszk sérülését a tükörben lekezeli az oprendszer. (mi meg ültünk a kocsmában) Ha kezelhetetlen a hiba, akkor még a második diszk meghibásodása előtt ki tudjuk cserélni. (és ülünk a kocsmában)

Visszakanyarodva a rugózást indító python programocskára. Az összes tudományából csak a MikroTik router backup formátumának a struktúrája - mint know-how - a lényeges. A periodikus mentéseket szét kell szedni [dir+]dat+idx darabokra, és az egyes darabokat összehasonlítani az előzővel. Ha nem változott, akkor ezt az új mentést el lehet dobni. Ha változott, akkor elegendő - mintegy diff-ként - a változást menteni. (Sajnos ezen a cuccon a konfig változás triggerelését nem lehet egyértelműen megoldani.) Az itt előforduló <<100kb fájlok esetén mindez memóriában elvégezhető. (Annak ellenére, hogy ez egy 256MB RAM + 1GB SSD + 16 GB CF képességű gépen fog futni. Így aztán sem mkdir sem symlink nem fog szerepelni a feladatban. ;) Sajnos C fordítót sem tudtam még felrakni, de a gawk és néhány egyéb program szépen kezeli a bináris adatokat, így ezzel sem lesz gond.

Arról nem is beszélve, ami shell scriptekben mindig probléma, hogy a műveletek nem atomikusak: mi van, ha a két vizsgálat között jön létre az adott nevű file, vagy könyvtár, vagy múlik el onnan?
Nem vagy egy kicsit paranoiás? ;)
Nyilvánlvalóan célszerű felkészülni arra is, hogy aljas módon feltöröm a rendszeredet és két assembler utasítás között belvágok egy baltát. ;)
Ha a fenti eset nem fordulna elő, akkor - elég sok operációs rendszerben - léteznek lock és interprocess kommunikációs módszerek. Az alapismeretek megszerzéséhez érdemes elolvasni pl. ezt a könyvet. Én ennek alapján fejelsztettem ki egy saját lock mechanizmust - már vagy 25 éve. Segítségével akár több száz processz tudja írni-olvasni a script-ből ugyanazt a fájlt, vagy adatbázishoz fordul, esetleg webes letöltést szolgál ki.

Persze azóta a GNU is kitett magáért. Sok olyan dolog készült, amit 25 éve még nekem kellett megírni. A régen írt lock túlságosan "hard", a komolyabb terheléseknél visszafogja a rendszert. Ezért áttértem az flock(1): Manage locks from shell scripts használatára. Legnagyobb bánatomra havonta néhányszor "szalajt". Igaz, a terhelés 56M process/nap - és kb. 10-15 process/lock, azaz elég sokszor fut. Teljesen triviális esetben, ha az flock-ot visszacserélem a saját lock-ra, akkor a hiba megszűnik. Nem tudnám eldönteni, hogy az flock, vagy a régi debian kernel hibája. :(

A részletes magyarázat: https://hup.hu/node/158046?comments_per_page=9999#comment-2201695
Működő példa, ha elhagyod a -e vizsgálatot: https://hup.hu/node/158046?comments_per_page=9999#comment-2201506

Természetesen, ha nem cél az mkdir végrehajthatósága, akkor elegendő lehet a -d is. Persze ez azért a ritkábbik eset. ;) Sajnos az mkdir nem rendelkezik force opcióval.

Azt hiszem nem ment át, mire való a Posix!

Ha hordozhatóra írsz valamit, akkor az egyben időtálló is lesz.
Ha megírsz ma egy scriptet úgy shell-ben, hogy az jól lefut Linuxon, Freebsd-n, AIX-on, vagy épp valami lelet 8-as Solarison, mert csak olyasmit használ, és csak olyasmire épít, amit és ahogyan a posixben definiálnak

AKKOR

biztos lehetsz benne, hogy az a script működni fog neked a systemd és más pötteringátkokkal szájbatekert 38.04 LTS buguntun is. Ha egyáltalán lesz még akkor olyan.

Míg amit most megírsz python3-ra, az nem biztos, hogy el fog neked menni majd a python4-en is. Amellett, hogy jól lehet programozni benne a pythonnal pont ez a bajom. Egyszer kellett volna megtervezni, és akkor jól! Meg nem olyan ro...dt szar lassúra.

Btw.: Amit egyszer megírtál 4-es perl-ben, az nagy valószínűséggel még a 6-os perl-ben is elmegy, ha nem valami nagyon specifikus lib-et használsz, amit nem portoltak.
És ugye, pont itt jön be a problémakör, az összes programnál, ami libraryket kínál neked: sokszor egy-egy lib api-ja olyan sűrűn és inkozisztensen változik az idők folyamán, hogy egy-egy maint-nek aztán elgurul a gyógyszere és jó kőműves módjára azt mondja, hogy ........... és evvel részéről a munka befejezettnek tekinthető

Hát én valaha abban a hitben éltem, hogy a perl az kompatibilis minden platformon önmagávall, mert ezt olvastam a könyvekben.
VMS-en kellett valamit barkácsolni, egy része ment DCL-ben, de a nagyját betoltam perlbe, mert milyen izgi... :) (fasság volt, de akkor jó ötletnek tűnt)
Eljött a nap, hogy irány valami linuxos cucc, mert a VMS-t kirántják alóla. Hát megizzadtam, mire linuxon elindult a perl szkriptem. Amire nem emlékszem, hogy a VMS-en futó perl még 4-es volt-e vagy már valamelyik 5-ös.

Python: beírtam ellenpéldaként a python2 -> python3 átállás szépségeit, utánáa vettem észre, hogy ezt már te is részletezted.
Kezdem kicsit úgy érezni, hogy kellőképp tökönszúrtam magam a pythonnal: 2.7-et ne használjak, mert rövidesen out of support vagymi, a 3.x-re meg n+1 cucc nincs áthozva (például rrd-tool, egy tutorialban említett gobject, amivel gtk-s alkalmazásokat lehetne állítólag thread safe-fé tenni stb.)

A perl védelmére felhoznám, hogy a platformok közötti differenciák is elég jól dokumentálva vannak a doksijában.

Így látatlanban kicsit nehéz elképzelni olyan szitut, hogy ez a perl hibája.

Utólag, ha valamibe belefutok, hogy egy scriptem nem működik valami más rendszeren, szeretek a valódi root cause végére járni. Olyankor rendszerint kiderül, hogy én nem vettem figyelembe valamit. Pedig... van pár én un*x a hátam mögött.

A posix mint szabvány, ezért is tetszett meg nagyon: ha CSAK olyan elvárásokat támasztasz, ami abban definiálva van, akkor az működni fog.
Nyilván az ellenoldala: shell scriptre nehéz (van egyáltalán ilyen tool?) unit teszteket írni.

Nem mondtam egy szóval sem, hogy nem voltak dokumentálva.
De nem is úgy ment, hogy átmásoltam a régi szerverről az újra, oszt' jónapot, pedig a feladat nem változott, csak...
Fájlok elérési útvonala "$1$DKA100:[DATA]input.txt" helyett "/mnt1/data/input.txt" jellegű változtatások, amikre az eredeti verziónál a fene se készült, eleve úgy indult, hogy amíg él, ez már VMS-en marad. (azóta szerintem már a HPUX is kiment alóla, ahol némi linuxos közvetítéssel futott)
(mondjuk az is csoda volt, hogy a VMS-re sikerült azt a perlt felerőszakolni :) )

Egy update a korábbihoz: az a python3-gtk-threadsafe dolog nem igaz teljesen, csak totál másképp néz ki, mint azt az eredeti ismertetőben leírták. :)

Valami ilyesmire tippeltem volna.
Egyébként az a szép, hogy ha jól sejtem, akkor az ilyesmiben még tud is segíteni a perl, ha használod a saját rutinjait az elérési utakkkal kapcsolatban.

Fejből meg nem mondom, de kb. mintha a python-ban is lenne valami os.path.join(), meg mintha valami ehhez hasonló lenne perl-ben is.
Ha meg, ami konfig, kiszervezed konfignak, és nem hardkódolod bele a kódba, akkor...

Persze az évek és szopások árán tanulja meg az ember az ilyesmit, hogy egyszerűbb az elején egyszer jól megírni és 20 másodperccel többet rászánni, mint összecsapni valami worksforme kódot, és utána meg egy nagyobb változásnál vakarni a fejet.

A python ilyen oldalról mondjuk nagyon jó: az interaktív shell-jét iszonyatosan tudom imádni!
Ott az "apróságokat", amivel kapcsolatban bizonytalan vagyok le tudom tesztelni.
Megírom a függvényt.
Megírom rá a unit tesztet.
bb test
Majd hozzá lehet ragasztani a többi kódhoz.

Namost ezt olyankor, mikor valami tegnapra kell, az op.rendszer önmagában nem tudja, perlt meg akkor látsz először... :DDD

Egyébként a példa rossz volt, mert pont az elérési utakkal nem nagyon volt lehetett gond (Úgy emlékszem, csak a VMS logikai neveket kellett linuxos környezeti változókra cserélni, ezek véletlenül jól voltak benne megcsinálva, arra kényszeresen ügyeltem, hogy VMS-en mindent, amit lehetett, logikainévvel hivatkozni), csak a konkrét problémákra nem emlékszem (15+ éve volt), de a színvonala kb. ez a szint. Doksiban egyértelműen le volt írva, hogy mit, hogyan, csakhát nem lettem sokkal gyakorlottabb a szkript megírása és költöztetése közti pár év alatt a perlben. :)

És igen, pythonban a shell, különösen így, hogy szinte nullán vagyok azzal is, a beépített helpjével, elég nagy segítség. Ruby-val volt egy nagy csalódás, hogy az irb helpje messze nem tudja azt, amit a python.

Nem annyira privát. Bennem is ott volt, hogy az a regexp illesztés, ami a világ egyéb nyelveinek szolgált mintául, a python dimenzióiban legyen ugyanannyira gördülékeny, de be kell ismerni, hogy ez a nyelv nem az, amelyben a munkamix úgy áll össze, hogy sztringmanipuláció + apró, ezért aztán nincs is rajta olyan kitüntetett figyelem.

Akkor fogalmazzunk másképp: esetemben ez főként a privát hülyeségem eredménye. :)
Én úgy értettem azt, amit gyu írt, hogy aki képes megtanulni egy perl szintaxist a helyenként a brainfuck nyelvre emlékeztető, "könnyen" memorizálható elemeivel, annak egy python már könnyedén megy.

Vallomás:
amikor először láttam perl kódot, azt hittem, hogy ez direkt valami nagymenő-only nyelv, és rendesen betojtam. Az volt a szerencsém, hogy a sokkban vagdalkozva véletlenül rábukkantam az a2p konverterre, ami az awk szkripteket perl kódokra "fordítja".

Pár napnyi a2p-vel rosettásás után (jut eszembe: http://www.rosettacode.org/wiki/Rosetta_Code) már azt mondtam, hogy bár minden programnyelvet nyelvész írna.

( asch v | 2018. 02. 22., cs – 01:11 )

Pont ma mondtam egyik kollegámnak, hogy a Java a kedvenc szkriptnyelvem. Mivel abban vagyok a legjobb mindent abban írok. De azért fájlok másolgatására, csomagolás készítésére, ilyesmire használok minimális szkripteket is. Sőt, ma például generáltam szkriptet Java-ból. De csak parancsok egymás után, a generált szkriptben nincs semmi vezérlés.

Mivel nem ismerem készségszinten folyton rá kell keresnem, hogy mi hogy van. Meg nem is nagyon tetszik őszintén szólva. Ezért mindent ami egy kicsit is összetettebb másban írok meg. Manapság a memóriahasználat meg ilyenek nem nagyon számítanak, pláne hogy fejlesztői gépre, meg build szerverre írok csak ilyesmit. Azokban meg legyen RAM.

( lx | 2018. 02. 22., cs – 01:18 )

Persze, hogy írok. A szerelem első látásra az a pillanat volt, amikor megláttam, hogy a Norton Batch Enhancerrel valamennyire használhatóvá tett command.com hol tart a bsh-hoz képest.
De már nem minden áron bármit.

Kb. az dönti el, hogy sh vagy valami más lesz-e a nyelv, hogy inkább egyéb programok összeszigszalagozásáról van-e szó, viszonylag kevés saját logikával, vagy ellenkezőleg.

Ahol intenzív tömbhasználatra és sok aritmetikai vagy sztringmanipulációs műveletre van szükség, ott legfeljebb ha wrapper lesz a bashből, mert ezekkel megtűzdelve a bash kód olvashatósága alulmúlja a direkt rosszindulatúan írt perl kódét, miközben a kényelmét meg sem közelíti.

Kivételt talán a midnight commander menüfájlja jelenti, amibe bármilyen okádékot képes vagyok beírni, ahelyett, hogy csak behívnék egy egyéb nyelvű szkriptet.

( iattilagy | 2018. 02. 22., cs – 07:13 )

Én inkább pythont használok ha saját script kell, nagyságrendekkel szebb a syntaxisa mint a bashnek. A sima bash scriptek szerintem ritka ocsmányak és nehezen olvashatók.

Tudnál példát a szépre?
Ezt a topicot ez ihlette: https://hup.hu/node/158009
Valami horror... alias brainfuck ;)
Szépen megírt shell szkriptet láttam, megkockáztatom: írtam is.
De olyat, ami szép, olvasható és kihasználja a bash mélységeit... olyat nagyon szeretnék látni.

Büszkeségem: https://github.com/balabit/syslog-ng/blob/master/contrib/syslog-ng-debun

Bár, egy ideje kikerült a kezem alól, de azért az is valami, hogy leraktam olyan alapokat, amiket aztán tudtak a lejegyzetelt ötleteim alapján továbbvinni a kollégák, meg aztán a többi saját ötletüket beletolni.

szép. én két dolgot változtatnék rajta, cd-ket kiszedni (mi garantálja hogy a cd sikerült és a következő parancs ott fut le?)
pl cd $dir ; find . helyett find $dir,

binárisokat teljes elérési úttal használni (/bin/rm /bin/df stb. ki tudja az aktuális könyvtár vagy a ~/bin rajta van-e a PATH-on és az odatett rm/df mit csinál).

pl mi értelme van egy vmstat=vmstat-nak?

ezen kívül az már egyedi preferencia hogy a változónevek nagybetűvel legyenek és mindenhol egységesen ${opt} legyen ha nem is szükséges az adott helyen cd ${tmpdir} vs printf "$tmpdir". valahol echo (shell echo, /bin/echo?), valahol printf van sima kiíratásra.

A cd $dir ; find .
és a find $dir
nem ugyanazt a kimenetet szolgáltatja.
Emiatt meg aztán még egy plusz filter childet ráhúzni a find-ra overkill lenne.
Ami elővigyázat megtörténhetne: if-be tenni azt a részt, és vizsgálni, hogy [ -d ${confdir} ]

Binárisok, hogy nem teljes path-al vannak így pont jó, mert megtartja a hordozhatóságot!
Ha a root beteszi a ~/bin -t a path-ba, avval sem látok problémát. Ha neki az szimpatikusabb, mint a /usr/local/sbin, ő dolga, ameddig POSIX compliant replacement tool-okat tesz oda.
Ha meg nem elvárt dolgot csinál a kedves root elsőnek kiértékelt df v. rm parancsa, akkor más script (pl. systemd unit) is futhat hibára -> elsőnek el tetszik majd azt hárítani, mielőtt syslog-ng related hibáról tetszik panaszkodni.
Ha meg szándékosan valami patkolt rm és df parancsa van a path-ban (vagy internal functionként .profile-ból betöltve) előbb a kiértékelésben, pl. audit okokból, én meg bedrótozok egy /bin/df -t, miközben meg amúgy lehet, hogy /bin -je sincs, noss...
Gondolom, innen már érthető. -> Ha egy hordozható valamit írunk, ne akarjunk okosabbak lenni a rendszernél, és ami még fontosabb: ne támaszkodjunk feltételezésekre.

Vannak benne olyanok, amiket már valószínűleg nem én tettem bele.
Ahogy látom, a fájl át lett nevezve, és evvel egyidejűleg a verziótörténetet is kinyírták a tranzíció alkalmával.
Én pl. biztos nem írtam volna le ilyet: echo ""
Én printf "\n" -t írnék. Az a portábilis írjunk ki egy soremelést megoldás.

De ez is, már gyanúsan nem a saját stílusom, vagy csak úgymaradt valami PoC jellegű kód:

distpkgoffile () {
local tmpfile=${tmpdir}/distpkgoffile.$$.tmp
rpm -qf $1 >$tmpfile
read x < $tmpfile
rm $tmpfile
echo "$x"
}

simán lehetne ennyi: rpm -qf $1
És akkor még mellékhatás sincs $x -el.

A ${opt}-al nem vágom, mire is gondolsz.
Az értelmetlenül csupa nagybetűs változónevektől feláll a szőr a hátamon.
Nem javítja (szerintem) az olvashatóságot.
Rövid, és biztosan egyszerű szöveg kiíratásra jó az echo.

A vmstat=vmstat -nak önmagában nincs sok értelme.
Viszont minden esetlegesen architektúraspecifikus parancs ki lett téve változókba. Ennyi az értelme.
Pl. solarison oob valószínűleg snoop-od van, nem tcpdump-od. A filter szintaxis tök ugyanaz, de pár paramétert másképp kell neki megfogalmazni mint a tcpdump-nak.
És akkor máris van értelme, még ha nem is ebben a konkrét esetben.
Itt jön be az, hogy ha esetleg fejlődik, és később valami eltérés van, akkor ezt a változót más architektúrán (architektúra alatt most következetesen a komplett stack-et értem, nem a hw-architektúrát értem!) fel lehet tölteni más tartalommal.

amúgy echo vs. printf viszonylatban: posix a printf-ről garantál csak következetes viselkedést. Ezért is nem szeretem az echo-t, csak egyszerű, fix szövegek kiíratására használni. Rövidebb.
Ne felejtsük el, hogy a kód, akkor jó, ha nem csak megbízhatóan azt csinálja, amit elvárunk, de hozzá is lehet könnyen nyúlni! Az rendszerint egy élő valami! Tökéletes kód nincs, csak aminek leálltak a fejlesztésével.

tévedés. pythonban is lehet rettentő ocsmányat elkövetni.

Futottam már bele olyanba, amikor a raidvezérlő cli-jének kétféle kimenete volt: humánnak formázott txt, illetve json.
fejlesztőkön, CR-on, mindenen keresztül bement úgy a kódbázisba a gyakornok kódja, hogy a humánnak formázott textual output dolgozta fel a következő képpen:
Fogta a teljes kimenetet. Splitelte a '-+\n' regexp mentén, ha jól emlékszem. (Vagyis olyan sorok, amikben csupa - jel van.
Majd ebből a tömbből kiemelte a 2. elemet. (Ebben volt a táblázat a diszkekről)
majd ezt széttördelte sorokra.
majd jött a for ciklus a sorokra, amiben
feltétel, az egyik mező szerint
teljesülés esetén push egy tömbbe egy másik oszlop tartalmát

Na ez kb. olyan szinten ronda, hogy még shell scriptben is szebben le lehet írni ezt a részt!
És akkor még nem beszéltünk arról, hogy miért nem olvasta inkább be azt a rohadás json formatted outputot, minek szenvedett a textual output feldolgozásával?

A whitespace szerintem sokkal szebb, mint a pájton: nincsenek benne mindenféle randa betűk meg számok... :-P
A binugzhuszárok által ekövetett ocsmányságok, vagy épp a DOS/Windows világból érkezett bat meg cmd guruk által leírt katasztrófák persze, hogy olvashatatlanok lesznek, mert nem tanulták meg, hogy hogyan lehet szép, érthető, jól formázott scripteket írni.

( zrubi v | 2018. 02. 22., cs – 15:23 )

Szerintem ezt attól kell(ene) függővé tenni, hogy a végeredményt hol kell majd futtatni.

Pl:

- egy "szappantartó" routeren, még bash sincs, oda a "mindennel kompatibilis" sh-t kell használni, hacsak nem akarsz egy script miatt több megabájtos csomagokat feltetetni dependenciaként.

- random disztribúción érdemes az alapértelmezett dogokat használni, mert az várhatóan mindenhol ugyan olyan verziójú lesz, tehát a scripted mindenhol ugyan úgy fog viselkedni.

Persze lehet úgy is hozzáálni, hogy megmondod hogy a te 3 soros sckripted miatt tegyenek fel php-t, abból is a legutóbbi aplha verziót, valami extrém modullal megfűszerezve, csak mert volt benne egy neked tetsző függvény, és az milyen cool.
(Csak ezt kevesen fogják elfogadni, és kidobják a szarodat még kipróbálás előtt ;)

Egy átlagos Linux szerveren mondjuk biztos van ba(sh), Perl, Python. (De még ezek esetén sem mindegy milyen verziójú az adott környezet!!!)

Ilyen esetben (ha már amúgy is van telepítve perl/php/python/akármi) én akkor szoktam mégis shell script mellett dönteni, hogy ha sok egyéb külső CLI-s parancsot kell meghívni, és/vagy fájlokat másolni/átnevezni.

Ha a feladat már komyolabb belső logikát, vagy több állományból programot, esetleg grafikus felületet igényel, akkor biztosan nem shell-ben kezdek neki...

--
zrubi.hu

( pepo v | 2018. 02. 22., cs – 16:11 )

Grafikus felületet a bashnek!!!: 


zenity --title  "kedvenc HUP cikkíróm" --text "Lentebb lehet kiválasztani" --list --radiolist --height=250 \
--column="5" --column "5" \
TRUE "Trey1" \
FALSE "Trey2" \
FALSE "Trey3"

( Foltos | 2018. 02. 23., p – 10:12 )

Nálam a hordozhatóság az elsődleges szempont. A szkripteknek mennie kell windows, illetve Linux alatt is.
Igyekszem úgy elkövetni a szkripteket, hogy "git bash" alól menjenek, ergo olyan eszközöket használjak csak, ami a git -nek amúgy is kell. Szerencsére a git elég sok mindent használ (curl, perl v5, ssh) szóval vannak lehetőségek, de pl fájóan hiányzik a make. Ugyanakkor felejtős, hogy olyan perl library -t használjak ami nincs fent alapból mert a cpan vagy megy vagy nem.
További komplikáció, hogy vannak fejlesztőink akik Cygwin pártiak, és a Cygwin rendesen meg tudja kavarni a dolgokat. Pl. amikor a readlink -f /cygdrive/foo/bar jellegű elérési utat ad vissza amitől az elindított natív windows -os program rosszul lesz. Akadnak kollégák, akik megfűszerezik a Cygwint avval, hogy a "/cygdrive" prefixet átállítják ami újabb csavart visz az ember életébe.

Igazából nincs Linux és windows között kényelmesen hordozható szkript nyelv. Mindegy milyen nyelvet használ az ember, mindenhol van rejtett taposó akna, és ha nem eleve hordozhatóságra fejlesztett a szkript akkor valahol nem fog menni. Sőt megkockáztatom még az összes platformon tesztelve sem lesz 100% -os, azaz nem tudhatod mikor tőri el valamelyik komponens frissítése.

( zeroms | 2018. 02. 23., p – 11:08 )

Automatizalt deploy es/vagy telepito programot szoktam bash-ben leprogramozni

( portal | 2018. 02. 23., p – 19:22 )

Azért "problémás" shell-ben programozni, mert maga a shell-script egy "hirbid megoldás".
Legegyszerűsítve, ugyanazokat a parancsokat írjuk be a script-be, amiket amúgy a konzolon futtatnánk le egymás után aminek futtatási jogot adtunk|tak. Ebben lehetnek a shell belső utasításai vagy változói, de lehetnek "külső" segédprogramok, mint pl. ls, grep, awk, mail, ...
És szerintem itt kezdődnek a gondok: csak maga a grep vagy a sed egy komplett szövegfeldolgozó, az awk pedig egy táblázatkezelő funkciókkal bíró "programozási nyelv", a maguk SAJÁT szintaktikájával. Sajnos erre még nincs szabvány. De hogy ne menjünk túl messzire, már egy egyszerű aritmetikai értékadásnál gondban lehetünk, ugyanis a 'let' és az 'expr' másképp érzékény a tagok közötti szóközökre, vagy azok hiányára. (Ehelyett a dupla zárójelezést érdemes használni, az jóval rugalmasabb ebből a szempontból)
Tehát ahhoz, hogy "elsőre működjön" a shell-scripted, tisztában kellene lenned az összes (a scriptben használt!) segédprogram szintaktikájával, és lehetséges kapcsolóival, ami szerintem (már-már) lehetetlen.
Igen, én is bevallom, bonyolultabb esetekben inkább a php-t választottam, eddig... :)

Ahhoz, hogy php-ben el tudd dönteni, hogy adott ponton normálisan fut-e a kódod, nem kell sem minden hívott függvény belső életét ismerned, sem az összes lehetséges kivételt, ami az adott helyen előfordulhat.

Ha érdekel, hogy mi a bibi, mert a hibának megfelelően akarod ágaztatni a programodat, megteheted. Ha viszont "csak" az érdekel, hogy még jó-e a futás vagy sem, és valamilyen elvárt tartományba esik-e az eredmény, akkor aszerint is eljárhatsz, fittyet hányva arra, hogy pontosan milyen természetű a hiba, és hogy a hívott rutinok lehetséges funkcionalitását 100%-ig kihasználod, vagy csak részüket (gondolj az opcionális paraméterekre, amelyeket esetleg sohasem használtál adott függvényekben!) -- csak az lényeg, hogy az a hívásforma, ahogyan használod ismert legyen előtted.

A shellben pontosan ugyanez a helyzet, csak a kivétel nem kivétel, a catch pedig nem catch.

És ezzel nem azt akartam mondani, hogy nem kell utánanézni annak, hogy mit csinál: kell, pont ugyanúgy, ahogy a php függvények paramétereinek és visszaadott értékeinek is. Ha peched van, és éppen a kedvenc függvényed esik áldozatul egy újratervezésnek, akkor még a nevének is.

"Tehát ahhoz, hogy "elsőre működjön" a shell-scripted, tisztában kellene lenned az összes (a scriptben használt!) segédprogram szintaktikájával, és lehetséges kapcsolóival, ami szerintem (már-már) lehetetlen."

Nem hiszem, hogy ez a legnagyobb gond. Az átlag scriptek felhasználnak 10-max 20?? külső programot.

Tetszőleges nyelven programozva a "printf és barátai" vagy a sztringkezelő függvények ennél többen vannak, s bizony azok paraméterezését, használatát is meg kell tanulni ahhoz, hogy egy C/C++/Java/Python program "elsőre működjön".

Annyi igaz, hogy a shellből elérhető (segéd)programok jóval heterogénebb társaságot alkotnak, a paraméterezésük meg pont annyira logikus, mint az

ls -x vs. cp -x

Ha már feldobtad...

Hacsak épp nem felhasználónak akarod megmutatni (pl. automatizált e-mailben elküldeni) az ls outputját, más use-case-t tud-e valaki felsorolni rá?

Hirtelen egy olyan sem jut eszembe, amikor shell scriptben program kimenetét feldolgozva az a program az ls lenne.
Talán egy kivétel jut eszembe, de az is ritka eset, mint a fehér holló, hogy abban a formában kell a "scriptnek" feltennie a kérdést, hogy az ls kelljen a válaszhoz.

Mondjuk egy progress-ben írt program dolgozza fel a felparaméterezett "ls" kimenetét... És ugye az "ls"-ből linux alatt is van kétféle, paraméterezésben nem teljesen kompatibilis, úgyogy anno egy ilyen környezetben a "régi" ls binárist fel kellett másolni minden adatbázisszerverre, és a db-t futtató usernek PATH-t is kellett hozzá reszelni, hogy a megfelelő "ls"-t lássa...

Azóta ha jól tudom, kikalapálták vagy a programot, vagy készült egy script, ami "eljátssza" a régi ls-t az új paraméterezésével...

Zeller eleve banális csacskaságot írt.
Ha lista kell fájlokról: find.
Igen, hordozható.
Ha hordozhatóra akarod írni a programot, akkor nem a find dokumentációját olvasod el, hanem amit már sokszor emlegettem: A posix szabványt. Ami kapcsolókat abban leírnak, az mindegyik find implementációban egységesen fog működni. Ahol meg nem (including gnu!) ott az per definició bug!

A cygwin hordozhatóbbnak bizonyult, mint a java. ;) Persze csak akkor, ha eltekintünk attól az apróságtól, amikor bitre egyforma gépeken másképp kell ugyanazt a C programot fordítani. De ezt egy idő után már megszokja az ember.
A python 2.7-et sem értem miért jön. Tán tévedek: systemd? :-D

"A cygwin hordozhatóbbnak bizonyult, mint a java."
A cygwin igen furcsa módokon tud keresztbe tenni az embernek. Pl.: kb 2 éve jártam úgy, hogy a cygwines make alapú build végtelen ciklusba került, ha build közben megnyitottam egy második cygwin bash ablakot.
Akkor is érdekességek történnek, ha különböző cygwin verzióval fordított programokat együtt szeretnél használni.

Szóval a cygwin egyazon gépen sem mindig kompatibilis saját magával, és akkor még "hordozásról" szó sem volt.

Ez az hordozás nem az a hordozás. ;)
Egyrészt ott van a (Windows) frissítés után a rebase. Elmaradása esetén fork hiba jön.
Különben főként ssh kapcsolathoz használjuk - az működik. A "technológia" lényege, hogy minimális programot futtatunk a Windows kliensen, és nem indulhat shell. Így azért elég stabil, megy XP-től a 2012 serverig mindenen. Még fatökű üzemeltetőkkel is. :)

Még nem olyan rég óta kell céges környezetben windowsos desktopról git-et elérjek, így cygwin-nel kapcsolatos első tapasztalataim:
git bash-jában kiadva egy git diff-et azt mondja minden rendben, a repóm szinkronban van az upstream-mel, nincs változás.
Ez kb. szinkronban van az én felfogásommal is.

cygwin evvel szemben az ő git bash-ja, azt mondja, hogy van egy csomó eltérés. Valahogy nem képes felfogni a crlf-ek közti eltérést, vagy ebből valami szívügye problémát csinálni.
tig viszont csak cygwin-ben van, és rohadt idegesítő, hogy ha csak kell valami ui, hogy gyorsan átfussak valamin, hogy avval mi is a szitu... na arra használhatatlan. Megyek vissza a git bash-hoz. Csak a staged changeknél régebbi (vagy staged) változások megnézésére alkalmas a cygwin-es tig.

-> Ami nekem lokálban kell a windwos desktopon, pl. akár egy shell scriptes ötlet PoC tesztelésére -> git bash
Nagyjából mindent ad, ami kell nekem lokálban.
Kivéve man page-k. Az párszor jól jött volna. Na, kb. olyankor szoktam cygwin-t indítani.
Nekem még ssh-zni is kényelmesebb a git bash-ja. Openssh-t használ, így azok a konfigok amiket megírok l*nuxra a .ssh/config -omba, egy az egyben hordozhatók a windowsomra is.