Xiki

Linux.com představuje projekt Xiki. Xiki přichází s novým konceptem práce v "příkazovém řádku". Uživatel pracuje s textovým editorem. Po spuštění příkazu přímo z editoru se výpis příkazu zobrazí opět v editoru. Výpisy lze různě sbalovat a rozbalovat, příkazy opětovně spouštět. Vše je editovatelné, například výpis SQL dotazu nebo HTML stránky. Úpravou výpisu SQL dotazu lze aktualizovat obsah databáze. Součástí Xiki je webový server. Pro práci s Xiki lze tak využívat webového rozhraní. K dispozici je několik videoukázek práce s Xiki. Projekt lze aktuálně podpořit na Kickstarteru. [Slashdot]

30.6.2014 09:31 | Ladislav Hagara | Zajímavý projekt

Komentáře

[pjoter]

Kdyz vidim Ruby, tak skripu zuby. Je to az neskutecne na co jsou schopni lidi dat penize

[mankind_boost]

Hm, asi si to sam prepisu do nejakyho normalniho jazyka...

[smutik]

Tak skuste mrknut na tuto perlu

[mankind_boost]

Nejdřív jsem si myslel, že je to jenom dost propracovaná satira. Ale oni to myslí vážně! :-O

[Prcek]

To je odkaz jak stehno. Pokud ti to pomůže, tak na vytváření odkazů tu máš funkci .

[mankind_boost]

Taky sem na to furt klikal a ono nic

[:::]

Úpravou výpisu SQL dotazu lze aktualizovat obsah databáze.

Takze tam v kodu nekde musi byt modul ktery rozumi databazim a SQL dotazum. Totez pro dalsi technolohie...

Protoze kazdy prikaz si obvykle definuje vyznam vystupu vlastnim zpusobem, bude potreba napsat zvlast parser a dalsi veci pro kazdy prikaz ktery to ma podporovat.

Nechcu nikoho odrazovat na zacatku projektu, ale myslim ze z toho zakonite musi vzniknout moloch ktery NE-bude umet vsechno, a NE-bude umet nic poradne.

[Fluttershy, yay!]

Není to tu poprvé. Kdo si dneska vzpomene na všechny ty "sémantické/grafické shelly"?

[xkucf03]

Nechcu nikoho odrazovat na zacatku projektu

Mě na tom zaujalo, že na tom prý dělá už deset let a někdo na tom videu říkal, že to používá snad už sedm let. O Xiki slyším dnes poprvé.

ale myslim ze z toho zakonite musi vzniknout moloch ktery NE-bude umet vsechno, a NE-bude umet nic poradne.

Tyhle věci se dají dělat modulárně, co příkaz, to modul a teoreticky by sis mohl při instalaci vybrat jen to, co budeš používat, nebo alespoň při startu aktivovat jen to, co používáš nebo by se moduly mohly startovat dynamicky až ve chvíli, kdy jsou potřeba.

A je to spíš takové obecnější TUI než náhrada CLI.

P.S. ta instalace je fakt pekelná, nedávno jsem o tom psal.

[chrono]

Mě na tom zaujalo, že na tom prý dělá už deset let a někdo na tom videu říkal, že to používá snad už sedm let. O Xiki slyším dnes poprvé.

Správa o xiki sa z času na čas objaví na reddit alebo ycombinator.

[David Jaša]

Nechcu nikoho odrazovat na zacatku projektu, ale myslim ze z toho zakonite musi vzniknout moloch ktery NE-bude umet vsechno, a NE-bude umet nic poradne.

Tedy něco jako augiáš (augeas :)) pro konfiguráky?

[Ivan]

Presne tak. Navic jeden takovy moloch uz mame. Jmenuje se Emacs a vyse uvedene vlastnosti (shell-mode, sql-mode) spokojene pouzivam vice nez 15 let.

PS: sql-mode pro Oracle je jen "wrapper" nad sqlplus.

[tacoberu]

Inspirativní. Myslím, že si s tím budu chvilku hrát.

[frdrx]

Tak bez tohodle se asi obejdu.

[Šangala]

To musí bavit… :)

[skunkOS]

zsh

[Milan Vančura]

Pamatuji si to na osmibitovém ATARI, tam to tak fungovalo. Akorát na to nepotřebovali dotaci z kickstarteru a vešlo se jim to i s interpretem jazyka do 16kB :)

[Milan]

Nejake detaily by nebyly?

[Pavel Čejka]

To by mne taky zajímalo.

Vím, že mnohé editory a interpretery BASICu, které zároveň na osmibitech fungovaly jako jakýsi shell (typicky Sinclairy používají BASIC jako universální OS/zavaděč/kalkulačku/programovací jazyk v jednom) a bylo běžné, že si uživatel mohl při editaci vybrat řádek a po odmazáním čísla na jeho začátku ho odeslat a řádek se interpretoval a zároveň zůstal součástí programu. Proměnné ovlivněné odeslanými příkazy se změnily, ale změny v řádku se bez jeho čísla neuložily. Dalším příkazem bylo možné takto změněné proměnné uložit třeba na disk, nebo pásku ...

I když to mělo svá pozitiva (v rámci platformy a pro jednoduché úkoly), nemám ani trochu pocit, že by mi tohle na Linuxu chybělo, nebo že by to mohlo mít jakýkoli přínos.

[Miloslav Ponkrác]

Pokud si vzpomínám, na Atari to fungovalo celoobrazovkově. Stačilo řádit kdekoli na obrazovce, bralo se to v pozici kurzoru. Ale přesně si nevzpomínám.

Nicméně, pokud bych si mohl vybrat, nějaký rozumější Basic byl rozhodně silnější jazyk, než je bash. A kdybych si mohl vybrat, dal bych Basicu před bashem rozhodně přednost.

Osobně se snažím sh/bashe jakkoli zbavit kromě jednoduchých úkolů. Takže už jsem příkazoval v pythonu i leččems.

Nemyslím si, že úloha Basicu jako shellu i jednoduchého interpretovacího jazyka byla špatná. Rozhodně to byl dobrý tah, a myslím, že lepší tah, než je linux shell. Z mého subjektivního pohledu.

Osobně si myslím, že shell by měl být především programovací jazyk doplněný o pár věcí pro práci s procesy, než shell typu bash horko těžko doplněný o jakž takž programovací konstrukce.

Takže mně toto na linuxu rozhodně velmi chybí.

[potato]

Nicméně, pokud bych si mohl vybrat, nějaký rozumější Basic byl rozhodně silnější jazyk, než je bash. A kdybych si mohl vybrat, dal bych Basicu před bashem rozhodně přednost.

To je tedy zase perla.

Jaký smysl má srovnávat shell a Basic?

Dokážeš uvést příklad alespoň jedné netriviální úlohy (tj. ne vypsání Hello world!), jejíž implementaci by příčetný člověk zvažoval v shellu i Basicu?

