Problemi utilizzo tlmgr

salve a tutti!
Ho installato la texlive2009 nel mio Ubuntu-Linux, ma purtroppo non riesco ad utilizzare tlmgr.
O meglio: se sono loggato come utente normale mi funziona (ma non ho i privilegi per modificare niente), se divento utente di root tramite “sudo” allora mi dice
`sudo tlmgr -gui
…
sudo: tlmgr: command not found
`
Come mai?

sudo -s tlmgr -gui

In questo modo non diventi l’utente root, ma rimani te stesso. È un problema di PATH.

Ciao
Enrico

Purtroppo anche facendo così non risolvo
`$ sudo -s tlmgr -gui
[sudo] password for antonio:
/bin/bash: tlmgr: comando non trovato`
In che senso è un problema di PATH? Intendi che magari ho sbagliato ad editare il file ~/.bashrc quando ho installato?

`$ sudo -u antonio tlmgr -gui`
Il problema è che sudo da solo prende come ambiente quello definito per l’utente root e il PATH dell’utente root non contiene il riferimento agli eseguibili di TeX che hai impostato nella tua shell.

Ciao
Enrico

purtroppo nemmeno con quest’altro comando…
E quindi come dovrei fare per inserire il riferimento agli eseguibili di TeX nel PATH dell’utente root??

Mi pare strano; riporta quelli che ti risponde con
`sudo sudo -V`
In ogni caso dovrebbe funzionare con la sequenza di comandi
`sudo su
export PATH=/usr/local/texlive/2009/bin/:${PATH}
tlmgr -gui`
Al posto di devi mettere il nome della directory dove ci sono gli eseguibili, che ottieni dalla shell chiedendo “which -p tex”

Ciao
Enrico

Allora, lato positivo: con l’ultimo comando che mi hai dato funziona.

Ti riporto l’output del comando che mi hai detto di digitare
`$ sudo sudo -V
Sudo version 1.7.0

Sudoers path: /etc/sudoers
Authentication methods: 'pam'
…
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
…
Locale to use while parsing sudoers: C
Local IP address and netmask pairs:
192.168.0.2 / 255.255.255.0
fe80::222:faff:fe4c:df8e / ffff:ffff:ffff:ffff::
`

La parte che ho segnato in rosso è quella rilevante: per motivi di sicurezza, sudo è stato compilato in modo da usare sempre quel PATH. Il piano alternativo funziona perché “sudo su” entra in una shell dove puoi modificare il PATH nel modo indicato. Fa’ molta attenzione: non dimenticarti di uscire dalla shell di root quando finisci di lavorare con tlmgr.

Ciao
Enrico

Capito 🙂 Grazie mille!!!

è un po’ tardi… ma tu hai installato texlive senza i privilegi di sudo e senza creare i symlinks?

Capito 🙂 Grazie mille!!!

è un po’ tardi… ma tu hai installato texlive senza i privilegi di sudo e senza creare i symlinks?

Salve a tutti. Riprendo questa discussione per proporre una soluzione.

Ricapitolando, se non abbiamo attivato i symlink al momento dell’installazione (e probabilmente è bene non farlo perché si “disturba” troppo l’ambiente), il comando sudo tlmgr gui non funziona.
Acquisire i diritti di root per lo script è tuttavia essenziale coma sappiamo. Tuttavia è solo un problema di PATH quindi il comando sudo /usr/local/texlive/2009/bin/i386-linux/tlmgr gui funziona.
Allora perché non definire molto semplicemente un alias? ecco il comando:
alias supertlmgr=”sudo /usr/local/texlive/2009/bin/i386-linux/tlmgr”

In questo modo possiamo lavorare con il nuovo comando così:
supertlmgr update -all

Geniale vero? 8)

Salve a tutti. Riprendo questa discussione per proporre una soluzione.

