Forums Linux Autres OS Linux Debian

[hs] Cible et lien symbolique : comportement différent ?

Le
Alexandre Hoïde
Salut à vous de la liste,

Un petit truc m'échappe et, à vot' bon coeur, j'aimerais mieux comprendre.
J'ai :
/usr/bin/x-terminal-emulator@
-> /etc/alternatives/x-terminal-emulator@
-> /usr/bin/urxvt*

Donc, si je ne m'abuse, lancer urxvt à l'aide des liens symboliques ou
directement du fichier /usr/bin/urxvt devrait être strictement équivalent,
non ?! Or, j'ai un petit ~/.Xresources :

!--
URxvt*.transparent: true
URxvt*.shading: 100
URxvt.scrollBar:false
URxvt*internalborder: 6
urxvt*foreground: #f2f2f2
urxvt*background: #101010
!--

Où l'on voit que le nom de la ressource est mal orthographié sur les
deux dernières entrées (urxvt au lieu de URxvt).

Eh bien figurez-vous que, lancé avec /usr/bin/urxvt, toutes les lignes du
.Xresources sont honorées, tandis qu'avec
/{usr/bin,etc/alternatives}/x-terminal-emulator, les deux dernières lignes
[fautives] sont ignorées (je n'ai que les couleurs par défaut).

En corrigeant mon .Xresources s/ur/UR tout rentre dans l'ordre mais cet
ordre est soudain devenu obscur à mes yeux.

PS Expérience faite sur une Sid à jour avec Awesome. Les liens symboliques ont
été générés par «update-alternatives --config x-terminal-emulator».

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20131003222923.GA4326@gmail.com
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Sébastien NOBILI
Le #25702512
Le vendredi 04 octobre 2013 à 0:29, Alexandre Hoïde a écrit :
Eh bien figurez-vous que, lancé avec /usr/bin/urxvt, toutes les lignes du
.Xresources sont honorées, tandis qu'avec
/{usr/bin,etc/alternatives}/x-terminal-emulator, les deux dernières lignes
[fautives] sont ignorées (je n'ai que les couleurs par défaut).



Je viens de tester, URxvt interprète :
- toutes les lignes qui correspondent à son nom de ressource interne
(« URxvt »),
- toutes les lignes dont le nom de ressource correspond au nom du fichier
par lequel il a été appelé.

Test rapide :
ln -s /usr/bin/urxvt /tmp/toto
/tmp/toto

Toutes les lignes du fichier Xresources correspondant à « toto » seront
interprétées.

Ça te permet de faire une gestion de « profils » à pas cher !

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Philippe Deleval
Le #25702692
On 04/10/2013 00:29, Alexandre Hoïde wrote:
Salut à vous de la liste,

Un petit truc m'échappe et, à vot' bon coeur, j'aimerais mieux comprendre.
J'ai :
/usr/bin/x-terminal-emulator@
-> /etc/alternatives/x-terminal-emulator@
-> /usr/bin/urxvt*

Donc, si je ne m'abuse, lancer urxvt à l'aide des liens symboliques ou
directement du fichier /usr/bin/urxvt devrait être strictement équivalent,
non ?! Or, j'ai un petit ~/.Xresources :

!--
URxvt*.transparent: true
URxvt*.shading: 100
URxvt.scrollBar:false
URxvt*internalborder: 6
urxvt*foreground: #f2f2f2
urxvt*background: #101010
!--

Où l'on voit que le nom de la ressource est mal orthographié sur les
deux dernières entrées (urxvt au lieu de URxvt).

Eh bien figurez-vous que, lancé avec /usr/bin/urxvt, toutes les lignes du
.Xresources sont honorées, tandis qu'avec
/{usr/bin,etc/alternatives}/x-terminal-emulator, les deux dernières lignes
[fautives] sont ignorées (je n'ai que les couleurs par défaut).

En corrigeant mon .Xresources s/ur/UR tout rentre dans l'ordre... mais cet
ordre est soudain devenu obscur à mes yeux.

PS Expérience faite sur une Sid à jour avec Awesome. Les liens symboliques ont
été générés par «update-alternatives --config x-terminal-emulator».



Bonjour

A titre informatif, un programme peut accéder par la pile Linux (en C
par args[0]) à la commande par lequel il est lancé. Autrement dit le
programme "sait" s'il a été lancé par un alias, un lien symbolique ou
directement. Reste à savoir pourquoi urxvt se comporte différemment
suivant que la ligne de commande contient urxvt ou x-terminal-emulator.
Je n'ai aucune compétence sur ce point.

Cordialement

Philippe Deleval

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
BERTRAND Joël
Le #25702762
Philippe Deleval wrote:
On 04/10/2013 00:29, Alexandre Hoïde wrote:
Salut à vous de la liste,

Un petit truc m'échappe et, à vot' bon coeur, j'aimerais mieux
comprendre.
J'ai :
/usr/bin/x-terminal-emulator@
-> /etc/alternatives/x-terminal-emulator@
-> /usr/bin/urxvt*

Donc, si je ne m'abuse, lancer urxvt à l'aide des liens symboliques ou
directement du fichier /usr/bin/urxvt devrait être strictement
équivalent,
non ?! Or, j'ai un petit ~/.Xresources :

!--
URxvt*.transparent: true
URxvt*.shading: 100
URxvt.scrollBar:false
URxvt*internalborder: 6
urxvt*foreground: #f2f2f2
urxvt*background: #101010
!--

Où l'on voit que le nom de la ressource est mal orthographié sur les
deux dernières entrées (urxvt au lieu de URxvt).

Eh bien figurez-vous que, lancé avec /usr/bin/urxvt, toutes les lignes du
.Xresources sont honorées, tandis qu'avec
/{usr/bin,etc/alternatives}/x-terminal-emulator, les deux dernières
lignes
[fautives] sont ignorées (je n'ai que les couleurs par défaut).

En corrigeant mon .Xresources s/ur/UR tout rentre dans l'ordre... mais
cet
ordre est soudain devenu obscur à mes yeux.

PS Expérience faite sur une Sid à jour avec Awesome. Les liens
symboliques ont
été générés par «update-alternatives --config x-terminal-emulator».



Bonjour

A titre informatif, un programme peut accéder par la pile Linux (en C
par args[0]) à la commande par lequel il est lancé. Autrement dit le
programme "sait" s'il a été lancé par un alias, un lien symbolique ou
directement.



Attention, ça n'est pas portable. Je ne sais plus sous quel Unix j'ai
pu constater que cela ne fonctionnait pas... et je pense que c'est à la
discrétion du shell, pas de l'OS. Je suis même déjà tombé sur un OS où
toute la ligne de commande, arguments compris, se trouvait dans argv[0]
et un autre qui omettait le nom de la commande et dont argv[0] contenait
directement le premier argument !

Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Alexandre Hoïde
Le #25703052
On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote:
Philippe Deleval wrote:
>A titre informatif, un programme peut accéder par la pile Linux (en C
>par args[0]) à la commande par lequel il est lancé. Autrement dit le
>programme "sait" s'il a été lancé par un alias, un lien symbolique ou
>directement.

Attention, ça n'est pas portable. Je ne sais plus sous quel Unix
j'ai pu constater que cela ne fonctionnait pas... et je pense que
c'est à la discrétion du shell, pas de l'OS. Je suis même déjà tombé
sur un OS où toute la ligne de commande, arguments compris, se
trouvait dans argv[0] et un autre qui omettait le nom de la commande
et dont argv[0] contenait directement le premier argument !



Oui, dans mon désir que la transparence référentielle s'impose sur terre
comme aux cieux, j'avais omis d'intégrer ces détails impurs à ma
réflexion. Merci à vous deux pour ces précisions.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Sylvain L. Sauvage
Le #25703142
[Je réponds au précédent mais j’ai perdu le cour riel…]

Le vendredi 4 octobre 2013 15:18:43 Alexandre Hoïde a écrit :
On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote:
[…]
> Attention, ça n'est pas portable. Je ne sais plus sous quel
> Unix
> j'ai pu constater que cela ne fonctionnait pas... et je
> pense que c'est à la discrétion du shell, pas de l'OS. Je
> suis même déjà tombé sur un OS où toute la ligne de
> commande, arguments compris, se trouvait dans argv[0] et un
> autre qui omettait le nom de la commande et dont argv[0]
> contenait directement le premier argument !



C’est un standard du langage C¹.
Mauvais compilateur/libc, changer compilateur/libc.

¹ Cf. section 5.1.2.2.1 de la version C99 ( http://www.open-std.or g/jtc1/sc22/WG14/www/docs/n1256.pdf p.11, 23e page du
PDF).

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Sylvain L. Sauvage
Le #25703162
Le vendredi 4 octobre 2013 15:58:10 Sylvain L. Sauvage a écrit :
[…]
C’est un standard du langage C¹.
Mauvais compilateur/libc, changer compilateur/libc.

¹ Cf. section 5.1.2.2.1 de la version C99 (
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
p.11, 23e page du PDF).



Oh, et si quatorze ans, ça vous paraît trop jeune comme
standard, c’est comme ça depuis au moins l’ANSI C (1988) :
http://flash-gordon.me.uk/ansi.c.txt (même section, mêmes mot s).

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
BERTRAND Joël
Le #25703172
Sylvain L. Sauvage wrote:
[Je réponds au précédent mais j’ai perdu le courriel…]

Le vendredi 4 octobre 2013 15:18:43 Alexandre Hoïde a écrit :
On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote:
[…]
Attention, ça n'est pas portable. Je ne sais plus sous quel
Unix
j'ai pu constater que cela ne fonctionnait pas... et je
pense que c'est à la discrétion du shell, pas de l'OS. Je
suis même déjà tombé sur un OS où toute la ligne de
commande, arguments compris, se trouvait dans argv[0] et un
autre qui omettait le nom de la commande et dont argv[0]
contenait directement le premier argument !





C’est un standard du langage C¹.
Mauvais compilateur/libc, changer compilateur/libc.

¹ Cf. section 5.1.2.2.1 de la version C99 ( http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf p.11, 23e page du
PDF).




Le compilo est un gcc récent avec un linux embarqué sur je ne sais plus
quelle architecture. Et la libc était une eglibc des familles. D'un
autre côté, je suis assez d'accord avec toi, c'est une très mauvaise
libc :-P

Entre-nous, c'est le shell qui empile ça grçace à un appel de la libc
avant l'appel au main() (dans le cas du C). Si le shell décide de tout
mettre dans argv[0] parce que ça lui fait plaisir, je ne vois pas trop
ce que le compilo pourrait faire...

Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Erwan David
Le #25703442
Le 04/10/2013 16:03, BERTRAND Joël a écrit :
Sylvain L. Sauvage wrote:
[Je réponds au précédent mais j’ai perdu le courriel…]

Le vendredi 4 octobre 2013 15:18:43 Alexandre Hoïde a écrit :
On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote:
[…]
Attention, ça n'est pas portable. Je ne sais plus sous quel
Unix
j'ai pu constater que cela ne fonctionnait pas... et je
pense que c'est à la discrétion du shell, pas de l'OS. Je
suis même déjà tombé sur un OS où toute la ligne de
commande, arguments compris, se trouvait dans argv[0] et un
autre qui omettait le nom de la commande et dont argv[0]
contenait directement le premier argument !





C’est un standard du langage C¹.
Mauvais compilateur/libc, changer compilateur/libc.

¹ Cf. section 5.1.2.2.1 de la version C99 (
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf p.11, 23e
page du
PDF).




Le compilo est un gcc récent avec un linux embarqué sur je ne sais
plus quelle architecture. Et la libc était une eglibc des familles.
D'un autre côté, je suis assez d'accord avec toi, c'est une très
mauvaise libc :-P

Entre-nous, c'est le shell qui empile ça grçace à un appel de la
libc avant l'appel au main() (dans le cas du C). Si le shell décide de
tout mettre dans argv[0] parce que ça lui fait plaisir, je ne vois pas
trop ce que le compilo pourrait faire...

Cordialement,

JKB




Tu dois donc avoir un C free-standing, plutôt qu'un C hosted. Dans ce
cas il n'y a de fait pas de libc, mais une lib qui n'implémente que
partiellement les fonctionalités de la libc.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
BERTRAND Joël
Le #25705312
Erwan David a écrit :
Le 04/10/2013 16:03, BERTRAND Joël a écrit :
Sylvain L. Sauvage wrote:
[Je réponds au précédent mais j’ai perdu le courriel…]

Le vendredi 4 octobre 2013 15:18:43 Alexandre Hoïde a écrit :
On Fri, Oct 04, 2013 at 12:50:35PM +0200, BERTRAND Joël wrote:
[…]
Attention, ça n'est pas portable. Je ne sais plus sous quel
Unix
j'ai pu constater que cela ne fonctionnait pas... et je
pense que c'est à la discrétion du shell, pas de l'OS. Je
suis même déjà tombé sur un OS où toute la ligne de
commande, arguments compris, se trouvait dans argv[0] et un
autre qui omettait le nom de la commande et dont argv[0]
contenait directement le premier argument !





C’est un standard du langage C¹.
Mauvais compilateur/libc, changer compilateur/libc.

¹ Cf. section 5.1.2.2.1 de la version C99 (
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf p.11, 23e
page du
PDF).




Le compilo est un gcc récent avec un linux embarqué sur je ne sais
plus quelle architecture. Et la libc était une eglibc des familles.
D'un autre côté, je suis assez d'accord avec toi, c'est une très
mauvaise libc :-P

Entre-nous, c'est le shell qui empile ça grçace à un appel de la
libc avant l'appel au main() (dans le cas du C). Si le shell décide de
tout mettre dans argv[0] parce que ça lui fait plaisir, je ne vois pas
trop ce que le compilo pourrait faire...

Cordialement,

JKB




Tu dois donc avoir un C free-standing, plutôt qu'un C hosted. Dans ce
cas il n'y a de fait pas de libc, mais une lib qui n'implémente que
partiellement les fonctionalités de la libc.



Non, non, je t'assure que c'est un eglibc et un vrai compilo C (gcc)
brut de fonderie.

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Répondre en citant
Poster une réponse
Anonyme