Dozvíme se také, zda lepší jazyk XSLT, FORTRAN, nebo SQL? A Jan Tleskač?

[pc2005]

Já v shellu napsal emulátor disketovky .

[Miloslav Ponkrác]

„Jaký smysl má srovnávat shell a Basic?“

Velký. Ostatně Basic pro řadu počítačů fungoval přesně ve smyslu shellu.

---

„Dokážeš uvést příklad alespoň jedné netriviální úlohy (tj. ne vypsání Hello world!), jejíž implementaci by příčetný člověk zvažoval v shellu i Basicu?“

V shellu i basicu jde napsat hodně věcí. A příčetný člověk by raději psal řadu úloh v shellovém jazyce, protože proč ne?

[Jakub Galgonek]

Tazatel se ale ptal nejspíše na něco jiného. Tipuji, že chtěl vědět, zda množina netriviálních úloh, které má smysl řešit v shellu, a množina netriviálních úloh, které má smysl řešit v Basicu, mají neprázdný průnik.

[Miloslav Ponkrác]

To je špatně položená otázka.

Pokud by byla otázka myšlena takto, tak mi to přijde, jako kdyby se mně někdo ptal, mám vedle sebe mentálně retardovaného člověka s IQ 70 (bash) a génia s IQ 150 (slušný programovací jazyk jako shell). A ptám se, k čemu jsou oba zároveň (v průniku schopností) použitelní. Pokud je snaha najít průnik činností s retardem, pak opravdu vyšší schopnosti člověka s IQ 150 jsou zbytečné.

Stejným způsobem mohu dokázat, že LInux je k ničemu. Mám kladivo a Linux. Která množina úloh mající neprázdný průnik v řešení kladivem a Linuxem má smysl řešit na Linuxu. Snadno dojdu k tomu, že stačí kladivo, Linux je zbytečný.

---

Čím schopnější jazyk shellu budete mít, tím větší počet úloh se v něm vyplatí řešit. Čím blbější a dřevěnější jazyk shellu (jako je třeba bash) budete mít, tím větší počet úloh je lépe řešit věci v čemkoli jiném, než v shellu.

Vzhledem k tomu, že bash je velice špatný a dřevěný, pokud ho chci použít jako programovací jazyk (což neznamená, že v něj nejde udělat leccos, ale je to dosti nepříjemné), tak rozumně (s velkým důrazem na slovo rozumně) v něm mnoho realizovat najde.

[xkucf03]

Vzhledem k tomu, že bash je velice špatný a dřevěný, pokud ho chci použít jako programovací jazyk

Chybu vidím právě v tom, že někdo chce BASH používat jako programovací jazyk – je to asi jako kdybych chtěl zatloukat hřebíky počítačovou myší – moc to nepůjde, ale to přece neznamená, že myši jsou špatné.

Ano, BASH se na programování moc nehodí, taky bych si vybral raději něco jiného (C/C++. Javu, Perl, Python, PHP atd.), ale tu nostalgii po BASICu fakt nějak nechápu, nepřijde mi to jako dobrý jazyk, ve kterém bych chtěl psát programy.

Smysl BASHe vidím v tom, že je to lepidlo pro spojování jiných programů, skriptovací jazyk, viz #24 – a k tomu se hodí docela dobře (a mnohem líp než nějaký BASIC). V programovacích jazycích by tohle šlo taky dělat, ale většinou hůř, protože jim chybí ty syntaktické prostředky, které má BASH – muselo by se to suplovat nějakým frameworkem nebo sadou funkcí pro spouštění procesů, jejich propojování do rour, směrování vstupů/výstupů atd.

[pavlix]

nepřijde mi to jako dobrý jazyk, ve kterém bych chtěl psát programy.

+1

A věřím že nikomu, do na něm nezačínal ;).

[Miloslav Ponkrác]

Tak proč se v shellu někdo snaží programovat?

Podívejte se třeba na git, implementačně je to nalepovák z C kódů a shellových skriptů.

Mnoho unix/linux programů nejde slušně portovat, protože jsou plné shellových skriptů.

Právě, že v shellu se snaží až příliš mnoho lidí programovat a shellové skripty jsou používány v linuxu až přečasto jako programovací jazyk. Od balíčkovacích systémů přes polovinu programů v linuxu.

Proto mi přijde snaha kategoricky být proti programovacímu v jazyku shellu být poněkud v rozporu s reálnou linuxovou skutečností. A nebo žiji v paralelním vesmíru, kde je všechno jinak a nějakou červí dírou jsem se dostal do této diskuse.

[pavlix]

Tak proč se v shellu někdo snaží programovat?

Co to má prosím společného s mojí reakcí na BASIC?

Podívejte se třeba na git, implementačně je to nalepovák z C kódů a shellových skriptů.

Nikoliv. Git je naprogramovaný v C a shell tam používá podle mě velmi rozumným způsobem a k věcem, kde to mi to dává smysl.

Od balíčkovacích systémů přes polovinu programů v linuxu.

Tady je asi zajímavým příkladem Gentoo, kde se shell používá k integraci kde čeho a můj dojem z toho je, že to funguje velmi hezky. Nicméně se zde nebavíme o aplikacích či systémových službách, ale o případech, kdy se shell používá jako wrapper, skriptovátko a konfigurační jazyk. Osobně v tom nevidím problém ani snahu používat shell jako náhradu programovacího jazyka. Pokud s tím někdo (windowsáci, Ponkrác, kdokoliv) problém mají, tak si ho asi budou muset vyřešit sami ;).

[Miloslav Ponkrác]

„Nikoliv. Git je naprogramovaný v C a shell tam používá podle mě velmi rozumným způsobem a k věcem, kde to mi to dává smysl.“

Jinak řečeno, je to nalepovák z C a shellových skriptů tak, jak jsem to napsal. Neřekl jsem vůbec nic jiného.

To, že Vám to dává smysl, mně nikoli. Ovšem smysl – to je subjektivní názor.

---

„Osobně v tom nevidím problém ani snahu používat shell jako náhradu programovacího jazyka. Pokud s tím někdo (windowsáci, Ponkrác, kdokoliv) problém mají, tak si ho asi budou muset vyřešit sami“

Vždycky, když nemáte věcné argumenty, tak autoritativně prohlésíte, že má někdo problémy? Wow!!!

[xkucf03]

Právě, že v shellu se snaží až příliš mnoho lidí programovat a shellové skripty jsou používány v linuxu až přečasto jako programovací jazyk. Od balíčkovacích systémů přes polovinu programů v linuxu.

Asi jim to nepřijde tak strašné nebo prostě nemají lepší nástroj. Bash/sh lze považovat za jakousi základní součást systému (alespoň toho unixového), což se o různých Pythonech, Perlech, PHP a jiných říct nedá – jsou přeci jen něco navíc, přestože jsou poměrně rozšířené.

[Šangala]

