J'ai beau chercher sur le forum , g pas trouvé de réponse en C .
Pour info , le délire ce passe sous linux et ce que je veux faire c'est couper la chaine suivante par exemple : /home/seb/media/monfilm.avi en /home/seb/media et monfilm.avi
sachant que ces chaines ne sont jamais constantes , cela peut etre :
/mnt/cdrom/dir2/rep2/monfilm.avi et je vousdrais /mnt/cdrom/dir2/rep2 et monfilm.avi .
 
g essayé de voir avec la fonction strstr mais j'y arrive pas a trouver comment dire on separe la chaine de caractere qui suit le dernier "/"
merci de votre aide.

fais une recherche sur strtok dans ce forum  
voila c'est la:
http://forum.hardware.fr/forum2.ph [...] h=&subcat=

Ben, tu peux bien faire la recherche toi même, style :

 
En principe, ça devrait ê qqch comme ça...

man 3 basename au lieu de réinventer la roue (et d'ailleurs avec un superbe exemple de code ultra-buggé et dangereux)
 
man 3 basename donc
 
(si vous voulez les critiques, sur le code: overflow à gogo, memset inutiles, strchr personne connait. etc, pas une ligne sans problème. désolé Elg   )

 
strchr trouve la 1ère occurence, on veut la dernière. Alors à moins d'inverser la chaine avant, je n'vois pas bien à quoi il pourrait nous servir.
les memset, il vaut mieux en faire trop que pas assez, ça n'coute rien (ou si peu).
et overflow, où ça ? (là, rien ne m'empêche d'utiliser strcpy et strlen sans risque d'overflow : je contrôle ma chaine de char, je sais qu'elle ne dépasse pas)

 
ca mériterait presque une fortune

strrchr désolé...allez laisse tomber ton code est mauvais...

 
à, ça j'connaissais pas.
En général de toute façon, sans compilo, j'fais toujours des fautes toutes nulles. Mais sinon, en quoi il est si mauvais ce code ?

ben je te trouve tres presomptueux avec tableaux et tes nombres magiques. les memset sont completement inutiles. enfin, c'est de toutes façons quelque chose du ressort du système. basename fait d'ailleurs bien mieux le boulot
 
chemin         dirname        basename
       "/usr/lib"     "/usr"         "lib"
       "/usr/"        "/"            "usr"
       "usr"          "."            "usr"
       "/"            "/"            "/"
       "."            "."            "."
       ".."           "."            ".."
 
gaffe, c'est pas réentrant

Préfère déjà strncpy à strcpy.
Ensuite, avec ton code, que se passe-t-il si on copie un chemin de 600 caractères, avec comme nom de fichier final .../toto.fic ?
 

je serais d'avis pour marquer ce topic résolu

surtout aue j'ai propose strtok des le depart, ce qui est la meilleure solution vue jusqu'ici  

n'importe quoi. la solution de elg est mal implémentée, mais c'est la solution si on ne veut pas utiliser basename (pourquoi s'en priver d'ailleurs, bordel, ce topic est un topic unix et rien d'autre!!!)

et strtok va pas sous unix  

si, mais pourquoi se faire chier a réimplémenter la roue bordaille

Ben, en fait au départ, j'allais répondre pour Windows (jusqu'a aujourd'hui, j'ai fais que de la prog ss Windows).  
Pour les tailles de mes chaines, j'aurais donc fait :

Là, à priori, on est sur que la chaine est terminée par un caractère null (et pas d'overflow, et strcpy est ok, et strlen aussi). Du coup j'me suis un peu merdé. Et du coup, en C ss unix, on fait quoi pour être sur de ne jamais avoir une chaine trop grande ? Gestion dynamique de la mémoire ? Enfin, c'est vrai que j'me suis un peu merdé là...  
Pour les memset, jusqu'a maintenant, dans le doute, j'initialisais toujours mes chaines avant de les utiliser. C pas la peine, les standard du C disent que l'espace mémoire réservé est forcément mis à 0 ?
Et la solution de basename, c'est pasz ANSI ça. 'vaut mieux écrire du standard autant que possible, surtout quand la solution ANSI est simple, vs croyez pas ?

strtok, c'est la roue  

 
Ben, c'est pas ça, mais strtok, ça fait faire la recherche dans la mauvais sens. Vu ce qu'il veut faire, ça parait plus logique de partir de la fin de la chaine. Donc strrchr (que j'avais raté) parait + approprié...

et basename PUTAIN          

non parce qu'ici on fait de la programmation système.
 
edit: avec ton raisonnement, on peut allez tres tres loin...
edit2: on a pas la meme definition de la simplicité
edit3: la C ANSI ne connait pas la notion de répertoire...

Il n'a qu'a faire une boucle et ne prendre que la derniere valeur retournee, c'est pas bien complique.
 
Enfin maintenant il a l'embarras du choix

tout ça parce que psebcopathe alambiqué son 'je suis sous linux, je voudrais à partir d'un chemain d'acces obtenir le répertoire d'une part et d'autre part le nom du fichier'

 
21 posts pour ça, ça fait un peu beaucoup, certes...
Mais tu m'as pas répondu :  
du moment qu'on réserve un espace mémoire, on peut être sur qu'il est initialisé à 0 ?

non. dans notre cas, on s'en fiche. et pour traiter des chaines de caracteres en C, un simple *tab=0 suffit si tu flippes. sinon fait marcher calloc

sous windows c'est :
PathRemoveFileSpec() et PathFindFileName()

 
Ben, *tab = 0, ça n'sert pas à grand chose dans le cas dont j'ai parlé (ou je peux me permettre d'utiliser strlen et compagnie grace aux _MAX_PATH et autre _MAX_ de Windows).
Et puis, calloc et malloc, franchement, c du pareil au même. Simple question de gouts...

c'est toi qui flippe au point de faire du memset plus que raison et t'aimes pas calloc?

 
Ouais. Enfin, j'essayais de m'adapater autant que j'le pouvais a son cas Unix.
Bref, je m'incline...

calloc initialise l'espace alloue a 0 d'apres le type de ta variable  
malloc ne fait rien lui

bon, qui calcule le rapport signal/bruit de ce topic

kwotaid
 
edit: elg, reviens ici  

 
à, ça j'savais pas !

 
Pourquoi, Qué passa ?

 
donc sous linux/unix, la solution est strtok ? (surtout pas basename, ca doit pas marcher)
 
hihihi je kiffes.

 
...Beaucoup de bruit pour pas grand chose !? c ça que tu veux dire ?
Humm, t'as pas franchement tord !

gné?

c'est sur que t'a appris beaucoup aujourd'hui  

 
Sans "s" le kiffe...
Hé, le strtok, c'est pas de moi !
Et basename, je me tue à dire que j'connaissais pas (sans faire de prog Unix, ça parait plutôt logique, non !?)

tu pouvais pas deviner que c'etait pour système Unix