EMACSulation

di
Eric Marsden
traduzione di
Michele Recine
Molte persone hanno Emacs come editor principale lanciato da Elm per editare i messaggi di email. Usare Emacs in tale modo è ovviamente poco vantaggioso in quanto per ogni documento realizzato si apre una sessione di Emacs, ciò causando prestazioni ridottissime dovute alla frammentazione nell'uso della memoria. Per ovviare a questo problema si può utilizzare la variabile di ambiente EDITOR.


Emacs come server

Molte persone hanno Emacs come editor principale lanciato da Elm per editare i messagi di email. Lancianre Emacs in tale maniera è un peccato, a causa della frammentazione nell'uso della memoria, ma anche perchè il rinfresco di  Emacs non condivide i buffers e a la catena (deposito per il testo del taglia/incolla) con le altre invocazioni dell'applicativo. Invece di eseguire Emacs per ciascun documento, potete settare la variabile di ambiente EDITOR a emacsclient.

Il meccanismo di servizio di Emacs permette ad un unico processo Emacs di soddisfare qualsiasi richiesta di editazione di altre applicazioni. Al fine di abilitarlo è necessario aggiungere una linea simile a (server-start) in ~/.emacs. Quando si indica emacsclient filename, il programma ricerca un processo Emacs (eseguendone uno se necessario) e invia un messaggio di richiesta edit filename. Il processo chiamante (la  shell ad esempio) è bloccato mentre il file è in editazione. Quando avete terminato scrivete C-x # ed il client sarà sbloccato.

Gnuserv

