Portál AbcLinuxu, 10. května 2025 20:24
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]
Tiskni
Sdílej:
.
Ú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.
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.
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.
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?
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č?
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.
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 ;).
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 ;).
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é.
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
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…
sudo git format-patch origin/master -o /etc/portage/patches/my-group/my-package-with-versionAle pravda je, že si umím představit i pohodlnější cestu.
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.
30.6.2014 20:02
30.6.2014 11:21
30.6.2014 12:23
1.7.2014 07:08
1.7.2014 16:10
2.7.2014 14:59
2.7.2014 20:28
#!/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čí.
#!/usr/bin/tcc -run
3.7.2014 23:15
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
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á.
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.
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.
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é.
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.
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í.
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 textu1 pomocí nástrojů jako grep a cut.
Chtělo by to nějaký formát2 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
Pěkné, to už vypadá skoro jako BASH
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ě1, 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)
print() je obvykle zbytečné.
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.
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.
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.
ls("/etc", "-1")wc(ls("/etc", "-1"), "-l")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í.
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čka1 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ích2 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
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.
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:
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.
přeci jen je to víc programovací jazyk než BASH
Turingovsky úplné jsou stejně.
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…
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.
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ě).
Viděl, ale nepřijde mi to čitelnější než Bash<flamebait>Tak to si zajdi k optikovi.</flamebait>
Stále čekám, až mi někdo přepíše ten příklad výše do jiného jazyka
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é…
`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...
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).
3.7.2014 23:10
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
3.7.2014 17:32
