Warning: this is an htmlized version!
The original is here, and the conversion rules are here. |
####### # # E-scripts com vários textos em português (documentação escrita # para a CIPSGA). # # Note 1: use the eev command (defined in eev.el) and the # ee alias (in my .zshrc) to execute parts of this file. # Executing this file as a whole makes no sense. # An introduction to eev can be found here: # # (find-eev-quick-intro) # http://angg.twu.net/eev-intros/find-eev-quick-intro.html # # Note 2: be VERY careful and make sure you understand what # you're doing. # # Note 3: If you use a shell other than zsh things like |& # and the for loops may not work. # # Note 4: I always run as root. # # Note 5: some parts are too old and don't work anymore. Some # never worked. # # Note 6: the definitions for the find-xxxfile commands are on my # .emacs. # # Note 7: if you see a strange command check my .zshrc -- it may # be defined there as a function or an alias. # # Note 8: the sections without dates are always older than the # sections with dates. # # This file is at <http://angg.twu.net/e/cipsga.e> # or at <http://angg.twu.net/e/cispga.e.html>. # See also <http://angg.twu.net/emacs.html>, # <http://angg.twu.net/.emacs[.html]>, # <http://angg.twu.net/.zshrc[.html]>, # <http://angg.twu.net/escripts.html>, # and <http://angg.twu.net/>. # ####### Índice geral dos textos ----------------------- Um outro manifesto do eev (versão de junho de 2001, em andamento) # «.eevm» (to "eevm") # «.eevm1» (to "eevm1") Emacs e eev.el, ou: como automatizar quase tudo (um tutorial sobre Emacs com uma diferença importante: esse é escrito do ponto de vista certo! :) # «.emacs_e_eev» (to "emacs_e_eev") # «.lisp_hiperlinks» (to "lisp_hiperlinks") # «.code-c-d» (to "code-c-d") # «.eev» (to "eev") # «.blocos_delimitados» (to "blocos_delimitados") # «.eeg» (to "eeg") # «.ancoras» (to "ancoras") # «.mkto_dff_inn» (to "mkto_dff_inn") # «.variaveis» (to "variaveis") # «.glyphs» (to "glyphs") # «.demos_eeg2» (to "demos_eeg2") # «eevm» (to ".eevm") Um outro manifesto do eev (versão de junho de 2001, em andamento) ================================================================= 0) Quando eu era garoto e comecei a brincar com computadores, no início da década de 80, a gente tinha que aprender tudo sozinho, pelos manuais em inglês -- aliás, eu comecei a aprender inglês técnico exatamente tentando ler os manuais, passei pra inglês de verdade quando comecei a jogar Zork, vários anos depois; mas isso é outra história. Bom, voltando: eu era fascinado por computadores, e eles eram vendidos como máquinas que podiam ser programadas pra fazer tudo que fosse programável; e era evidente que algumas pessoas sabiam usá-los desse modo, já que existiam programas grandes fantásticos, como por exemplo os jogos de fliperama e de Atari (quem pegou essa época provavelmente sabe do que eu estou falando: comparando com os jogos de hoje os jogos de Atari e de flipper correspondem a experiências psicodélicas, enquanto os de hoje correspondem a TVs de 24 polegadas) -- e depois de pensar o suficiente sobre como os jogos eram feitos eu comecei a perceber como linguagens de programação eram coisas maravilhosas também, já que a linguagem perfeita permitiria que a gente programasse um jogo em tempo recorde e exatamente como a gente o tinha imaginado, sem precisar fazer muitas concessões por causa de detalhes técnicos... pois bem, então eu era fascinado por jogos e por linguagens como ferramentas pra fazer jogos, e jogos de computador eram mais poderosos do que filmes, músicas e livros: uma pessoa sem preparo e sem sensibilidade não entende uma obra de arte, mas na minha cabeça de melão TODO MUNDO entendia um jogo de computador. Acho que eu não preciso explicar mais nada, né? Se eu conseguisse programar os jogos de computador que apareciam nos meus sonhos todos os meus problemas estariam resolvidos. Mas o tempo foi passando e apesar dos meus esforços eu nunca conseguia programar nada que prestasse; eu me perdia se tentava fazer programas com mais de 30 linhas, por exemplo. Era óbvio que as pessoas que faziam os jogos e as linguagens de programação estavam usando truques e modos de pensar que eu não conhecia, e eu não estava conseguindo aprender essas coisas só pelos livros e por mexer nos programas a que eu tinha acesso... e quando eu lia as revistas "cabeça" daquela época, como Byte e Dr. Dobb's, eu via que os autores dos artigos vinham de meios que fervilhavam de idéias e onde parecia não haver uma distância muito grande entre ter uma idéia e implementá-la num programa... droga, e eu nem tinha nenhum amigo que programasse, e o máximo que eu consegui, depois de muitos anos, foi ficar amigo de um amigo do meu pai o suficiente pra que eu pudesse telefonar pra ele de vez em quando quando eu tinha dúvidas de C. Bom, eu pensava, quando eu entrar na universidade eu vou cair num ambiente parecido com o dos caras da Byte e da Dr. Dobb's... só que eu acabei indo fazer arquitetura, porque eu vi que as pessoas de ciências exatas eram insuportáveis, e quando eu desisti da arquitetura e mudei pra matemática (matemática não é uma ciência exata; matemática é uma espécie de ioga sem a caretice e com muito mais adrenalina) eu vi que não era nada daquilo: os administradores dos laboratórios de computadores nos tratavam como se nós (usuários) fôssemos hackers em potencial e nos davam o mínimo de informações e de acesso às máquinas: em 94 ou 95 a gente tinha direito de ocupar 300KB de espaço em disco e de usar uma máquina (rodando AIX, eu acho, e com pouquíssimos programas instalados) uma hora por dia; o acesso a manuais era pífio, estudantes de graduação não tinham direito a tirar livros da biblioteca da Informática, e pra conseguir me entrosar com os usuários que sabiam um pouco mais no laboratório eu aparentemente precisaria me interessar pelas coisas que eles faziam, que eram bater papo no IRC, falar besteira na sala ao mesmo tempo, e depois ir tomar cerveja e falar mais besteira. Ou seja, eu estava ferrado. Bom, chega. Isso é muito deprimente, não quero falar sobre isso agora. Em 95 eu depois de mil peripécias consegui comprar um PC-AT com 386 e CD-ROM e um CD de Linux ("Yggdrasil Plug & Play Linux - Summer '94"). Vou pular a parte de como é que eu concluí que era pelo Linux que eu devia começar e ir direto pro que aconteceu assim que eu já tinha ele instalado. # «eevm1» (to ".eevm1") 1) O Linux tinha uma interface de linha de comando parecida com a do DOS, mas muitíssimo mais bem-feita e mais conveniente; a impressão geral que dava era de que toda vez que alguém vinha com uma boa idéia para um "feature" novo esse feature era adicionado. A manpage do shell -- o shell é o programa que cuida dessa interface de linha de comando, e as manpages são uma das formas de documentação de um programa num sistema *NIX -- listava todos esses features, e eram tantos que não dava nem pra saber por onde começar... ainda por cima havia vários shells diferentes, o que indicava que várias vezes tinha acontecido de alguém não gostar do design dos shells que já existiam e resolver fazer um novo. E também não havia, pelo menos à primeira vista, nada que indicasse que os shells tais e tais eram os mais importantes e os outros eram secundários. Por sorte muitos dos programas do Linux eram arquivinhos de texto com indicações de que o sistema precisa invocar um determinado programa para executá-los; se um arquivo desses (eles são chamados de "scripts") começava com a linha "#!/bin/bash" deduzia-se que o resto do seu texto seria interpretado pelo bash, que é um dos shells -- e portanto a sintaxe desse script deveria ser bem parecida com a sintaxe que a gente usa na linha de comando quando usa o bash como shell; não exatamente igual, porque muitos comandos acabam só sendo usados quando a gente usa o bash interativamente, batendo os comandos à mão, e outros quase só são úteis pra escrever esses programinhas. Bom, mas já era um começo: lendo esses scripts (que eram cheios de comentários, aliás) dava pra aprender um monte de jeitos de usar os shells, # (find-node "(bash)Comments") # «emacs_e_eev» (to ".emacs_e_eev") Emacs e eev.el, ou: como automatizar quase tudo =============================================== Parte 1: Emacs, Lisp e hiperlinks --------------------------------- # «lisp_hiperlinks» (to ".lisp_hiperlinks") Em geral as pessoas acham que o Emacs é um editor de texto. Isso não é bem verdade, e seria mais correto dizer que ele é um ambiente Lisp que é usado na maior parte do tempo como editor de texto. # (find-elnode "Command Loop") Cada tecla que você aperta é interpretada pelo Emacs ou como um comando inteiro ou como um prefixo para um comando mais longo, que toma várias teclas; por exemplo, C-a (isto é, "control-a") geralmente corresponde à função `beginning-of-line', que move o cursor para o início da linha; C-x é um prefixo, e C-x C-e é um comando completo -- `eval-last-sexp', que executa a expressão em Lisp que está logo antes do cursor. Um outro exemplo um pouco mais estranho é a tecla M-x ("meta-x"; na maior parte das configurações isso é o mesmo que "alt-x"), que permite executar comandos pelo nome -- M-x eval-last-sexp é o mesmo que C-x C-e. # (find-enode "Keys") # (find-enode "Moving Point" "`beginning-of-line'") # (find-enode "User Input" "Meta") # (find-enode "User Input" "<ALT> which is really a <META> key") # (find-enode "M-x") # (find-enode "Completion") # (find-enode "Minibuffer") # (find-enode "Key Help") Digamos que você esteja editando a versão em texto deste artigo. Se você puser o cursor logo depois do "(+ 1 2)" daqui de baixo e bater C-x C-e você vai ver um "3" aparecer na última linha da tela (no espaço chamado de "minibuffer"); o que aconteceu foi que você executou a expressão em Lisp "(+ 1 2)", o que não teve nehuma conseqüência muito interessante, e a expressão retornou o valor 3 -- a soma de 1 e 2. (+ 1 2) # (find-elnode "Lists as Boxes") # (find-elinode "Run a Program") # (find-enode "Lisp Eval") # (find-elnode "Functions for Key Lookup" "Function: key-binding") # (key-binding "\C-x\C-e") Se você executa uma das expressões abaixo (também com C-x C-e, obviamente) o Emacs abre o arquivo /etc/inittab, no primeiro caso, e o "arquivo" ~/ -- o seu home directory -- no segundo; como o ~/ é um diretório e não um arquivo normal o Emacs vai mostrar o conteúdo do diretório de uma forma que faça sentido e entrar no modo "Dired", em que certas teclas vão ser interpretadas de modos especiais; por exemplo o "q" sai do modo Dired, e o Enter abre o arquivo ou subdiretório que está na linha em que o cursor está. Como a função find-file está associada à seqüência de teclas C-x C-f, teria sido equivalente bater C-x C-f /etc/inittab ou C-x C-f ~/. (find-file "/etc/inittab") (find-file "~/") # (find-enode "Dired") # (find-enode "Visiting" "`find-file'") Se você tiver carregado no seu Emacs a biblioteca eev.el (possivelmente seguindo as instruções de instalação que estão no apêndice) então várias outras funções vão estar definidas, e passa a ser bastante conveniente usar essas funções para fazer hiperlinks em arquivos de texto; as funções find-enode, find-elnode e find-elinode, que já apareceram acima sem grandes explicações, abrem páginas da documentação em formato "info" do Emacs -- do próprio manual do Emacs, do manual do Lisp do Emacs, e de um outro manual chamado "Introduction to Emacs Lisp", respectivamente. Se uma chamada a uma função dessas tiver um parâmetro extra além do nome da página, ele é interpretado como um string que o Emacs tem que procurar no texto; o cursor é posto logo depois da primeira ocorrência desse string. Se você estiver lendo esta página em formato HTML isso não vai funcionar: o seu browser vai abrir a página certa, mas não vai localizar a posição indicada. # (find-angg "eev.el" "find-") # (find-angg ".emacs" "new_goto-position") A função `find-fline', definida no eev.el, é uma versão do `find-file' que aceita o parâmetro extra que diz por que string procurar; ela tem esse nome porque quando eu comecei a escrever essas funções (lá pelos idos de 1995) o parâmetro extra era sempre um número, que era interpretado como um número de linha. Hoje em dia o parâmetro numérico ainda é aceito, mas é bem mais conveniente usar strings, já que um link para string em geral continua fazendo sentido quando o arquivo é alterado. # «code-c-d» (to ".code-c-d") O eev.el também define muitos outros tipos de hiperlinks: para arquivos, para tags, para documentação em HTML, e para manpages; os para manpages (e outros tipos mais estranhos) precisam dos truque da próxima seção para serem utilizados. Além disso o eev.el também define a função `code-c-d', que funciona como uma fabriquinha de funções de hiperlink: uma simples chamada ao `code-c-d' como a abaixo (code-c-d "grub" "/usr/src/grub-0.5.95/" "grub") vai definir `find-grubfile', `find-grubnode', `find-grubw3', `find-grubtag' e algumas outras funções e variáveis para uso interno, bem menos interessantes; pra quem sabe Lisp e quer os detalhes técnicos, o que acontece quando rodamos o `code-c-d' acima é que o Emacs gera e executa os comandos abaixo: (setq ee-grubdir "/usr/src/grub-0.5.95/") (setq ee-grubtagsfile "/usr/src/grub-0.5.95/TAGS") (defun ee-grubfile (str) (concat (substitute-in-file-name ee-grubdir) str)) (defun ee-use-grub-tags () (setq tags-file-name ee-grubtagsfile)) (defun find-grubfile (str &rest pos-spec-list) (ee-use-grub-tags) (apply 'find-fline-nosubst (ee-grubfile str) pos-spec-list)) (defun find-grubtag (str) (ee-use-grub-tags) (find-tag str)) (defun find-grubw3 (furl &rest pos-spec-list) (apply 'find-w3 (ee-grubfile furl) pos-spec-list)) (setq ee-temp-code "grub" ee-temp-infofile "grub") (defun find-grubnode (nodename &rest pos-spec-list) (find-node2 "grub" nodename pos-spec-list "grub"))) O último `defun' não teria sido gerado se tivéssemos omitido o último parâmetro do `code-c-d'. # (find-angg "eev.el" "code-c-d") # (find-elinode "defun") Parte 2: Blocos de código no meio de um texto qualquer ------------------------------------------------------ # «eev» (to ".eev") Considere o bloco abaixo: rm -Rv /tmp/c/ mkdir /tmp/c/ cd /tmp/c/ cat > demo.c <<'---' #include <stdio.h> main() { int sum, i; for(sum=0, i=0; i<10; ++i) sum += i; printf("Sum: %d\n", sum); } --- gcc -E demo.c > demo.E gcc -S demo.c gcc -S demo.c -g -o demog.s gcc -c demo.c gcc -c demo.c -g -o demog.o gcc demo.c -o demo -v 2>&1 | tee ogv gcc demo.c -o demog -g -v 2>&1 | tee ogvg diff ogv ogvg ./demo que é uma série de comandos para o shell (bash ou zsh) que criam um diretório "/tmp/c/" e um pequeno arquivo em C lá chamado "demo.c", e depois chamam o gcc de vários modos para processar esse arquivo, gerando vários formas intermediárias entre o ".c" e o executável, para as quais nós geralmente não damos a menor bola... Há vários modos de executar um bloco desses para ver na prática o que ele faz. Poderíamos usar o mouse e pastar (:-) todas as linhas dele para um shell, ou simplesmente batê-las à mão; poderíamos também gravar o bloco para um arquivo, chamado digamos "/tmp/xxx", usando o o comando `write-region' do Emacs, e depois executá-lo com "bash /tmp/xxx" ou ". /tmp/xxx"... # (find-enode "M-x") # (find-enode "Misc File Ops") O eev.el implementa dois modos muitos mais rápidos de executar um bloco desses. O primeiro modo -- o segundo modo será descrito na próxima seção -- é selecionar o bloco e bater `M-x eev'; isso grava o bloco num determinado arquivo temporário (por default "~/tmp/ee.sh"), e se você der o comando "ee" num shell (e se tudo tiver sido instalado corretamente, veja o apêndice) então o shell vai executar o bloco em "verbose mode" na shell corrente -- o que quer dizer principalmente que cada comando é mostrado antes de ser executado e que os comandos que mudam o estado da shell -- como "cd" e "set" -- funcionam como esperaríamos: se batêssemos as cinco linhas abaixo tac <<'---' first second --- cd /tmp/ à mão num shell veríamos algo como: /home/edrx(edrx)# tac <<'---' > first > second > --- second first /home/edrx(edrx)# cd /tmp/ /tmp(edrx)# e com `M-x eev' e "ee" o que nós vemos é: /home/edrx(edrx)# ee tac <<'---' first second --- second first cd /tmp/ /tmp(edrx)# que é parecido o suficiente; para um modo de "enganar" perfeitamente a shell e outros programas e obter exatamente o mesmo resultado que se cada linha tivesse sido batida à mão veja a seção [eeg e Expect], mais adiante. Repare (ou lembre!) que linhas começadas com "#" são tratadas pelo shell como sendo comentários, o que significa que elas não são executadas, não importa o que contenham; podemos pôr hyperlinks em Emacs Lisp nos comentários e o shell não vai perceber nada, e quando formos editar um script desses no Emacs poderemos seguir esses hiperlinks... Imagine que temos alguns arquivos de anotações, cada um contendo uma mistura de texto, links e blocos de código shell; os links apontam para pontos relevantes em outros dos nossos arquivos de anotações, e também para outros lugares com documentação importante, e para alguns scripts que nós escrevemos; esses scripts provavelmente começaram como blocos de código shell nos arquivos de anotações, e quando nós os transformamos em scripts nós resolvemos manter os links que eles continham, já que não havia motivo para tirá-los... bom, com isso o Emacs acaba virando um ambiente fantástico: cada coisa que escrevemos aponta para outros lugares relacionados, e seguir os links é facílimo, e quando os seguimos continuamos dentro do Emacs, de onde os links continuam funcionando... tudo fica muito próximo e muito acessível. Para um exemplo realista de quão linkadas as coisas podem ficar, veja <http://angg.twu.net/>. Parte 3: Blocos delimitados --------------------------- # «blocos_delimitados» (to ".blocos_delimitados") Se você tiver feito a instalação "completa" (veja o apêndice) a tecla F3 estará associada a um comando do Emacs chamado `ee-bounded', cuja ação default é rodar o comando `eev-bounded', que por sua vez funciona como uma espécie de `eev' que nos dispensa de marcar o bloco explicitamente: ao invés de gravar a "região corrente" do Emacs (i.e., o trecho do buffer corrente que está entre o `point' e a `mark') o F3 grava o trecho em torno do cursor que vai até certos "delimitadores" configuráveis; por default o `eev-bounded' usaria como delimitadores strings "\n#-\n" (ou seja, linhas que só contêm "#-"), mas eu normalmente prefiro "\n#*\n"; o "*" é simplesmente um caracter 15, que vai aparecer na sua tela como uma estrela vermelha ou como "^O". Para inserir um desses caracteres no seu texto bata `C-q C-o'. A seção [glyphs] explica como fazer o caracter 15 aparecer como uma estrela vermelha; a seção [variables] explica como o Emacs percebe que neste arquivo o delimitador tem que ser "\n#*\n" e não "\n#-\n". # (find-enode "Inserting Text" "* `C-q'") # (find-angg "eev.el" "eev") # (find-angg "eev.el" "bounded") Exemplo: #* # (eev-bounded) # (eev-bounded 'once) tac <<'---' um dois --- #* rev <<'---' um dois --- #* Note que dá pra executar o bloco acima todo de uma vez (i.e., ignorando que há um delimitador que o separa em dois bloquinhos F3-záveis) marcando-o do jeito usual e batendo `M-x eev'; a linha "#*" do meio vai ser considerada como comentário pelo shell e não vai atrapalhar na execução. O eev não é o único comando que tem uma versão com delimitadores; o eelatex também tem, e o eeg (que nós ainda não vimos) também. Exemplo: se você rodar `M-x eelatex-bounded' dentro do bloco abaixo o Emacs vai gravar um script temporário que quando executado com "ee" num shell vai interpretar o bloco gravado como um texto em LaTeX. %* % (eelatex-bounded) % (eelatex-bounded 'once) Um texto em \LaTeX %* Se você tiver preguiça de bater `M-x eelatex-bounded' você pode executar uma das linhas `eelatex-bounded' acima (`eev-bounded' no exemplo anterior); os comandos eexxx-bounded admitem um parâmetro opcional, que se estiver presente vai indicar que a função eexxx-bounded deve ser rodada "uma vez só", i.e., não deve se tornar o default para o F3. Um modo alternativo de passar esse parâmetro adicional é batendo, por exemplo, `M-1 M-x eelatex-bounded'. # (find-enode "Completion") # (find-enode "Arguments") Em TeX e LaTeX o caracter que indica comentário é o "%", não o "#", e daí faz mais sentido usar delimitadores começados com "%". Os delimitadores usados para LaTeX também podem ser controlados pelos truques da seção [variables]. Parte 4: A interface genérica: eeg ---------------------------------- # «eeg» (to ".eeg") Se você souber o suficiente de programação em shell você deve ser capaz de controlar boa parte dos programas interativos usando "pipes". Um exemplo simples: #* echo 1+2 | bc bc <<'---' 2+3 3+4 --- #* Só que muitos programas interativos se comportam de modo diferente quando percebem que o input está vindo de um pipe, e muitas vezes você gostaria de fazer aparecer na tela exatamente o que o programa responderia interativamente, mas sem ter que digitar tudo manualmente... A "interface genérica do eev", que consiste em um programinha em Expect chamado "eeg" e dois comandos de Emacs, `M-x eeg' e `M-x eeg-bounded', cuida disso. `M-x eeg' funciona parecido com `M-x eev', só que o texto do bloco marcado no Emacs é gravado num outro arquivo temporário, por default ~/bin/ee.generic; numa instalação adequada a variável de shell $EEG contém o nome desse arquivo, e portanto em #* cat > $EEG <<'---' 2+3 3+4 quit --- eeg bc #* o "cat" vai funcionar como se tivéssemos marcado as três linhas entre os "---"s manualmente no Emacs e dado `M-x eeg'. O truque é que quando chamamos o bc "através do eeg", como na linha "eeg bc", o bc roda normalmente, em modo interativo, com quase todas as teclas que o usuário bate sendo mandadas diretamente para o bc, sem nenhum tratamento; só uma é "traduzida" de modo especial: a cada vez que o usuário bate `M-l' o eeg manda pro bc uma das linhas do arquivo $EEG, seguida de um `<enter>', e se todas as linhas já foram mandadas, o eeg descarta o `M-l' e não faz nada. Daí, se executamos o bloco acima com `ee' num shell e batemos `M-l asfdg <enter> M-l M-l', vemos algo como: /home/edrx(edrx)# ee cat > $EEG <<'---' 2+3 3+4 quit --- eeg bc bc 1.05 Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 2+3 5 asdfg 0 3+4 7 quit /home/edrx(edrx)# O Expect é capaz de controlar qualquer programa que se comunique via terminal (i.e., via stdin, stdout, stderr e /dev/tty), o que inclui programas "muito interativos" como ssh, telnet, adduser, emacs, vi, etc, e praticamente só exclui os programas que só rodam em X. A idéia é que "tudo" (se a gente fingir que as interfaces gráficas não existem!) pode ser controlado pelo Expect e pelo eeg. Para alguns programas pode ser mais conveniente usar uma variação do eeg que não se restrinja a mandar uma linha (terminada por CR) de cada vez. Eu estou escrevendo uma variação dessas: # (find-angg "EXPECT/eeg3") Ela já funciona, mas a sintaxe do arquivo $EEG que ela usa ainda é muito ruim. Parte 5: âncoras e links locais ------------------------------- # «ancoras» (to ".ancoras") (...) # (find-angg "eev.el" "find-anchor") # (find-angg "eev.el" "to_and_back") Parte 6: links para informações sobre um pacote num sistema Debian ------------------------------------------------------------------ # (find-angg "eev.el" "find-anchor") find-status Parte 7: truques para inserir links num texto --------------------------------------------- # «mkto_dff_inn» (to ".mkto_dff_inn") # (find-angg "eev.el" "inn") # (find-angg "eev.el" "dff") # (find-angg "eev-extras.el") (Falar também algo sobre gravar macros) Parte 7: variáveis ------------------ # «variaveis» (to ".variaveis") # (find-enode "Variables") # (find-elinode "Variables") # (find-elnode "Variables") Parte 8: glyphs --------------- # «glyphs» (to ".glyphs") Apêndice: criando demos com eeg2 ------------------------------- # «demos_eeg2» (to ".demos_eeg2") # (find-es "anatocc" "cdecl") find-status find-vldifile xxx.list # (find-es "anatocc" "cdecl") ".e"s # (find-es "anatocc" "dlopen") alias pro bash ;; (describe-function 'find-fline) ;; (describe-function 'find-node) ;; (describe-function 'ee-goto-position) ;; (describe-function 'eev) ;; (describe-function 'eeman) ;; (describe-function 'eecd) ;; (describe-function 'eeg) ;; (describe-function 'eev-bounded) ;; (describe-function 'eelatex) ;; (describe-function 'eelatex-bounded) ;; (describe-function 'eeg-bounded) ;; (describe-function 'end-of-line-then-eval-last-sexp) ;; (describe-function 'ee-bounded) ;; (describe-function 'code-c-d) ;; (describe-function 'inn) ;; (describe-function 'dff) Apêndice I: Instalando o eev.el num sistema Debian -------------------------------------------------- # (find-es "escripts") # (find-es "escripts" "copy_of_edrxs_home_LR") # (find-angg "README") Apêndice __: Rodando um demo em eeg2 Rodando no X instalar rxvt corrigir o eeg pra ele aceitar +128? echo 'kover::0:0:kover:/home/edrx:/usr/bin/zsh' >> /etc/passwd # Local Variables: # coding: utf-8-unix # End: