Installer texlive sous linux

[dbitouze (Denis Bitouzé)]

Le 03/03/20 à 11h29, Daniel Flipo a écrit :

Je n’ai jamais été convaincu par les arguments avancés à ce sujet. Seul inconvénient bénin et au remède connu : si un nouvel exécutable est installé par mise à jour de la TeX Live, il ne sera pas automatiquement pris en compte. Remède :

┌──── │ tlmgr path add └────

Je partage pour ma part l’avis des développeurs de TeXLive. Puisque tu insistes, à défaut de pouvoir développer /leurs/ arguments, je vais te préciser en quoi les liens me dérangent.

C’est bien pour ça que j’ai taquiné le Daniel

1. J’ai 365 binaires dans ma TEXLive 2019 (pas complète), ça ferait donc 365 liens ajoutés dans /usr/local/bin où il y a actuellement une vingtaine binaires « locaux ». Je trouve ça crade.

Apparemment, je suis bien plus « cratitude compliant » que toi, alors

┌──── │ $ ls /usr/local/bin | wc -l │ 511 └────

Même pas peur !

2. On voit régulièrement passer sur la liste texlive, des messages de gens qui ont des installations TeX bancales, c’est souvent dû à liens symboliques qui n’ont pas été supprimés ou incorrectement mis à jour.

Ça me semble de moins en moins fréquent.

3. La méthode des liens impose que /tous/ les utilisateurs d’une même machine aient recours à la /même/ distribution TeX.

Bah…

/Même sur une machine mono-utilisateur/, ça n’est pas optimal, je m’explique : – comment fais-tu pour basculer sur une texlive antérieure (ou sur la distrib TeX de Linux) si un de tes fichiers ne compile plus ou mal ?

Je dirais, pour basculer sur la 2018 alors que c’est la 2019 qui est active (pas testé) :

┌──── │ $ /usr/local/texlive/2018/bin/x86_64-linux/tlmgr path add └────

puis, pour revenir à la 2019

┌──── │ $ /usr/local/texlive/2019/bin/x86_64-linux/tlmgr path add └────

– si tu veux participer au « prétest » de la version 2020, tu installes celle-ci à côté de la 2019 ; c’est bien agréable de pouvoir basculer de l’une à l’autre pour comparer ou juste pour retrouver quelque chose de stable lorsque la « prétest » bogue temporairement.

Analogue, et testé après installation de la TL prétest 2020, pas en root (dossier d’installation /home/bitouze/texlive/2020 et liens symboliques dans /home/bitouze/bin, /home/bitouze/man, /home/bitouze/info). C’est alors la TL 2020 qui est active et, si je veux repasser à la TL 2019, il me suffit de lancer :

┌──── │ $ tlmgr path remove └────

Pour basculer à nouveau sur la 2020, un simple :

┌──── │ $ ~/texlive/2020/bin/x86_64-linux/tlmgr path add └────

suffit.

La méthode du PATH est très souple : – je peux tester seul la version « prétest » sans gêner les autres utilisateurs et /moi-même/ basculer sur la version stable à tout moment pour mon travail de production,

Idem : cf. ci-dessus.

il suffit de changer mon PATH.

– Lorsque la version 2020 sortira je pourrai l’installer sans crainte, la tester et revenir en cas de souci à la 2019 juste grâce à un changement de PATH (utilisateur par utilisateur) ou par modification du lien « current » (pour tous).

Idem : cf. ci-dessus.

Je comprends parfaitement que tu présentes la méthode des liens lors de la journée de Dunkerque, où il te faut faire installer /vite/ une distribution sur une quantité de machines disparates (divers variantes de Linux, Windows, Mac), afin de passer à /l’utilisation/ de LaTeX qui est l’objet de la journée.

Oui, mais pas seulement : je trouve que, en plus d’être simple et rapide, c’est tout à fait viable

D’après tes transparents, tu fais installer TeXLive en « root », ce n’est pas optimal non plus

Je ne comprends pas non plus cette réticence. Et comment fais-tu autrement sur une machine multi-utilisateurs ?

mais ça t’évite les « chown », « umask », « chmod » et consorts que tu /ne peux pas expliquer/ dans le temps dont tu disposes.

En effet !

Je ne critique pas ton choix.

Je ne critique pas non plus le tien J’ai lancé cette discussion pour que soient argumentés les avantages et inconvénients des deux méthodes.

Ma notice s’adresse à des gens qui sont disposés à améliorer leur installation TeX, quitte à y passer un peu de temps. Je préfère leur indiquer ce que j’ai fait pendant les nombreuses années où j’étais administrateur du serveur de notre labo et qui me donne encore toute satisfaction sur ma machine familiale (trois utilisateurs).

À la lumière de mes arguments ci-dessus, ne penses-tu pas que la méthode des liens symboliques donne également toute satisfaction ?

OUI, la modification du PATH demande de l’attention (il y a différents « shell, » différentes syntaxes, etc.)

C’est ce qui m’y a fait renoncer, notamment dans le chapitre relatif à l’installation de la TeX Live dans le livre « LaTeX, l’essentiel » que Jean-Côme et moi avons co-écrit.

MAIS c’est à faire en principe une seule fois (au moins sur une machine mono-utilisateur avec le lien « current » que je propose).

Oui mais, cette fois-là, ça me semble un peu décourageant, notamment pour les utilisateurs de Linux pas spécialement geeks.

Enfin je crois utile que les utilisateurs de Linux aient une connaissance minimale des fichiers d’initialisation « .profile », « .bash_rc », etc. et de leur syntaxe.

Lorsque le besoin s’en fait /vraiment/ sentir, oui. Sinon…

Bien cordialement.

Denis

[daniel.flipo]

Le 05/03/2020 à 09:52, Denis Bitouzé a écrit :

À la lumière de mes arguments ci-dessus, ne penses-tu pas que la méthode
des liens symboliques donne également toute satisfaction ?

NON, j’ai déjà exposé mes arguments contre.

Pourquoi ne poses-tu pas la question sur la liste TeXLive, en tant que
traducteur de la doc française ? les concepteurs (Karl Berry, Norbert
Preining) t’expliqueront sûrement mieux que moi pourquoi /ils/
déconseillent cette méthode (tout comme l’installation en “root”).

Bien cordialement,–
Daniel Flipo

[PBideault (Patrick Bideault)]

Empty body

[michel.bovani]

Le 5 mars 2020 à 13:33, Daniel Flipo xyz@xyz.tld a écrit :

(tout comme l’installation en “root”).

Si tu veux faire une installation multi-utilisateurs, t’es quand même bien obligé d’utiliser aussi moins sudo, non ?

Michel Bovani

[dbitouze (Denis Bitouzé)]

Le 05/03/20 à 13h33, Daniel Flipo a écrit :

Le 05/03/2020 à 09:52, Denis Bitouzé a écrit :

À la lumière de mes arguments ci-dessus, ne penses-tu pas que la méthode des liens symboliques donne également toute satisfaction ?

NON, j’ai déjà exposé mes arguments contre.

Certes, mais tu n’as pas exposé de contre-contre-arguments contre mes contre-arguments

Pourquoi ne poses-tu pas la question sur la liste TeXLive, en tant que traducteur de la doc française ? les concepteurs (Karl Berry, Norbert Preining) t’expliqueront sûrement mieux que moi pourquoi /ils/ déconseillent cette méthode

Ça a déjà été discuté :

┌──── │ [tex-live] Why is "create symlinks in standard directories" option hidden? └────

et, en gros, les arguments avancés sont les mêmes que les tiens. Comme je le disais, « [j]e n’ai jamais été convaincu par les arguments avancés à ce sujet ». D’autant que, là non plus, aucune réponse n’a été apportée à mes contre-arguments.

(tout comme l’installation en « root »).

Je vais poser la question.

Bien cordialement.

Denis

[dbitouze (Denis Bitouzé)]

Le 05/03/20 à 14h40, Patrick Bideault a écrit :

Le jeudi 5 mars 2020 à 09:52 Denis Bitouzé écrivit :

OUI, la modification du PATH demande de l’attention (il y a différents « shell, » différentes syntaxes, etc.)

C’est ce qui m’y a fait renoncer, notamment dans le chapitre relatif à l’installation de la TeX Live dans le livre « LaTeX, l’essentiel » que Jean-Côme et moi avons co-écrit.

Ce livre est tellement introuvable que je commence à avoir des doutes sur son existence passée ! Il en va de même par la traduction du TeXbook ! Il est grand temps de s’autoriser la question suivante : les ouvrages charpento-bitouzesques ne sont-ils que des mythes ?