A kde je hranice mezi programování a psaním skriptu? Mám v Bashu nadělané, řekl bych docela široké věci a i kraviny jako generování text grafů a řekl bych, že to je programování a to první odkázané bych ani jinak dělat nechtěl(to druhé je spíš „hrej si“ ;)) - ono lze programovat s podmínkou a goto a několik programů jsem si napsal i v Oook!, který je přímo konvertovatelný z/na Brainfuck, jen je mnohem lidštější.

[xkucf03]

A kde je hranice mezi programování a psaním skriptu?

Bude to trochu definice kruhem: skriptování je to, co dělám v Bashi Jde o lepení programů pomocí rour, směrování vstupů/výstupů, jednoduchá konfigurace, příprava prostředí pro proces (např. proměnné prostředí, kontrola existence souborů/adresářů), jednoduché IFy, cykly.

Např. v Bashi vyberu .jary, které se mají dát do CLASS_PATH, a tím se zapnou některé pluginy – třeba na základě toho, že si uživatel přidal hodnotu do bashového pole v konfiguráku nebo že umístil soubor do určitého adresáře. Prostě takové různé pomocné a přípravné práce – ale samotný program už je v jiném jazyce.

Mám v Bashu nadělané, řekl bych docela široké věci a i kraviny jako generování text grafů a řekl bych, že to je programování a to první odkázané bych ani jinak dělat nechtěl(to druhé je spíš „hrej si“ ;))

Oba odkazy vedou na stejnou stránku.

To KVM klonování VM dle předlohy mi přijde jako celkem dobrá úloha pro Bash a skriptování. Ale když jsem koukal dovnitř, tak kolem 800 už je celkem dost. Podle mého se ideální bashový/perlový skript vejde na jednu obrazovku

[Šangala]

Já bych řekl, že jak jednou napíšeš if za jiným účelem než ošetření návratového kódu, tak už programuješ :)

Druhý měl vést sem (Jak nám říkali na jednom školení »technologii copy&paste« jsem nezvládl…).

800 je hodně, ale oproti druhému odkazu :), ono by to šlo rozházet do více souborů - zvažoval jsem to - je to o přístupu, v takovém případě prostě píšu a jedu furt pryč dál a dál v jednom filesu a mně se v tom orientuje dobře, napsat něco takového v jednom filesu třeba v C++ tak se asi dobrovolně oběsím…

[pavlix]

Mně osobně kromě vyloženě úloh pro shell vyhovuje to, že lze skutečně v systému jen upravit zdrojový soubor a mám připravené nové chování. To stejné funguje v Pythonu a musím říct, že to u různých toolů hojně využívám. Někdy dělám i to, že si původní verzi zazálohuju a pak používám diff k získání patche, popřípadě rovnou použiju quilt.

Zajímalo by mě, jestli by taková vlastnost šla nějak rozumně rozšířit i na céčkovské programy, jako že by systém byl schopný detekovat, že daná binárka má být před spuštěním nově zkompilována na základě úpravy zdrojového kódu. Chápu, že bash něčím takovým vůbec netrpí a python to má vyřešené tím, že jednomu zdrojáku odpovídá jeden výsledný modul, takže to u typického céčkovského programu tak jednoduše nepůjde. Jako náhradu osobně používám Gentoo, kde ale naopak typicky používám gitovský repozitář a v něm něco ve smyslu následujícího příkazu.

sudo git format-patch origin/master -o /etc/portage/patches/my-group/my-package-with-version

Ale pravda je, že si umím představit i pohodlnější cestu.

[Šangala]

Zajímalo by mě, jestli by taková vlastnost šla nějak rozumně rozšířit i na céčkovské programy, jako že by systém byl schopný detekovat, že daná binárka má být před spuštěním nově zkompilována na základě úpravy zdrojového kódu.

Toho lze docílit obyčejnou obálkou, pro jednoduché účely to používám (g++ -o xx xx.cpp && ./xx), i s detekcí stačí jen uložit třeba SHA1 spočítané nad obvykle malou binárkou je to za neviditelný zlomek sekundy, takže spuštění to neovlivní, nicméně při změně i 5MiB binárka může mít 20min kompilaci.

[pavlix]

To asi úplně není to, o čem jsem psal výše, že?

[Šangala]

Nejsem si jistý, možná ano…

[pavlix]

Já si jsem jistý, že nikoliv.

[Josef Kufner]

Interpretované C není moc těžké udělat. Potřebuješ k tomu gcc a jeden dočasný soubor:

#!/bin/bash
sed -n -e '7,$p' < "$0" | /usr/bin/gcc -x c -o "$0.$$.out" -
$0.$$.out "$0" "$@"
STATUS=$?
rm $0.$$.out
exit $STATUS

#include <stdio.h>

int main(int argc, char **argv)
{
  int i;
  for (i = 0; i < argc; i++)
    printf("argv[%d] -> %s\n", i, argv[i]);
  return 0;
}

(zdroj)

Tu hlavičku můžeš dát do samostatného skriptu/binárky, aby to bylo hezčí.

[CiV]

A nebo jednodušeji s tcc. Stačí dát na začátek C skriptu:

#!/usr/bin/tcc -run

[pavlix]

To není to, o čem jsem psal.

[Bystroushaak]

Zajímalo by mě, jestli by taková vlastnost šla nějak rozumně rozšířit i na céčkovské programy, jako že by systém byl schopný detekovat, že daná binárka má být před spuštěním nově zkompilována na základě úpravy zdrojového kódu.

Takhle se dá používat TCC:

TCC allows programs to be run automatically at compile time using a command-line switch. This allows programs to be run as a shell script under Unix-like systems which support the shebang interpreter directive syntax.

Ale že by teda bylo programování v C nějaká slast, to se taky říct nedá.

[pavlix]

Nemyslím si, že je tcc v dnešní době volba, ale ani tak to není to, o čem jsem psal. Nevím jak z napsaného mohlo hned několik lidí usoudit, že si chci psát skriptíky v C, to je přece nesmysl. Můj komentář byl o pohodlné úpravě zdrojového kódu libovolného balíku tak jako by tomu bylo, pokud by všechen software v systému byl v Pythonu s přímo upravitelnými zdrojáky. V tom ttc ani nic z uvedeného v komentářích výše nijak nepomůže.

[pavlix]

jsou přeci jen něco navíc, přestože jsou poměrně rozšířené.

A neexistuje pro ně dlouhodobě uznávaný standard, což pro shell existuje a pokud vývojáři používají bashismy tak i tak lze říct, že je současná podoba bashe o něco stálejší než třeba současná podoba pythonu.

[Miloslav Ponkrác]

„Chybu vidím právě v tom, že někdo chce BASH používat jako programovací jazyk – je to asi jako kdybych chtěl zatloukat hřebíky počítačovou myší – moc to nepůjde, ale to přece neznamená, že myši jsou špatné.“