Ricapitolando, se non abbiamo attivato i symlink al momento dell’installazione (e probabilmente è bene non farlo perché si “disturba” troppo l’ambiente), il comando sudo tlmgr gui non funziona.
Acquisire i diritti di root per lo script è tuttavia essenziale coma sappiamo. Tuttavia è solo un problema di PATH quindi il comando sudo /usr/local/texlive/2009/bin/i386-linux/tlmgr gui funziona.
Allora perché non definire molto semplicemente un alias? ecco il comando:
alias supertlmgr=”sudo /usr/local/texlive/2009/bin/i386-linux/tlmgr”

In questo modo possiamo lavorare con il nuovo comando così:
supertlmgr update -all

Geniale vero? 8)

my 2 cents

`sudo ln -s /usr/local/texlive/2009/bin/i386-linux/tlmgr /usr/local/bin/tlmgr`

creiamo un bel link a tlmgr all’interno del PATH predefinito.

Salve a tutti. Riprendo questa discussione per proporre una soluzione.

Ricapitolando, se non abbiamo attivato i symlink al momento dell’installazione (e probabilmente è bene non farlo perché si “disturba” troppo l’ambiente), il comando sudo tlmgr gui non funziona.
Acquisire i diritti di root per lo script è tuttavia essenziale coma sappiamo. Tuttavia è solo un problema di PATH quindi il comando sudo /usr/local/texlive/2009/bin/i386-linux/tlmgr gui funziona.
Allora perché non definire molto semplicemente un alias? ecco il comando:
alias supertlmgr=”sudo /usr/local/texlive/2009/bin/i386-linux/tlmgr”

In questo modo possiamo lavorare con il nuovo comando così:
supertlmgr update -all

Geniale vero? 8)

my 2 cents

`sudo ln -s /usr/local/texlive/2009/bin/i386-linux/tlmgr /usr/local/bin/tlmgr`

creiamo un bel link a tlmgr all’interno del PATH predefinito.

😯
la tua soluzione non può essere ammessa, perché sostanzialmente è quello che fa lo script d’installazione con i symlink
😆
e poiché dalla mia esperienza e dalla lettura di un post sul forum (di Enrico) mi sono fatto l’idea che i symlink possono essere tutt’altro che una comodità, occorre evitare di applicarli anche se sono comodi.
❗

😯
la tua soluzione non può essere ammessa, perché sostanzialmente è quello che fa lo script d’installazione con i symlink
😆
e poiché dalla mia esperienza e dalla lettura di un post sul forum (di Enrico) mi sono fatto l’idea che i symlink possono essere tutt’altro che una comodità, occorre evitare di applicarli anche se sono comodi.
❗

riesci ad indicarmi questo post?
non sono riuscito a trovarlo con una ricerca nel forum…
o puoi spiegarmi cosa c’e’ di cosi’ cattivo nei simlink?
se e’ solo il problema che finisco nel PATH dell’utente basta sostituire bin con sbin.

😯
la tua soluzione non può essere ammessa, perché sostanzialmente è quello che fa lo script d’installazione con i symlink
😆
e poiché dalla mia esperienza e dalla lettura di un post sul forum (di Enrico) mi sono fatto l’idea che i symlink possono essere tutt’altro che una comodità, occorre evitare di applicarli anche se sono comodi.
❗

riesci ad indicarmi questo post?
non sono riuscito a trovarlo con una ricerca nel forum…
o puoi spiegarmi cosa c’e’ di cosi’ cattivo nei simlink?
se e’ solo il problema che finisco nel PATH dell’utente basta sostituire bin con sbin.

Il post credo fosse quello in evidenza nella board principale, ho forse era una discussione che è poi passata a TeX Live dal problema originario.
La mia idea è che se controlli il PATH puoi semplicemente gestire più TeX Live installate sul sistema o affiancare alla distro che so metti una ConTeXt minimal.
Con i symlink va a finire che si deve litigare col sistema per inidizzarlo verso gli eseguibili desiderati.
Poi Enrico può dire la sua e chiarirci meglio.
Bye

Il post credo fosse quello in evidenza nella board principale, ho forse era una discussione che è poi passata a TeX Live dal problema originario.
La mia idea è che se controlli il PATH puoi semplicemente gestire più TeX Live installate sul sistema o affiancare alla distro che so metti una ConTeXt minimal.
Con i symlink va a finire che si deve litigare col sistema per inidizzarlo verso gli eseguibili desiderati.
Poi Enrico può dire la sua e chiarirci meglio.
Bye