Pas du tout :

┌──── │ Amazon.fr - INTRODUCTION A LATEX - Denis Bitouzé, Jean-Cöme Charpentier - Livres └────

127 € : 'y en a qui n’ont vraiment aucune vergogne !

#10ansquejecherche

Peut-être dans des BU ?

Denis

[daniel.flipo]

Le 05/03/2020 à 13:57, Michel Bovani a écrit :

Le 5 mars 2020 à 13:33, Daniel Flipo xyz@xyz.tld a écrit :

(tout comme l’installation en “root”).

Si tu veux faire une installation multi-utilisateurs, t’es quand même bien obligé d’utiliser aussi moins sudo, non ?

Non, pas du tout ! la seule chose qui importe est pour que tous les
utilisateurs aient accès aux fichiers est que les droits soient “r” pour
les fichiers, “rx” pour les exécutables et “rx” pour les répertoires.
C’est l’objet du “umask 022”.

Ensuite les mises à jour se font sans sudo ce qui me paraît quand même
plus prudent.

Peu importe qui est le proprio du répertoire /usr/local/texlive/ (root
ou toto). Si j’étais encore un peu plus parano que je ne le suis, je
mettrais un utilisateur “texlive” proprio de /usr/local/texlive/ et je
ferais “sudo texlive” pour mettre à jour texlive…

–
Daniel Flipo

[dbitouze (Denis Bitouzé)]

Le 05/03/20 à 15h43, Denis Bitouzé a écrit :

(tout comme l’installation en « root »).

Je vais poser la question.

En fait, la documentation de la TeX Live ne déconseille nulle part l’installation en tant que root. La seule mention à root qui s’y trouve est : « (you don’t have to be root or administrator to install TEX Live, but you do need write access to the target directory) ».

Denis

[daniel.flipo]

Le 05/03/2020 à 15:43, Denis Bitouzé a écrit :

Le 05/03/20 à 13h33, Daniel Flipo a écrit :

Le 05/03/2020 à 09:52, Denis Bitouzé a écrit :

À la lumière de mes arguments ci-dessus, ne penses-tu pas que la méthode
des liens symboliques donne également toute satisfaction ?

NON, j’ai déjà exposé mes arguments contre.

Certes, mais tu n’as pas exposé de contre-contre-arguments contre mes
contre-arguments

Je n’ai aucun goût pour les polémiques interminables.

Si tu acceptes d’avoir 400 ou 500 liens symboliques dans /usr/local/bin
et préfères taper des commandes du genre

┌────
│ $ /usr/local/texlive/2018/bin/x86_64-linux/tlmgr path add
└────

plutôt que de gérer la variable PATH, ou de modifier un lien symbolique,
que veux-tu que j’ajoute ?

Comme je l’écrivais le 02/03/2020 à 22:29

« Il y a différentes approches possibles, l’important est que chacun en
trouve une qui lui convienne. »

Bien cordialement.

–
Daniel Flipo

[dbitouze (Denis Bitouzé)]

Le 05/03/20 à 14h24, Daniel Flipo a écrit :

Le 05/03/2020 à 13:57, Michel Bovani a écrit :

Le 5 mars 2020 à 13:33, Daniel Flipo xyz@xyz.tld a écrit :

(tout comme l’installation en « root »).

Si tu veux faire une installation multi-utilisateurs, t’es quand même bien obligé d’utiliser aussi moins sudo, non ?

Non, pas du tout ! la seule chose qui importe est pour que tous les utilisateurs aient accès aux fichiers est que les droits soient « r » pour les fichiers, « rx » pour les exécutables et « rx » pour les répertoires. C’est l’objet du « umask 022 ».

Ce qui se fait en root, non ? Mais, OK, ça ne se fait qu’une fois.

Ensuite les mises à jour se font sans sudo ce qui me paraît quand même plus prudent.

Raisonnable.

Peu importe qui est le proprio du répertoire /usr/local/texlive/ (root ou toto). Si j’étais encore un peu plus parano que je ne le suis, je mettrais un utilisateur « texlive » proprio de /usr/local/texlive/ et je ferais « sudo texlive » pour mettre à jour texlive…

Pourquoi pas…

Denis

[jmhuffle]