Tím, že použijete špatnou analogii neznamená, že máte pravdu. Myš se nepoužívá ani na programování ani na skritování. Co takhle třeba srovnání s veverkami nebo s Ruskem či s kanibaly nebylo by? Případně třeba s prvoky? Prostě cokoli, co v čem se nedá ani skriptovat ani programovat, abyste měl analogii co nejváce přitaženou za vlasy.

Nevidím sebemenší důvod, proč by shellový jazyk neměl být použitelný jako programovací jazyk, Naopak si myslím, že by to tak správně mělo být.

To, že si to na linuxu málokdo umí představit, protože bash tomu nevyhovuje nic neznamená.

Miloslav Ponkrác

[xkucf03]

Tím, že použijete špatnou analogii neznamená, že máte pravdu. Myš se nepoužívá ani na programování ani na skritování. Co takhle třeba srovnání s veverkami nebo s Ruskem či s kanibaly nebylo by? Případně třeba s prvoky? Prostě cokoli, co v čem se nedá ani skriptovat ani programovat, abyste měl analogii co nejváce přitaženou za vlasy.

Tak jinak: má smysl psát vysoce optimalizovanou implementaci šifrovacího algoritmu nebo kodeky v Javě? Má smysl psát podnikové aplikace v assembleru? Odpověď je v obou případech ne, ale to neznamená, že by Java nebo assembler byly obecně špatné nástroje – jen mohou být špatně použity, pro nevhodný úkol.

Nevidím sebemenší důvod, proč by shellový jazyk neměl být použitelný jako programovací jazyk, Naopak si myslím, že by to tak správně mělo být.

Nemám s tím problém – kdyby se v Bashi/shellu lépe programovalo, tak by mi to vůbec nevadilo, dokonce bych to uvítal. Ale je otázka, za jakou cenu.

Na programovací jazyk mám jiné nároky než na skriptovací jazyk resp. shell a ty požadavky mi přijdou do značné míry neslučitelné. Pokud by se ale někomu podařilo tyto rozpory vyřešit, tak budu jedině rád.

[Miloslav Ponkrác]

„Tak jinak: má smysl psát vysoce optimalizovanou implementaci šifrovacího algoritmu nebo kodeky v Javě? Má smysl psát podnikové aplikace v assembleru? Odpověď je v obou případech ne, ale to neznamená, že by Java nebo assembler byly obecně špatné nástroje – jen mohou být špatně použity, pro nevhodný úkol.“

To jsou přesně příklady toho, co 99,999 % programátorů programuje dnes a denně.

Znovu, nevhodnými příklady možná přesvědčíte nepozorného čtenáře, ale pravdu mít nebudete.

---

„Na programovací jazyk mám jiné nároky než na skriptovací jazyk resp. shell a ty požadavky mi přijdou do značné míry neslučitelné. Pokud by se ale někomu podařilo tyto rozpory vyřešit, tak budu jedině rád.“

Pokouší se o to, a řekl bych více méně úspěšně na mnoha platformách. Linuxová komunita ale postupuje stylem, že co vidí a používá ona už vylepšit nejde. A zásobuje svět články „boření mýtů o …“, ve kteérm píše, že není schopna ničeho, než toho co vidí.

V podstatě o sjednocení programovacího a skriptovacího jazyka se pokoušejí na každé platformě (mimo linuxu, kde věří, že linux je dokonalý a cokoli jiného, než je dnešní stav je krokem zpět).

Na 8bitech to zkusili s Basicem, na LISP mašinách s LISPem, na Windows teď s PowerScriptem, u IBM s REXXem, a tak bych mohl přidat stovky a stovky dalších.

Já sám odmítám používat sh a bash jako nesmysl. Nic to neumí a na nástroj na spouštění procesů a rour je to poněkud nemsylně složité.

[pavlix]

Linuxová komunita ale postupuje stylem, že co vidí a používá ona už vylepšit nejde. A zásobuje svět články „boření mýtů o …“, ve kteérm píše, že není schopna ničeho, než toho co vidí.

Představa, že je linuxová komunita nějaký názorově jednotný celek, je přinejmenším přitažená za vlasy.

[Miloslav Ponkrác]

„Představa, že je linuxová komunita nějaký názorově jednotný celek, je přinejmenším přitažená za vlasy.“

Já jsem nepsal o NÁZORECH linuxové komunity, ale o jejích ČINECH.

„Zásobování světa články“ není o tom, co si myslí, ale o čem je 99,999 % činů, tedy článků.

A bohužel už mám pocit, že linuxová komunita plodí články velmi jednostranné a monotónní. Co si názorově myslí nevím, ale o tom jsem nepsal, psal jsem o tom, jak se projevuje činy ve článcích.

[pavlix]

Já jsem nepsal o NÁZORECH linuxové komunity, ale o jejích ČINECH.

Tento úhybný manévr připadá mi tragikomický, vzhledem k tomu, že to na absurditě toho tvrzení vůbec nic nemění.

[xkucf03]

Ten REXX vypadá zajímavě, podívám se na to.

BTW: asi před rokem jsem tu psal dotaz, kde mi šlo spíš o to, jak dostat některé zajímavé vlastnosti z Bashe (roury) do programovacího jazyka.

Když se vrátím k shellu: nebylo by marné přijmout některé principy z relačních databází. Aby se projekce a restrikce nemusela dělat na úrovni textu¹ pomocí nástrojů jako grep a cut.

Chtělo by to nějaký formát² pro strukturovaná data – tabulku případně posloupnost tabulek. A pak by se s tím dost dobře pracovalo v Bashi. Napsal bych třeba:

příkaz-produkující-data | restrikce | projekce | příkaz-zpracovávající-data > výstupní-soubor.txt

A těmi rourami by se předávala data v tom standardním formátu. Taky by tam šlo dělat JOIN nebo si odložit nějakou výsledkovou sadu do proměnné a zpracovat ji později nebo opakovaně procházet.

Tím bychom měli dobré datové struktury a zároveň syntaktickou podporu pro propojování procesů a směrování vstupu/výstupu.

Nic to neumí a na nástroj na spouštění procesů a rour je to poněkud nemsylně složité.

Nějaký tip na jednoduchý jazyk pro spouštění procesů a roury?

_{[1] s nepříliš dobře specifikovaným a standardním formátem, který je potřeba neustále parsovat a serializovat
[2] ať už binární nebo textový, to je celkem jedno, ale musí být otevřený, dobře specifikovaný a musí ho začít používat většina programů pro svůj standardní vstup a výstup}

[Gejza Jenča]

Ja som si spravil niečo na podobnom základe, ale je to špecializované na manipuláciu s bibliografickými odkazmi. Serializačný jazyk je YAML, je to dotiahnuté do podoby, keď to vyhovuje mojim požiadavkám. Nemá to JOIN (lebo to robí nad jednou "tabuľkou"), len FILTER a MAP. Má to koncept úložiska, do ktorého môžu dáta vprúdiť a zlúčiť sa s existujúcimi.