il problema della doppia TeXlive installata si risolve chiamando il link tlmgr-local o qualsiasialtracosaabbiaunnomediverso. anche per ConTeXt funziona.
sono curioso di capire questa incompatibilita’… linux e’ un sistema operativo serio e la gran parte dei problemi e’ solo dovuta a conoscenze non abbastanza approfondite 😉

[quote]:shock:
la tua soluzione non può essere ammessa, perché sostanzialmente è quello che fa lo script d’installazione con i symlink
😆
e poiché dalla mia esperienza e dalla lettura di un post sul forum (di Enrico) mi sono fatto l’idea che i symlink possono essere tutt’altro che una comodità, occorre evitare di applicarli anche se sono comodi.
❗

riesci ad indicarmi questo post?
non sono riuscito a trovarlo con una ricerca nel forum…
o puoi spiegarmi cosa c’e’ di cosi’ cattivo nei simlink?
se e’ solo il problema che finisco nel PATH dell’utente basta sostituire bin con sbin.

Il post credo fosse quello in evidenza nella board principale, ho forse era una discussione che è poi passata a TeX Live dal problema originario.
La mia idea è che se controlli il PATH puoi semplicemente gestire più TeX Live installate sul sistema o affiancare alla distro che so metti una ConTeXt minimal.
Con i symlink va a finire che si deve litigare col sistema per inidizzarlo verso gli eseguibili desiderati.
Poi Enrico può dire la sua e chiarirci meglio.
Bye[/quote]
Non userei un symlink, un alias è più che sufficiente e meno invasivo, ma probabilmente questo caso richiede una funzione, in modo che l’ambiente contenga la giusta impostazione per gli eseguibili. Dare “/usr/…/tlmgr” quando il PATH indirizza a /usr/bin e non a /usr/local/texlive/…” potrebbe essere disastroso.

La gestione di due TeX Live su Ubuntu non è così semplice. Si potrebbe pensare a uno script che chiamato con un parametro sceglie la distribuzione impostando correttamente il PATH, diciamo
`choosetexlive debian
choosetexlive texlive`
Estrarre o aggiungere dalla variabile PATH la stringa “/usr/texlive/…:” in testa al valore di $PATH non è difficile.

Ma questo purtroppo non risolve il problema; infatti anche se l’ambiente nella propria shell contiene il valore corretto e “pdflatex pippo” punterebbe al giusto eseguibile, lanciare Emacs o Kile con i menù di sistema lascerebbe il valore di default di PATH: ogni processo lanciato da questi userebbe la TeX Live Debian (con gli eseguibili in /usr/bin).

La soluzione che ho trovato, non proprio il meglio, è usare il file .pam_environment. Se voglio usare la TeX Live indipendente, ho questo file nella home che contiene
`PATH=/usr/local/texlive/…:/usr/local.bin:/usr/bin:`
Se voglio usare la TeX Live Debian, devo rinominare questo file, uscire e rientrare dall’account. 🙁

Si potrebbe trovare una via di scampo con un sistema simile a quello usato da MacTeX: aggiungere al PATH standard, in cima, l’indicazione di /usr/texbin; questo sarebbe un link simbolico alla directory degli eseguibili della TeX Live indipendente oppure a /usr/bin. Uno script può facilmente sovrascrivere quel link. Nemmeno questo risolverebbe il problema, perché qualcosa in /usr/local/bin non verrebbe visto prima di un programma con lo stesso nome in /usr/bin nel caso si usi la TeX Live Debian, contraddicendo il principale uso di /usr/local/bin. 🙁

Non c’entra, ma oggi il mirror di Roma2 era di nuovo lentissimo dopo settimane di prestazioni normali. 🙁

Ciao
Enrico

La gestione di due TeX Live su Ubuntu non è così semplice. Si potrebbe pensare a uno script che chiamato con un parametro sceglie la distribuzione impostando correttamente il PATH, diciamo
`choosetexlive debian
choosetexlive texlive`
Estrarre o aggiungere dalla variabile PATH la stringa “/usr/texlive/…:” in testa al valore di $PATH non è difficile.

