Newsgroup: it.comp.os.linux.iniziare
Titolo: Che cosa è una shell?

Come da oggetto.
Ed una root?
Scusate la mia inesperienza.
Grazie mille!



adesso mi tiro addosso le orde dei puristi
una shell e' il programma base di linux 
quella che ti permette di fare tutto (e meglio) da riga di comando
hai presente konsole? ecco.
root e' l'utente amministratore quello che ha il potere di fare tutto al
sistema e agli altri utenti
dare o togliere permessi (per intenderci) per l'uso del sistema
orso

  Ed una root?
Dipende dal contesto. In inglese "root" vuol dire "radice", ma in linux/unix
su applica almeno in due-tre contesti diversi.
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky

GENTILISSIMI!!!!

> Ed una root?
I> Dipende dal contesto. In inglese "root" vuol dire "radice", ma in linux/unix
I> su applica almeno in due-tre contesti diversi.
I file in  Unix e Linux sono conservati in  una gerarchia di directory
poste ad albero e le  varie partizioni fisiche sono mascherate (non ci
sono c, d, e et similia).
root o / e` la directory posta in cima alla gerarchia.
Storicamente l'utente  numericamente indicato da  Userid 0 e  gruppo 0
(che e` l'utente onnipotente del sistema) aveva la home directory in /
e da qui il nome root anche per l'utente.
Sotto X11  la root  window e`  invece lo sfondo  in cui  puoi comunque
avere output dinamico (e senza cazzabubbole come ActiveDesktop).
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/

  Gli ultimi due proprio no!
Se prendiamo la definizione in senso lato, rischiano di rientrarci.


* \#NonValid#/ [2004-05-24 19:03]:
Leggiti gli appunti di informatica libera:
 
http://a2.swlibero.org/
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

> Gli ultimi due proprio no!
I> Se prendiamo la definizione in senso lato, rischiano di rientrarci.
Oddio, in  senso microsoft.  E se  la prendo in  senso abbastanza lato
anche il  mio mestolo di cucina  e` una shell :)  :) :). L'informatica
NON  e` terreno di  sensi lati,  e` il  dominio dei  linguaggi formali
privi di ambiguita`.



Non si dice che i sistemi unix-like sono come una setrie di gusci (=livelli)
concentrici in cui uno contiene l'altro. In questo caso il kernel potrebbe
essere inteso come il guscio software che contiene l'HW, e la shell è un
altro livello sw (o guscio) che contiene il kernel. A sua volta è contenua
da altri programmi da linea di comando, che a loro volte possono essere
contenuti da interfaccia grafica.
Del resto, come già mi fu detto qui, se ci pensi bene
shell=conchiglia=guscio.
Un po' come le matriosche.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 privi di ambiguita`.
I file manager sono a tutti gli effetti shell grafiche, c'e' poco da
definire in senso lato. Che poi il termine shell venga comunemente
associato alla linea di comando e' un altro par di maniche, ma di fatto
fanno la stessa identica cosa.
HTH,
  ngw

  linguaggi formali privi di ambiguita`.
Bene, ridefinisco:
Se prendiamo la definizione di shell, nautilus e konqueror ci rientrano.
Il "senso lato" e` stato formulato male. Nel senso comune, shell e` quella
a caratteri. Ma se si prende la definizone (il "senso lato" della mia infelice
frase originaria), come detto, nautilus, konqueror ed explorer ci rientrano.


> privi di ambiguita`.
NW> I file manager sono a tutti gli effetti shell grafiche, c'e' poco da
NW> definire in senso lato. Che poi il termine shell venga comunemente
NW> associato alla linea di comando e' un altro par di maniche, ma di fatto
NW> fanno la stessa identica cosa.
Peccato che la shell non faccia SOLO gestione di file. Un file manager
ha un sottoinsieme ridotto delle possibilita` di una vera shell (e dato
che il nome shell e` nato con Unix se non erro...) anche se questo non
vuole dire sia inutile.


