Dans un programme (en C) j'aimerai pouvoir reconnaître si deux noms
de répertoires sont en fait les mêmes répertoires.
Par exemple, reconnaitre que "/usr/bin" et "/usr/../usr/bin" sont le
même répertoire.
Je pourrais regarder l'inode, mais il me semble que les inodes sont
uniques par systèmes de fichier uniquement, donc ce n'est surement pas
la solution ultime. Je pourrais aussi remplacer les "/../" par des "/"
mais ça ne règle pas la question des liens symbolique (et c'est laid).
Je me demandais s'il n'y avait pas un truc bien connu, genre un appel
système, pour résoudre ce problème. Qu'en dites vous ?
J'ai posté avant de réfléchir, désolé pour le bruit. Il faut évidement utiliser comme clef l'inode et l'identifiant du device.
[...]
Sinon, pour repondre a la question dans l'objet de l'enfilade (le subject du thread): realpath(3)
-- Stéphane
Paul Gaborit
À (at) Wed, 25 Jun 2008 07:53:04 +0000 (UTC), Stephane CHAZELAS écrivait (wrote):
Sinon, pour repondre a la question dans l'objet de l'enfilade (le subject du thread): realpath(3)
Je ne connaissais pas cette fonction... mais après avoir vu la doc et surtout la section "BUGS", je n'en conseillerais pas l'utilisation !
Petit extrait (en français en plus) :
N'utilisez jamais cette fonction. Sa conception est erronée (à moins d'utiliser la caractéristique non standard resolved_path == NULL) car elle ne permet pas de connaître la taille nécessaire pour le tampon de sortie resolved_path. D'après POSIX, un tampon de taille PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une constante définie et peut être obtenue avec pathconf(3). En outre, interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX prévient que les résultats de pathconf(3) peuvent être immenses et inappropriés pour allouer de la mémoire et d'autre part pathconf(3) peut renvoyer -1 indiquant que PATH_MAX est illimité.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 25 Jun 2008 07:53:04 +0000 (UTC),
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> écrivait (wrote):
Sinon, pour repondre a la question dans l'objet de l'enfilade
(le subject du thread): realpath(3)
Je ne connaissais pas cette fonction... mais après avoir vu la doc et
surtout la section "BUGS", je n'en conseillerais pas l'utilisation !
Petit extrait (en français en plus) :
N'utilisez jamais cette fonction. Sa conception est erronée (à moins
d'utiliser la caractéristique non standard resolved_path == NULL)
car elle ne permet pas de connaître la taille nécessaire pour le
tampon de sortie resolved_path. D'après POSIX, un tampon de taille
PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une
constante définie et peut être obtenue avec pathconf(3). En outre,
interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX
prévient que les résultats de pathconf(3) peuvent être immenses et
inappropriés pour allouer de la mémoire et d'autre part pathconf(3)
peut renvoyer -1 indiquant que PATH_MAX est illimité.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 25 Jun 2008 07:53:04 +0000 (UTC), Stephane CHAZELAS écrivait (wrote):
Sinon, pour repondre a la question dans l'objet de l'enfilade (le subject du thread): realpath(3)
Je ne connaissais pas cette fonction... mais après avoir vu la doc et surtout la section "BUGS", je n'en conseillerais pas l'utilisation !
Petit extrait (en français en plus) :
N'utilisez jamais cette fonction. Sa conception est erronée (à moins d'utiliser la caractéristique non standard resolved_path == NULL) car elle ne permet pas de connaître la taille nécessaire pour le tampon de sortie resolved_path. D'après POSIX, un tampon de taille PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une constante définie et peut être obtenue avec pathconf(3). En outre, interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX prévient que les résultats de pathconf(3) peuvent être immenses et inappropriés pour allouer de la mémoire et d'autre part pathconf(3) peut renvoyer -1 indiquant que PATH_MAX est illimité.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Stephane CHAZELAS
2008-06-25, 13:46(+02), Paul Gaborit:
À (at) Wed, 25 Jun 2008 07:53:04 +0000 (UTC), Stephane CHAZELAS écrivait (wrote):
Sinon, pour repondre a la question dans l'objet de l'enfilade (le subject du thread): realpath(3)
Je ne connaissais pas cette fonction... mais après avoir vu la doc et surtout la section "BUGS", je n'en conseillerais pas l'utilisation !
Petit extrait (en français en plus) :
N'utilisez jamais cette fonction. Sa conception est erronée (à moins d'utiliser la caractéristique non standard resolved_path == NULL)
Cette /caractéristique/ ne sera apparemment plus non-standard quand la prochaine de version de SUS sortira car elle est dans le draft courant.
car elle ne permet pas de connaître la taille nécessaire pour le tampon de sortie resolved_path. D'après POSIX, un tampon de taille PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une constante définie et peut être obtenue avec pathconf(3). En outre, interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX prévient que les résultats de pathconf(3) peuvent être immenses et inappropriés pour allouer de la mémoire et d'autre part pathconf(3) peut renvoyer -1 indiquant que PATH_MAX est illimité.
-- Stéphane
2008-06-25, 13:46(+02), Paul Gaborit:
À (at) Wed, 25 Jun 2008 07:53:04 +0000 (UTC),
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> écrivait (wrote):
Sinon, pour repondre a la question dans l'objet de l'enfilade
(le subject du thread): realpath(3)
Je ne connaissais pas cette fonction... mais après avoir vu la doc et
surtout la section "BUGS", je n'en conseillerais pas l'utilisation !
Petit extrait (en français en plus) :
N'utilisez jamais cette fonction. Sa conception est erronée (à moins
d'utiliser la caractéristique non standard resolved_path == NULL)
Cette /caractéristique/ ne sera apparemment plus non-standard
quand la prochaine de version de SUS sortira car elle est dans
le draft courant.
car elle ne permet pas de connaître la taille nécessaire pour le
tampon de sortie resolved_path. D'après POSIX, un tampon de taille
PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une
constante définie et peut être obtenue avec pathconf(3). En outre,
interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX
prévient que les résultats de pathconf(3) peuvent être immenses et
inappropriés pour allouer de la mémoire et d'autre part pathconf(3)
peut renvoyer -1 indiquant que PATH_MAX est illimité.
À (at) Wed, 25 Jun 2008 07:53:04 +0000 (UTC), Stephane CHAZELAS écrivait (wrote):
Sinon, pour repondre a la question dans l'objet de l'enfilade (le subject du thread): realpath(3)
Je ne connaissais pas cette fonction... mais après avoir vu la doc et surtout la section "BUGS", je n'en conseillerais pas l'utilisation !
Petit extrait (en français en plus) :
N'utilisez jamais cette fonction. Sa conception est erronée (à moins d'utiliser la caractéristique non standard resolved_path == NULL)
Cette /caractéristique/ ne sera apparemment plus non-standard quand la prochaine de version de SUS sortira car elle est dans le draft courant.
car elle ne permet pas de connaître la taille nécessaire pour le tampon de sortie resolved_path. D'après POSIX, un tampon de taille PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une constante définie et peut être obtenue avec pathconf(3). En outre, interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX prévient que les résultats de pathconf(3) peuvent être immenses et inappropriés pour allouer de la mémoire et d'autre part pathconf(3) peut renvoyer -1 indiquant que PATH_MAX est illimité.
-- Stéphane
rixed
On 2008-06-25, Paul Gaborit wrote:
D'après POSIX, un tampon de taille PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une constante définie et peut être obtenue avec pathconf(3). En outre, interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX prévient que les résultats de pathconf(3) peuvent être immenses et inappropriés pour allouer de la mémoire et d'autre part pathconf(3) peut renvoyer -1 indiquant que PATH_MAX est illimité.
On en apprend des choses ! Je me sert tous les jours de PATH_MAX.
J'espère que je ne coderais plus qu'en lisp le jour où PATH_MAX vaudra quelquechose qui ne tient pas sur la pile :-)
Bon, je ne regrette pas d'avoir posé ma question finalement.
On 2008-06-25, Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
D'après POSIX, un tampon de taille
PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une
constante définie et peut être obtenue avec pathconf(3). En outre,
interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX
prévient que les résultats de pathconf(3) peuvent être immenses et
inappropriés pour allouer de la mémoire et d'autre part pathconf(3)
peut renvoyer -1 indiquant que PATH_MAX est illimité.
On en apprend des choses ! Je me sert tous les jours de PATH_MAX.
J'espère que je ne coderais plus qu'en lisp le jour où PATH_MAX vaudra
quelquechose qui ne tient pas sur la pile :-)
Bon, je ne regrette pas d'avoir posé ma question finalement.
D'après POSIX, un tampon de taille PATH_MAX suffit, mais PATH_MAX n'est pas nécessairement une constante définie et peut être obtenue avec pathconf(3). En outre, interroger pathconf(3) n'aide pas vraiment, car d'une part POSIX prévient que les résultats de pathconf(3) peuvent être immenses et inappropriés pour allouer de la mémoire et d'autre part pathconf(3) peut renvoyer -1 indiquant que PATH_MAX est illimité.
On en apprend des choses ! Je me sert tous les jours de PATH_MAX.
J'espère que je ne coderais plus qu'en lisp le jour où PATH_MAX vaudra quelquechose qui ne tient pas sur la pile :-)
Bon, je ne regrette pas d'avoir posé ma question finalement.
Cyrille Lefevre
a écrit :
Bonjour !
Dans un programme (en C) j'aimerai pouvoir reconnaître si deux noms de répertoires sont en fait les mêmes répertoires.
Par exemple, reconnaitre que "/usr/bin" et "/usr/../usr/bin" sont le même répertoire.
Je pourrais regarder l'inode, mais il me semble que les inodes sont uniques par systèmes de fichier uniquement, donc ce n'est surement pa s la solution ultime. Je pourrais aussi remplacer les "/../" par des "/" mais ça ne règle pas la question des liens symbolique (et c'est lai d).
Je me demandais s'il n'y avait pas un truc bien connu, genre un appel système, pour résoudre ce problème. Qu'en dites vous ?
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
rixed@happyleptic.org a écrit :
Bonjour !
Dans un programme (en C) j'aimerai pouvoir reconnaître si deux noms
de répertoires sont en fait les mêmes répertoires.
Par exemple, reconnaitre que "/usr/bin" et "/usr/../usr/bin" sont le
même répertoire.
Je pourrais regarder l'inode, mais il me semble que les inodes sont
uniques par systèmes de fichier uniquement, donc ce n'est surement pa s
la solution ultime. Je pourrais aussi remplacer les "/../" par des "/"
mais ça ne règle pas la question des liens symbolique (et c'est lai d).
Je me demandais s'il n'y avait pas un truc bien connu, genre un appel
système, pour résoudre ce problème. Qu'en dites vous ?
Dans un programme (en C) j'aimerai pouvoir reconnaître si deux noms de répertoires sont en fait les mêmes répertoires.
Par exemple, reconnaitre que "/usr/bin" et "/usr/../usr/bin" sont le même répertoire.
Je pourrais regarder l'inode, mais il me semble que les inodes sont uniques par systèmes de fichier uniquement, donc ce n'est surement pa s la solution ultime. Je pourrais aussi remplacer les "/../" par des "/" mais ça ne règle pas la question des liens symbolique (et c'est lai d).
Je me demandais s'il n'y avait pas un truc bien connu, genre un appel système, pour résoudre ce problème. Qu'en dites vous ?
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Alain Montfranc
a écrit
Bonjour !
Dans un programme (en C) j'aimerai pouvoir reconnaître si deux noms de répertoires sont en fait les mêmes répertoires.
Par exemple, reconnaitre que "/usr/bin" et "/usr/../usr/bin" sont le même répertoire.
Je pourrais regarder l'inode, mais il me semble que les inodes sont uniques par systèmes de fichier uniquement, donc ce n'est surement pas la solution ultime. Je pourrais aussi remplacer les "/../" par des "/" mais ça ne règle pas la question des liens symbolique (et c'est laid).
Je me demandais s'il n'y avait pas un truc bien connu, genre un appel système, pour résoudre ce problème. Qu'en dites vous ?
Sinon en quick and dirty :
if [ -d $dir } then (cd $dir; pwd) else echo "No such directory..." >&2 exit 1 fi
rixed@happyleptic.org a écrit
Bonjour !
Dans un programme (en C) j'aimerai pouvoir reconnaître si deux noms
de répertoires sont en fait les mêmes répertoires.
Par exemple, reconnaitre que "/usr/bin" et "/usr/../usr/bin" sont le
même répertoire.
Je pourrais regarder l'inode, mais il me semble que les inodes sont
uniques par systèmes de fichier uniquement, donc ce n'est surement pas
la solution ultime. Je pourrais aussi remplacer les "/../" par des "/"
mais ça ne règle pas la question des liens symbolique (et c'est laid).
Je me demandais s'il n'y avait pas un truc bien connu, genre un appel
système, pour résoudre ce problème. Qu'en dites vous ?
Sinon en quick and dirty :
if [ -d $dir }
then
(cd $dir; pwd)
else
echo "No such directory..." >&2
exit 1
fi
Dans un programme (en C) j'aimerai pouvoir reconnaître si deux noms de répertoires sont en fait les mêmes répertoires.
Par exemple, reconnaitre que "/usr/bin" et "/usr/../usr/bin" sont le même répertoire.
Je pourrais regarder l'inode, mais il me semble que les inodes sont uniques par systèmes de fichier uniquement, donc ce n'est surement pas la solution ultime. Je pourrais aussi remplacer les "/../" par des "/" mais ça ne règle pas la question des liens symbolique (et c'est laid).
Je me demandais s'il n'y avait pas un truc bien connu, genre un appel système, pour résoudre ce problème. Qu'en dites vous ?
Sinon en quick and dirty :
if [ -d $dir } then (cd $dir; pwd) else echo "No such directory..." >&2 exit 1 fi
Matthieu Moy
Cyrille Lefevre <cyrille.lefevre-news% writes:
a écrit :
Bonjour !
Dans un programme (en C) j'aimerai pouvoir reconnaître si deux noms de répertoires sont en fait les mêmes répertoires.
Par exemple, reconnaitre que "/usr/bin" et "/usr/../usr/bin" sont le même répertoire. [...]