Ma questo purtroppo non risolve il problema; infatti anche se l’ambiente nella propria shell contiene il valore corretto e “pdflatex pippo” punterebbe al giusto eseguibile, lanciare Emacs o Kile con i menù di sistema lascerebbe il valore di default di PATH: ogni processo lanciato da questi userebbe la TeX Live Debian (con gli eseguibili in /usr/bin).

La soluzione che ho trovato, non proprio il meglio, è usare il file .pam_environment. Se voglio usare la TeX Live indipendente, ho questo file nella home che contiene
`PATH=/usr/local/texlive/…:/usr/local.bin:/usr/bin:`
Se voglio usare la TeX Live Debian, devo rinominare questo file, uscire e rientrare dall’account. 🙁

Si potrebbe trovare una via di scampo con un sistema simile a quello usato da MacTeX: aggiungere al PATH standard, in cima, l’indicazione di /usr/texbin; questo sarebbe un link simbolico alla directory degli eseguibili della TeX Live indipendente oppure a /usr/bin. Uno script può facilmente sovrascrivere quel link. Nemmeno questo risolverebbe il problema, perché qualcosa in /usr/local/bin non verrebbe visto prima di un programma con lo stesso nome in /usr/bin nel caso si usi la TeX Live Debian, contraddicendo il principale uso di /usr/local/bin. 🙁

Non c’entra, ma oggi il mirror di Roma2 era di nuovo lentissimo dopo settimane di prestazioni normali. 🙁

Ciao
Enrico

l’annoso problema dell’uso di versioni differenti dello stesso software sotto linux si risolve egregiamente (la battuta con egreg e’ troppo facile… :lol:) con i modules.
vedi qua per info approfondite http://modules.sourceforge.net/man/module.html.
questo implica che, comunque, anche i programmi grafici vadano lanciati da una shell che abbia il modulo adeguato caricato.

La gestione di due TeX Live su Ubuntu non è così semplice. Si potrebbe pensare a uno script che chiamato con un parametro sceglie la distribuzione impostando correttamente il PATH, diciamo
`choosetexlive debian
choosetexlive texlive`
Estrarre o aggiungere dalla variabile PATH la stringa “/usr/texlive/…:” in testa al valore di $PATH non è difficile.

Ma questo purtroppo non risolve il problema; infatti anche se l’ambiente nella propria shell contiene il valore corretto e “pdflatex pippo” punterebbe al giusto eseguibile, lanciare Emacs o Kile con i menù di sistema lascerebbe il valore di default di PATH: ogni processo lanciato da questi userebbe la TeX Live Debian (con gli eseguibili in /usr/bin).

La soluzione che ho trovato, non proprio il meglio, è usare il file .pam_environment. Se voglio usare la TeX Live indipendente, ho questo file nella home che contiene
`PATH=/usr/local/texlive/…:/usr/local.bin:/usr/bin:`
Se voglio usare la TeX Live Debian, devo rinominare questo file, uscire e rientrare dall’account. 🙁

Si potrebbe trovare una via di scampo con un sistema simile a quello usato da MacTeX: aggiungere al PATH standard, in cima, l’indicazione di /usr/texbin; questo sarebbe un link simbolico alla directory degli eseguibili della TeX Live indipendente oppure a /usr/bin. Uno script può facilmente sovrascrivere quel link. Nemmeno questo risolverebbe il problema, perché qualcosa in /usr/local/bin non verrebbe visto prima di un programma con lo stesso nome in /usr/bin nel caso si usi la TeX Live Debian, contraddicendo il principale uso di /usr/local/bin. 🙁

Non c’entra, ma oggi il mirror di Roma2 era di nuovo lentissimo dopo settimane di prestazioni normali. 🙁

Ciao
Enrico

l’annoso problema dell’uso di versioni differenti dello stesso software sotto linux si risolve egregiamente (la battuta con egreg e’ troppo facile… :lol:) con i modules.
vedi qua per info approfondite http://modules.sourceforge.net/man/module.html.
questo implica che, comunque, anche i programmi grafici vadano lanciati da una shell che abbia il modulo adeguato caricato.

