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
On Thu, 08 Feb 2007 20:08:35 +0100, Nina Popravka wrote:
Et question subsidiaire : c'est quoi le premier point ? source...
Des psychopathes, je vous dis ;->>>>>> Comme si c'était pas déjà assez compliqué comme ça. -- Nina
Sébastien Kirche
Le 8 février 2007 à 20:08, Nina Popravka a formulé :
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)
'me semble que cette méthode fonctionne sur les shells bourne (comme bash) mais pas les c-shells (Seychelles ?) comme csh et tcsh.
Et question subsidiaire : c'est quoi le premier point ?
Ça exécute le script qui suit dans le shell courant sans lancer un sous-shell. Comme cela les variables qui sont définies dans vars le restent pour les manips suivantes. Autrement les définitions sont perdues car un processus parent n'hérite pas (l'environnement) de ses enfants. -- Sébastien Kirche
Le 8 février 2007 à 20:08, Nina Popravka a formulé :
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)
'me semble que cette méthode fonctionne sur les shells bourne (comme
bash) mais pas les c-shells (Seychelles ?) comme csh et tcsh.
Et question subsidiaire : c'est quoi le premier point ?
Ça exécute le script qui suit dans le shell courant sans lancer un
sous-shell. Comme cela les variables qui sont définies dans vars le
restent pour les manips suivantes. Autrement les définitions sont
perdues car un processus parent n'hérite pas (l'environnement) de ses
enfants.
--
Sébastien Kirche
Le 8 février 2007 à 20:08, Nina Popravka a formulé :
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)
'me semble que cette méthode fonctionne sur les shells bourne (comme bash) mais pas les c-shells (Seychelles ?) comme csh et tcsh.
Et question subsidiaire : c'est quoi le premier point ?
Ça exécute le script qui suit dans le shell courant sans lancer un sous-shell. Comme cela les variables qui sont définies dans vars le restent pour les manips suivantes. Autrement les définitions sont perdues car un processus parent n'hérite pas (l'environnement) de ses enfants. -- Sébastien Kirche
cf
Nina Popravka wrote:
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 ?
Le premier point indique d'exécuter le script comme si chacune de ses commandes était tapée directement depuis la ligne de commande, alors que quand il n'y a pas le point, le script est exécuté dans un "sous-shell".
La différence essentielle est que dans le deuxième cas (exécution sans le point), l'environnement du shell courant n'est pas modifié. Lorsqu'on veut exécuter un script qui modifie de façon durable les variables d'environnement (ce qui est sans doute le cas du tien, comme son nom l'indique), il est donc nécessaire de l'exécuter avec le point.
Par exemple, si le script toto contient juste la commande a=5 :
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 ?
Le premier point indique d'exécuter le script comme si chacune de ses
commandes était tapée directement depuis la ligne de commande, alors que
quand il n'y a pas le point, le script est exécuté dans un "sous-shell".
La différence essentielle est que dans le deuxième cas (exécution sans
le point), l'environnement du shell courant n'est pas modifié. Lorsqu'on
veut exécuter un script qui modifie de façon durable les variables
d'environnement (ce qui est sans doute le cas du tien, comme son nom
l'indique), il est donc nécessaire de l'exécuter avec le point.
Par exemple, si le script toto contient juste la commande a=5 :
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 ?
Le premier point indique d'exécuter le script comme si chacune de ses commandes était tapée directement depuis la ligne de commande, alors que quand il n'y a pas le point, le script est exécuté dans un "sous-shell".
La différence essentielle est que dans le deuxième cas (exécution sans le point), l'environnement du shell courant n'est pas modifié. Lorsqu'on veut exécuter un script qui modifie de façon durable les variables d'environnement (ce qui est sans doute le cas du tien, comme son nom l'indique), il est donc nécessaire de l'exécuter avec le point.
Par exemple, si le script toto contient juste la commande a=5 :
On Thu, 08 Feb 2007 20:39:02 +0100, Sébastien Kirche wrote:
Ça exécute le script qui suit dans le shell courant sans lancer un sous-shell. Comme cela les variables qui sont définies dans vars le restent pour les manips suivantes. Autrement les définitions sont perdues car un processus parent n'hérite pas (l'environnement) de ses enfants. Lumineux, merci m'sieur !
:-) -- Nina
On Thu, 08 Feb 2007 20:39:02 +0100, Sébastien Kirche
<sebastien.kirche.no@spam.free.fr.invalid> wrote:
Ça exécute le script qui suit dans le shell courant sans lancer un
sous-shell. Comme cela les variables qui sont définies dans vars le
restent pour les manips suivantes. Autrement les définitions sont
perdues car un processus parent n'hérite pas (l'environnement) de ses
enfants.
Lumineux, merci m'sieur !
On Thu, 08 Feb 2007 20:39:02 +0100, Sébastien Kirche wrote:
Ça exécute le script qui suit dans le shell courant sans lancer un sous-shell. Comme cela les variables qui sont définies dans vars le restent pour les manips suivantes. Autrement les définitions sont perdues car un processus parent n'hérite pas (l'environnement) de ses enfants. Lumineux, merci m'sieur !
:-) -- Nina
Nina Popravka
On Thu, 8 Feb 2007 15:42:04 -0400, (Christian Fauchier) wrote:
Bref des variables globales et locales. Ce qui dépasse un peu mon entendement, c'est que c'est très chiant de changer de syntaxe au niveau d'un shell, because automatismes, donc je comprend pas trop ce qu'il a pris à une branche de barbus de changer la syntaxe d'un truc aussi élémentaire. -- Nina
On Thu, 8 Feb 2007 15:42:04 -0400, cf@nospam.invalid (Christian
Fauchier) wrote:
Bref des variables globales et locales.
Ce qui dépasse un peu mon entendement, c'est que c'est très chiant de
changer de syntaxe au niveau d'un shell, because automatismes, donc je
comprend pas trop ce qu'il a pris à une branche de barbus de changer
la syntaxe d'un truc aussi élémentaire.
--
Nina
Bref des variables globales et locales. Ce qui dépasse un peu mon entendement, c'est que c'est très chiant de changer de syntaxe au niveau d'un shell, because automatismes, donc je comprend pas trop ce qu'il a pris à une branche de barbus de changer la syntaxe d'un truc aussi élémentaire. -- Nina
Nina Popravka
Et une deuxième angoisse métaphysique : pourquoi tcsh est caps sensitive, et pas bash ??? Je pensais *nix caps sensitive par essence ? -- Nina
Et une deuxième angoisse métaphysique :
pourquoi tcsh est caps sensitive, et pas bash ???
Je pensais *nix caps sensitive par essence ?
--
Nina
On Sat, 10 Feb 2007 22:10:20 +0100, Erwan David wrote:
Surement un traitement différent du files System %£%*¨ case insensitive... Ah le chien... Ca va me prendre 3 heures de Google pour intuitionner
le sens de cette remarque certainement très pertinente :-) -- Nina
Saïd
Nina Popravka :
On Sat, 10 Feb 2007 22:10:20 +0100, Erwan David wrote:
Surement un traitement différent du files System %£%*¨ case insensitive... Ah le chien... Ca va me prendre 3 heures de Google pour intuitionner
le sens de cette remarque certainement très pertinente :-)
Sur des partitions HFS+, si on a un fichier dont le vrai nom est: Fichier et qu'un programme demande a ouvrir le fichier dont le nom est: fichier alors le systeme accepte et ouvre le fichier "Fichier". Ca veut dire que le systeme de fichier HFS+ n'est pas sensible a la casse. La plupart des systemes de fichier utilises par des sytemes UNIX sont sensibles a la casse.
appremment tcsh, ne tient pas compte du fait que HFS+ y est insensible. Il n'accpete pas de lancer la commande systemachin (celle que tu as utilisee dans ton exemple) parce qu'il ne voit que le vrai nom de la commande qui doit etre SystemMAchin. bash a l'air de tenir compte des specificites du HFS+ et zsh (que j'utilise) le fait aussi.
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Nina Popravka :
On Sat, 10 Feb 2007 22:10:20 +0100, Erwan David <erwan@rail.eu.org>
wrote:
Surement un traitement différent du files System %£%*¨ case
insensitive...
Ah le chien... Ca va me prendre 3 heures de Google pour intuitionner
le sens de cette remarque certainement très pertinente :-)
Sur des partitions HFS+, si on a un fichier dont le vrai nom est:
Fichier
et qu'un programme demande a ouvrir le fichier dont le nom est:
fichier
alors le systeme accepte et ouvre le fichier "Fichier". Ca veut dire que le
systeme de fichier HFS+ n'est pas sensible a la casse. La plupart des
systemes de fichier utilises par des sytemes UNIX sont sensibles a la casse.
appremment tcsh, ne tient pas compte du fait que HFS+ y est insensible. Il
n'accpete pas de lancer la commande systemachin (celle que tu as utilisee
dans ton exemple) parce qu'il ne voit que le vrai nom de la commande qui
doit etre SystemMAchin. bash a l'air de tenir compte des specificites du
HFS+ et zsh (que j'utilise) le fait aussi.
--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger
On Sat, 10 Feb 2007 22:10:20 +0100, Erwan David wrote:
Surement un traitement différent du files System %£%*¨ case insensitive... Ah le chien... Ca va me prendre 3 heures de Google pour intuitionner
le sens de cette remarque certainement très pertinente :-)
Sur des partitions HFS+, si on a un fichier dont le vrai nom est: Fichier et qu'un programme demande a ouvrir le fichier dont le nom est: fichier alors le systeme accepte et ouvre le fichier "Fichier". Ca veut dire que le systeme de fichier HFS+ n'est pas sensible a la casse. La plupart des systemes de fichier utilises par des sytemes UNIX sont sensibles a la casse.
appremment tcsh, ne tient pas compte du fait que HFS+ y est insensible. Il n'accpete pas de lancer la commande systemachin (celle que tu as utilisee dans ton exemple) parce qu'il ne voit que le vrai nom de la commande qui doit etre SystemMAchin. bash a l'air de tenir compte des specificites du HFS+ et zsh (que j'utilise) le fait aussi.
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Nina Popravka
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. -- Nina
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.
--
Nina
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. -- Nina