> linguaggi formali privi di ambiguita`.
I> Bene, ridefinisco:
I> Se prendiamo la definizione di shell, nautilus e konqueror ci rientrano.
Hanno la medesima capacita` di /bin/sh ?
A naso NO (e nautilus e` perdigiunta "maleducato" verso X).
Vedi altra risposta pubblicata.


 vuole dire sia inutile.
Qui c'e' una discreta confusione.
La definizione di shell e' abbastanza chiara, si tratta di un
semplicissimo "layer" sul sistema operativo, che non specifica in alcun
modo quale funzionalita' debba implementare se non in standard poco
seguiti, soprattutto quando si arriva alle varie shell (che prima o poi,
si dice, verranno cambiate ecc. ecc., ma che di fatto restano sempre
uguali). L'unica conforme alla lettera a POSIX.2 credo sia bash, con
l'apposita opzione --posix
Seguendoti alla lettera, si potrebbe dire che Nautilus/Konqueror
gestiscono i file in modo estremamente piu' efficente di /bin/sh, dato
che, ad esempio, con /bin/sh non puoi nemmeno listarli (hint: which ls).
Anche l'assunto per cui una shell per essere una shell deve fare le
stesse cose che fa /bin/sh e' errato, non e' specificato da nessuna
parte.
Visto che parlavi di Windows credo che nemmeno il classico 
command.com
implementi tutte le funzionalita' della Bourne Shell, cio' non significa
che non sia una shell.
HTH,
  ngw

> vuole dire sia inutile.
NW> Seguendoti alla lettera, si potrebbe dire che Nautilus/Konqueror
NW> gestiscono i file in modo estremamente piu' efficente di /bin/sh, dato
NW> che, ad esempio, con /bin/sh non puoi nemmeno listarli
Vabbe`.  Un megagrammo  di  sofismi.  
Verissimo che da sola /bin/sh non lista i file (bash si). Ma la bourne
shell ha il solo compito  di interpretare sequenze di comandi. Fa poco
e` vero.   Ma collaborando con tutto  il resto si  lascia dietro certi
pachidermi grafici di kilometri. L'unico  caso dove un file manager e`
(per me) piu` comodo sono le  directory strapiene di roba (i.e. la mia
home dopo un paio di anni).
E sopratutto un file manager  usualmente non ti permette di automatiz-
zare le cose, come dice mia moglie "gli manca il for" (e` un semi-joke 
ovviamente).
Ah, gestiscimi il bootstrap di una macchina con Konqueror.
NW> (hint: which ls).
Non e` l'unico, e` il piu` comodo.
NW> Anche l'assunto per cui una shell per essere una shell deve fare le
NW> stesse cose che fa /bin/sh e' errato, non e' specificato da nessuna
NW> parte.
Si.  Nei  sorgenti  di  shell.  Prima di  shell  nessun  programma  di
interfaccia con il sistema si chiamava shell. La definizione di shell
come layer sul nucleo nasce proprio con Unix (famosa l'immagine delle
sfere concentriche).
NW> Visto che parlavi di Windows credo che nemmeno il classico 
command.com
NW> implementi tutte le funzionalita' della Bourne Shell, cio' non significa
NW> che non sia una shell.
command.com
 e` una shell, orrida. cmd.exe e` parimenti orrida anche se
gira su sistemi meno orridi.
Quella che Microsoft definisce la shell di Windows e` un'altra cosa.
E non e` una shell, nemmeno orrida.


  E non e` una shell, nemmeno orrida.
OK, dato che la programmabilita` non e` condizione necessaria per
essere una shell, cosa rende konqueror meno shell di 
command.com
?


  essere una shell, cosa rende konqueror meno shell di 
command.com
?
O, per amor di precisione,
"...essere una shell, cosa manca invece a konqueror che ha 
command.com
?"


> E non e` una shell, nemmeno orrida.
I> OK, dato che la programmabilita` non e` condizione necessaria per
I> essere una shell
No, la programmabilita` e` fondamentale per essere una shell.
Ripeto, shell  come termine per lo  strato tra l'utente  ed il sistema
nasce  con Unix.  Che se  non ricordo  male e`  il primo  sistema dove
sparisce  la  differenziazione  tra  programma  utente  e  comando  di
sisttema (che in Unix e` un programma utente).
E Linux e` un replacement per Unix.
i> , cosa rende konqueror meno shell di 
command.com
?
Gli manca il  for come direbbe mia moglie. Vedi  sopra.
E ti ripeto. Gestiscimi il bootsrap con konqueror (che e` una imitazione
di Internet Explorer, che e` un browser web). Gli manca il for :), mi sa
che non ce la fai.


  E ti ripeto. Gestiscimi il bootsrap con konqueror
il processo di boot, ad ogni buon conto, non DEVE essere gestito per
forza con script di shell. E` una scelta implementativa come un'altra.


> E ti ripeto. Gestiscimi il bootsrap con konqueror
I> il processo di boot, ad ogni buon conto, non DEVE essere gestito per
I> forza con script di shell. E` una scelta implementativa come un'altra.
Non in Unix quindi non in Linux.
E'   vero  che   e`   una  scelta   implementativa   (non  tutti   gli
S.O. gestiscono  il boot  in questo modo,  anzi forse Unix  e derivati
sono un caso anomalo), ma e` molto intelligente come scelta.


  sono un caso anomalo), ma e` molto intelligente come scelta.
