utilisation et modification de nom de fichier

Marsh Posté le 10-05-2003 à 10:31:58

#include <stdio.h>

int main (char *argv[]) {
char nom_listing [100] ;

strcpy (nom_listing, argv[1]) ;
printf ("%s", nom_listing) ;
strcat (nom_listing, ".l" ) ;
printf ("%s", nom_listing) ;

// unlink (listing);
}

en fait je voudrais utiliser le nom_de_fichier pointe par argv[1]
afin de creer un nouveau fichier s appelant nom_de_fichier.l

le probleme doit etre dans mon utilisation de argv[1]
j obtiens Bus Error (core dumped)

---------------
Les accents sont en option... j'ai un clavier qwertz.

Reply

Marsh Posté le 10-05-2003 à 10:31:58

Reply

Marsh Posté le 10-05-2003 à 10:37:51

Code :

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
char *nom=NULL;
int i;
for(i=1; i<argc; ++i)
{
/* sizeof ".l" == sizeof '.' + sizeof 'l' + sizeof '\0' */
nom=realloc(nom, strlen(argv[i])+sizeof ".l" );
strcpy(nom, argv[i]);
strcat(nom, ".l" );
puts(nom);
}
free(nom);
return 0;
}

Message édité par Taz le 10-05-2003 à 10:46:02

Reply

Marsh Posté le 10-05-2003 à 11:04:15

est ce qu il est possible d obtenir le meme resultat avec srpintf en gardant non comme tableau de caracteres et en faisant un unlink apres?

---------------
Les accents sont en option... j'ai un clavier qwertz.

Reply

Marsh Posté le 10-05-2003 à 11:17:19

oui

remplace

strcpy(nom, argv[i]);
strcat(nom, ".l" );

par

sprintf(nom, "%s.l", argv[i]);

Reply

Marsh Posté le 10-05-2003 à 11:42:41

merci

---------------
Les accents sont en option... j'ai un clavier qwertz.

Reply

Marsh Posté le 10-05-2003 à 11:52:13

Si effectivement tu veux créer le fichier .l a partir du nom original, tu devrais faire qque chose dans le genre suivant:

Code :

#include <string.h>
#include <stdio.h>
#include <sys/stat.h>
#include <unistd.h>
int main (int argc, char **argv)
{
if (argc > 1)
{
char *path = getcwd(NULL, 0);
if (path)
{
char *nom_listing = (char *) malloc(strlen(path)+strlen(argv[1])+ 4);
stat statbuffer;
if (nom_listing)
{
strcpy(nom_listing, path);
strcat(nom_listing, "/" );
strcpy(nom_listing, argv[1]);
strcat(nom_listing, ".l" );
if (stat(nom_listing, &statbuffer))
{
FILE *fichier = fopen(nom_listing, "a+" );
if (fichier)
fclose(fichier);
}
free(nom_listing);
}
free(path);
}
}
exit(0);
}

Tu verifies que tu as un nom en parametre, tu recuperes le repertoire courant, tu crees un nom absolu de fichier listing a partir du repertoire courant et de ton nom de fichier, tu verifies que le fichier correspondant n'existe pas, et s'il n'existe pas, tu le crée.
A+,

Message édité par gilou le 10-05-2003 à 11:55:34

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Reply

Marsh Posté le 10-05-2003 à 11:53:26

on paralias de C ANSI jusqu'à présent

Reply

Marsh Posté le 10-05-2003 à 11:59:25

++Taz a écrit :

on paralias de C ANSI jusqu'à présent

Vu l'utilisation en commentaire de unlink dans le post initial, je subodore que c'est pour Unix/Linux qu'elle écrit son code.
A+,

Message édité par gilou le 10-05-2003 à 11:59:56

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Reply

Marsh Posté le 10-05-2003 à 12:01:22

ben y a remove en ANSI [:spamafote]

Reply

Marsh Posté le 10-05-2003 à 12:07:23

++Taz a écrit :

ben y a remove en ANSI [:spamafote]

remove et unlink ne sont pas pareil: remove encapsule a la fois unlink pour les nom de fichiers et rmdir pour les noms de repertoires).
A priori, s'il y a un remove, il y a aussi un unlink, non?
A+,
PS: Lirai la suite ce soir, la je vas baffrer, puis je vas sur Paris.

Message édité par gilou le 10-05-2003 à 12:08:21

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Reply

Marsh Posté le 10-05-2003 à 12:07:23

Reply

Marsh Posté le 10-05-2003 à 12:13:49

non, c'est l'inverse. remove ne vire que les fichiers puisque la notion de répertoire n'existe pas en C.

par contre unlink fait plus
voir le man 2 unlink

Reply

Marsh Posté le 10-05-2003 à 13:28:59

je dois programmer en C un assembleur qui tourne sous Linux

---------------
Les accents sont en option... j'ai un clavier qwertz.

Reply

Marsh Posté le 10-05-2003 à 13:31:41

ben si les fonctions ANSI te satisfont, utilise les. sinon prends celles de l'API

Reply

Marsh Posté le 10-05-2003 à 14:12:11

++Taz a écrit :

non, c'est l'inverse. remove ne vire que les fichiers puisque la notion de répertoire n'existe pas en C.

par contre unlink fait plus
voir le man 2 unlink

Ce n'est pas ce que dit la man page unix:

Citation :

REMOVE (3)
delete a name and possibly the file it refers to

SYNOPSIS
#include <stdio.h> int remove(const char * pathname );