Pôvodne som mal v úmysle to propagovať medzi príslušníkmi môjho kmeňa, ale po skusmom sondovaní sa to ukázalo pomerne nepriechodné. Keďže mne to vyhovovalo a postačovalo, stratil som motiváciu.

Tu je to, markdown dokumentácia je v doc podadresári.

https://bitbucket.org/gjenca/yacite

[pavlix]

Mimochodem, na plumbum jsi se díval?

[xkucf03]

Pěkné, to už vypadá skoro jako BASH

[Miloslav Ponkrác]

„Smysl BASHe vidím v tom, že je to lepidlo pro spojování jiných programů, skriptovací jazyk, viz #24 – a k tomu se hodí docela dobře (a mnohem líp než nějaký BASIC).“

Tak proč je ten bash složitý jako prase? V zásadě intepretr bashe je složitější, než interpretr řady programovacích jazyků, o Basicu vůbec nemluvě.

---

„V programovacích jazycích by tohle šlo taky dělat, ale většinou hůř, protože jim chybí ty syntaktické prostředky, které má BASH – muselo by se to suplovat nějakým frameworkem nebo sadou funkcí pro spouštění procesů, jejich propojování do rour, směrování vstupů/výstupů atd.“

Kolik programovacích jazyků znáte? Možná by bylo dobré se na toto zeptat, než budeme diskutovat dále.

[xkucf03]

Tak proč je ten bash složitý jako prase?

Možná proto, aby byl jednoduchý navenek, na používání a byl tolerantní co se týče vstupu, měl volnou syntaxi. Platným skriptem pro Bash je třeba i soubor obsahující jediné slovo. Stejně jako složitý soubor, obsahující různé cykly, funkce, větvení. Pár znaků oddělených mezerami může znamenat jak systémový příkaz, tak vestavěný příkaz, tak funkci, tak textový řetězec, tak klíčové slovo. Většina programovacích jazyků by takový vstup odmítla a ohlásila chybu. Neříkám, jestli je to dobře nebo špatně¹, ale ta vnitřní složitost prostě není samoúčelná, má podle mého tento důvod.

V programovacích jazycích by tohle šlo taky dělat, ale většinou hůř, protože jim chybí ty syntaktické prostředky, které má BASH – muselo by se to suplovat nějakým frameworkem nebo sadou funkcí pro spouštění procesů, jejich propojování do rour, směrování vstupů/výstupů atd.

Kolik programovacích jazyků znáte? Možná by bylo dobré se na toto zeptat, než budeme diskutovat dále.

Co jsem zatím viděl, tak nejblíž tomu byla nestandardní knihovna sh pro Python. Ale kvůli ní bych potřeboval ten Python (jak jsem psal, nepovažuji ho za tak základní a nedílnou součást systému jako bash/sh) a musel bych si ji nainstalovat nějakým obskurním nestandardním způsobem:

pip install sh

a bůhví co tam bude za bezpečnostní díry. V mé distribuci AFAIK tahle knihovna není.

A co se týče funkčnosti, žádná sláva to není. Názvy systémových příkazů se sice namapují na názvy funkcí, takže je nemusím psát do uvozovek, ale hodnoty parametrů ano.

Tohle:

print(ifconfig("wlan0"))

mi přijde pro účely skriptování méně pohodlné než tohle:

ifconfig wlan0

proč bych měl psát nějaké otravné závorky nebo uvozovky, když je pro interaktivní práci v shellu nebo jednoduché skripty nepotřebuji?

Tohle je taky dobrý fór:

print(wc(ls("/etc", "-1"), "-l"))

opravdu se mi to nečte ani nepíše ve skriptu lépe než:

ls -l /etc | wc -l

A jak v tom mám sakra vidět, že první parametr ls("/etc", "-1") funkce wc() se vloží na standardní vstup, zatímco ten druhý "-l" se použije jako argument příkazu?

V Bashi by to bylo jasné:

ls -l /etc | wc -l

vs. třeba:

echo `ls -a`

nebo

echo $(ls -a)

Ta syntaktická podpora pro spouštění a propojování procesů a směrování vstupu/výstupu v tom programovacím jazyce prostě chybí a je tam horko těžko dolepená nějaká náhrada pomocí funkcí.

Než budeme diskutovat dále, uvítal bych, kdyby se tahle diskuse přenesla z teoretické roviny do alespoň trochu praktické. Bylo by fajn uvést nějaké příklady, jak zapsat třeba tohle:

(cat soubor.txt; echo "další hodnoty") | nějaký-příkaz > jiný-soubor.txt

lépe než v Bashi. Ať už v nějakém existujícím jazyce/frameworku, který by mohl Bash nahradit, nebo alespoň v nějakém hypotetickém jazyce v zatím neexistující ale lepší syntaxi.

_{[1] pro skriptovací (nikoli programovací) jazyk mi to přijde spíš dobře (naopak u programovacího jazyka by mi přílišná tolerance vadila)}

[pavlix]

Používat v pythoním promptu okolo výrazů print() je obvykle zbytečné.

[xkucf03]

O ten print() tam zrovna vůbec nejde, to jsem jen zkopíroval z dokumentace k té knihovně. Moje výhrady směřovaly k tomu, co je uvnitř něj.

[pavlix]

Tak uvnitř je ifconfig wlan0 versus ifconfig("wlan0"), což je na čtení zcela srovnatelné, ale je na tom vidět, že je bash na psaní přecijen o mnoho pohodlnější právě za cenu komplikovanějšího parseru, tedy přesně to, nad čím se mistr Ponkrác tak podivuje.

[xkucf03]

Ten ifconfig("wlan0") mi až tolik nevadí (i když psát ty závorky a uvozovky třeba v interaktivním shellu by se mi nechtělo), mnohem horší mi přijde:

wc(ls("/etc", "-1"), "-l")

u kterého prostě nevidím, co se předává jako argument a co jako standardní vstup – je za tím nějaké magické chování.

Když bych dal:

print(ls("/etc", "-1"))

tak z toho ls asi vypadne text, který se vytiskne. Ale když je tam wc místo print, tak z toho neleze text a nepředává se jako argument, ale nějak se výstup jednoho příkazu nasměruje na vstup druhého.

Nevím, co by se stalo, kdybych hodnotu ls("/etc", "-1") přiřadil do proměnné a tu pak vložil jako parametr wc() – předala by se jako argument příkazu nebo jako proud dat na jeho standardní vstup?

Oproti tomu je ten Bash na první pohled čitelný a i se líp píše (můžu vynechat většinu závorek a uvozovek).

IMHO by víc pomohl ten standardní formát pro tabulková data + klasické unixové roury a vhodné příkazy pro restrikci a projekci… než vymýšlení nějaké nové syntaxe. Takovým náznakem jsou hodnoty oddělené nulovým bajtem, s čímž umí pracovat třeba xargs nebo find, ale ještě by to chtělo něco pro oddělení sloupců, záhlaví a možnost mít více tabulek v jednom proudu dat.