Fuori discussione, questo :)


  - fare quel che faceva la prima shell di Unix (giusto?)
    ^
    `- in generale,


 writes:
I> E anche quello dei tizi di Enlightenment ("E17 will be a desktop shell", 
I> piu` o meno, oltre che di quelli della gnome foundation, se ben ricordo.
Sinceramente non  li ritengo pozzi di verita`  infallibili. Anzi, temo
che anche loro siano vittime  di quella "mutilazione mentale" che puo`
causare  l'esposizione ad uno  strumento/modo di  fare/conoscienza non
corretta  prima di aver  appreso quella  corretta. Un  mio prof  di un
esame piuttosto duro  diceva che e` pericoloso studiare  male la prima
volta. (il termine mutilazione viene invece dagli effetti che Dijkstra
attribuiva al BASIC).
I> Bien. Stavo/Stiamo cercando di astrarre i le caratteristiche che
I> definiscono la shell e rendono un programma idoneo ad essere una shell.
Una shell  e` lo strumento  indispensabile per una  interazione totale
col sistema.  Senza una shell  il sistema non e`  utilizzabile perche'
manca lo strato di interazione con l'utente e quindi e` inutile.
Le GUI non ce la fanno a svolgere questo compito completamente neanche
prese nella loro  totalita`, figuriamoci se una componente  di una GUI
da sola ce la fa.
D'altro canto c'era stata l'obiezione  che ls non e` parte di /bin/sh.
Se per questo la prima shell non aveva nemmeno test, if, case, echo ed
una serie di altri programmi che poi sono stato inclusi nel binario di
bash diventando builtin.
Ciononostante if, for, test etc sono  parte della shell di Unix si cui
sh e` la base (cercate da qualche parte l'esaurito Unix di Kernighan e
Pike, in  inglese forse "The  Unix Programming Environment"  e` ancora
disponibile). E GNU/Linux e` un replacement di Unix proprio come primo
obiettivo.
Guardiamoci in  faccia: Linux vive anche  senza X e ci  si puo` essere
produttivi anche senza  X. X e` comodo e  molto, ma non indispensabile
salvo per certe dockapp  di WindowMaker che sono perfettamente inutili
e quindi assolutamente indispensabili.
Senza  /bin/bash (o  equivalente)  Linux e`  inservibile.  E non  solo
perche' non fa  il boot. Perche' non riesci  ad interagire col sistema
(e non tiratemi fuori i daemon da remoto, che senza shell in Linux non
tiri su nemmeno la rete).
Tra l'altro imparatevi ad usare la shell di Unix, fa bene alla mente.



sostanzialmente tu usi il significato (1), ma in base al significato (2)
un filemanager e` una shell. Non una Shell (se mi passate la case
sesitiveness per motivi di chiarezza), ma pur sempre una shell. Ovvero
un modo pratico e conveniente di accedere ad *una* risorsa, il
filesystem.
Detto questo se vogliamo intavolare una discussione se sia meglio Shell
o filemanager, personalmente voto Shell.
Insomma... la questione di prima, e` tutta una questione di
'significato' attribuito ai termini. E devo ammettere peraltro che (1)
e` di gran lunga piu` comune.
Penso che la maggior parte delle persone (che sappiano cosa e` unix)
quando sentono parlare di shell pensino ad (1).
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan

  Tra l'altro imparatevi ad usare la shell di Unix, fa bene alla mente.
E chi ti dice che non lo stia gia` facendo? ;)