Interessante discussione,
perché non farne un qualcosa di più per esempio un articolo per la prossima ArsTeXnica, o una guida da pubblicare sul sito di GuIT?
Una guida passo passo per risolvere i problemi con i moduli potrebbe essere un lavoro utile e piacevole.

capitalaslash che te pare dell’idea?

OT: Lucid è davvero formidabile, il mio PC vecchio di dieci anni è ringiovanito di almeno cinque. 😈

[quote]La gestione di due TeX Live su Ubuntu non è così semplice. Si potrebbe pensare a uno script che chiamato con un parametro sceglie la distribuzione impostando correttamente il PATH, diciamo
`choosetexlive debian
choosetexlive texlive`
Estrarre o aggiungere dalla variabile PATH la stringa “/usr/texlive/…:” in testa al valore di $PATH non è difficile.

Ma questo purtroppo non risolve il problema; infatti anche se l’ambiente nella propria shell contiene il valore corretto e “pdflatex pippo” punterebbe al giusto eseguibile, lanciare Emacs o Kile con i menù di sistema lascerebbe il valore di default di PATH: ogni processo lanciato da questi userebbe la TeX Live Debian (con gli eseguibili in /usr/bin).

La soluzione che ho trovato, non proprio il meglio, è usare il file .pam_environment. Se voglio usare la TeX Live indipendente, ho questo file nella home che contiene
`PATH=/usr/local/texlive/…:/usr/local.bin:/usr/bin:`
Se voglio usare la TeX Live Debian, devo rinominare questo file, uscire e rientrare dall’account. 🙁

Si potrebbe trovare una via di scampo con un sistema simile a quello usato da MacTeX: aggiungere al PATH standard, in cima, l’indicazione di /usr/texbin; questo sarebbe un link simbolico alla directory degli eseguibili della TeX Live indipendente oppure a /usr/bin. Uno script può facilmente sovrascrivere quel link. Nemmeno questo risolverebbe il problema, perché qualcosa in /usr/local/bin non verrebbe visto prima di un programma con lo stesso nome in /usr/bin nel caso si usi la TeX Live Debian, contraddicendo il principale uso di /usr/local/bin. 🙁

Non c’entra, ma oggi il mirror di Roma2 era di nuovo lentissimo dopo settimane di prestazioni normali. 🙁

Ciao
Enrico

l’annoso problema dell’uso di versioni differenti dello stesso software sotto linux si risolve egregiamente (la battuta con egreg e’ troppo facile… :lol:) con i modules.
vedi qua per info approfondite http://modules.sourceforge.net/man/module.html.
questo implica che, comunque, anche i programmi grafici vadano lanciati da una shell che abbia il modulo adeguato caricato.

Interessante discussione,
perché non farne un qualcosa di più per esempio un articolo per la prossima ArsTeXnica, o una guida da pubblicare sul sito di GuIT?
Una guida passo passo per risolvere i problemi con i moduli potrebbe essere un lavoro utile e piacevole.

capitalaslash che te pare dell’idea?

OT: Lucid è davvero formidabile, il mio PC vecchio di dieci anni è ringiovanito di almeno cinque. :twisted:[/quote]

Aggiungo che la guida potrebbe contenere anche un’altra cosa assai utile:
*** l’installazione e l’uso di TeX Live in rete
Come gestire un unica distribuzione “server” di TeX Live per un gruppo di lavoro che condivida classi di documento specifiche.
Un aggiornamento per esempio delle classi per la “carta intestata” delle comunicazioni aziendali sarebbe centralizzato, quindi immediatamente disponibile ed in modo trasparente per il team.
Un paio di GuITmeeting fa avevo accennato alla cosa direttamente a Norbert Preining che con la sua intuitività tecnologica l’aveva data per un operazione fattibile attraverso Samba.
Grazie.