[pavlix]

ls("/etc", "-1")

Toto je vcelku přirozený přepis, pokud nebereš v úvahu odlišnou povahu argumentu a volby, ale považuješ přitom každý příkaz za funkci, což je poněkud nepřirozené.

wc(ls("/etc", "-1"), "-l")

Zde už je podle mě chybný zápis, vzhledem k tomu, že wc neočekává text v prvním argumentu, ale ve vstupním datovém proudu, nehledě na to, že ls by pak muselo vracet výjimku, což naznačuje objektový přístup, který wc(..., "-l") zrovna neevokuje. Podle mě, aby to dávalo smysl, tak musíš sémantiku datových proudů zachovat ale tím pádem bys měl mít možnost i ty zdroje datových proudů různě řetězit, jak jsi sám v jiných komentářích uváděl.

Osobně bych podrobný listing viděl složenou akci a tedy akci na jiné úrovni než je čisté ls nebo os.listdir() a klidně by se mohly doplnit nějaké operátory, které by tohle uměly hezky řešit. Co třebá následující python-like pseudoḱód?

def ls(location, columns=["name", "mtime", "ctime"]):
    for item in os.listdir(location):
        yield os.stat(location)

len(ls("/etc"))

A nebo malá úprava pomocí vylepšené syntaxe.

ls("/etc") -> len()

Samozřejmě asi vidíš, jak je v tomto případě -l u ls nejen zbytečné, ale kvůli řádku navíc i škodlivé.

ještě by to chtělo něco pro oddělení sloupců, záhlaví a možnost mít více tabulek v jednom proudu dat.

To všechno bys podle mě dostal z nějaké méně debilní formy D-Bus API, popřípadě třeba i s JSONu. Už jen to, že chceš víc tabulek podle mě naznačuje, že SQL style není dostatečně flexibilní.

[xkucf03]

pokud nebereš v úvahu odlišnou povahu argumentu a volby

Však technicky mezi nimi žádný rozdíl není, argumenty/volby jsou jen pole textových řetězců předávaných programu – jestli to má nějakou sémantiku, to je věc toho programu, ale shell o tom nic neví.

Tady by se hodil nějaký formát pro strojově čitelný popis CLI rozhraní. Existuje docopt, ale myslím, že bylo i něco lepšího a umělo to snad i generovat nějaké GUI…

Bash completion by mohlo být mnohem lepší a mohly by se z toho generovat nápovědy i pro jiné shelly (klidně i grafické), nebo třeba objektové obaly pro různé programovací jazyky.

Co třebá následující python-like pseudoḱód?

Tohle už vypadá líp.

A tím se pomalu dostáváme k tomu, že když se člověk přesune od skriptování/shellu k programovacímu jazyku, nedává už tolik smysl volat systémové příkazy a vytvářet podprocesy, ale je lepší používat funkce/metody daného jazyka, které budou přijímat a vracet nějaké sofistikovanější datové struktury než jen vstupně/výstupní proudy dat.

Samozřejmě asi vidíš, jak je v tomto případě -l u ls nejen zbytečné, ale kvůli řádku navíc i škodlivé.

Tady je to zrovna jednička¹ a ne malé L, ale zbytečné to tam asi je, protože ls se chová trochu kouzelně a v rouře vypisuje po řádcích² i bez toho.

To všechno bys podle mě dostal z nějaké méně debilní formy D-Bus API

S D-Busem nemám až tolik zkušeností, abych ho hodnotil jako debilní nebo nedebilní.

popřípadě třeba i s JSONu

JSON ani XML právě ne – za důležitou vlastnost považuji, aby šlo zřetězit více souborům prostým napojením za sebe pomocí cat. Jako to jde s textovými soubory – ba dokonce lépe, protože u těch textových souborů si musíš dávat pozor, aby končily znakem konce řádku (což je takový dobrý zvyk, ale nejde se na to spolehnout a pak se soubory spojí blbě).

Leda mít konvenci, že po nalezení konce dokumentu začneme číst ze vstupního proudu nový dokument…

Asi by šla použít ASN.1, ale to je možná až příliš bohatý formát. Na druhou stranu je to existující standard…

BTW: něco v tomhle smyslu jsem udělal v SQL-DK – formát pro dávkové soubory – dávky se dají catem jednoduše spojovat. Nebo v Bashi napsat něco ve smyslu:

(generátor-dávky …; generátor-dávky …; generátor-dávky … ) | zpracování-dávky

Což je tedy jednoduchý binární formát, ale zase se používá jen v tom jednom programu.

Už jen to, že chceš víc tabulek podle mě naznačuje, že SQL style není dostatečně flexibilní.

SQL je dostatečně flexibilní. Běžně ti jeden dotaz může vrátit víc výsledkových sad (tabulek). Většina příkazů by vracela jednu tabulku (ls, find atd.) a některé by vracely víc propojených relací (ip, ifconfig – rozhraní + IP adresy, atd.).

Výstup z ip (sadu tabulek) by sis uložil do bashové proměnné. Tu bys pak poslal rourou nějakému příkazu, který by z toho vybral jednu tabulku. Nebo jinému, který by udělal jejich JOIN. A další rourou bys to poslal příkazu podobnému grepu, který by ale viděl hranice sloupců a uměl by filtrovat podle nich a uměl by spojovat podmínky pomocí AND a OR případně nějaké jednoduché funkce. Další rourou bys to předal příkazu, který by vybral jen některé sloupce nebo nad nimi zavolal určité funkce. Pak by byl příkaz podobný sortu, který by ale rozuměl těm sloupcům a uměl by řadit podle kteréhokoli z nich.

Dobré na tom je, že by nebylo potřeba dělat nový shell, v pohodě by šel použít Bash, a jen by stačilo specifikovat ten formát a postupně upravit programy, aby v něm uměly generovat výstup + dopsat těch pár nástrojů (grep, cut, sort…).

No nic, radši toho už nechám, mám z těch databází asi nějaké profesionální deformace

_{[1] list one file per line
[2] viz ls | sort vs. ls}

[Josef Kufner]

Ten docopt je pěkný, díky.

[xkucf03]

Nicméně, pokud bych si mohl vybrat, nějaký rozumější Basic byl rozhodně silnější jazyk, než je bash. A kdybych si mohl vybrat, dal bych Basicu před bashem rozhodně přednost.

K shellům typu BASH mám taky různé výhrady, ale tohle mě celkem překvapuje – BASH má taky řadu dobrých a unikátních vlastností.

Jak by se v tom „rozumnějším BASICu“ třeba spojovalo víc příkazů pomocí rour? Jak by se přesměrovával standardní vstup/výstup? Jak bych tam třeba zapsal tohle:

(cat soubor.txt; echo "další hodnoty") | nějaký-příkaz > jiný-soubor.txt

? Co třeba takové proměnné prostředí předávané spouštěným procesům? A co proměnné snadno vkládané do textu?

echo "statický text $promenna zase text"

BASIC mi přijde jako jazyk pro tvorbu jednoho programu – zatímco BASH je jazyk pro propojování existujících programů, spouštění podprocesů.

Na druhou stranu takové IFy a cykly v BASHi by šly určitě vylepšit – ale spíš bych šel směrem céčka/javy než směrem BASICu.

[Miloslav Ponkrác]

To je věcí rozšíření Basicu o jeden dva příkazy.

Já netrvám na Basicu. Je mi v zásadě jedno, jestli základ shellu bude tvořit C/C++/Python/Basic/cokoli rozumného.

Rozšířením programovacího jazyka o 1—2 příkazy v syntaxi (a to ještě třeba C++ nebo Python by vše z bashe dokázalo zapsat téměř přímo, není třeba je rozšířovat) a použít jako shell vznikne mnohem kvalitnější shell, než opakem. Tedy mít sh a snažit se z něj udělat nalepováky relativně dřevěný a neschopný programovací jazyk jako je bash.

Právě si myslím, že použití Basicu jako shellu v 8bitech, nebo LISPu v LISP mašinách, prostě schopného programovacího jazyka, je velmi nedoceněnou věcí. A IMHO mnohem lepší, než unixové standardní shelly.

Ne vše unix udělal nejlépe.

Miloslav Ponkrác

[Fluttershy, yay!]

Jde používat třeba Scheme shell (scsh).

[xkucf03]

Rozšířením programovacího jazyka o 1—2 příkazy v syntaxi (a to ještě třeba C++ nebo Python by vše z bashe dokázalo zapsat téměř přímo, není třeba je rozšířovat)

To je právě otázka, jak by to vypadalo. V BASHi mám (, ), |, >, <, &&, || a dají se v tím elegantně propojovat procesy. V programovacím jazyce by to musely být funkce, tzn. názevFunkce(parametr1, parametr2) nebo v lepším případě vlastní operátory v C++, ale nevím, jestli by to tam šlo udělat srovnatelně jednoduché jako v BASHi.

Další věc jsou názvy spouštěných programů – v BASHi ho napíšu jednoduše bez jakýchkoli uvozovek a shell si ho už najde v cestě. V programovacím jazyku bych ho musel psát asi jako textový řetězec v nějakých uvozovkách. Případně by se musely nějak zaregistrovat funkce pro všechny programy v cestě a pak bych psal třeba něco jako

uname("-a")

ale je to zase takové zesložitění a odstínění uživatele od podstaty věci.

A potom parametry příkazů – je to pole textových řetězců, ale v BASHi mám dost velkou volnost a můžu je psát bez uvozovek

ls -l -a

a uvozovky přidám, až když je potřebuji:

ls -l -a "Můj adresář"

V programovacím jazyce bych většinou musel konstruovat to pole nebo aspoň psát textové hodnoty do uvozovek/apostrofů.

vznikne mnohem kvalitnější shell, než opakem

Kvalitnější určitě, ale nevím, jestli uživatelsky přívětivý.

V zásadě jsou to tři různé úlohy:

• interaktivní práce
• skriptování, lepení programů, propojování procesů
• programování

Na programování bych si jednoznačně vybral něco lepšího než BASH.

Pro interaktivní práci ale chci co nejjednodušší syntaxi, psát co nejméně, liší se to v tom, že píšu ad-hoc příkazy, sedím u toho, vím, co právě spouštím, může to být i trochu „nebezpečné“ – nechci řešit nějaké uvozovky, závorky, pole, pokud to není nezbytně nutné – chci prostě spustit příkaz, předat mu parametry, případně udělat nějakou jednoduchou rouru. K tomu bych fakt nechtěl používat plnohodnotný programovací jazyk.

To skriptování (píšu skript do souboru pro pozdější opakované spouštění) je někde mezi tím, ale taky nejsem moc zvědavý na nějaké uvozovky, závorky, pole atd. pokud to není nutné. Tady by připadal v úvahu třeba Perl, který má stále dostatečně volnou syntaxi, ale přeci jen je to víc programovací jazyk než BASH. Nicméně to propojování procesů už tam není tak elegantní jako v BASHi.

[Miloslav Ponkrác]

Podívejte se jak jednoduše některé programovací jazyky zvládly vložené přímé SQL příkazy. Taky neplatí žádné z těch výhrad, co píšete.

[Martin Mareš]

Pokud víte o nějakém, který to zvládl jednoduše, elegantně a efektivn, sem s ním. Všechny případy, které jsem zatím potkal, byly dost ošklivé bastly.

[Martin Mareš]

... byť nevylučuji, že tento dojem alespoň zpola vznikl tím, že SQL samo je ošklivý bastl.

[Miloslav Ponkrác]

Toto všechno jsou implementační detaily. A jsou snadno řešitelné, aby to v programovacím jazyce bylo elegantní a přímé.

[Fluttershy, yay!]

Lisp jsi asi nikdy neviděl...?

přeci jen je to víc programovací jazyk než BASH

Turingovsky úplné jsou stejně.

[Miloslav Ponkrác]

Přesně LISP jsem měl na mysli. Myslím, že je velmi blízko tomu, co by mohlo bát dobrým skriptovacím jazykem, mnohem schopnějším, než cokoli v bashi.

[Fluttershy, yay!]

Však není nutné používat zrovna bash (přestože vyhnout se mu nejde). Je tu zsh, C shell, zmíněný scsh aj.

[Miloslav Ponkrác]

Původně jsem psal svůj názor na podporu projektu, o kterém je zprávička. Když jsem viděl video, tak mi to strašně připomnělo práci s 8bitovým Atari.

Nemám unixové shelly prostě rád, jsou to nejdřevěnější způsoby ovládání, jaké kdy která platforma vymyslela. Jako interaktivní vykonávač příkazů je mi sh/bash nesympatický, protože nic neumí (ani to co uměly 8bity dávno), jako skriptovací a programovací jazyk je sh/bash rovněž na pendrek.

Rozdíl mezi skriptovacím a programovacím jazykem není totiž v ideálním případě žádný.

Pod linuxem jsem se klasickému unixovému shellu vždy vyhýbal. Je to prostě nejhorší způsob ovládání platformy, jaký jsem kdy viděl. Pokud jsem před 30 lety dělal u vzdálených unixových terminálů, dokázal jsem unix shell ocenit. Ale jako desktopový systém ho považuji za obludného dinosaura. Příkazová řádka lze udělat mnohlém lépe a luxusněji.

A tím tu končím. CO jsem chtěl říci, to jsem řekl.

[Fluttershy, yay!]

Hmmm, ale to nic neříká o tom, co je špatně s tím, co jsem vyjmenoval.

[xkucf03]

