Pourquoi cette commande :
. ./vars
passe en bash et pas en tcsh ?
(évidemment je suis positionnée dans le bon répertoire, et vars s'y
trouve)
Et question subsidiaire : c'est quoi le premier point ?
--
Nina
Surement un traitement différent du files System %£%*¨ case insensitive...
Ou la config par défaut de chacun des deux shell qui prend ou non en compte cette sensibilité.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Erwan David <erwan@rail.eu.org> wrote:
Surement un traitement différent du files System %£%*¨ case
insensitive...
Ou la config par défaut de chacun des deux shell qui prend ou non en
compte cette sensibilité.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Surement un traitement différent du files System %£%*¨ case insensitive...
Ou la config par défaut de chacun des deux shell qui prend ou non en compte cette sensibilité.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Vincent Lefevre
Dans l'article , Nina Popravka écrit:
On Sat, 10 Feb 2007 22:35:16 +0100, Erwan David wrote:
Les commandes sont des fichiers. bash doit chercher le fichier avec le nom que tu lui as demandé. Comme HFS+ est case insensitive quelle que soit la casse que tu as utilisé il va le trouver. tcsh lui doit vérifier que le fichier truvé a bien le bon nom (avec la bonne casse).
Ok, merci à tous les deux. Mèzalors pourquoi ça ne s'applique pas aux noms de répertoires ? Parce que là, tous les deux s'en foutent.
Parce qu'ils sont probablement gérés différemment. Je suppose que tcsh a le comportement suivant ou quelque chose similaire:
1. Il regarde s'il a la commande dans sa table de hachage. Comme tcsh ne sait pas a priori que le système de fichiers est insensible à la casse, cette recherche est sensible à la casse.
2. S'il a trouvé la commande, il l'exécute.
3. Sinon il reconstruit sa table de hachage, et repasse en 1, mais avec une erreur s'il ne trouve rien.
Cependant bash a le même problème. Et s'il y a 2 exécutables ./foo et bin/Foo, alors la commande foo va exécuter ./foo tandis que la commande Foo va exécuter bin/Foo (la casse va être ignorée seulement si la commande avec la bonne casse n'est pas trouvée, ce qui n'est pas très cohérent):
Quant à zsh, il va toujours exécuter bin/Foo, i.e. il va toujours ignorer la casse et exécuter la première commande située dans le $PATH, ce qui est AMHA le comportement attendu (et même pas besoin d'un rehash):
Dans l'article <kefss2l70qg4lr32bavjkjmkv6jbp4khqh@4ax.com>,
Nina Popravka <Nina@nospam> écrit:
On Sat, 10 Feb 2007 22:35:16 +0100, Erwan David <erwan@rail.eu.org>
wrote:
Les commandes sont des fichiers. bash doit chercher le fichier avec le
nom que tu lui as demandé. Comme HFS+ est case insensitive quelle que
soit la casse que tu as utilisé il va le trouver. tcsh lui doit
vérifier que le fichier truvé a bien le bon nom (avec la bonne casse).
Ok, merci à tous les deux.
Mèzalors pourquoi ça ne s'applique pas aux noms de répertoires ? Parce
que là, tous les deux s'en foutent.
Parce qu'ils sont probablement gérés différemment. Je suppose que tcsh
a le comportement suivant ou quelque chose similaire:
1. Il regarde s'il a la commande dans sa table de hachage. Comme tcsh
ne sait pas a priori que le système de fichiers est insensible à
la casse, cette recherche est sensible à la casse.
2. S'il a trouvé la commande, il l'exécute.
3. Sinon il reconstruit sa table de hachage, et repasse en 1, mais
avec une erreur s'il ne trouve rien.
Cependant bash a le même problème. Et s'il y a 2 exécutables ./foo
et bin/Foo, alors la commande foo va exécuter ./foo tandis que la
commande Foo va exécuter bin/Foo (la casse va être ignorée seulement
si la commande avec la bonne casse n'est pas trouvée, ce qui n'est
pas très cohérent):
Quant à zsh, il va toujours exécuter bin/Foo, i.e. il va toujours
ignorer la casse et exécuter la première commande située dans le
$PATH, ce qui est AMHA le comportement attendu (et même pas besoin
d'un rehash):
On Sat, 10 Feb 2007 22:35:16 +0100, Erwan David wrote:
Les commandes sont des fichiers. bash doit chercher le fichier avec le nom que tu lui as demandé. Comme HFS+ est case insensitive quelle que soit la casse que tu as utilisé il va le trouver. tcsh lui doit vérifier que le fichier truvé a bien le bon nom (avec la bonne casse).
Ok, merci à tous les deux. Mèzalors pourquoi ça ne s'applique pas aux noms de répertoires ? Parce que là, tous les deux s'en foutent.
Parce qu'ils sont probablement gérés différemment. Je suppose que tcsh a le comportement suivant ou quelque chose similaire:
1. Il regarde s'il a la commande dans sa table de hachage. Comme tcsh ne sait pas a priori que le système de fichiers est insensible à la casse, cette recherche est sensible à la casse.
2. S'il a trouvé la commande, il l'exécute.
3. Sinon il reconstruit sa table de hachage, et repasse en 1, mais avec une erreur s'il ne trouve rien.
Cependant bash a le même problème. Et s'il y a 2 exécutables ./foo et bin/Foo, alors la commande foo va exécuter ./foo tandis que la commande Foo va exécuter bin/Foo (la casse va être ignorée seulement si la commande avec la bonne casse n'est pas trouvée, ce qui n'est pas très cohérent):
Quant à zsh, il va toujours exécuter bin/Foo, i.e. il va toujours ignorer la casse et exécuter la première commande située dans le $PATH, ce qui est AMHA le comportement attendu (et même pas besoin d'un rehash):
On Sun, 11 Feb 2007 03:47:00 +0000 (UTC), Vincent Lefevre <vincent+ wrote:
la casse va être ignorée seulement si la commande avec la bonne casse n'est pas trouvée, ce qui n'est pas très cohérent): Et source d'erreurs potentielles pour quelqu'un qui comme moi n'a pas
l'habitude d'un truc case sensitive. C'est pour ça que ça m'a tiré l'oeil. C'est assez couillon, comme comportement. -- Nina
On Sun, 11 Feb 2007 03:47:00 +0000 (UTC), Vincent Lefevre
<vincent+news@vinc17.org> wrote:
la casse va être ignorée seulement
si la commande avec la bonne casse n'est pas trouvée, ce qui n'est
pas très cohérent):
Et source d'erreurs potentielles pour quelqu'un qui comme moi n'a pas
l'habitude d'un truc case sensitive. C'est pour ça que ça m'a tiré
l'oeil. C'est assez couillon, comme comportement.
--
Nina
On Sun, 11 Feb 2007 03:47:00 +0000 (UTC), Vincent Lefevre <vincent+ wrote:
la casse va être ignorée seulement si la commande avec la bonne casse n'est pas trouvée, ce qui n'est pas très cohérent): Et source d'erreurs potentielles pour quelqu'un qui comme moi n'a pas
l'habitude d'un truc case sensitive. C'est pour ça que ça m'a tiré l'oeil. C'est assez couillon, comme comportement. -- Nina
Vincent Lefevre
Dans l'article , Nina Popravka écrit:
On Sun, 11 Feb 2007 03:47:00 +0000 (UTC), Vincent Lefevre <vincent+ wrote:
la casse va être ignorée seulement si la commande avec la bonne casse n'est pas trouvée, ce qui n'est pas très cohérent): Et source d'erreurs potentielles pour quelqu'un qui comme moi n'a pas
l'habitude d'un truc case sensitive. C'est pour ça que ça m'a tiré l'oeil. C'est assez couillon, comme comportement.
C'est plutôt l'incohérence qui est source d'erreurs. Il faut que le système de fichiers soit traité de manière complètement "insensible à la casse" ou complètement "sensible à la casse". Quelque chose d'intermédiaire, c'est une mauvaise idée, et AMHA un bug.
Dans l'article <m5kts2djsl5kd2mcsjm1vnsva5n3u5dunm@4ax.com>,
Nina Popravka <Nina@nospam> écrit:
On Sun, 11 Feb 2007 03:47:00 +0000 (UTC), Vincent Lefevre
<vincent+news@vinc17.org> wrote:
la casse va être ignorée seulement
si la commande avec la bonne casse n'est pas trouvée, ce qui n'est
pas très cohérent):
Et source d'erreurs potentielles pour quelqu'un qui comme moi n'a pas
l'habitude d'un truc case sensitive. C'est pour ça que ça m'a tiré
l'oeil. C'est assez couillon, comme comportement.
C'est plutôt l'incohérence qui est source d'erreurs. Il faut que le
système de fichiers soit traité de manière complètement "insensible
à la casse" ou complètement "sensible à la casse". Quelque chose
d'intermédiaire, c'est une mauvaise idée, et AMHA un bug.
On Sun, 11 Feb 2007 03:47:00 +0000 (UTC), Vincent Lefevre <vincent+ wrote:
la casse va être ignorée seulement si la commande avec la bonne casse n'est pas trouvée, ce qui n'est pas très cohérent): Et source d'erreurs potentielles pour quelqu'un qui comme moi n'a pas
l'habitude d'un truc case sensitive. C'est pour ça que ça m'a tiré l'oeil. C'est assez couillon, comme comportement.
C'est plutôt l'incohérence qui est source d'erreurs. Il faut que le système de fichiers soit traité de manière complètement "insensible à la casse" ou complètement "sensible à la casse". Quelque chose d'intermédiaire, c'est une mauvaise idée, et AMHA un bug.
