Soient deux répertoires A et B (dans mon home, mettons), C un
sous-répertoire de A, et D un lien symbolique placé dans B et pointant vers
C. Si, depuis B, je fais 'cd D', et que j'affiche PWD,
j'obtiens /home/moi/B/D. Si je fais 'cd ..' je reviens dans B. Si par
contre, je choisis un fichier F de C, et que, au moment où mon PWD
est /home/moi/B/D, je fais 'cp F ..', F se retrouve dans A.
Je trouve ça assez troublant : est-ce que c'est un comportement normal ?
Quelle est la logique derrière ça ?
Je connais l'option -P de cd qui permet de savoir toujours où on est pour de
vrai et évite les ambiguïtés, mais parfois j'utilise des liens symboliques
pointant vers un répertoire « profond » dans la hiérarchie, et c'est
justement pour ne pas avoir à me farcir le chemin complet à chaque fois (en
même temps, il y a une notion de répertoire nommé sous zsh je crois, ça
doit aider...)
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote: [...]
PWD Set by the shell to be an absolute pathname of the current working directory, containing no components of type symbolic link, no components that are dot, and no components that are dot-dot when the shell is initialized. If an application sets or unsets the value of PWD , the behaviors of the cd and pwd utilities are unspecified.
Je faisais reference au fait que ksh/bash heritent PWD de l'environnement allant a l'encontre de POSIX.
Je ne conteste pas le fait qu'ils assignent un chemin logique a $PWD ou que cd .. ne fait pas un chdir("..").
-- Stephane
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote:
[...]
PWD
Set by the shell to be an absolute pathname of the
current working directory, containing no components
of type symbolic link, no components that are dot,
and no components that are dot-dot when the shell is
initialized. If an application sets or unsets the
value of PWD , the behaviors of the cd and pwd
utilities are unspecified.
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote: [...]
PWD Set by the shell to be an absolute pathname of the current working directory, containing no components of type symbolic link, no components that are dot, and no components that are dot-dot when the shell is initialized. If an application sets or unsets the value of PWD , the behaviors of the cd and pwd utilities are unspecified.
Je faisais reference au fait que ksh/bash heritent PWD de l'environnement allant a l'encontre de POSIX.
Je ne conteste pas le fait qu'ils assignent un chemin logique a $PWD ou que cd .. ne fait pas un chdir("..").
-- Stephane
Cyrille Lefevre
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote: [...]
PWD Set by the shell to be an absolute pathname of the current working directory, containing no components of type symbolic link, no components that are dot, and no components that are dot-dot when the shell is initialized. If an application sets or unsets the value of PWD , the behaviors of the cd and pwd utilities are unspecified.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_05_03 oui, mais la page suivante ne fait pas référence aux liens symboliques :
Je faisais reference au fait que ksh/bash heritent PWD de l'environnement allant a l'encontre de POSIX.
je ne vois rien dans la norme qui interdise cela.
pour aller plus loin, la variable $PWD est supposée symboliser le répertoire courant lorsqu'elle existe, à cet effet, en hériter ne me semble pas incohérent.
pour autant, cela peut effectivement poser un pb si un prog fork un shell alors qu'il a fait un chdir() sans avoir mis a jour $PWD.
toutefois, je viens de faire un test sous cygwin sans rencontrer le pb que met en avant ! à tester sous de vrais unix... la réponse demain :)
idem avec cc.c : int main() { putenv("PWD=/");printf("%sn",getenv("PWD"));return(execlp(getenv("SHELL"),0)); }
comme ça, on ne peut pas accuser system() de faire quoique ce soit.
Regards, Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote:
[...]
PWD
Set by the shell to be an absolute pathname of the
current working directory, containing no components
of type symbolic link, no components that are dot,
and no components that are dot-dot when the shell is
initialized. If an application sets or unsets the
value of PWD , the behaviors of the cd and pwd
utilities are unspecified.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_05_03
oui, mais la page suivante ne fait pas référence aux liens symboliques :
Je faisais reference au fait que ksh/bash heritent PWD de
l'environnement allant a l'encontre de POSIX.
je ne vois rien dans la norme qui interdise cela.
pour aller plus loin, la variable $PWD est supposée symboliser le
répertoire courant lorsqu'elle existe, à cet effet, en hériter ne
me semble pas incohérent.
pour autant, cela peut effectivement poser un pb si un prog fork un
shell alors qu'il a fait un chdir() sans avoir mis a jour $PWD.
toutefois, je viens de faire un test sous cygwin sans rencontrer le pb
que met en avant ! à tester sous de vrais unix... la réponse demain :)
idem avec cc.c :
int main() {
putenv("PWD=/");printf("%sn",getenv("PWD"));return(execlp(getenv("SHELL"),0));
}
comme ça, on ne peut pas accuser system() de faire quoique ce soit.
Regards, Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
remove "%nospam" and ".invalid" to answer me.
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote: [...]
PWD Set by the shell to be an absolute pathname of the current working directory, containing no components of type symbolic link, no components that are dot, and no components that are dot-dot when the shell is initialized. If an application sets or unsets the value of PWD , the behaviors of the cd and pwd utilities are unspecified.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_05_03 oui, mais la page suivante ne fait pas référence aux liens symboliques :
Je faisais reference au fait que ksh/bash heritent PWD de l'environnement allant a l'encontre de POSIX.
je ne vois rien dans la norme qui interdise cela.
pour aller plus loin, la variable $PWD est supposée symboliser le répertoire courant lorsqu'elle existe, à cet effet, en hériter ne me semble pas incohérent.
pour autant, cela peut effectivement poser un pb si un prog fork un shell alors qu'il a fait un chdir() sans avoir mis a jour $PWD.
toutefois, je viens de faire un test sous cygwin sans rencontrer le pb que met en avant ! à tester sous de vrais unix... la réponse demain :)
idem avec cc.c : int main() { putenv("PWD=/");printf("%sn",getenv("PWD"));return(execlp(getenv("SHELL"),0)); }
comme ça, on ne peut pas accuser system() de faire quoique ce soit.
Regards, Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre. remove "%nospam" and ".invalid" to answer me.
Stephane Chazelas
On Thu, 06 Dec 2007 03:13:52 +0100, Cyrille Lefevre wrote:
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote: [...]
PWD Set by the shell to be an absolute pathname of the current working directory, containing no components of type symbolic link, no components that are dot, and no components that are dot-dot when the shell is initialized. If an application sets or unsets the value of PWD , the behaviors of the cd and pwd utilities are unspecified.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_05_03 oui, mais la page suivante ne fait pas référence aux liens symboliques :
Je faisais reference au fait que ksh/bash heritent PWD de l'environnement allant a l'encontre de POSIX.
je ne vois rien dans la norme qui interdise cela.
Ben si puisque le shell est censé initialiser $PWD avec un chemin qui ne contient ni ".." ni symlink.
$ cd /tmp $ ln -s . here $ env PWD=/tmp/here/here/here bash -c 'echo $PWD' /tmp/here/here/here
(plein de symlinks).
pour aller plus loin, la variable $PWD est supposée symboliser le répertoire courant lorsqu'elle existe, à cet effet, en hériter ne me semble pas incohérent.
A ceci pres que ca a des repercusions genantes comme dans
env PWD=/tmp/here/here bash -c 'cd .. && pwd'
Cela dit, meme avec cette non-conformance fixee, il faut quand-meme utiliser cd -P
comme dans
bash -c 'cd "$1"' - /tmp/here/../etc
pour autant, cela peut effectivement poser un pb si un prog fork un shell alors qu'il a fait un chdir() sans avoir mis a jour $PWD.
toutefois, je viens de faire un test sous cygwin sans rencontrer le pb que met en avant ! à tester sous de vrais unix... la réponse demain :)
Ben, ya pas de symlink la-dedans, d'ailleurs, y-a-t'il des symlinks sous cygwin?
-- Stephane
On Thu, 06 Dec 2007 03:13:52 +0100, Cyrille Lefevre wrote:
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote:
[...]
PWD
Set by the shell to be an absolute pathname of the
current working directory, containing no components
of type symbolic link, no components that are dot,
and no components that are dot-dot when the shell is
initialized. If an application sets or unsets the
value of PWD , the behaviors of the cd and pwd
utilities are unspecified.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_05_03
oui, mais la page suivante ne fait pas référence aux liens symboliques :
Je faisais reference au fait que ksh/bash heritent PWD de
l'environnement allant a l'encontre de POSIX.
je ne vois rien dans la norme qui interdise cela.
Ben si puisque le shell est censé initialiser $PWD avec un
chemin qui ne contient ni ".." ni symlink.
$ cd /tmp
$ ln -s . here
$ env PWD=/tmp/here/here/here bash -c 'echo $PWD'
/tmp/here/here/here
(plein de symlinks).
pour aller plus loin, la variable $PWD est supposée symboliser le
répertoire courant lorsqu'elle existe, à cet effet, en hériter ne
me semble pas incohérent.
A ceci pres que ca a des repercusions genantes comme dans
env PWD=/tmp/here/here bash -c 'cd .. && pwd'
Cela dit, meme avec cette non-conformance fixee, il faut
quand-meme utiliser cd -P
comme dans
bash -c 'cd "$1"' - /tmp/here/../etc
pour autant, cela peut effectivement poser un pb si un prog fork un
shell alors qu'il a fait un chdir() sans avoir mis a jour $PWD.
toutefois, je viens de faire un test sous cygwin sans rencontrer le pb
que met en avant ! à tester sous de vrais unix... la réponse demain :)
On Thu, 06 Dec 2007 03:13:52 +0100, Cyrille Lefevre wrote:
On Wed, 05 Dec 2007 00:55:26 +0100, Cyrille Lefevre wrote: [...]
PWD Set by the shell to be an absolute pathname of the current working directory, containing no components of type symbolic link, no components that are dot, and no components that are dot-dot when the shell is initialized. If an application sets or unsets the value of PWD , the behaviors of the cd and pwd utilities are unspecified.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_05_03 oui, mais la page suivante ne fait pas référence aux liens symboliques :
Je faisais reference au fait que ksh/bash heritent PWD de l'environnement allant a l'encontre de POSIX.
je ne vois rien dans la norme qui interdise cela.
Ben si puisque le shell est censé initialiser $PWD avec un chemin qui ne contient ni ".." ni symlink.
$ cd /tmp $ ln -s . here $ env PWD=/tmp/here/here/here bash -c 'echo $PWD' /tmp/here/here/here
(plein de symlinks).
pour aller plus loin, la variable $PWD est supposée symboliser le répertoire courant lorsqu'elle existe, à cet effet, en hériter ne me semble pas incohérent.
A ceci pres que ca a des repercusions genantes comme dans
env PWD=/tmp/here/here bash -c 'cd .. && pwd'
Cela dit, meme avec cette non-conformance fixee, il faut quand-meme utiliser cd -P
comme dans
bash -c 'cd "$1"' - /tmp/here/../etc
pour autant, cela peut effectivement poser un pb si un prog fork un shell alors qu'il a fait un chdir() sans avoir mis a jour $PWD.
toutefois, je viens de faire un test sous cygwin sans rencontrer le pb que met en avant ! à tester sous de vrais unix... la réponse demain :)
Ben, ya pas de symlink la-dedans, d'ailleurs, y-a-t'il des symlinks sous cygwin?
-- Stephane
Jean-Louis Hamel
Ben, ya pas de symlink la-dedans, d'ailleurs, y-a-t'il des symlinks sous cygwin?
Sous cygwin on peut créer des symlinks (avec "ln -s ...") et, ce qui est intéressant, ces symlinks sont aussi des raccourcis Windows (alors que les raccourcis Windows créés avec Windows ne sont pas des symlinks pour cygwin). "cd -P" fonctionne correctement sous cygwin avec ces symlinks.
-- JLH
Ben, ya pas de symlink la-dedans, d'ailleurs, y-a-t'il des
symlinks sous cygwin?
Sous cygwin on peut créer des symlinks (avec "ln -s ...") et, ce qui est
intéressant, ces symlinks sont aussi des raccourcis Windows (alors que
les raccourcis Windows créés avec Windows ne sont pas des symlinks pour
cygwin).
"cd -P" fonctionne correctement sous cygwin avec ces symlinks.
Ben, ya pas de symlink la-dedans, d'ailleurs, y-a-t'il des symlinks sous cygwin?
Sous cygwin on peut créer des symlinks (avec "ln -s ...") et, ce qui est intéressant, ces symlinks sont aussi des raccourcis Windows (alors que les raccourcis Windows créés avec Windows ne sont pas des symlinks pour cygwin). "cd -P" fonctionne correctement sous cygwin avec ces symlinks.