Lisp jsi asi nikdy neviděl...?

Viděl, ale nepřijde mi to čitelnější než Bash a psát v tom skripty nebo dokonce interaktivně v konsoli bych asi nechtěl.

Jak by tam vypadalo třeba tohle:

(cat soubor.txt; echo "další hodnoty") | nějaký-příkaz > jiný-soubor.txt

Neříkám, že Bash je dokonalý, a rád se přiučím něco lepšího, ale zatím mi přijde, že tu lidi jen kopou do Bashe, aniž by navrhli alternativu, ukázali konkrétní lepší syntaxi.

Turingovsky úplné jsou stejně.

Mluvím o vhodnosti pro daný účel – jde třeba o datové typy, struktury, objekty…

[Fluttershy, yay!]

Jak by tam vypadalo třeba tohle:

Scheme shell jsem odkazoval o fous výš, můžeš se podívat. To, že v něm prostředí interpreta za moc nestojí (doplňování a tak), je věc druhá, ale netýká se ani tak jazyka, jako toho, že ho nikdo neimplementoval, což je technický detail. Kdyby to roli hrálo, nechápu obhajobu bashe, když existuje např. zsh.

[xkucf03]

Scheme shell jsem odkazoval o fous výš, můžeš se podívat.

Koukal jsem:

Print a list of all the executables available in the current PATH to the standard output:

#!/usr/local/bin/scsh -s
!#
 
(define (executables dir)
  (with-cwd dir
    (filter file-executable? (directory-files dir #t))))
(define (writeln x) (display x) (newline))
 
(for-each writeln
  (append-map executables ((infix-splitter ":") (getenv "PATH"))))

pro srovnání:

#!/bin/bash
IFS=":" read -a CESTY <<< "$PATH"
find "${CESTY[@]}" -executable -type f

Jak by tedy vypadal ten jednořádkový příklad, co jsem psal? Nějak si to nedokážu představit (nebo si to představuji moc složitě).

[Fluttershy, yay!]

(náhodné pozorování)

Je pozoruhodné, že ten kód ve Scheme je čitelný, zatímco to v bashi vypadá, jako kdyby se kočka prošla po klávesnici. Pravda, s trochou syntaktického cukru by to i ve Scheme vypadalo jako Ruby (aka Matz Lisp), tzn. skoro jako Perl/bash. Ale jsou tam makra...

[Fluttershy, yay!]

Teda prefixové Ruby.

[pavlix]

Tak hlavně je ten lisp o něco komplikovanější, ale nemá žádné zásadní závislosti. Předpokládám, že pokud bys v lispu jen zapsal volání příkazu find, že to bude skoro stejně jednoduchý zápis jako v bashi, zvlášť kdybys netrval na vnějších závorkách u jednořádkového vstupu.

A na příkazu find by stejně jako na tom céčkovském bylo nějtěžší zpracovat seznam parametrů a na základě toho volat jinak triviální akce. Pravděpodobně bys implementoval find jenom jako traversal tool a zbytek bys místo speciálního jazyka zase řešil v lispu.

[Fluttershy, yay!]

BTW

Viděl, ale nepřijde mi to čitelnější než Bash

<flamebait>Tak to si zajdi k optikovi.</flamebait>

[xkucf03]

Stále čekám, až mi někdo přepíše ten příklad výše do jiného jazyka

[Miloslav Ponkrác]

Ten jiný jazyk vznikne třeba v budoucnosti. Jinak já nejsem zastánce nejkratších kódů, ale nejlépe udržovatelných. Obvykle stačí vhodná knihovna a cokoli v jakémkoli jazyce uděláte jediným příkazem šitým přesně na ten případ.

Jednoduše doufám, že vývoj půjde dále. A jsem rád, že žádná jiná platfroma nepřevzala unix shell v syrové podobě.

A jsem rád, že na každé jiné platformě se snaží, aby příkazový řádek byl nad programovacím jazykem alespoň trochu schopným. A v tomto mi LISP a Basic přišly jako dobré pokusy.

Projekt Xixi je mi sympatický, byť je o něčem trochu jiném.

Kdybych si mohl vybrat, zda budu v příkazové řádce mít Basic či LISP a nebo libovolný z rodiny klasických unix shellů včetně bashe, vyberu si s radostí to první.

[xkucf03]

Jinak já nejsem zastánce nejkratších kódů, ale nejlépe udržovatelných.

Stejně jako já, souhlasím s tím – u programování.

U psaní skriptů tak napůl (i když spíše ano), ale u interaktivní práce vůbec – tam toho chci psát co nejméně – pár písmenek, doplnit tabulátorem (včetně parametrů: bash-completion nebo ekvivalent), nepsat uvozovky kolem textových řetězců, pokud to není nutné…

[Josef Kufner]

A tady se pomalu dostáváme k rozdílu mezi programovacím jazykem a shellem.

Programovací jazyk musí být dobře čitelný a udržovatelný, klidně i za cenu trochu větší ukecanosti – závorky, uvozovky, středníky, deklarace proměnných a složitějších typů, …

Od shellu je na druhou stranu očekáváno, že vyjádření příkazu bude co nejstručnější a nejefektivnější. Udržovatelnost je nepodstatná, neboť příkaz je na jedno použití.

Klíčem k úspěchu je tedy propojit programovací jazyk s shellem tak, aby se jednoduché příkazy psaly jednoduše a komplikované skripty se také psaly jednoduše.

Jako celkem prosté řešení mi přijde použít dva jazyky. Ovšem pokud se uživatel horko těžko naučí jeden (bash), je nereálné po něm chtít umět i druhý (např. python)...

[:::]

Myslim ze perl by byl skoro idealni shell jazyk. Pri pouziti backticks je mozne spoustet a retezit procesy:

`a | b | c`;

Jenom pro praci s vetsim vystupem by to chtelo aby vysledek tohodle nebyl retezec, ale stream objekt.

Pri praci v interaktivnim modu by to mohlo fungovat tak ze by se backticky automaticky vlozili kolem kazdyho radku. Tim bys ziskal zakladni spousteni a retezeni procesu s velice jednoduchou a uspornou syntaxi, a kdyz bys potreboval vic tak bys nejak prepnul mod a mel k dispozici cely perl...

[xkucf03]

Ale zase tak jednoduché to není – schválně si zkus spustit třeba mc nebo htop.

Udělat to použitelné pro interaktivní práci by dalo IMHO příliš práce a asi to za to nestojí. Pro skriptování to může být použitelné (i když většinou pracuji stylem, že základem je bashový skript a Perl volám až z něj pro konkrétní úlohy).

[wamba]

tak existuje Zoidberg, který kombinuje Perl s shellem.

[Bystroushaak]

Takže už jsem příkazoval v pythonu i leččems.

Jen kdyby to někdo ještě nezachytil; K tomuhle doporučuji ten mnou zde již několikrát avizovaný sh modul.