5 mars 2020 18:02 “Daniel Flipo” xyz@xyz.tld a écrit:

(…)
Je n’ai aucun goût pour les polémiques interminables.

Si tu acceptes d’avoir 400 ou 500 liens symboliques dans /usr/local/bin
et préfères taper des commandes du genre
(…)

Ajoutons notre grain de sel à cette très intéressante discussion… Moi non plus, je n’ai pas trop de goût pour les polémiques interminables. Je serais plutôt d’accord avec Denis - c’est mon problème -, mais il y a un point qui n’a pas encore été évoqué. Il n’est pas très bon d’avoir une énorme liste de répertoires dans la variable d’environnement PATH et mettre des liens à partir de /usr/local/bin me paraît une bonne solution à condition qu’il s’agisse de liens symboliques et pas de liens durs, c’est-à-dire qu’ils soient créés par la commande “ln -s r1 r2” et pas “ln r1 r2”. Cela permet d’identifier par un coup de “ls -l” la provenance d’une commande de ce répertoire. Etant donné l’énorme tas de commandes apportées par l’installation de TeXLive, cela me paraît plus clair.

Quant au risque qu’un lien pointe sur une ressource effacée, je dirais que c’est un contrôle qui fait partie du boulot d’ingénieur système, au même titre que de s’assurer que les utilisateurs n’ont pas accès à des commandes “dangereuses”. J’ai personnellement fait ce boulot, je sais de quoi je parle.

Quant à basculer d’une installation de TeX à une autre, il me semble qu’on n’a jamais deux installations qui sont vraiment en concurrence. Il y a toujours une instalation stable - pour laquelle les liens symboliques me semblent OK - et une autre qu’on cherche à tester, mais dans ce dernier cas, c’est une procédure transitoire pour laquelle des solutions ont été abondamment décrites.

Bien à vous,

J.-M. H.

[marot.jacques]

Le 05/03/2020 à 18:01, Daniel Flipo a écrit :

Je n’ai aucun goût pour les polémiques interminables.

Si tu acceptes d’avoir 400 ou 500 liens symboliques dans /usr/local/bin
et préfères taper des commandes du genre

┌────
│ $ /usr/local/texlive/2018/bin/x86_64-linux/tlmgr path add
└────

plutôt que de gérer la variable PATH, ou de modifier un lien symbolique,
que veux-tu que j’ajoute ?

Comme je l’écrivais le 02/03/2020 à 22:29

« Il y a différentes approches possibles, l’important est que chacun en
trouve une qui lui convienne. »

Bien cordialement.

Bonjour

Convaincu par cette discussion que créer des liens symbolyques
dans /usr/ bin n’était pas une bonne idée, et après avoir lu le
résultat de :

          ls  -al /usr/bin  | less