DESCRIPTION
remove deletes a name from the filesystem. It calls unlink for files, and rmdir for directories.
If the removed name was the last link to a file and no processes have the file open the file is deleted and the space it was using is made available for reuse.

If the name was the last link to a file but any processes still have the file open the file will remain in existence until the last file descriptor referring to it is closed.

If the name referred to a symbolic link the link is removed.

If the name referred to a socket, fifo or device the name for it is removed but processes which have the object open may continue to use it.

RETURN VALUE
On success, zero is returned. On error, -1 is returned, and errno is set appropriately.

ERRORS
EFAULT

pathname points outside your accessible address space.

EACCES

Write access to the directory containing pathname is not allowed for the process's effective uid, or one of the directories in pathname did not allow search (execute) permission.

EPERM

The directory containing pathname has the sticky-bit ( S_ISVTX ) set and the process's effective uid is neither the uid of the file to be deleted nor that of the directory containing it.

ENAMETOOLONG

pathname was too long.

ENOENT

A directory component in pathname does not exist or is a dangling symbolic link.

ENOTDIR

A component used as a directory in pathname is not, in fact, a directory.

ENOMEM

Insufficient kernel memory was available.

EROFS

pathname refers to a file on a read-only filesystem.

CONFORMING TO
ANSI C, SVID, AT&T, POSIX, X/OPEN, BSD 4.3

BUGS
In-felicities in the protocol underlying NFS can cause the unexpected disappearance of files which are still being used.

NOTE
Under libc4 and libc5, remove was an alias for unlink (and hence would not remove directories).

SEE ALSO
- unlink (2) - - rename (2) - - open (2) - - rmdir (2) - - mknod (2) - - mkfifo (3) - - link (2) - - rm (1) - unlink(8) man3/insque 3 man3/resolver 3 man3/resolver 3 man3/resolver 3 man3/resolver 3 man3/resolver 3 man3/resolver 3

Citation :

UNLINK (2)
delete a name and possibly the file it refers to

SYNOPSIS
#include <unistd.h> int unlink(const char * pathname );

DESCRIPTION
unlink deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open the file is deleted and the space it was using is made available for reuse.
If the name was the last link to a file but any processes still have the file open the file will remain in existence until the last file descriptor referring to it is closed.

If the name referred to a symbolic link the link is removed.

If the name referred to a socket, fifo or device the name for it is removed but processes which have the object open may continue to use it.

RETURN VALUE
On success, zero is returned. On error, -1 is returned, and errno is set appropriately.

ERRORS
EFAULT

pathname points outside your accessible address space.

EACCES

Write access to the directory containing pathname is not allowed for the process's effective uid, or one of the directories in pathname did not allow search (execute) permission.

EPERM

The directory containing pathname has the sticky-bit ( S_ISVTX ) set and the process's effective uid is neither the uid of the file to be deleted nor that of the directory containing it, or pathname is a directory.

ENAMETOOLONG

pathname was too long.

ENOENT

A directory component in pathname does not exist or is a dangling symbolic link.

ENOTDIR

A component used as a directory in pathname is not, in fact, a directory.

EISDIR

pathname refers to a directory.

ENOMEM

Insufficient kernel memory was available.

EROFS

pathname refers to a file on a read-only filesystem.

ELOOP

Too many symbolic links were encountered in translating pathname .

EIO

An I/O error occurred.

CONFORMING TO
SVr4, SVID, POSIX, X/OPEN, 4.3BSD. SVr4 documents additional error conditions EBUSY, EINTR, EMULTIHOP, ETXTBUSY, ENOLINK.

BUGS
Infelicities in the protocol underlying NFS can cause the unexpected disappearance of files which are still being used.

SEE ALSO
- link (2) - - rename (2) - - open (2) - - rmdir (2) - - mknod (2) - - mkfifo (3) - - remove (3) - - rm (1) -

:whistle:
A+,

Message édité par gilou le 10-05-2003 à 14:23:12

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Reply

Marsh Posté le 10-05-2003 à 14:51:14

oui mais c'est là une extension. fo faire gaffe aux man. y a ecrit ansi quand la focnton existe en ANSI, mais le comportement est souvent étendu. donc prudence

Reply

Marsh Posté le 11-05-2003 à 09:39:15

Sauf que dans ce cas precis, remove a ete inventée bien apres unlink et rmdir. Alors parler d'extension...

En fait, au départ, remove devait juste remplacer unlink; c'est suite a des questions posées au comité de standardisation qu'elle a aussi remplacé rmdir. Voir par exemple ce document: http://www.pasc.org/interps/unoffi [...] .1-59.html
Personellement, quite a se conformer a un standard, je preferre POSIX.
A+,

Message édité par gilou le 11-05-2003 à 09:39:38

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Reply

Marsh Posté le 11-05-2003 à 09:41:00

mai fait ce qui te plait

Reply

Marsh Posté le 11-05-2003 à 09:46:59

Et pis de toute facon, Microsoft (le standard de facto, non? )préconise l'emploi de System.IO.File.Delete

Code :

[Visual Basic]
Public Shared Sub Delete( _
ByVal path As String _
)
[C#]
public static void Delete(
string path
);
[C++]
public: static void Delete(
String* path
);
[JScript]
public static function Delete(
path : String
);

[:pioupiou]
A+,

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Reply

utilisation et modification de nom de fichier

Sujets relatifs:

Leave a Replay