…
Si potrebbe trovare una via di scampo con un sistema simile a quello usato da MacTeX: aggiungere al PATH standard, in cima, l’indicazione di /usr/texbin; questo sarebbe un link simbolico alla directory degli eseguibili della TeX Live indipendente oppure a /usr/bin. Uno script può facilmente sovrascrivere quel link. Nemmeno questo risolverebbe il problema, perché qualcosa in /usr/local/bin non verrebbe visto prima di un programma con lo stesso nome in /usr/bin nel caso si usi la TeX Live Debian, contraddicendo il principale uso di /usr/local/bin. 🙁

Si potrebbe però risolvere il problema se lo script creasse /usr/texbin come symlink a /usr/local/texlive/2009/bin/ se chiamato con argomento “texlive” e invece facesse puntare /usr/texbin a una directory vuota se chiamato con argomento “debian”. Così non ci sarebbero problemi di precedenze.

Aggiungo che l’ho provato; con il symlink
`/usr/texbin -> /usr/local/texlive/2009/bin/i386-linux`
il sistema trova gli eseguibili “indipendenti”; se do
`sudo mv /usr/texbin{,~}`
ovviamente troverà gli eseguibili “debian”. Basta dunque aggiungere “/usr/texbin” al PATH definito in /etc/environment e tutto va a posto. 🙂 Almeno fino al prossimo aggiornamento.

Ciao
Enrico

La gestione di due TeX Live su Ubuntu non è così semplice. Si potrebbe pensare a uno script che chiamato con un parametro sceglie la distribuzione impostando correttamente il PATH, diciamo
`choosetexlive debian
choosetexlive texlive`
Estrarre o aggiungere dalla variabile PATH la stringa “/usr/texlive/…:” in testa al valore di $PATH non è difficile.

Per quanto mi riguarda, dati che sono l’unico utente ed admin
della mia linux box,apro una shell
e
`
export PATH=/opt/TeXLive2008/texlive/2008/bin/i386-linux:$PATH`
oppure
`
export PATH=/opt/TeXLive2009/tl2009/bin/i386-linux:$PATH`
Ho 3 texlive e qualche decina di minimals e non ho mai avuto problemi di convivenza.
Ovvio che non va bene questo
`
export PATH=/opt/TeXLive2008/texlive/2008/bin/i386-linux:$PATH
export PATH=/opt/TeXLive2009/tl2009/bin/i386-linux:$PATH`
i.e. ogni bash ha una ed una sola texlive — ma ho tante bash quant me ne servono.

La gestione di due TeX Live su Ubuntu non è così semplice. Si potrebbe pensare a uno script che chiamato con un parametro sceglie la distribuzione impostando correttamente il PATH, diciamo
`choosetexlive debian
choosetexlive texlive`
Estrarre o aggiungere dalla variabile PATH la stringa “/usr/texlive/…:” in testa al valore di $PATH non è difficile.

Per quanto mi riguarda, dati che sono l’unico utente ed admin
della mia linux box,apro una shell
e
`
export PATH=/opt/TeXLive2008/texlive/2008/bin/i386-linux:$PATH`
oppure
`
export PATH=/opt/TeXLive2009/tl2009/bin/i386-linux:$PATH`
Ho 3 texlive e qualche decina di minimals e non ho mai avuto problemi di convivenza.
Ovvio che non va bene questo
`
export PATH=/opt/TeXLive2008/texlive/2008/bin/i386-linux:$PATH
export PATH=/opt/TeXLive2009/tl2009/bin/i386-linux:$PATH`
i.e. ogni bash ha una ed una sola texlive — ma ho tante bash quant me ne servono.

Il problema è diverso: se lanci una compilazione da un Emacs che non sia un processo figlio della shell in parola, il PATH sarà quello “di sistema”.

Ciao
Enrico

Il problema è diverso: se lanci una compilazione da un Emacs che non sia un processo figlio della shell in parola, il PATH sarà quello “di sistema”.

ovvio,ma come utente linux
non vedo proprio nessun problema ad aprire una shell e lanciare emacs.

Il problema è diverso: se lanci una compilazione da un Emacs che non sia un processo figlio della shell in parola, il PATH sarà quello “di sistema”.