j’ai entrepris d’effacer à la main tous les liens symboliques vers
/usr/local/texlive/2019/bin/x86_64-linux/*
que j’avais pris la mauvaise habitude apparemment d’accepter à chaque
mise à jour de TEXLIVE.
Mon installation sous fedora avec l’éditeur KILE installé et compilé à
la main pour éviter les dépendances
vers une texlive obsolète quand on passe par les dépots redhat continue
à fonctionner parfaitement.

Il y a tellement de liens à effacer que j’ai renoncé à mi-chemin en
espérant qu’un linuxien chevronné pourrait
me souffler ici la manière d’élaborer une commande qui permettrait
d’effacer tous ces liens sans devoir répéter
à la main des centaines de commandes du types :

rm /usr/bin/pdflatex

Merci à tous les personnes sur cette liste à qui je dois beauoup
depuis les Texlives du siècle dernier.

Jacques MAROT

[dbitouze (Denis Bitouzé)]

Le 05/03/20 à 18h01, Daniel Flipo a écrit :

Le 05/03/2020 à 15:43, Denis Bitouzé a écrit :

Le 05/03/20 à 13h33, Daniel Flipo a écrit :

Le 05/03/2020 à 09:52, Denis Bitouzé a écrit :

À la lumière de mes arguments ci-dessus, ne penses-tu pas que la méthode des liens symboliques donne également toute satisfaction ?

NON, j’ai déjà exposé mes arguments contre.

Certes, mais tu n’as pas exposé de contre-contre-arguments contre mes contre-arguments

Je n’ai aucun goût pour les polémiques interminables.

Moi non plus, mais il ne s’agit pas dans mon esprit de polémique. Cf. ci-dessous.

Si tu acceptes d’avoir 400 ou 500 liens symboliques dans /usr/local/bin et préfères taper des commandes du genre

┌──── │ $ /usr/local/texlive/2018/bin/x86_64-linux/tlmgr path add └────

plutôt que de gérer la variable PATH, ou de modifier un lien symbolique, que veux-tu que j’ajoute ?

Comme je l’écrivais le 02/03/2020 à 22:29

« Il y a différentes approches possibles, l’important est que chacun en trouve une qui lui convienne. »

Dans un des précédents messages de ce fil, tu répondais au fait que je conseillais l’usage des liens symboliques car ça simplifiait sacrément la procédure d’installation :

« Là, non pas d’accord. Ce n’est pas conseillé », en ajoutant certes plus loin « mais les goûts et les couleurs… ».

Or, si j’ai cherché à nous pousser dans nos retranchements, c’est parce que, justement, j’ai plusieurs fois lu que les liens symboliques n’étaient pas conseillé pour l’installation de la TL mais :

1. je n’ai jamais eu aucun problème avec ;
2. les arguments avancés en défaveur de cette méthode ne m’ont jamais convaincus et n’ont jamais été vraiment étayés, notamment après que j’ai avancé des contre-arguments.

Du coup, je voulais être enfin convaincu :

• soit que je faisais erreur et qu’il me fallait réviser mon jugement ;
• soit que je pouvais parfaitement continuer à (conseiller d’)utiliser la méthode des liens symboliques.

Je conclus donc de notre échange que la méthode des liens symboliques ne peut pas vraiment être déconseillée : c’est une des deux méthodes possibles dont les avantages/inconvénients relèvent plutôt de goûts personnels que de critères objectifs.

Je peux donc en toute tranquillité d’esprit continuer à (conseiller d’)utiliser cette méthode.

Bien cordialement.

Denis

[jmhuffle]

6 mars 2020 11:34 “MAROT Jacques” xyz@xyz.tld a écrit:

(…)
Il y a tellement de liens à effacer que j’ai renoncé à mi-chemin en
espérant qu’un linuxien chevronné pourrait
me souffler ici la manière d’élaborer une commande qui permettrait
d’effacer tous ces liens sans devoir répéter
à la main des centaines de commandes du types :

Personnellement, je ne ferais pas un enlèvement “aveugle”, mais examinerais au cas par cas les liens. Pour en obtenir la liste :

ls -F |grep @$

pour enlever les “@” à la fin des noms :

ls -F |grep @$|awk -F@ ‘{print $1}’

Bien à vous,

J.-M. H.

[raphael.plasson (Raphaël Plasson)]

Bonjour,

concernant ce débat sur la manière “propre” de maintenir la possibilité
d’avoir plusieurs installations concurrentes de TeXLive, tout en
permettant de switcher de l’une à l’autre, il me semble que vous devriez
regarder (en tout cas pour les installations sur Debian, et probablement
aussi de ses dérivés tels que Ubuntu) du coté des “alternatives”
(I Challenge Thee).

Pour info, il s’agit d’un système centralisé permettant de configurer
les exécutables via des liens (comme vous essayez de la faire), mais de
manière propre pour pouvoir basculer d’un exécutable à l’autre (pas de
création/suppression à la main de liens…). Cela peut en particulier
servir à avoir un exécutable pouvant pointer vers différentes version,
et de sélectionner la version par défaut.

Je prends l’exemple concernant php (juste parce qu’il s’agit du premier
exemple avec 2 versions concurrentes que j’ai trouvé, installé
présentement sur ma Debian ):

L’executable /usr/bin/php est un lien vers /etc/alternatives/php, et
/etc/alternatives/php est un lien vers /usr/bin/php7.4. Je peux
facilement basculer à une version de php à une autre avec la commande
“update-alternatives --config php” (en root). Cette commande me donne un
menu où j’ai le choix entre “auto” (le jour où j’installe php7.5, php
pointera vers lui), ou en manuel (j’ai le choix entre php7.3 et 7.4). Et
si je choisit de basculer en manuel sur php7.3, le lien
/etc/alternatives/php pointe alors vers /usr/bin/php7.3. Dans tous les
cas, le contenu des liens présents dans /usr/bin ne changent jamais (ils
pointent toujours vers le dossier /etc/alternatives), et seuls les liens
présents dans /etc/alternatives sont modifiés. Et ces liens ne sont
jamais modifiés à la main, mais via la commande update-alternatives.

À noter que ce système gère des “groupes” d’alternatives. Avec mon
exemple précédent sur php, basculer d’une version à une autre de php me
bascule non seulement l’exécutable /usr/bin/php, mais aussi le manuel
/usr/share/man/man1/php.1.gz sur la bonne version (donc maintient d’une
cohérence entre l’ensemble des liens du même groupe).

À priori, vous devriez pouvoir mettre en place ce mécanisme pour que vos
liens de /usr/local/bin pointent vers /etc/alternatives, et que ceux-ci
pointent vers les différentes TeXLive installées, et pouvoir basculer
d’une version à une autre par un simple update-alternatives (voir même
de tenter de faire cohabiter cette solution avec la TeXLive des packages
officiels de la distribution). Je ne sais pas si cela serai simple à
faire, mais ce serait une solution propre.

Raphaël

PS: Ce débat me conforte néanmoins dans ma position par rapport à
l’installation de logiciels sur un ordinateur: ce n’est pas un processus
trivial et anodin, surtout lorsqu’il s’agit d’un ensemble aussi imposant
que TeXLive. Il me semble que faire confiance au mainteneur des packages
officiels pour maintenir la cohérence avec le système est la solution la
plus sure. D’autant que sous Debian (SID), cela implique quand-même une
mise à jour mensuelle de la TeXLive, donc pas tant de retard que cela…

Le fait d’avoir définitivement basculé (il y a plus de 20 ans) sur
Debian a justement été motivé (en partie) par le fait de ne plus avoir à
me soucier de ces problèmes d’installation, et de laisser gérer le
système tout seul lorsque je lui demande d’installer un logiciel.

Le 06/03/2020 à 11:34, MAROT Jacques a écrit :

Le 05/03/2020 à 18:01, Daniel Flipo a écrit :

Je n’ai aucun goût pour les polémiques interminables.

Si tu acceptes d’avoir 400 ou 500 liens symboliques dans /usr/local/bin
et préfères taper des commandes du genre

┌────
│ $ /usr/local/texlive/2018/bin/x86_64-linux/tlmgr path add
└────

plutôt que de gérer la variable PATH, ou de modifier un lien symbolique,
que veux-tu que j’ajoute ?

Comme je l’écrivais le 02/03/2020 à 22:29

« Il y a différentes approches possibles, l’important est que chacun en
trouve une qui lui convienne. »

Bien cordialement.

Bonjour

Convaincu par cette discussion que créer des liens symbolyques
dans /usr/ bin n’était pas une bonne idée, et après avoir lu le
résultat de :

           ls  -al /usr/bin  | less

j’ai entrepris d’effacer à la main tous les liens symboliques vers
/usr/local/texlive/2019/bin/x86_64-linux/*
que j’avais pris la mauvaise habitude apparemment d’accepter à chaque
mise à jour de TEXLIVE.
Mon installation sous fedora avec l’éditeur KILE installé et compilé à
la main pour éviter les dépendances
vers une texlive obsolète quand on passe par les dépots redhat continue
à fonctionner parfaitement.

Il y a tellement de liens à effacer que j’ai renoncé à mi-chemin en
espérant qu’un linuxien chevronné pourrait
me souffler ici la manière d’élaborer une commande qui permettrait
d’effacer tous ces liens sans devoir répéter
à la main des centaines de commandes du types :

rm /usr/bin/pdflatex

Merci à tous les personnes sur cette liste à qui je dois beauoup
depuis les Texlives du siècle dernier.

Jacques MAROT

[jean-yves.baudais]

Bonjour,

Le 06/03/2020 à 11:34, MAROT Jacques a écrit :

Il y a tellement de liens à effacer que j’ai renoncé à mi-chemin en
espérant qu’un linuxien chevronné pourrait

Pour avoir la liste des liens symboliques

SHELL> ls -F | grep “@” | sed “s/@//g”

et pour les effacer

SHEEL> ls -F | grep “@” | sed “s/@//g” | xargs rm

ou avec un sous-shell pour avoir l’option -i et y aller avec prudence

SHELL> rm -i ls -F | grep "@" | sed "s/\@//g"

–
Jean-Yves Baudais

[nicolas.richard]

Il y a tellement de liens à effacer que j’ai renoncé à mi-chemin en
espérant qu’un linuxien chevronné pourrait

Il me semble que c’est le rôle de “tlmgr path remove” (je pense qu’il y
a aussi des liens symboliques pour les manpage et les pages infos à enlever)

Sinon ceci devrait marcher:

find /usr/local/bin -maxdepth 1 -type l -lname ‘texlive’ -ls

(remplacer -ls par -delete après avoir vérifié que les fichiers trouvés
sont les bons.)

a+

Nicolas.

[dbitouze (Denis Bitouzé)]

Bonjour,

Le 06/03/20 à 11h34, MAROT Jacques a écrit :

Convaincu par cette discussion que créer des liens symbolyques dans /usr/ bin n’était pas une bonne idée,

Dans /usr/bin, non, en effet. Mais, par défaut, la TeX Live ne propose pas ce répertoire : elle propose /usr/local/bin, ce qui est en revanche raisonnable car, sauf erreur de ma part :

• /usr/bin est réservé aux programmes gérés par le système de packages de la distribution Linux ;
• /usr/local/bin est réservé aux programmes non gérés par le système de packages de la distribution Linux, typiquement ceux compilés ou installés « à la vanille ».

et après avoir lu le résultat de :

          ls  -al /usr/bin  | less

j’ai entrepris d’effacer à la main tous les liens symboliques vers
/usr/local/texlive/2019/bin/x86_64-linux/*

Comme déjà dit, un simple :

┌──── │ tlmgr path remove └────

aurait suffi.

Denis

[dbitouze (Denis Bitouzé)]

Le 06/03/20 à 08h42, xyz@xyz.tld a écrit :

Ajoutons notre grain de sel à cette très intéressante discussion… Moi non plus, je n’ai pas trop de goût pour les polémiques interminables. Je serais plutôt d’accord avec Denis - c’est mon problème -, mais il y a un point qui n’a pas encore été évoqué. Il n’est pas très bon d’avoir une énorme liste de répertoires dans la variable d’environnement PATH et mettre des liens à partir de /usr/local/bin me paraît une bonne solution à condition qu’il s’agisse de liens symboliques et pas de liens durs, c’est-à-dire qu’ils soient créés par la commande « ln -s r1 r2 » et pas « ln r1 r2 ».

L’installateur de la TeX Live, avec l’option en question, crée bien des liens symboliques et non en dur. Par exemple :

┌──── │ $ ls -l /usr/local/bin/pdflatex │ lrwxrwxrwx 1 root root 49 mars 3 18:18 /usr/local/bin/pdflatex → /usr/local/texlive/2019/bin/x86_64-linux/pdflatex └────

Quant au risque qu’un lien pointe sur une ressource effacée, je dirais que c’est un contrôle qui fait partie du boulot d’ingénieur système,

Mais ça n’est pas bien méchant à faire :

┌──── │ find /usr/local/bin -xtype l -delete └────

Quant à basculer d’une installation de TeX à une autre, il me semble qu’on n’a jamais deux installations qui sont vraiment en concurrence. Il y a toujours une instalation stable - pour laquelle les liens symboliques me semblent OK - et une autre qu’on cherche à tester, mais dans ce dernier cas, c’est une procédure transitoire pour laquelle des solutions ont été abondamment décrites.

Yep.

Denis

[marot.jacques]

Le 06/03/2020 à 15:29, Jean-Yves Baudais a écrit :

Bonjour,

Le 06/03/2020 à 11:34, MAROT Jacques a écrit :

Il y a tellement de liens à effacer que j’ai renoncé à mi-chemin en
espérant qu’un linuxien chevronné pourrait

Pour avoir la liste des liens symboliques

SHELL> ls -F | grep “@” | sed “s/@//g”

et pour les effacer

SHEEL> ls -F | grep “@” | sed “s/@//g” | xargs rm

ou avec un sous-shell pour avoir l’option -i et y aller avec prudence

SHELL> rm -i ls -F | grep "@" | sed "s/\@//g"

Il est pas question d’effacer tous les liens,

mais seulement ceux qui pointent vers
/usr/local/texlive2019/…

–
Jean-Yves Baudais