Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous FreeBSD, telles que -n Number the output lines, starting at 1. Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi s'arrêter.
Quel intéret alors qu'on a "sed =" ?
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous
FreeBSD, telles que
-n Number the output lines, starting at 1.
Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi
s'arrêter.
Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous FreeBSD, telles que -n Number the output lines, starting at 1. Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi s'arrêter.
Quel intéret alors qu'on a "sed =" ?
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Benoit Izac
Bonjour,
le 14/09/2006 à 19:46, Emmanuel Dreyfus a écrit dans le message <1hlo6u5.5s1xr71i70eg8N% :
Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous FreeBSD, telles que -n Number the output lines, starting at 1. Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi s'arrêter.
Quel intéret alors qu'on a "sed =" ?
Ou encore nl(1) qui est justement fait pour.
-- Benoit Izac
Bonjour,
le 14/09/2006 à 19:46, Emmanuel Dreyfus a écrit dans le message
<1hlo6u5.5s1xr71i70eg8N%manu@netbsd.org> :
Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous
FreeBSD, telles que
-n Number the output lines, starting at 1.
Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi
s'arrêter.
le 14/09/2006 à 19:46, Emmanuel Dreyfus a écrit dans le message <1hlo6u5.5s1xr71i70eg8N% :
Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous FreeBSD, telles que -n Number the output lines, starting at 1. Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi s'arrêter.
Quel intéret alors qu'on a "sed =" ?
Ou encore nl(1) qui est justement fait pour.
-- Benoit Izac
Miod Vallat
Sur ce point, il faut relativiser, ce sont de mauvais exemples :
Ce sont surtout les seuls exemples liés à OpenBSD. Donc, à mes yeux,
Non, ce sont les exemples qui ont fait du bruit parce que soit ils se sont cassés la gueule, soit ils font n'importe quoi, dans les deux cas parce qu'ils sont gérés par des incapables.
Un fork spécialisé d'OpenBSD qui marche et qui ne fait pas de bruit, c'est par exemple PMON2000. Il y avait aussi une appliance basée sur un OpenBSD modifié il y a quelques années, tournant sur une machine sans MMU, et dont j'ai oublié le nom.
- MirBSD est le plus abouti de ces forks, [...]
Bof. J'ai dû mal à considérer ce projet comme abouti, alors qu'il n'arrête pas de changer d'orientation. D'un autre côté, l'absence de
J'ai écrit «le plus abouti», par comparaison avec les autres, hein. Seul un souci de ne pas heurter la sensibilité des lecteurs du groupe me retient de dire ici ce que je pense de ce CancrelatBSD.
Sur ce point, il faut relativiser, ce sont de mauvais exemples :
Ce sont surtout les seuls exemples liés à OpenBSD. Donc, à mes yeux,
Non, ce sont les exemples qui ont fait du bruit parce que soit ils se
sont cassés la gueule, soit ils font n'importe quoi, dans les deux cas
parce qu'ils sont gérés par des incapables.
Un fork spécialisé d'OpenBSD qui marche et qui ne fait pas de bruit,
c'est par exemple PMON2000. Il y avait aussi une appliance basée sur un
OpenBSD modifié il y a quelques années, tournant sur une machine sans
MMU, et dont j'ai oublié le nom.
- MirBSD est le plus abouti de ces forks, [...]
Bof. J'ai dû mal à considérer ce projet comme abouti, alors qu'il
n'arrête pas de changer d'orientation. D'un autre côté, l'absence de
J'ai écrit «le plus abouti», par comparaison avec les autres, hein. Seul
un souci de ne pas heurter la sensibilité des lecteurs du groupe me
retient de dire ici ce que je pense de ce CancrelatBSD.
Sur ce point, il faut relativiser, ce sont de mauvais exemples :
Ce sont surtout les seuls exemples liés à OpenBSD. Donc, à mes yeux,
Non, ce sont les exemples qui ont fait du bruit parce que soit ils se sont cassés la gueule, soit ils font n'importe quoi, dans les deux cas parce qu'ils sont gérés par des incapables.
Un fork spécialisé d'OpenBSD qui marche et qui ne fait pas de bruit, c'est par exemple PMON2000. Il y avait aussi une appliance basée sur un OpenBSD modifié il y a quelques années, tournant sur une machine sans MMU, et dont j'ai oublié le nom.
- MirBSD est le plus abouti de ces forks, [...]
Bof. J'ai dû mal à considérer ce projet comme abouti, alors qu'il n'arrête pas de changer d'orientation. D'un autre côté, l'absence de
J'ai écrit «le plus abouti», par comparaison avec les autres, hein. Seul un souci de ne pas heurter la sensibilité des lecteurs du groupe me retient de dire ici ce que je pense de ce CancrelatBSD.
Manuel Bouyer
Michel Talon wrote:
Il y a une tres bonne raison pour ne pas mettre une telle option a cat: elle est completement non standard. Des que des gens vont s'en servir, ca va automatiquement rendre le script non portable.
Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous FreeBSD, telles que -n Number the output lines, starting at 1. Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi s'arrêter.
Celle la elle est la depuis tres longtemps. Je suis meme a peu pres sur que le cat de SunOS 4 l'avait deja (quand je faisait des TP sur sun3, ca ne nous rajeunis pas ...) C'est peut-etre aussi dans une norme quelconque.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Il y a une tres bonne raison pour ne pas mettre une telle option a cat:
elle est completement non standard. Des que des gens vont s'en servir,
ca va automatiquement rendre le script non portable.
Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous
FreeBSD, telles que
-n Number the output lines, starting at 1.
Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi
s'arrêter.
Celle la elle est la depuis tres longtemps. Je suis meme a peu pres sur
que le cat de SunOS 4 l'avait deja (quand je faisait des TP sur sun3,
ca ne nous rajeunis pas ...)
C'est peut-etre aussi dans une norme quelconque.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
Il y a une tres bonne raison pour ne pas mettre une telle option a cat: elle est completement non standard. Des que des gens vont s'en servir, ca va automatiquement rendre le script non portable.
Absolument d'accord, sauf que cat a déjà des options aussi farfelues sous FreeBSD, telles que -n Number the output lines, starting at 1. Par conséquent une fois qu'on a mis le doigt dans l'engrenage, pourquoi s'arrêter.
Celle la elle est la depuis tres longtemps. Je suis meme a peu pres sur que le cat de SunOS 4 l'avait deja (quand je faisait des TP sur sun3, ca ne nous rajeunis pas ...) C'est peut-etre aussi dans une norme quelconque.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
espie
In article <eec8sd$2oqk$, Manuel Bouyer wrote:
Celle la elle est la depuis tres longtemps. Je suis meme a peu pres sur que le cat de SunOS 4 l'avait deja (quand je faisait des TP sur sun3, ca ne nous rajeunis pas ...) C'est peut-etre aussi dans une norme quelconque.
Tres specifique, la norme. J'ai verifie tout a l'heure, c'est pas dans Single Unix.
Mais je suis d'accord. D'ailleurs je crains bien l'avoir filee comme `option standard' a des etudiants...
In article <eec8sd$2oqk$1@biggoron.nerim.net>,
Manuel Bouyer <bouyer@nerim.net> wrote:
Celle la elle est la depuis tres longtemps. Je suis meme a peu pres sur
que le cat de SunOS 4 l'avait deja (quand je faisait des TP sur sun3,
ca ne nous rajeunis pas ...)
C'est peut-etre aussi dans une norme quelconque.
Tres specifique, la norme. J'ai verifie tout a l'heure, c'est pas dans
Single Unix.
Mais je suis d'accord. D'ailleurs je crains bien l'avoir filee comme
`option standard' a des etudiants...
Celle la elle est la depuis tres longtemps. Je suis meme a peu pres sur que le cat de SunOS 4 l'avait deja (quand je faisait des TP sur sun3, ca ne nous rajeunis pas ...) C'est peut-etre aussi dans une norme quelconque.
Tres specifique, la norme. J'ai verifie tout a l'heure, c'est pas dans Single Unix.
Mais je suis d'accord. D'ailleurs je crains bien l'avoir filee comme `option standard' a des etudiants...
Et bien justement ça tend à rendre l'impossible possible, en gardant une copie de la version originale de /etc, il peut détecter les modifications que tu as faites, et le réappliquer à la version actuelle. Ce qu'ils appellent un "three-way merge". De temps en temps il peut y avoir un conflit que tu dois résoudre à la main.
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser une sorte de tag dans un commentaire en fin de ligne, genre placer un hash de la ligne par defaut. Comme ca, lors de l'update la ligne sans le commentaire est hachee et comparee au hash. Si cela correspond c'est une option par defaut, sinon c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet quelque chose dans le genre ... ... a moins que quelqu'un trouve une faille dans cette idee :)
Et bien justement ça tend à rendre l'impossible possible, en
gardant une copie de la version originale de /etc, il peut détecter
les modifications que tu as faites, et le réappliquer à la version
actuelle. Ce qu'ils appellent un "three-way merge". De temps en
temps il peut y avoir un conflit que tu dois résoudre à la main.
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser une sorte de tag dans un commentaire en fin de ligne, genre placer un hash de la ligne par defaut.
Comme ca, lors de l'update la ligne sans le commentaire est hachee et comparee au hash. Si cela correspond c'est une option par defaut, sinon c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet quelque chose dans le genre ...
... a moins que quelqu'un trouve une faille dans cette idee :)
Et bien justement ça tend à rendre l'impossible possible, en gardant une copie de la version originale de /etc, il peut détecter les modifications que tu as faites, et le réappliquer à la version actuelle. Ce qu'ils appellent un "three-way merge". De temps en temps il peut y avoir un conflit que tu dois résoudre à la main.
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser une sorte de tag dans un commentaire en fin de ligne, genre placer un hash de la ligne par defaut. Comme ca, lors de l'update la ligne sans le commentaire est hachee et comparee au hash. Si cela correspond c'est une option par defaut, sinon c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet quelque chose dans le genre ... ... a moins que quelqu'un trouve une faille dans cette idee :)
Et bien justement ça tend à rendre l'impossible possible, en gardant une copie de la version originale de /etc, il peut détecter les modifications que tu as faites, et le réappliquer à la version actuelle. Ce qu'ils appellent un "three-way merge". De temps en temps il peut y avoir un conflit que tu dois résoudre à la main.
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser une sorte de tag dans un commentaire en fin de ligne, genre placer un hash de la ligne par defaut. Comme ca, lors de l'update la ligne sans le commentaire est hachee et comparee au hash. Si cela correspond c'est une option par defaut, sinon c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet quelque chose dans le genre ... ... a moins que quelqu'un trouve une faille dans cette idee :)
La connerie, c'est qu'un hash, c'est a peu pres aussi long, voire plus que la ligne. A ce compte, autant mettre la ligne originale en commentaire. A ce compte autant GARDER une copie du fichier original a cote, ce qui est deja fait.
Par contre, utiliser un diff un peu plus intelligent, voire capable de faire des trucs dependants du contexte, ca pourrait ne pas faire de mal. D'experience, cvs update passe son temps a faire des trucs immondes cote conflits sur les fichiers denses, style Makefile...
In article <20060914225634.61a98c5e.anti@spam.gov>,
mips <mips@cyberspace.org> wrote:
Et bien justement ça tend à rendre l'impossible possible, en
gardant une copie de la version originale de /etc, il peut détecter
les modifications que tu as faites, et le réappliquer à la version
actuelle. Ce qu'ils appellent un "three-way merge". De temps en
temps il peut y avoir un conflit que tu dois résoudre à la main.
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser une
sorte de tag dans un commentaire en fin de ligne, genre placer un hash
de la ligne par defaut.
Comme ca, lors de l'update la ligne sans le commentaire est hachee et
comparee au hash. Si cela correspond c'est une option par defaut, sinon
c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet quelque
chose dans le genre ...
... a moins que quelqu'un trouve une faille dans cette idee :)
La connerie, c'est qu'un hash, c'est a peu pres aussi long, voire plus
que la ligne. A ce compte, autant mettre la ligne originale en commentaire.
A ce compte autant GARDER une copie du fichier original a cote, ce qui est
deja fait.
Par contre, utiliser un diff un peu plus intelligent, voire capable de
faire des trucs dependants du contexte, ca pourrait ne pas faire de mal.
D'experience, cvs update passe son temps a faire des trucs immondes
cote conflits sur les fichiers denses, style Makefile...
Et bien justement ça tend à rendre l'impossible possible, en gardant une copie de la version originale de /etc, il peut détecter les modifications que tu as faites, et le réappliquer à la version actuelle. Ce qu'ils appellent un "three-way merge". De temps en temps il peut y avoir un conflit que tu dois résoudre à la main.
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser une sorte de tag dans un commentaire en fin de ligne, genre placer un hash de la ligne par defaut. Comme ca, lors de l'update la ligne sans le commentaire est hachee et comparee au hash. Si cela correspond c'est une option par defaut, sinon c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet quelque chose dans le genre ... ... a moins que quelqu'un trouve une faille dans cette idee :)
La connerie, c'est qu'un hash, c'est a peu pres aussi long, voire plus que la ligne. A ce compte, autant mettre la ligne originale en commentaire. A ce compte autant GARDER une copie du fichier original a cote, ce qui est deja fait.
Par contre, utiliser un diff un peu plus intelligent, voire capable de faire des trucs dependants du contexte, ca pourrait ne pas faire de mal. D'experience, cvs update passe son temps a faire des trucs immondes cote conflits sur les fichiers denses, style Makefile...
mips
On 14 Sep 2006 18:20:44 GMT Miod Vallat wrote:
Sur ce point, il faut relativiser, ce sont de mauvais exemples :
Ce sont surtout les seuls exemples liés à OpenBSD. Donc, à mes yeux,
Non, ce sont les exemples qui ont fait du bruit parce que soit ils se sont cassés la gueule, soit ils font n'importe quoi, dans les deux cas parce qu'ils sont gérés par des incapables.
Un fork spécialisé d'OpenBSD qui marche et qui ne fait pas de bruit, c'est par exemple PMON2000. Il y avait aussi une appliance basée sur un OpenBSD modifié il y a quelques années, tournant sur une machine sans MMU, et dont j'ai oublié le nom.
Et RTMX ?
mips
On 14 Sep 2006 18:20:44 GMT
Miod Vallat <miod@online.fr> wrote:
Sur ce point, il faut relativiser, ce sont de mauvais exemples :
Ce sont surtout les seuls exemples liés à OpenBSD. Donc, à mes
yeux,
Non, ce sont les exemples qui ont fait du bruit parce que soit ils
se sont cassés la gueule, soit ils font n'importe quoi, dans les
deux cas parce qu'ils sont gérés par des incapables.
Un fork spécialisé d'OpenBSD qui marche et qui ne fait pas de bruit,
c'est par exemple PMON2000. Il y avait aussi une appliance basée
sur un OpenBSD modifié il y a quelques années, tournant sur une
machine sans MMU, et dont j'ai oublié le nom.
Sur ce point, il faut relativiser, ce sont de mauvais exemples :
Ce sont surtout les seuls exemples liés à OpenBSD. Donc, à mes yeux,
Non, ce sont les exemples qui ont fait du bruit parce que soit ils se sont cassés la gueule, soit ils font n'importe quoi, dans les deux cas parce qu'ils sont gérés par des incapables.
Un fork spécialisé d'OpenBSD qui marche et qui ne fait pas de bruit, c'est par exemple PMON2000. Il y avait aussi une appliance basée sur un OpenBSD modifié il y a quelques années, tournant sur une machine sans MMU, et dont j'ai oublié le nom.
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser une sorte de tag dans un commentaire en fin de ligne, genre placer un hash de la ligne par defaut. Comme ca, lors de l'update la ligne sans le commentaire est hachee et comparee au hash. Si cela correspond c'est une option par defaut, sinon c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet quelque chose dans le genre ... ... a moins que quelqu'un trouve une faille dans cette idee :)
La connerie, c'est qu'un hash, c'est a peu pres aussi long, voire plus que la ligne. A ce compte, autant mettre la ligne originale en commentaire. A ce compte autant GARDER une copie du fichier original a cote, ce qui est deja fait.
Un hash qui a une distribution suffisante pour reperer une modification d'option n'est pas forcement un truc de 2 kilometres de long. Un hash tout con sur 32 ou 64 bits suffit, genre du fnv. Voir un double hash base sur deux methodes differentes pour limiter les chances de tomber sur une collision.
In article <20060914225634.61a98c5e.anti@spam.gov>,
mips <mips@cyberspace.org> wrote:
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser
une sorte de tag dans un commentaire en fin de ligne, genre placer
un hash de la ligne par defaut.
Comme ca, lors de l'update la ligne sans le commentaire est hachee
et comparee au hash. Si cela correspond c'est une option par
defaut, sinon c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet
quelque chose dans le genre ...
... a moins que quelqu'un trouve une faille dans cette idee :)
La connerie, c'est qu'un hash, c'est a peu pres aussi long, voire
plus que la ligne. A ce compte, autant mettre la ligne originale en
commentaire. A ce compte autant GARDER une copie du fichier
original a cote, ce qui est deja fait.
Un hash qui a une distribution suffisante pour reperer une modification d'option n'est pas forcement un truc de 2 kilometres de long.
Un hash tout con sur 32 ou 64 bits suffit, genre du fnv. Voir un double hash base sur deux methodes differentes pour limiter les chances de tomber sur une collision.
Je vais sans doute dire une connerie mais pourquoi ne pas utiliser une sorte de tag dans un commentaire en fin de ligne, genre placer un hash de la ligne par defaut. Comme ca, lors de l'update la ligne sans le commentaire est hachee et comparee au hash. Si cela correspond c'est une option par defaut, sinon c'est une option modifiee.
Tiens si je trouve du temps un de ces jours je coderais p'tet quelque chose dans le genre ... ... a moins que quelqu'un trouve une faille dans cette idee :)
La connerie, c'est qu'un hash, c'est a peu pres aussi long, voire plus que la ligne. A ce compte, autant mettre la ligne originale en commentaire. A ce compte autant GARDER une copie du fichier original a cote, ce qui est deja fait.
Un hash qui a une distribution suffisante pour reperer une modification d'option n'est pas forcement un truc de 2 kilometres de long. Un hash tout con sur 32 ou 64 bits suffit, genre du fnv. Voir un double hash base sur deux methodes differentes pour limiter les chances de tomber sur une collision.
mips
Miod Vallat
Et RTMX ?
RTMX n'existe plus, contrairement aux autres exemples donnés.
Et RTMX ?
RTMX n'existe plus, contrairement aux autres exemples donnés.