ovvio,ma come utente linux
non vedo proprio nessun problema ad aprire una shell e lanciare emacs.

Confondi te con l’utente medio. 🙂 Nemmeno io ho difficoltà (anche su Mac OS X uso spesso la shell per lanciare le compilazioni, sono abituato a vedere scorrere il log e posso interagire in caso di errori), ma l’utente medio probabilmente non è così avvezzo.

Il metodo proposto funziona: oggi ho creato una nuova macchina virtuale con Ubuntu 10, ci ho messo entrambe le versioni della TeX Live 2009, ho modificato /etc/environment, creato il symlink e lanciato Emacs dal menù generale. Se da una shell faccio le manovre indicate nel messaggio precedente, Emacs è perfettamente felice di usare una o l’altra versione. Funziona bene anche con TeXWorks, purché nelle preferenze si “alzi di un posto” /usr/texbin.

È vero che così si “sporca” /usr, ma il vantaggio di avere tlmgr è indubbio. Chiaro che per fare esperimenti come i tuoi, è meglio fare tutto da una shell.

Ciao
Enrico

Confondi te con l’utente medio. 🙂

si, io sono…Scarso.

Interessante discussione,
perché non farne un qualcosa di più per esempio un articolo per la prossima ArsTeXnica, o una guida da pubblicare sul sito di GuIT?
Una guida passo passo per risolvere i problemi con i moduli potrebbe essere un lavoro utile e piacevole.

capitalaslash che te pare dell’idea?

OT: Lucid è davvero formidabile, il mio PC vecchio di dieci anni è ringiovanito di almeno cinque. 😈

sarei onorato di vedere una cosa scritta da me in mezzo a nomi ben piu’ importanti per il TeX nazionale 😆
io la volonta’ ce l’ho… magari col supporto di chi e’ piu’ esperto nel divulgare (cosa che puo’ essere abbastanza complessa).

l’installazione centralizzata e’ una buona idea, anche se io la vedrei piu’ cosi’:
– ognuno ha la sua installazione locale con i suoi pacchetti
– si crea una cartella comune con i pacchetti condivisi che viene aggiunta ai path del TeX
in questo modo la macchina e’ indipendente per quanto riguarda la possibilita’ di lavorare anche con la rete non funzionante e in piu’ ogni utente puo’ avere le sue personalizzazioni.

Interessante discussione,
perché non farne un qualcosa di più per esempio un articolo per la prossima ArsTeXnica, o una guida da pubblicare sul sito di GuIT?
Una guida passo passo per risolvere i problemi con i moduli potrebbe essere un lavoro utile e piacevole.

capitalaslash che te pare dell’idea?

OT: Lucid è davvero formidabile, il mio PC vecchio di dieci anni è ringiovanito di almeno cinque. 😈

sarei onorato di vedere una cosa scritta da me in mezzo a nomi ben piu’ importanti per il TeX nazionale 😆
io la volonta’ ce l’ho… magari col supporto di chi e’ piu’ esperto nel divulgare (cosa che puo’ essere abbastanza complessa).

l’installazione centralizzata e’ una buona idea, anche se io la vedrei piu’ cosi’:
– ognuno ha la sua installazione locale con i suoi pacchetti
– si crea una cartella comune con i pacchetti condivisi che viene aggiunta ai path del TeX
in questo modo la macchina e’ indipendente per quanto riguarda la possibilita’ di lavorare anche con la rete non funzionante e in piu’ ogni utente puo’ avere le sue personalizzazioni.

Di contro tuttavia devo mantenere aggiornate n installazioni anziché una sola.

Comunque se tu imbastisci un articolo poi ci pensa il revisore di ArsTeXnica a migliorare gli aspetti divulgativi.
L’articolo va poi presentato al GuITmeeting 2010 a meno che non aspetti la prima uscita della rivista del gruppo.

Al momento opportuno sono disponibile per leggere la bozza e, per quanto possano valere darti la mia opinione in merito (riferimento email giaconet dot mailbox chiocciola gmail anotherdot com).

Dovresti trovare un titolo giusto tipo “TeX at work on Linux”.
Ciao.