Remplacement de chaines de caractères dans un (ou des) fichier(s).
24 réponses
Séverin TERRIER
Bonjour à tou(te)s,
J'aurais besoin d'effectuer des remplacements de chaines de caractères dans
un (ou des) fichier(s).
Le remplacement devra se faire pour remplacer des pseudo-balises par des
balises HTML, ou l'inverse.
On utilisera donc une liste de paire <element> <element_remplacant>, pour
définir les différentes chaines à remplacer, dans le(s) fichier(s). Enfin,
c'est comme ça que je vois les choses...
Précision d'échelle :
- le nombre de paires sera assez limité (<10)
- la taille des fichiers est faible (<10 Ko)
- le nombre de fichiers est faible (<100).
Les fichiers dans lesquels le remplacement devra avoir lieu seront répartis
dans plusieurs répertoires, a raison d'un seul fichier .ext a remplacer
dans chaque répertoire (le répertoire contenant d'autres fichiers à
ignorer).
Le passage de commande précisera l'opération (codage/décodage), ainsi que
le ou les fichiers à traiter.
Je ne sais pas si je peux faire ça le plus simplement/efficacement
directement en shell unix (+ awk, sed...), ou en utilisant perl (par
exemple)...
Donc si vous avez des idées, exemples, script déjà établis, je suis
preneur, sachant que je suis débutant en script et perl...
Merci d'avance pour votre aide.
--
http://severinterrier.free.fr/Boot/ Tout est gratuit et en français.
CD de dépannage basé sur XP (ou 2003) avec interface graphique,
multitâche, support NTFS (lecture/écriture), réseau, gravure...
CD ou DVD Ultime, permettant d'installer plusieurs versions de
Windows, d'avoir des outils de dépannage, et beaucoup plus...
Disquettes de boot modulaires (support CD-Rom, réseau, NTFS, noms longs)
Il manque MacOSX et Linux 2.4 et 2.6 qui sépare aussi.
Euh, non :
Linux 2.2.9-2.6.7(x86)| 127 | c | | |
Et je confirme :
ssecem /tmp $ cat t #!/tmp/printargs un deux trois j'irai dans les bois ssecem /tmp $ ./t argv[0] = "/tmp/printargs" argv[1] = "un deux trois j'irai dans les bois" argv[2] = "./t" ssecem /tmp $ uname -a Linux ssecem 2.6.5 #2 Wed Apr 14 23:36:02 CEST 2004 i686 GNU/Linux
Linux 2.6 ne sépare pas les arguments, et si je me souviens bien, 2.4 non plus.
Il me semble que ça n'a absolument aucune importance, car tout les shells dignes de ce nom semble en tenir compte!
En tout cas, clisp interprete parfaitement bien la chaine "-q -ansi" puisqu'il n'affiche pas sa banière et passe en mode ANSI.
Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
Nicolas George <nicolas$george@salle-s.org> writes:
Pascal Bourguignon wrote in message
<87k6uuvvt7.fsf@thalassa.informatimago.com>:
Il manque MacOSX et Linux 2.4 et 2.6 qui sépare aussi.
Euh, non :
Linux 2.2.9-2.6.7(x86)| 127 | c | | |
Et je confirme :
ssecem /tmp $ cat t
#!/tmp/printargs un deux trois j'irai dans les bois
ssecem /tmp $ ./t
argv[0] = "/tmp/printargs"
argv[1] = "un deux trois j'irai dans les bois"
argv[2] = "./t"
ssecem /tmp $ uname -a
Linux ssecem 2.6.5 #2 Wed Apr 14 23:36:02 CEST 2004 i686 GNU/Linux
Linux 2.6 ne sépare pas les arguments, et si je me souviens bien, 2.4 non
plus.
Il me semble que ça n'a absolument aucune importance, car tout les
shells dignes de ce nom semble en tenir compte!
En tout cas, clisp interprete parfaitement bien la chaine "-q -ansi"
puisqu'il n'affiche pas sa banière et passe en mode ANSI.
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Il manque MacOSX et Linux 2.4 et 2.6 qui sépare aussi.
Euh, non :
Linux 2.2.9-2.6.7(x86)| 127 | c | | |
Et je confirme :
ssecem /tmp $ cat t #!/tmp/printargs un deux trois j'irai dans les bois ssecem /tmp $ ./t argv[0] = "/tmp/printargs" argv[1] = "un deux trois j'irai dans les bois" argv[2] = "./t" ssecem /tmp $ uname -a Linux ssecem 2.6.5 #2 Wed Apr 14 23:36:02 CEST 2004 i686 GNU/Linux
Linux 2.6 ne sépare pas les arguments, et si je me souviens bien, 2.4 non plus.
Il me semble que ça n'a absolument aucune importance, car tout les shells dignes de ce nom semble en tenir compte!
En tout cas, clisp interprete parfaitement bien la chaine "-q -ansi" puisqu'il n'affiche pas sa banière et passe en mode ANSI.
Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
andrea ferraris
Stephane Chazelas wrote:
Je n'avais pas l'intention d'etre pedant
Je crois que personne ne l'a, aussi si l'est ;-) mais je trouve que vous étiez assez plus précis que pédant ;-)
merci.
Andrea
Stephane Chazelas wrote:
Je n'avais pas l'intention d'etre pedant
Je crois que personne ne l'a, aussi si l'est ;-)
mais je trouve que vous étiez assez plus précis
que pédant ;-)
Je crois que personne ne l'a, aussi si l'est ;-) mais je trouve que vous étiez assez plus précis que pédant ;-)
merci.
Andrea
Stephane Chazelas
2004-09-17, 23:03(+02), Pascal Bourguignon: [...]
Linux 2.6 ne sépare pas les arguments, et si je me souviens bien, 2.4 non plus.
Il me semble que ça n'a absolument aucune importance, car tout les shells dignes de ce nom semble en tenir compte!
Les shells (sauf zsh) ne parsent pas cette ligne. C'est une fonctionnalité du systeme d'exploitation. Si exec(2) renvoie un ENOEXEC, alors le shell peut decider de quoi faire de ce fichier (s'il a les permissions d'executions).
Par exemple, csh (au moins certaines versions) va regarder le premier caractere. Si c'est un "#", alors il va lancer /bin/csh sur le fichier. Sinon, il utilise /bin/sh. Les autres shells vont soit lancer /bin/sh (ou l'equivalent POSIX) soit lancer une instance d'eux-memes, soit vont utiliser un fils d'eux-memes (pas d'appel a exec). zsh est l'exception, il va faire le boulot du systeme a sa place (s'il ne supporte pas le #!): interpreter #! et passer un seul argument.
Donc, en gros, si le systeme supporte #!, le shell n'a aucune influence dans le processus, et - clisp est lance avec 1 argument: "-q -ansi" (la plupart du temps) - avec deux arguments sur FreeBSD ("-q" et "-ansi" - avec 1 arguments "-q" sur d'autres - ... voir tableau
Si le systeme ne supporte pas #! (je n'ai encore jamais croisé de tel systeme), alors - ce sera "csh" et pas "clisp" qui interpretera le script si le shell est "csh" - clisp est lancé avec 1 argument "-q -ansi" si le shell est zsh - ce sera /bin/sh ou bash ou ksh suivant quel autre shell a lance la commande. - Ca renverra un ENOEXEC si ce fichier n'est pas exectuté par un shell.
En tout cas, clisp interprete parfaitement bien la chaine "-q -ansi" puisqu'il n'affiche pas sa banière et passe en mode ANSI.
Si, clisp decoupe ses arguments pour en faire des arguments virtuels (empiete sur les prerogatives des shells), alors OK, on a affaire a un cas particulier.
Sinon, des lignes comme:
#! /usr/bin/awk -F/ -f
ne marcheront pas (sauf sous FreeBSD), il est bon de le savoir.
Dans le source code de GNU clisp:
/* * Script execution on Unix is implemented like this: * - The basename/fullname of the interpreter is put into argv[0]. * - (Optional - only if at least one interpreter-arg is present.) Next * comes the tail of the "#!..." line. On SunOS 4, Linux, IRIX, AIX, * OSF/1: with leading whitespace stripped, but whitespace inside it * untouched (!). On Solaris, HP-UX: with leading whitespace stripped, * and cut off at the next whitespace character (!!). * - Next comes the filename of the script. * - Then all the arguments of the script. * We therefore need to split argv[1] into pieces. We shouldn't split * "-x" arguments into pieces. However, fortunately, the "-x" argument * cannot appear as argv[1] (because "-x" must precede it), and it * cannot appear within the "#!..." line (because "#!" and "-x" are * mutually exclusive). * As a workaround against the Solaris/HP-UX problem, we split not * only at normal spaces, but also at hard spaces. * See <impnotes.html#quickstart>. */
-- Stephane
2004-09-17, 23:03(+02), Pascal Bourguignon:
[...]
Linux 2.6 ne sépare pas les arguments, et si je me souviens bien, 2.4 non
plus.
Il me semble que ça n'a absolument aucune importance, car tout les
shells dignes de ce nom semble en tenir compte!
Les shells (sauf zsh) ne parsent pas cette ligne. C'est une
fonctionnalité du systeme d'exploitation. Si exec(2) renvoie un
ENOEXEC, alors le shell peut decider de quoi faire de ce fichier
(s'il a les permissions d'executions).
Par exemple, csh (au moins certaines versions) va regarder le
premier caractere. Si c'est un "#", alors il va lancer /bin/csh
sur le fichier. Sinon, il utilise /bin/sh. Les autres shells
vont soit lancer /bin/sh (ou l'equivalent POSIX) soit lancer une
instance d'eux-memes, soit vont utiliser un fils d'eux-memes
(pas d'appel a exec). zsh est l'exception, il va faire le boulot
du systeme a sa place (s'il ne supporte pas le #!): interpreter
#! et passer un seul argument.
Donc, en gros, si le systeme supporte #!, le shell n'a aucune
influence dans le processus, et
- clisp est lance avec 1 argument: "-q -ansi" (la plupart du
temps)
- avec deux arguments sur FreeBSD ("-q" et "-ansi"
- avec 1 arguments "-q" sur d'autres
- ... voir tableau
Si le systeme ne supporte pas #! (je n'ai encore jamais croisé
de tel systeme), alors
- ce sera "csh" et pas "clisp" qui interpretera le script si le
shell est "csh"
- clisp est lancé avec 1 argument "-q -ansi" si le shell est zsh
- ce sera /bin/sh ou bash ou ksh suivant quel autre shell a
lance la commande.
- Ca renverra un ENOEXEC si ce fichier n'est pas exectuté par un
shell.
En tout cas, clisp interprete parfaitement bien la chaine "-q -ansi"
puisqu'il n'affiche pas sa banière et passe en mode ANSI.
Si, clisp decoupe ses arguments pour en faire des arguments
virtuels (empiete sur les prerogatives des shells), alors OK,
on a affaire a un cas particulier.
Sinon, des lignes comme:
#! /usr/bin/awk -F/ -f
ne marcheront pas (sauf sous FreeBSD), il est bon de le savoir.
Dans le source code de GNU clisp:
/*
* Script execution on Unix is implemented like this:
* - The basename/fullname of the interpreter is put into argv[0].
* - (Optional - only if at least one interpreter-arg is present.) Next
* comes the tail of the "#!..." line. On SunOS 4, Linux, IRIX, AIX,
* OSF/1: with leading whitespace stripped, but whitespace inside it
* untouched (!). On Solaris, HP-UX: with leading whitespace stripped,
* and cut off at the next whitespace character (!!).
* - Next comes the filename of the script.
* - Then all the arguments of the script.
* We therefore need to split argv[1] into pieces. We shouldn't split
* "-x" arguments into pieces. However, fortunately, the "-x" argument
* cannot appear as argv[1] (because "-x" must precede it), and it
* cannot appear within the "#!..." line (because "#!" and "-x" are
* mutually exclusive).
* As a workaround against the Solaris/HP-UX problem, we split not
* only at normal spaces, but also at hard spaces.
* See <impnotes.html#quickstart>.
*/
Linux 2.6 ne sépare pas les arguments, et si je me souviens bien, 2.4 non plus.
Il me semble que ça n'a absolument aucune importance, car tout les shells dignes de ce nom semble en tenir compte!
Les shells (sauf zsh) ne parsent pas cette ligne. C'est une fonctionnalité du systeme d'exploitation. Si exec(2) renvoie un ENOEXEC, alors le shell peut decider de quoi faire de ce fichier (s'il a les permissions d'executions).
Par exemple, csh (au moins certaines versions) va regarder le premier caractere. Si c'est un "#", alors il va lancer /bin/csh sur le fichier. Sinon, il utilise /bin/sh. Les autres shells vont soit lancer /bin/sh (ou l'equivalent POSIX) soit lancer une instance d'eux-memes, soit vont utiliser un fils d'eux-memes (pas d'appel a exec). zsh est l'exception, il va faire le boulot du systeme a sa place (s'il ne supporte pas le #!): interpreter #! et passer un seul argument.
Donc, en gros, si le systeme supporte #!, le shell n'a aucune influence dans le processus, et - clisp est lance avec 1 argument: "-q -ansi" (la plupart du temps) - avec deux arguments sur FreeBSD ("-q" et "-ansi" - avec 1 arguments "-q" sur d'autres - ... voir tableau
Si le systeme ne supporte pas #! (je n'ai encore jamais croisé de tel systeme), alors - ce sera "csh" et pas "clisp" qui interpretera le script si le shell est "csh" - clisp est lancé avec 1 argument "-q -ansi" si le shell est zsh - ce sera /bin/sh ou bash ou ksh suivant quel autre shell a lance la commande. - Ca renverra un ENOEXEC si ce fichier n'est pas exectuté par un shell.
En tout cas, clisp interprete parfaitement bien la chaine "-q -ansi" puisqu'il n'affiche pas sa banière et passe en mode ANSI.
Si, clisp decoupe ses arguments pour en faire des arguments virtuels (empiete sur les prerogatives des shells), alors OK, on a affaire a un cas particulier.
Sinon, des lignes comme:
#! /usr/bin/awk -F/ -f
ne marcheront pas (sauf sous FreeBSD), il est bon de le savoir.
Dans le source code de GNU clisp:
/* * Script execution on Unix is implemented like this: * - The basename/fullname of the interpreter is put into argv[0]. * - (Optional - only if at least one interpreter-arg is present.) Next * comes the tail of the "#!..." line. On SunOS 4, Linux, IRIX, AIX, * OSF/1: with leading whitespace stripped, but whitespace inside it * untouched (!). On Solaris, HP-UX: with leading whitespace stripped, * and cut off at the next whitespace character (!!). * - Next comes the filename of the script. * - Then all the arguments of the script. * We therefore need to split argv[1] into pieces. We shouldn't split * "-x" arguments into pieces. However, fortunately, the "-x" argument * cannot appear as argv[1] (because "-x" must precede it), and it * cannot appear within the "#!..." line (because "#!" and "-x" are * mutually exclusive). * As a workaround against the Solaris/HP-UX problem, we split not * only at normal spaces, but also at hard spaces. * See <impnotes.html#quickstart>. */
-- Stephane
Stephane Chazelas
2004-09-20, 11:45(+00), Stephane Chazelas: [...]
Donc, en gros, si le systeme supporte #!, le shell n'a aucune influence dans le processus, et - clisp est lance avec 1 argument: "-q -ansi" (la plupart du temps)
Oui, enfin avec trois arguments: argv[0] = /path/to/clisp voire du script suivant les systemes argv[1] = "-q -ansi" argv[2] = le script
-- Stephane
2004-09-20, 11:45(+00), Stephane Chazelas:
[...]
Donc, en gros, si le systeme supporte #!, le shell n'a aucune
influence dans le processus, et
- clisp est lance avec 1 argument: "-q -ansi" (la plupart du
temps)
Oui, enfin avec trois arguments:
argv[0] = /path/to/clisp voire du script suivant les systemes
argv[1] = "-q -ansi"
argv[2] = le script
Donc, en gros, si le systeme supporte #!, le shell n'a aucune influence dans le processus, et - clisp est lance avec 1 argument: "-q -ansi" (la plupart du temps)
Oui, enfin avec trois arguments: argv[0] = /path/to/clisp voire du script suivant les systemes argv[1] = "-q -ansi" argv[2] = le script
