Post by Gian Uberto LauriPost by Gian Uberto LauriIo continuo a pensare che la risposta sia no perche' c'e` un programma
originario che si chiama shell e fa certe cose -che quei tool non
fanno-, chi si basa sulla definizione 2 dell'HJF dice "si".
NW> Una shell non configura la rete (ifconfig e compagnia lo fanno, una
NW> shell *avvia* ifconfig), non permette operazioni sui file (ls, touch,
NW> more, less, mkdir, tutti esterni),
Menntre sulla prima potrei anche essere d'accordo, sulla seconda ti
dico che e` un puro esercizio retorico assolutamente assurdo.
Il dato di fatto e' che sono comandi esterni alla shell.
Tra l'altro non si capisce bene perche' usare due pesi e due misure.
Post by Gian Uberto LauriShell e` l'interprete e gli altri moduli sono stati messi all'esterno
semplicemente perche' era imbecille metterli all'interno dello stesso
eseguibile viste le dimensioni della ram. Hanno scelto invece (con
Unix) la strada dei programmi che cooperano...
E ti rispondi da solo. Tant'e' che una shell, come la intendi tu,
violerebbe pesantemente questa filosofia, sarebbe un software che tenta
di fare piu' o meno tutto. Non e' cosi', avvia programmi, che
naturalmente possono avere una interazione *decisamente* maggiore di
/bin/sh. mkdir e compagnia, tra l'altro, *non sono* parte della shell,
vengono proprio distribuiti a parte (binutils o simili da voi, da me
sono parte del core).
Post by Gian Uberto LauriNW> non deve essere programmabile.
Vorrei vedere quella di MULTICS che ha dato il via alla cosa cosa faceva.
Ai fini della discussione non e' granche' utile. Ha dato il nome "shell"
ma il concetto di shell c'e' da sempre.
Post by Gian Uberto LauriIn ogni caso e` una cosa che se la fai bene ci deve essere per il semplice
fatto che se non ti sogni l'automatizzazione delle operazione e di attuare
la cooperazione dei programmi se non al livello base della pipe.
Esattamente come command.com, che le pipe le aveva. Tra l'altro DOS era
strautilizzato proprio perche' non richiedeve granche' di hardware,
figurati avere un interprete nella shell.
Post by Gian Uberto LauriCUT
NW> Command.com, ad esempio, non era affatto programmabile, i file batch non
NW> erano script, erano "liste di eseguibili" *avviati* l'uno dietro
NW> l'altro, ma la shell DOS non aveva alcuna struttura di controllo
Non ne sono cosi` certo. Purtroppo non ho sottomano il bat che avvia
Emacs sotto Window 9x (command.com come interprete) ma mi pare chi
fossero delle strutture if.
Ti pare male, command.com non era programmabile, da qui il nome "batch".
L'unica istruzione era tale SET. BTW, anche con delle istruzioni IF non
sarebbe stato "programmabile", la battuta sul for l'hai fatta tu no ?
Post by Gian Uberto LauriNW> Le Lisp Machine, ad esempio, avevano come shell un interprete
NW> Lisp. Il magico CBM64 (sigh!) aveva come shell un interprete BASIC.
Occhio con certe affermazioni.
Le Lisp Machine erano macchine il cui HW era stato pensato per
eseguire efficentemente il LISP (e per alcune cose una JVM hardware di
oggi non penso sarebbe molto differente se non per il supporto alla
programmazione a oggetti come l'istruzione di chiamata a metodo
virtuale).
La Lisp Machine della Symbolics la conosco solo di nome e per un
programma che e` nato in quell'ambiente (ma che quando e` nato NON
usava LISP). Sicuramente il prodotto concorrente portato avanti da
Stallman aveva sotto ITS del PDP-10 e quella della Symbolics aveva
sotto un S.O. di supporto al LISP (e magari anche questa editor
esterni).
Mi sfugge in che parte hai contestato la mia affermazione. Le Lisp
Machine erano sistemi come altri, soltanto poco evoluti, e che giravano
su hardware su cui ora non faresti girare vi. Le operazioni venivano
svolte interfacciandosi al sistema operativo in Lisp, che e' un
linguaggio come un altro, e una shell come un'altra, esattamente come
bash e tcsh o ksh.
Che poi sotto Lisp da un certo punto in poi sia spuntato un sistema
operativo e' ovvio, e' normalissima evoluzione.
Post by Gian Uberto LauriQuanto al 64 il basic non era una shell, era l'unico programma in
esecuzione ma non ti permetteva l'accesso totale al sistema. 3 comandi
in croce (load, save e run, vabbe`, mettiamoci sys e sono 4) non ti
danno l'interazione col sistema.
Da questo si deduce che il C64 non permetteva l'interazione con il
sistema, non aveva una shell del resto.
Non ti accorgi che la tua testi fa acqua da tutte le parti ?
L'interprete BASIC era naturalmente la shell, e potevi accedere a
*tutto*, io ci ho perso i giorni migliori della mia vita con quei
giornalini del piffero e i POKE per far cambiare colore allo schermo.
Il punto e' che il sistema operativo era tutto li :)
Tra l'altro avrebbe *piu'* requisiti di command.com secondo i tuoi
parametri, in quanto era anche programmabile.
Post by Gian Uberto LauriNW> Tra l'altro Nautilus *e'* programmabile, in piu' o meno qualsiasi
NW> linguaggio che vuoi, incluso /bin/sh stesso.
Ha una interfaccia che prende un programma scritto al volo e lo esegue ?
Naturalmente, dove interfaccia significa doppioclick. Non capisco il tuo
stupore, e' una funzionalita' abbastanza idiota e abbastanza ovvia.
Sai che gioia per i miei lusers trovarsi lo script zenity + shell come
python (e ora pure ruby, maniaco di merda che sono) da cliccare
piuttosto che aprire il terribile terminale ?
Post by Gian Uberto LauriContinuo a pensare che come shell Emacs si lasci indietro Nautilus di
miglia :), per lo meno e` rispettoso dei programmi preesistenti che
incontra.
Tant'e' che per farlo girare su X decentemente l'hanno dovuto forkare :)
Non so questa cosa di X e Nautilus, la vuoi spiegare ?
HAND,
ngw