Copia dell'HJF, presente nella R4.0.0, l'ultima prima che Raymond andasse
berserker. Interessante, e` nata con Multics. Azz, avrei dovuto leggere la
documentazione.
EF> sostanzialmente tu usi il significato (1), ma in base al significato (2)
EF> un filemanager e` una shell. Non una Shell (se mi passate la case
EF> sesitiveness per motivi di chiarezza), ma pur sempre una shell.
Per il  significato 2  c'e` wrapper  che e` piu`  comune e  fa perdere
ambiguita` (cosa assolutamente negativa nell'ambito informatico).
EF> E devo ammettere peraltro che (1)
EF> e` di gran lunga piu` comune.
EF> Penso che la maggior parte delle persone (che sappiano cosa e` unix)
EF> quando sentono parlare di shell pensino ad (1).
Diciamo  che in un  contesto Unix-GNU/Linux  (quale i.c.o.l.i)  (2) e`
"errato" e (3) antidiluviano. :)


 writes:
I> Volevo pero` mostrare che la "definizione allargata" non viene soltanto
I> dai lidi redmondiani.
Ma  e` effetto di  una cosa  che a  volte viene  definita "mutilazione
mentale", l'effetto negativo di essere stati esposti prima ad una cosa
errata.
I> Da cui si dedurrebbe che la 'shell' e` in realta` un concetto che puo`
I> essere realizzato con piu` programmi separati;
Era cosi` in origine, per  questioni di dimensioni. Con la bash alcuni
programmi sono divantati comandi builtin.
I> In questo caso, effettivamente nautilus/konqueror non possono essere
I> considerati shell, ma tutto l'ambiente di cui fanno parte puo` esserlo
I> (Desktop shell). Se poi magari presento una patch con cui rendo
I> programmabile (in TCL, in Python, in PERL...) il suddetto insieme,
I> ecco che recupero anche la programmabilita`, rientrando quindi
I> nei canoni della shell sin qui delineati.
Si,  e non sarebbe  male. Peccato  che a  sentire certi  editoriali di
Pennington vadano nella direzione opposta.
I> Senza shell, e` inservibile, come da definizione di shell. :)
Ho detto bash o chi per lei apposta. In un sistema GNU (e GNU/Linux e`
un sistema GNU  in quanto il kernel Linux usa tutta  una serie di tool
GNU per diventare un OS completo) la shell di sistema e` la bash ma in
casi  particolari  (le microinstallazioni  su  floppy)  si puo`  usare
altro.


  errata.
Mica sono tanto convinto di 'sta cosa.
(snip sul resto, pare si sia trovato un punto d'incontro)


 berserker.
erh... in che senso?!
-- 
§       ZeD       §
§ Up da 50 minuti §
§   29/05/2004    §
§                 §

 E non e` una shell, nemmeno orrida.
Beh, io direi:
E' orrida, e non e' nemmeno una shell.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

> errata.
I> Mica sono tanto convinto di 'sta cosa.
Perche' probabilmente ti sei salvato usando la shell.
Ma c'e`  e la vedi  sopratutto quando vedi  indicare una GUI  verso il
sistema come assolutamente necessaria perche' l'interfaccia a linea di
comando  e` troppo  difficile ad  esempio, con  i  conseguenti blocchi
degli  utenti. Che  poi son  balle, che  mia suocera  Linux lo  usa, e
conoscendo mio cognato, non lo usa con una replica dell'interfaccia di
Windows.
Una  GUI  ha  una sua  utilita`,  ci  sono  N argomenti  di  carattere
psicologico  a favore.   Ma fintanto  che rimane  una  interfaccia non
espandibile e non stravolgibile castra in partenza la potenzialita` di
sviluppo  dell'utente che  rimane  convinto che  "non  ci siano  altre
strade".  Te  lo   dico  perche'  sono  anni  che   in  varie  persone
indipendentemente notiamo il fenomeno.


> berserker.
Z> erh... in che senso?!
Principalmente ha  cominciato a togliere entries che  sebbene non piu`
in ampio uso rimangono nella storia. Ed a includere termini mainstream.
Il cambio di formato anche se modaiolo non e` una cosa malvagia in se.


  Windows.
Guarda, sull'argomento CLI vs GUI sfondi una porta aperta, con
tanto di zerbino con su scritto "benvenuti". Ricordo ancora , ad esempio,
flame allucinanti (e, ovviamente in quanto flame, inconcludenti) in materia,
e stavo (e sto) dalla parte della CLI.
La potenza della bash con annessi & connessi non e` in discussione.
La ragion d'essere di questo (sotto)thread e` che, data la definzione
di shell, mi sembra(va) che anche determinate GUI vi potessero rientrare;
che programmi come nautilus/konqueror/explorer potessero essere definiti
dunque 'shell'. E da li e` partita la discussione, che, almeno dal mio
punto di vista, ha prodotto risultati interessanti.
Argomenti affini, quali, ad esempio, quale sia l'interfaccia migliore,
se la CLI possa essere usata con beneficio anche dai nuovi utenti e cosi`
via non li ritenevo interessanti ai fini del sottothread...


 writes:
I> 29 May 2004 18:09:02 +0200: [it.comp.os.linux.iniziare] "Gian Uberto Lauri"
I>  on "Re: Che cosa è una shell?":
I> di shell, mi sembra(va) che anche determinate GUI vi potessero rientrare;
I> che programmi come nautilus/konqueror/explorer potessero essere definiti
I> dunque 'shell'. 
Io 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".
i> E da li e` partita la discussione, che, almeno dal mio
I> punto di vista, ha prodotto risultati interessanti.
Indubbiamente.
I> Argomenti affini, quali, ad esempio, quale sia l'interfaccia migliore,
I> se la CLI possa essere usata con beneficio anche dai nuovi utenti e cosi`
I> via non li ritenevo interessanti ai fini del sottothread...
L'e` che sto lavorando sulla cosa... 


  L'e` che sto lavorando sulla cosa... 
Beh, argomento interessante, molto. Se pubblichi qualcosa (== anche una 
pagina web riassuntiva, mica un paper per forza o cose cosi`.) mi piacerebbe 
leggerlo.
Personalmente, tutte le volte che mi addentro nel campo rimbalzo sul muro
di gomma dell'inerzia mentale, e la cosa non e` granche` piacevole.


> L'e` che sto lavorando sulla cosa... 
I> Beh, argomento interessante, molto. Se pubblichi qualcosa
Se  esce esce  via web,  e` un  commento all'editoriale  pubblicato da
Pennington e poi  tradotto sul Pluto Journal. Se  ti va di contattarmi
per e-mail il dominio e` eng dot it.


 L'e` che sto lavorando sulla cosa... 
Concordo anch'io sul fatto che le shell testuali siano di qualche ordine
di magnitudine superiori a quelle grafiche sotto piu' o meno tutti gli
aspetti, era solo una precisazione. Le shell grafiche sono utili giusto
quando non vuoi togliere la mano dal mouse, anche per gestire la propria
home anche la classica Bourne Shell (che io ho nuda e cruda, voi presumo
un alias su /bin/bash) e' superiore, non fosse per il fatto che e'
possibile usare le varie wildcards, per non parlare di find (e che per
un uso effettivo di Nautilus la tastiera la devi comunque usare).
Non stavo mettendo in discussione quello, e tra l'altro ho poca
esperienza di Windows, se mi e' durato un anno e' tanto, uso Unix da
qualche anno di piu'.
HAND,
  ngw

> 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.
Shell 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...
NW> non deve essere programmabile.
Vorrei vedere quella di MULTICS che ha dato il via alla cosa cosa faceva. 
In 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.
E non hai mai trovato nella tua vita cose cosi` ovvie che la gente si e`
dimenticata di formalizzarle dandole per scontate ?
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.
NW> 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).
Quanto 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.
NW> 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 ?
Continuo a pensare che come  shell Emacs si lasci indietro Nautilus di
miglia :),  per lo meno  e` rispettoso dei programmi  preesistenti che
incontra.


 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

> incontra.
NW> Tant'e' che per farlo girare su X decentemente l'hanno dovuto forkare :)
Cazzate.  Quello ottenuto dal fork  ha e` stato ampiamente raggiunto e
probabilmente  sorpassato, e`  meno  efficiente e  mi  pareva di  aver
sentito voci di  carenza di mantainer.  Ed il fork  e` stato fatto per
motivi di licensing in quanto Stallman non voleva includere del codice
che non era libero.
Senza contare che le ultime  versioni sono diventate un pelino cafone.
Ho provato  ad installare  XEmacs per venire  incontro agli  utenti di
tale editor  che avevano  rogne con la  generazione delle faces  di un
modo che  ho pasticciato, la  prima cosa che  ha fatto e`  stata sput-
tanare  la configurazione  dello GNU  Emacs.  Meno male  che avevo  il
backup.
Invece per molto  tempo molta gente lo ha usato  come login shell. Oh,
poi in  un buffer di Emacs  lanciavano la shell vera  e propria avendo
quindi a disposizione  tutta una serie di "servizi"  che la vecchia sh
non dava.
NW> Non so questa cosa di X e Nautilus, la vuoi spiegare ?
Semplicemente  prova a partire  con X  e un  windowmanager X,  che so,
AfterStep, WindowMaker,  gwm...  Niente  Gnome. Poi lancia  Nautilus e
guarda  se ha  rispettato  il  tuo WindowManager.   Direi  di no.   Ha
sostituito la root window di X con una nuova finestra (e vai di spreco
di memoria)  senza decorazioni grande  quanto lo schermo.  Niente piu`
menu del window manager attivabili con un click sulla root window. Bel
rispetto.
