J'ai un serveur web dont le fichier de configuration est abondament
commenté.
Maintenant que j'ai compris toutes les options, je souhaiterai faire
mumuse avec pour peauffiner.
Il serait bon que je puisse naviguer dans ce fichier le plus rapidement
possible et avoir une vue globale la plus confortable.
Les commentaires me sont maintenant inutiles. Au pire, je peux me baser
sur un fichier sample à coté.
Les commentaires sont les lignes qui commencent par "#".
Si je fais un
sed 's,#.*,,g' /home/mihamina/web/etc/zope.conf | sed '/^$/d'
J'ai eu des lignes blanches à la place des commentaires. C'est bien, mais
c'était trop aéré. Des lignes blanches, c'est encore moins utile que
des commentaires... J'ai un peu cherché, c'est comme ça que j'ai trouvé
un moyen de remplacer les commentaires par "vraiment rien".
Y-a-t-il mieux?
PS: J'utilise ZSH au cas ou ça peut me faciliter encore plus la tache...
Merci d'avance.
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
le 07/06/2005 à 11:08, Jacques L'helgoualc'h a écrit dans le message <slrndaap0d.1l7.lhh+ :
Si tu ne veux pas utiliser les EREs (Extended Regular Expressions), tu dois le faire en 2 fois car il n'y a pas de ``|'' en BRE (Basic Regular Expressions) : grep -v '^[[:space:]]*#' fichier | grep -v '^[[:space:]]*$'
ça dépend du grep, alors :
$ echo 'toto tata tutu' | grep -v 'a|u' toto $ grep --version grep (grep de GNU) 2.5.1
J'ai la même version donc les mêmes résultats ; en revanche ça ne fonctionne pas pour sed :
% printf 'totontatantutun' | sed -e '/a|u/d' toto tata tutu % printf 'totontatantutun' | sed -Ee '/a|u/d' toto % printf 'totontatantutun' | sed -re '/a|u/d' sed: illegal option -- r usage: [...] % uname -sr FreeBSD 5.4-RELEASE-p1
-- Benoit Izac
Bonjour,
le 07/06/2005 à 11:08, Jacques L'helgoualc'h a écrit
dans le message <slrndaap0d.1l7.lhh+no_spam@ulysse.maison> :
Si tu ne veux pas utiliser les EREs (Extended Regular Expressions),
tu dois le faire en 2 fois car il n'y a pas de ``|'' en BRE (Basic
Regular Expressions) :
grep -v '^[[:space:]]*#' fichier | grep -v '^[[:space:]]*$'
ça dépend du grep, alors :
$ echo 'toto
tata
tutu' | grep -v 'a|u'
toto
$ grep --version
grep (grep de GNU) 2.5.1
J'ai la même version donc les mêmes résultats ; en revanche ça ne
fonctionne pas pour sed :
% printf 'totontatantutun' | sed -e '/a|u/d'
toto
tata
tutu
% printf 'totontatantutun' | sed -Ee '/a|u/d'
toto
% printf 'totontatantutun' | sed -re '/a|u/d'
sed: illegal option -- r
usage: [...]
% uname -sr
FreeBSD 5.4-RELEASE-p1
le 07/06/2005 à 11:08, Jacques L'helgoualc'h a écrit dans le message <slrndaap0d.1l7.lhh+ :
Si tu ne veux pas utiliser les EREs (Extended Regular Expressions), tu dois le faire en 2 fois car il n'y a pas de ``|'' en BRE (Basic Regular Expressions) : grep -v '^[[:space:]]*#' fichier | grep -v '^[[:space:]]*$'
ça dépend du grep, alors :
$ echo 'toto tata tutu' | grep -v 'a|u' toto $ grep --version grep (grep de GNU) 2.5.1
J'ai la même version donc les mêmes résultats ; en revanche ça ne fonctionne pas pour sed :
% printf 'totontatantutun' | sed -e '/a|u/d' toto tata tutu % printf 'totontatantutun' | sed -Ee '/a|u/d' toto % printf 'totontatantutun' | sed -re '/a|u/d' sed: illegal option -- r usage: [...] % uname -sr FreeBSD 5.4-RELEASE-p1
-- Benoit Izac
Benoit Izac
Dans le message ,
sed -e 's/[[:space:]]*#.*$//' fichier | grep -v '^[[:space:]]*$'
ou plus simplement : sed -e 's/[[:space:]]*#.*$//;/^[[:space:]]*$/d' fichier
-- Benoit Izac
Dans le message <86hdgbgr07@message.id>,
sed -e 's/[[:space:]]*#.*$//' fichier | grep -v '^[[:space:]]*$'
ou plus simplement :
sed -e 's/[[:space:]]*#.*$//;/^[[:space:]]*$/d' fichier
sed -e 's/[[:space:]]*#.*$//' fichier | grep -v '^[[:space:]]*$'
ou plus simplement : sed -e 's/[[:space:]]*#.*$//;/^[[:space:]]*$/d' fichier
-- Benoit Izac
Jacques L'helgoualc'h
Le 07-06-2005, Benoit Izac a écrit : [...]
ça ne fonctionne pas pour sed :
% printf 'totontatantutun' | sed -e '/a|u/d' toto tata tutu % printf 'totontatantutun' | sed -Ee '/a|u/d' toto % printf 'totontatantutun' | sed -re '/a|u/d' sed: illegal option -- r usage: [...] % uname -sr FreeBSD 5.4-RELEASE-p1
Pas le même sed : GNU sed version 4.1.2 [...] --posix désactiver toutes les extensions GNU. -r, --regexp-extended utiliser la syntaxe des expressions régulières étendues dans le script.
$ printf 'totontatantutun' | sed -e '/a|u/d' toto
et aussi :
$ printf "totontitintata" | sed --posix '/a|i/d' toto
En dehors de :
BSD multi-byte sed (Japanese) Based on the latest version of GNU sed, which supports multi-byte characters.
il n'y a qu'une allusion à un « BSD sed » dans sedfaq.txt :
6.6.5. Limits on length of label names
GNU sed: no limit ssed: no limit HHsed v1.5: no limit sed v1.6: [pending] BSD sed: 8 characters
Note that GNU sed and ssed both consider a semicolon to terminate a label name.
6.6.6. Limits on length of write-file names
GNU sed: no limit ssed: no limit HHsed v1.5: no limit sed v1.6: [pending] BSD sed: 40 characters
-- Jacques L'helgoualc'h
Le 07-06-2005, Benoit Izac a écrit :
[...]
ça ne fonctionne pas pour sed :
% printf 'totontatantutun' | sed -e '/a|u/d'
toto
tata
tutu
% printf 'totontatantutun' | sed -Ee '/a|u/d'
toto
% printf 'totontatantutun' | sed -re '/a|u/d'
sed: illegal option -- r
usage: [...]
% uname -sr
FreeBSD 5.4-RELEASE-p1
Pas le même sed : GNU sed version 4.1.2
[...]
--posix
désactiver toutes les extensions GNU.
-r, --regexp-extended
utiliser la syntaxe des expressions régulières
étendues dans le script.
$ printf 'totontatantutun' | sed -e '/a|u/d'
toto
et aussi :
$ printf "totontitintata" | sed --posix '/a|i/d'
toto
En dehors de :
BSD multi-byte sed (Japanese)
Based on the latest version of GNU sed, which supports multi-byte
characters.
% printf 'totontatantutun' | sed -e '/a|u/d' toto tata tutu % printf 'totontatantutun' | sed -Ee '/a|u/d' toto % printf 'totontatantutun' | sed -re '/a|u/d' sed: illegal option -- r usage: [...] % uname -sr FreeBSD 5.4-RELEASE-p1
Pas le même sed : GNU sed version 4.1.2 [...] --posix désactiver toutes les extensions GNU. -r, --regexp-extended utiliser la syntaxe des expressions régulières étendues dans le script.
$ printf 'totontatantutun' | sed -e '/a|u/d' toto
et aussi :
$ printf "totontitintata" | sed --posix '/a|i/d' toto
En dehors de :
BSD multi-byte sed (Japanese) Based on the latest version of GNU sed, which supports multi-byte characters.
il n'y a qu'une allusion à un « BSD sed » dans sedfaq.txt :
6.6.5. Limits on length of label names
GNU sed: no limit ssed: no limit HHsed v1.5: no limit sed v1.6: [pending] BSD sed: 8 characters
Note that GNU sed and ssed both consider a semicolon to terminate a label name.
6.6.6. Limits on length of write-file names
GNU sed: no limit ssed: no limit HHsed v1.5: no limit sed v1.6: [pending] BSD sed: 40 characters
-- Jacques L'helgoualc'h
Benoit Izac
Bonjour,
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit dans le message <slrndabssp.6f3.lhh+ :
% printf 'totontatantutun' | sed -e '/a|u/d' toto tata tutu
$ printf "totontitintata" | sed --posix '/a|i/d' toto
J'ai beau relire ``Regular Expressions'' dans SUSv3 (IEEE Std 1003.1, 2003 Edition), je ne vois pas de trace de ``|'' dans les BREs contrairement au paragraphe ``ERE Alternation''.
De plus dans re_format(7) (toujours sur FreeBSD) on peut lire : | re_format -- POSIX 1003.2 regular expressions | [...] | Obsolete (``basic'') regular expressions differ in several respects. | `|' is an ordinary character and there is no equivalent for its | functionality.
Sur Linux aussi : <http://www.die.net/doc/linux/man/man7/regex.7.html> | Obsolete (``basic'') regular expressions differ in several | respects. `|', `+', and `?' are ordinary characters and there is no | equivalent for their functionality.
Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
-- Benoit Izac
Bonjour,
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit
dans le message <slrndabssp.6f3.lhh+no_spam@ulysse.maison> :
% printf 'totontatantutun' | sed -e '/a|u/d'
toto
tata
tutu
$ printf "totontitintata" | sed --posix '/a|i/d'
toto
J'ai beau relire ``Regular Expressions'' dans SUSv3 (IEEE Std 1003.1,
2003 Edition), je ne vois pas de trace de ``|'' dans les BREs
contrairement au paragraphe ``ERE Alternation''.
De plus dans re_format(7) (toujours sur FreeBSD) on peut lire :
| re_format -- POSIX 1003.2 regular expressions
| [...]
| Obsolete (``basic'') regular expressions differ in several respects.
| `|' is an ordinary character and there is no equivalent for its
| functionality.
Sur Linux aussi : <http://www.die.net/doc/linux/man/man7/regex.7.html>
| Obsolete (``basic'') regular expressions differ in several
| respects. `|', `+', and `?' are ordinary characters and there is no
| equivalent for their functionality.
Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit dans le message <slrndabssp.6f3.lhh+ :
% printf 'totontatantutun' | sed -e '/a|u/d' toto tata tutu
$ printf "totontitintata" | sed --posix '/a|i/d' toto
J'ai beau relire ``Regular Expressions'' dans SUSv3 (IEEE Std 1003.1, 2003 Edition), je ne vois pas de trace de ``|'' dans les BREs contrairement au paragraphe ``ERE Alternation''.
De plus dans re_format(7) (toujours sur FreeBSD) on peut lire : | re_format -- POSIX 1003.2 regular expressions | [...] | Obsolete (``basic'') regular expressions differ in several respects. | `|' is an ordinary character and there is no equivalent for its | functionality.
Sur Linux aussi : <http://www.die.net/doc/linux/man/man7/regex.7.html> | Obsolete (``basic'') regular expressions differ in several | respects. `|', `+', and `?' are ordinary characters and there is no | equivalent for their functionality.
Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
-- Benoit Izac
Jacques L'helgoualc'h
Le 07-06-2005, Benoit Izac a écrit :
Bonjour,
bonjour,
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit [...]
$ printf "totontitintata" | sed --posix '/a|i/d' toto
J'ai beau relire ``Regular Expressions'' [...] Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
Ce n'est pas le mien ... J'ai justement ajouté cet exemple à la --gnu-posix parce qu'il me surprenait. -- Jacques L'helgoualc'h
Le 07-06-2005, Benoit Izac a écrit :
Bonjour,
bonjour,
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit
[...]
$ printf "totontitintata" | sed --posix '/a|i/d'
toto
J'ai beau relire ``Regular Expressions'' [...]
Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
Ce n'est pas le mien ... J'ai justement ajouté cet exemple à la
--gnu-posix parce qu'il me surprenait.
--
Jacques L'helgoualc'h
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit [...]
$ printf "totontitintata" | sed --posix '/a|i/d' toto
J'ai beau relire ``Regular Expressions'' [...] Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
Ce n'est pas le mien ... J'ai justement ajouté cet exemple à la --gnu-posix parce qu'il me surprenait. -- Jacques L'helgoualc'h
Antoine Leca
En <news:, Benoit Izac va escriure:
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit dans le message <slrndabssp.6f3.lhh+ :
$ printf "totontitintata" | sed --posix '/a|i/d' toto
J'ai beau relire ``Regular Expressions'' dans SUSv3 (IEEE Std 1003.1, 2003 Edition), je ne vois pas de trace de ``|'' dans les BREs contrairement au paragraphe ``ERE Alternation''. <...>
D'accord.
Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
Bin, Posix (2001) permet bien d'avoir des extensions sans conséquences, non ? Ici, | n'a pas de signification pour Posix, donc il est permis de lui assigner un sens, je pense.
Bien sûr, si --posix sert à détecter les trucs non portables (Posix strict), là il y aurait comme un défaut...
Antoine
En <news:86wtp5g8yo@message.id>, Benoit Izac va escriure:
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit
dans le message <slrndabssp.6f3.lhh+no_spam@ulysse.maison> :
$ printf "totontitintata" | sed --posix '/a|i/d'
toto
J'ai beau relire ``Regular Expressions'' dans SUSv3 (IEEE Std 1003.1,
2003 Edition), je ne vois pas de trace de ``|'' dans les BREs
contrairement au paragraphe ``ERE Alternation''.
<...>
D'accord.
Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
Bin, Posix (2001) permet bien d'avoir des extensions sans conséquences, non
? Ici, | n'a pas de signification pour Posix, donc il est permis de lui
assigner un sens, je pense.
Bien sûr, si --posix sert à détecter les trucs non portables (Posix strict),
là il y aurait comme un défaut...
le 07/06/2005 à 21:20, Jacques L'helgoualc'h a écrit dans le message <slrndabssp.6f3.lhh+ :
$ printf "totontitintata" | sed --posix '/a|i/d' toto
J'ai beau relire ``Regular Expressions'' dans SUSv3 (IEEE Std 1003.1, 2003 Edition), je ne vois pas de trace de ``|'' dans les BREs contrairement au paragraphe ``ERE Alternation''. <...>
D'accord.
Donc, pour moi, ton ``--posix'' ne fonctionne pas correctement.
Bin, Posix (2001) permet bien d'avoir des extensions sans conséquences, non ? Ici, | n'a pas de signification pour Posix, donc il est permis de lui assigner un sens, je pense.
Bien sûr, si --posix sert à détecter les trucs non portables (Posix strict), là il y aurait comme un défaut...
Antoine
Antoine Leca
En <news:slrndabssp.6f3.lhh+, Jacques L'helgoualc'h va escriure:
% uname -sr FreeBSD 5.4-RELEASE-p1
il n'y a qu'une allusion à un « BSD sed » dans sedfaq.txt : 6.6.5. Limits on length of label names BSD sed: 8 characters 6.6.6. Limits on length of write-file names BSD sed: 40 characters
Je pense qu'il y a une confusion dans cette FAQ.
En fait, je vois deux « sed BSD »: l'original (inclus dans 4.2BSD par exemple), en fait le même que celui de M. McMahon (présent dans V7 ou S3), avec les mêmes problèmes, rappelés ci-dessus (et pas mal d'autres, genre les caractères accentués entre [] ou comme arguments de y///). Cette version est « encombrée », évidemment. Cette version permet par exemple s/.../.../P.
Et la version programmée en 1993 par Diomidis Spinellis à partir du brouillon Posix-2, et qui est présente dans Lite/2 et tous les *BSD actuels. Plus de flag P pour s. Mais plus non plus de limitations comme celles ci-dessus.
Antoine
En <news:slrndabssp.6f3.lhh+no_spam@ulysse.maison>,
Jacques L'helgoualc'h va escriure:
% uname -sr
FreeBSD 5.4-RELEASE-p1
il n'y a qu'une allusion à un « BSD sed » dans sedfaq.txt :
6.6.5. Limits on length of label names
BSD sed: 8 characters
6.6.6. Limits on length of write-file names
BSD sed: 40 characters
Je pense qu'il y a une confusion dans cette FAQ.
En fait, je vois deux « sed BSD »: l'original (inclus dans 4.2BSD par
exemple), en fait le même que celui de M. McMahon (présent dans V7 ou S3),
avec les mêmes problèmes, rappelés ci-dessus (et pas mal d'autres, genre les
caractères accentués entre [] ou comme arguments de y///). Cette version est
« encombrée », évidemment. Cette version permet par exemple s/.../.../P.
Et la version programmée en 1993 par Diomidis Spinellis à partir du
brouillon Posix-2, et qui est présente dans Lite/2 et tous les *BSD actuels.
Plus de flag P pour s. Mais plus non plus de limitations comme celles
ci-dessus.
En <news:slrndabssp.6f3.lhh+, Jacques L'helgoualc'h va escriure:
% uname -sr FreeBSD 5.4-RELEASE-p1
il n'y a qu'une allusion à un « BSD sed » dans sedfaq.txt : 6.6.5. Limits on length of label names BSD sed: 8 characters 6.6.6. Limits on length of write-file names BSD sed: 40 characters
Je pense qu'il y a une confusion dans cette FAQ.
En fait, je vois deux « sed BSD »: l'original (inclus dans 4.2BSD par exemple), en fait le même que celui de M. McMahon (présent dans V7 ou S3), avec les mêmes problèmes, rappelés ci-dessus (et pas mal d'autres, genre les caractères accentués entre [] ou comme arguments de y///). Cette version est « encombrée », évidemment. Cette version permet par exemple s/.../.../P.
Et la version programmée en 1993 par Diomidis Spinellis à partir du brouillon Posix-2, et qui est présente dans Lite/2 et tous les *BSD actuels. Plus de flag P pour s. Mais plus non plus de limitations comme celles ci-dessus.
Antoine
Jacques L'helgoualc'h
Le 08-06-2005, Antoine Leca a écrit :
Jacques L'helgoualc'h va escriure:
[sedfaq.txt] Je pense qu'il y a une confusion dans cette FAQ.
En fait, je vois deux « sed BSD »: l'original [...]
Et la version programmée en 1993 par Diomidis Spinellis à partir du brouillon Posix-2, et qui est présente dans Lite/2 et tous les *BSD actuels. Plus de flag P pour s. Mais plus non plus de limitations comme celles ci-dessus.
Cette seconde version semble donc carrément ignorée.
Merci pour ces précisions, -- Jacques L'helgoualc'h
Le 08-06-2005, Antoine Leca a écrit :
Jacques L'helgoualc'h va escriure:
[sedfaq.txt]
Je pense qu'il y a une confusion dans cette FAQ.
En fait, je vois deux « sed BSD »: l'original [...]
Et la version programmée en 1993 par Diomidis Spinellis à partir du
brouillon Posix-2, et qui est présente dans Lite/2 et tous les *BSD actuels.
Plus de flag P pour s. Mais plus non plus de limitations comme celles
ci-dessus.
Cette seconde version semble donc carrément ignorée.
Merci pour ces précisions,
--
Jacques L'helgoualc'h
[sedfaq.txt] Je pense qu'il y a une confusion dans cette FAQ.
En fait, je vois deux « sed BSD »: l'original [...]
Et la version programmée en 1993 par Diomidis Spinellis à partir du brouillon Posix-2, et qui est présente dans Lite/2 et tous les *BSD actuels. Plus de flag P pour s. Mais plus non plus de limitations comme celles ci-dessus.
Cette seconde version semble donc carrément ignorée.
Merci pour ces précisions, -- Jacques L'helgoualc'h
Benoit Izac
Bonjour,
le 08/06/2005 à 11:09, Antoine Leca a écrit dans le message <d86cl0$dil$ :
Bin, Posix (2001) permet bien d'avoir des extensions sans conséquences, non ? Ici, | n'a pas de signification pour Posix, donc il est permis de lui assigner un sens, je pense.
Selon SUSv3 : | The interpretation of an ordinary character preceded by a backslash | ( '' ) is undefined, [...]
Effectivement, on doit pouvoir faire ce que l'on veut. Ce qui veut dire aussi que tout script comportant ``|'' est non portable donc à éviter.
Bien sûr, si --posix sert à détecter les trucs non portables (Posix strict), là il y aurait comme un défaut...
Ça je ne sais pas, la seule chose que je vois dans la page man du gnu sed, c'est : | --posix | disable all GNU extensions. ce qui ne semble pas être le cas.
-- Benoit Izac
Bonjour,
le 08/06/2005 à 11:09, Antoine Leca a écrit
dans le message <d86cl0$dil$1@shakotay.alphanet.ch> :
Bin, Posix (2001) permet bien d'avoir des extensions sans
conséquences, non ? Ici, | n'a pas de signification pour Posix, donc
il est permis de lui assigner un sens, je pense.
Selon SUSv3 :
| The interpretation of an ordinary character preceded by a backslash
| ( '' ) is undefined, [...]
Effectivement, on doit pouvoir faire ce que l'on veut. Ce qui veut dire
aussi que tout script comportant ``|'' est non portable donc à éviter.
Bien sûr, si --posix sert à détecter les trucs non portables (Posix
strict), là il y aurait comme un défaut...
Ça je ne sais pas, la seule chose que je vois dans la page man du gnu
sed, c'est :
| --posix
| disable all GNU extensions.
ce qui ne semble pas être le cas.
le 08/06/2005 à 11:09, Antoine Leca a écrit dans le message <d86cl0$dil$ :
Bin, Posix (2001) permet bien d'avoir des extensions sans conséquences, non ? Ici, | n'a pas de signification pour Posix, donc il est permis de lui assigner un sens, je pense.
Selon SUSv3 : | The interpretation of an ordinary character preceded by a backslash | ( '' ) is undefined, [...]
Effectivement, on doit pouvoir faire ce que l'on veut. Ce qui veut dire aussi que tout script comportant ``|'' est non portable donc à éviter.
Bien sûr, si --posix sert à détecter les trucs non portables (Posix strict), là il y aurait comme un défaut...
Ça je ne sais pas, la seule chose que je vois dans la page man du gnu sed, c'est : | --posix | disable all GNU extensions. ce qui ne semble pas être le cas.