Gnuserv è un meccanismo di chiamata più sofisticato per  Emacs, scritto da 
Andy Norman (anche autore di ange-ftp). Permette di inviare comandi arbitrari in  Emacs Lisp a un processo Emacs in esecuzione sia sulla macchina locale che su una macchina connessa alla rete.
  1. Se state utilizzando  XEmacs tutto è settato in maniera opportuna; sara solo necessazio aggiungere (gnuserv-start) al vosto file ~/.emacs.
  2. Prelevate  il  gnuserv-2.1alpha RPM dalla distribuzione Redhat, oppure  the .deb  per la  Debian Hamm e saltate al passo 6 ;
  3. Scaricate il sorgente ;
  4. Editate  config.h ( suggerisco di usare #define DONT_USE_LITOUT) e gnuserv.h, dove scegliete il metodo di comunicazione (quello preimpostato è Internet domain sockets, che è necessario se intendete connetervi in maniera remota) ;
  5. Inserite il file gnuserv.el in qualche posto del percorso di ricerca di  Emacs. Assumiamo che abbiate la directory ~/elisp/  nella quale voi inserite le estensioni  Emacs Lisp; un alternativa è di copiare  gnuserv.el in una directory particolare per  Emacs Lisp come /usr/lib/emacs/site-lisp (scrivete C-h v load-path per visualizzare una lista delle possibilità) ;
  6. Aggiungete qualcosa del genere al file ~/.emacs :
  7.     (setq load-path (cons (expand-file-name "~/elisp") load-path))
        (autoload 'gnuserv-start "gnuserv" "Better Emacs server support")
        (setq gnuserv-frame (current-frame))
        (gnuserv-start)
    La seconda linea dice ad Emacs che la funzione gnuserv-start è definita in un file chiamato gnuserv.el, che Emacs caricherà a richiesta. La terza linea impedisce l'impostazione predefinita di aprire una nuova finestra per ciascun file che si va ad editare (lasciatelo così se lo preferite). La terza linea avvia il server.
Per controllare che tutto funzioni, scrivete
    ~$ gnuclient <filename>
che chiede ad  Emacs di aprire <filename>, come un cliente di emacs. Se ciò non funziona (con un messaggio simile a ``Refused connection'' oppure ``Broken pipe''), salatate alla seziones Sicurezza. Potete inviare anche un pezzo di  Emacs Lisp :
    
    ~$ gnudoit '(message "Hi there, %s!" (user-full-name))'

Applicazioni

Ora potete fare qualsiasi tipo di cose. Potete ottenere due copie di  Emacsen sulla rete per giocare a ping pong, inviando messaggi avanti e dietro. Potete usare Emacs come server di script CGI, approfittando della potente libreria senza incorrere nel sovraccarico di dover lanciare un interprete per ciscun script (un poco come il meccanismo FastCGI ). Ad esempio, costruiamo insieme un interfaccia esterna per lo psicologo inserito in Emacs:
     (defun eliza-start ()
       "Fire up the doctor."
       (interactive)
       (doctor)
       ;; We only have to type return once under this interface.
       (re-search-backward " twice" nil t)
       (replace-match "")
       (goto-char (point-max))
       (buffer-substring (point-min) (point-max)))

     (defun eliza-continue (str)
       "Send a string to the doctor and return her response."
       (interactive)
       (switch-to-buffer "*doctor*")
       (insert "\n" str "\n")
       (doctor-read-print)
       (save-excursion
         (re-search-backward "\n\n\\(\\(.+\n?\\)+\\)\n\n")
         (match-string 1)))

     (defun eliza-cleanup ()
       "Pay the bill and leave."
       (interactive)
       (let ((buf (get-buffer "*doctor*")))
          (if buf (kill-buffer buf))))
Tutto questo può essere utilizzato da linea di comando (per l'uso di CGI dovete pensare alla questione intricata dell'accesso concorrente) con uno script simile a:
     #! /bin/sh
     
     gnudoit '(eliza-start)'
     while read line
     do
         gnudoit "(eliza-continue \"$line\")"
     done
     gnudoit '(eliza-cleanup)'
Potete trovare anche usi costruttivi della tecnologia gnuserv, simile alla esecuzione di Gnus (un cliente Emacs per news/email) e al trasferimento con  ange-ftp da un  ``network Emacs'', cosi che il vostro Emacs primario non è affetto dai fermi di rete. Potete anche comunicare con Emacs attraverso una crontab, dicendogli di caricare una pagina web con Emacs/w3, o di inviare a qualcuno una email. Potete usare le email/news API di terze parti per Netscape per chiamare  Emacs invece dei clients di posta e news di cui e dotato Netscape. E' anche utile per inviare comandi a Emacs da un menu di un  window manager .

Cosiderazioni sulla Sicurezza

Sempre di più le distribuzioni Linux usano buone  X security come settagio dei sistemi. Si osserverà che, ad esempio, quando eseguite una "su" alla root su i moderni sistemi , non sara più possibile eseguire un clients X, perche il server X  è protetto da un cookie xauth .

Mentre permettere l'acceso al vostro visualizzatore X e abbastanza sbagliato (qualcuno potrebbe catturare tutto quello che scrivete, per esempio), fornire l'acceso remoto al vostro processo  Emacs e molto più preoccupante, cosi Emacs può eseguire comandi arbitrari con la vostra id, cancellare files, inviare email di insulti al Presidente degli Stati Uniti, etc.

Così la versione 2.1, di gnuserv è capace di utilizzare l'autenticazione MIT-MAGIC-COOKIE-1 per le richieste remote. Questo protocollo usa i contenuti del vostro file ~/.Xauthority , come descritto nelle pagine man per  xauth(1). Gnuserv necessita un  cookie per visualizzare il numero 999, che voi potete creare come segue (blade è il nome della macchina) :

    
      ~$ xauth add blade:999 . `cat /etc/passwd | md5sum` 
      ~$ xauth list
      blade/unix:0  MIT-MAGIC-COOKIE-1  bc1d627babdbabe9d1f288d2b57c348f
      blade:999  MIT-MAGIC-COOKIE-1  d89570b20925d401c05a79be67159cae
(`cat /etc/passwd | md5sum` è solo una maniera conveniente per generare il cookie; su molti sistemi  Linux sarete in grado di utilizzare il comando mcookie, oppure potete costruire a mano il vostro cookie). Ora devreste essere in grado di utilizzare gnuclient/gnudoit sulla macchina locale. Il prossimo passaggio e quello di trasferire il cookie su ciascuna macchia remota su cui intendete accedere ad  Emacs, con un comando simile a :
    
      ~$ xauth extract - blade:999 | rsh remotehost.edu xauth merge -
Se non eseguite  X dovete affidarvi ad un sistema di controllo basato sull' host: la variabile di ambiente GNU_SECURE si assume che punti ad un file che contiene una lista di macchine che sono autorizzate ad aprire connessioni ai vostri processi Emacs. Infine, se la vostra macchina non è in rete, probabilmente sarete già passati alla prossima sezione.

Come Funziona?

I vostri comandi prendono una strada abbastanza convoluta per ritrovare Emacs. Ci sono quattro parti coinvolte in una transazione: il  ``client'', o programma che richiede un servizio ad Emacs (Elm ad esempio), il programma gnuclient (che è in funzione su una macchina richiedente), il processo  gnuserv  (che è attivo  su una macchina che esegue Emacs), e certamente il processo  Emacs stesso. Essi comunicano come indicato nell seguente diagramma:

Communication diagram (3 kB)

Il Tallone di Achille del sistema è che il programma gnuserv muoia per qualche ragione, tutto va a finire in un blocco. Una metodo di comunicazione alternativo che coinvolge un numero minore di parti può essere inspirato dal protocollo di chiamata remoto di Netscape. Le funzionalita del  gnuclient potranno essere aggiunte direttamente ad Emacs, e una richiesta  a gnudoit si assomiglierebbe a:

    emacs -remote -lisp '(message "Hi")'
Il nuovo processo Emacs ricercherebbe  un processo esistente di  Emacs al quale consegnare la richiesta, o servirla direttamente. Lo svantaggio che ciascuna richiesta sarebbe più lenta, così  Emacs necessita di una chisura di processo ogni  volta. L'immagine è molto spesso nel disco di cache, cosi tutto questo diventa catastroficamente lento (tutto questo funziona bene con Mozilla, che è  molto più grande di Emacs).

Il prossimo numero ...

Ho ricevuto abbastanza email che chiedono informazioni su come customizzare vari aspetti di  Emacs, cosi cerchero di trattare questo vastissimo tema il prossimo mese, e di discutere del package Customize . Non esitate a contattarmi presso  <emarsden@mail.dotcom.fr> con commenti, correzioni o suggerimenti (quali sono i vostri favoriti, possono non essere fatti senza  packege di estensione per Emacs?). C-u 1000 M-x hail-emacs !

PS : Emacs in nessun modo è limitato al solo Linux, in quando esistono realizzazioni per molti altri sistemi (e per sistemi con operatività limitata ). Tuttavia , come uno dei pezzi principali del  software libero, uno dei più potenti, complesso e customizzabile, mi auguro che abbia un suo posto nella Linux Gazette.


Per l'articolo originale: © 1998 Eric Marsden
Pubblicato sul n. 29- Giugno 1998 di Linux Gazette
Per l'edizione italiana: © 1998 LGEI