Tu confonds le libéralisme qu'on te montre à la télé, avec celui qui existe en vrai.
heu ... j'avais l'impression que c'était toi qui faisait cette confusion ... Il faut juste trouver un autre nom pour ce que tu appelles libéralisme.
Ce sont des gens qui se contrefoutent de toi et qui te considèrent comme quantité négligeable, minable et destinée à leur bien être.
Ces gens que tu évoques (des noms ?) se revendiquent-ils comme libéraux ?
Le mot ne veut plus dire la même chose depuis des années.
oui ... comme par exemple pour les professions libérales, qui n'ont plus aucun respect d'autrui depuis des années et qui ne cherchent qu'à s'en mettre pleins les poches, c'est bien connu ... ;-)
Ce que je veux dire, c'est que dans ce cadre (les professions libérales), "libéral" a encore un autre sens. Est-il plus ou moins correct que le sens que tu lui donnes, ou le sens que lui donne le libéralisme ?
Ce qui me gène, c'est que le libéralisme est devenu un chouette épouvantail. Dans le monde capitaliste que nous connaissons, mettre tous les problèmes sur le dos du libéralisme, c'est de l'escroquerie intellectuelle. Et un bon moyen de faire ça, c'est de commencer par dénaturer le sens des mots.
Microsoft (par exemple) est une entreprise "libérale"
non. Une boite qui fait pression sur des états ne peut vraiment pas être libérale, c'est un contresens.
"le libéralisme est la négation du respect d'autri."
super ... avec ce genre de raccourcis là, on arrive des propositions telles que "les utilisateurs de linux sont tous des terroristes communistes ..."
cela dit, tu avais bien pris la précaution de préciser "Selon moi" ;)
une piste à creuser avec awk, en jouant sur le record separator.
En reprenant le même fichier toto qu'abofrp31 :
awk 'BEGIN {RS="^L"}{print NF}' toto
6
4
3
3
3
yapuka (c) travailler sur le traitement que doit faire awk. peut-être pour avoir des sauts de lignes toutes les 10 lignes, quelque chose comme ça : nb_lignes=10
awk 'BEGIN {RS="^L"; ORS=""}{print $0; for(i=NF; i <= '$nb_lignes'; i = i+1) print "\n"; print "^L"}' toto
il reste un ^L en toute fin de fichier.
Si ça ne te convient pas, il suffit dans un premier temps d'appliquer ce script awk sans le print "^L", et dans un deuxième temps d'ajouter les "^L" en question toutes les nb_lignes
attention, ça peut ne pas fonctionner, si la phrase contient des espaces.
A combiner avec la réponse d'abofrp31 pour faire plus complet.
#!/bin/bash
file=$1
shift;
echo $* >> file
quand on fait que du Linux et qu'on a pas à se soucier des problèmes de portabilité, un moyen simple de se sortir du grep qui apparait dans le ps ou pas, c'est d'utiliser l'option -C de ps.
Le truc cool aussi, c'est que l'option -C peut être invoquée plusieurs fois pour un même appel à ps, ce qui peut permettre de simplifier notoirement la réponse au problème d'abendas :)
C'est plus rigolo de chercher soi-même ;)
mais je peux proposer un bout de script avec des ps -C si c'est nécessaire.
les --null de locate et xargs ont été écrit pour répondre spécifiquement à ton besoin. L'idéal serait de comprendre pourquoi ça ne marche pas chez toi.
Quels sont les symptomes ?
N'aurais-tu pas des alias qui redifiniraient déjà locate et xargs qui empécheraient l'option --null de bien se comporter ?
parce que sed applique le remplacement sur le motif de recherche. Il se trouve que ton motif s'applique à une partie de la ligne, pas à toute la ligne. Sed effectue donc le remplacement sur ce bout de ligne, et laisse la fin de ligne inchangée.
Tu peux t'en sortir en rajoutant un .* à la fin de ton motif de recherche comme ça : ls -ld /tmp/ | sed -n 's/\(^[a-z]*\)\(\).*/\1 __/gp'
ben en fait, je suis d'accord avec le post de favardin.
Fonctionnellement, gérer des applications différentes dans des espaces de visualtisation différents (fenêtres, ou frame (qui n'est grossièrement qu'un cas particulier de fenetre)), c'est un peu ce que fait un window manager ...
Ca viendra peut-être un jour. Si t'avais connu les install de distrib pré 2000, tu verrais déjà tout le chemin parcouru depuis, et tu ne serais peut-être pas aussi impatient :)
Y a déjà la LSB qui travaille à identifier et uniformiser certains trucs pour toutes les distribs qui veulent respecter la LSB [1].
Pour le desktop, le project freedesktop [2] travaille là dessus aussi.
pour préciser d'où je parle, les gestionnaires de fenêtre que j'utilise : beaucoup Enlightenment et un peu Ion2. Je n'utilise pas de File Manager. Hors le web, mail et openoffice au boulot (ouin !), je fais quasi tout en ligne de commande. Et là, j'écoute Guerilla Poubelle, mais c'est complètement hors sujet.
2/ Concernant le drag'n'drop
Mon problème se pose dans la config classique, donc quand la fenêtre passe devant les autres lorsqu'on clique.
Est-ce que ça serait pas plutôt ça le problème ?
Pour Windows, le comportement par défaut (focus et mise au premier plan sur simple clic) est le seul comportement possible. Autrement dit, ce qui parait être une chouette solution (ne pas mettre la fenêtre en premier plan en cas de drag'n'drop) peut aussi être vu comme le contournement d'un problème de conception ...
Mais pour un gestionnaire de fenêtre sous Linux, c'est dommage si c'est la conf proposée par défaut. Je trouve la conf "focus sur curseur et mise au premier plan sur clic dans la barre de titre" plus confortable. Un début de preuve, c'est que le problème que tu décris n'existe pas dans cette conf ;-)
3/ Concernant la sélection sur clic dans la barre d'adresse
Le comportement actuel est peut-être lourd dans les barres d'url, mais il est bien pratique dans le shell. Mine de rien, il me semble que le débat sous jacent, c'est de savoir s'il faut que chaque application détermine sa propre façon de gérer le clic de souris ou s'il faut que le gestionnaire de fenêtre propose une interface homogène pour toutes les applis ... Pas simple comme question ...
Sinon, pour Firefox, Ctrl + l, ça marche nickel
pour la molette, je ne peux pas parler, en ce qui me concerne, elle ne sert que sur le Web :-)
Ne nous méprenons pas, je suis un grand fan du shell ! et en ligne de commande, je me fais plaisir. Si malin passe dans la coin, il confirmera peut -être ;)
Mais quand les outils shell que tu utilises pour contrôler tes applications deviennent bien gros, ça devient compliqué à maintenir.
Un des points qui me gène le plus dans le scripting shell, c'est la gestion d'erreur, que je trouve trop couteuse par rapport à d'autres langages de script .
Pour finir, en guise d'illustration, deux lignes jetables pas optimisées à lancer dans un /usr/bin qui donne chez moi :
$ wc -l `file * | grep Bourne | cut -d ':' -f 1` | grep -v total | awk '{tot = tot + $1}END{print tot " / " NR " ; " tot / NR}'
30066 / 246 ; 122.22
$ wc -l `file * | grep perl | cut -d ':' -f 1` | grep -v total | awk '{tot = tot + $1}END{print tot " / " NR " ; " tot / NR}'
85325 / 111 ; 768.694
Soit une longueur moyenne de 122 lignes pour les scripts sh et de 768 pour les script perl, alors que la syntaxe de perl est beaucoup plus compacte que celle du shell.
Je n'ai pas calculé l'écart type, mais j'ai vérifié que c'est pas un script perl de 50000 lignes qui fait monter la moyenne.
maintenant, à chacun d'en tirer les conclusions qu'il veut :)
Une idée comme ça : es-tu chez free ?
par défaut, ils filtrent le port 25.
Il faut explicitement demander de le laisser passer depuis l'interface de config du compte free.
Alors en fait, tu connais ces outils beaucoup mieux que moi. C'est juste qu'on ne mettait pas la même chose derrière le terme "gestion des dépendances", alors ça m'a enduit d'erreur ;-)
pour ma culture, tu sais si rpm connait le net depuis ses débuts ou si c'est un ajout "récent" (c-a-d post-2000 ;-) ?
(oui, j'ai la flemme de chercher sur le net. Non, ce n'est pas la peine de perdre du temps à chercher l'info si tu ne l'as pas en tête :-)
alors en fait, si, rpm gère les dépendances (ouf !). Ce qu'il ne sait pas faire par contre, c'est résoudre les problèmes des dépendances manquantes.
Yum, c 'est la surcouche qui connait le net, et qui sait télécharger des paquets en résolvant les problèmes de dépendance à ta place.
A noter aussi, il me semble, que rpm/yum ne gèrent pas la présence d'un même paquet dans plusieurs versions différentes aussi bien qu'apt. Du coup, une install d'un truc un peu récent peu forcer l'upgrade d'une tripotée de paquets. (genre un upgrade de python). Et quand l'espace disque est limitée sur la machine, ça peut devenir problèmatique (l'update de Fecora 3 à 5, puis de 5 à 7, c'est un peu sport :)
[^] # Re: Ne pas confondre
Posté par gaaaaaAab . En réponse à la dépêche La normalisation de OOXML relance le RGI.. Évalué à 2.
heu ... j'avais l'impression que c'était toi qui faisait cette confusion ... Il faut juste trouver un autre nom pour ce que tu appelles libéralisme.
Ce sont des gens qui se contrefoutent de toi et qui te considèrent comme quantité négligeable, minable et destinée à leur bien être.
Ces gens que tu évoques (des noms ?) se revendiquent-ils comme libéraux ?
Le mot ne veut plus dire la même chose depuis des années.
oui ... comme par exemple pour les professions libérales, qui n'ont plus aucun respect d'autrui depuis des années et qui ne cherchent qu'à s'en mettre pleins les poches, c'est bien connu ... ;-)
Ce que je veux dire, c'est que dans ce cadre (les professions libérales), "libéral" a encore un autre sens. Est-il plus ou moins correct que le sens que tu lui donnes, ou le sens que lui donne le libéralisme ?
Ce qui me gène, c'est que le libéralisme est devenu un chouette épouvantail. Dans le monde capitaliste que nous connaissons, mettre tous les problèmes sur le dos du libéralisme, c'est de l'escroquerie intellectuelle. Et un bon moyen de faire ça, c'est de commencer par dénaturer le sens des mots.
Microsoft (par exemple) est une entreprise "libérale"
non. Une boite qui fait pression sur des états ne peut vraiment pas être libérale, c'est un contresens.
[^] # Re: Ne pas confondre
Posté par gaaaaaAab . En réponse à la dépêche La normalisation de OOXML relance le RGI.. Évalué à 5.
super ... avec ce genre de raccourcis là, on arrive des propositions telles que "les utilisateurs de linux sont tous des terroristes communistes ..."
cela dit, tu avais bien pris la précaution de préciser "Selon moi" ;)
bon, ça vaut ce que ça vaut, mais voilà déjà la définition sur wikipedia : http://fr.wikipedia.org/wiki/Philosophie_lib%C3%A9rale
ps : je ne suis pas libéraliste ... 'fin, je crois pas
[^] # Re: Petit complément d'informations.
Posté par gaaaaaAab . En réponse au message Enlever un saut de page sur deux.. Évalué à 2.
En reprenant le même fichier toto qu'abofrp31 :
awk 'BEGIN {RS="^L"}{print NF}' toto
6
4
3
3
3
yapuka (c) travailler sur le traitement que doit faire awk. peut-être pour avoir des sauts de lignes toutes les 10 lignes, quelque chose comme ça :
nb_lignes=10awk 'BEGIN {RS="^L"; ORS=""}{print $0; for(i=NF; i <= '$nb_lignes'; i = i+1) print "\n"; print "^L"}' toto
il reste un ^L en toute fin de fichier.
Si ça ne te convient pas, il suffit dans un premier temps d'appliquer ce script awk sans le print "^L", et dans un deuxième temps d'ajouter les "^L" en question toutes les nb_lignes
[^] # Re: script
Posté par gaaaaaAab . En réponse au message Un script. Évalué à 3.
A combiner avec la réponse d'abofrp31 pour faire plus complet.
#!/bin/bash
file=$1
shift;
echo $* >> file
(man bash pour des explications sur shift et $*)
[^] # Re: sans eval uniquement avec des quotes doubles quotes contres quotes
Posté par gaaaaaAab . En réponse au message Un espace dans le path et l'execution devient impossible. Évalué à 1.
bon, là, on sort de mon domaine de compétence ... il faudrait un windows pour pouvoir tester des trucs sur cygwin ...
la commande eval ne fonctionne pas sur le csh cygwin ? ou tu ne peux/veux pas l'utiliser ?
[^] # Re: sed si l'adresse est variable
Posté par gaaaaaAab . En réponse au message Un espace dans le path et l'execution devient impossible. Évalué à 2.
et tant qu'à tétracapillotomer, ce serait plutôt addbackslashes ;-)
[^] # Re: sans eval uniquement avec des quotes doubles quotes contres quotes
Posté par gaaaaaAab . En réponse au message Un espace dans le path et l'execution devient impossible. Évalué à 2.
Comme ça alors ?
#!/bin/csh
set mavar="/home/roger/mes\ prog/echo"
"$mavar" titi
exit
# eval
Posté par gaaaaaAab . En réponse au message Un espace dans le path et l'execution devient impossible. Évalué à 3.
Sinon, pour économiser 1 caractère (la nature te dira merci ;), tu peux échapper l'espace avec \. Du coup, test2.csh devient :
#!/bin/csh
set mavar="/home/roger/mes\ prog/echo"
eval $mavar titi
exit
ouala !
[^] # Re: A ma sauce
Posté par gaaaaaAab . En réponse au message Script de surveillance de process en ksh. Évalué à 1.
Le truc cool aussi, c'est que l'option -C peut être invoquée plusieurs fois pour un même appel à ps, ce qui peut permettre de simplifier notoirement la réponse au problème d'abendas :)
C'est plus rigolo de chercher soi-même ;)
mais je peux proposer un bout de script avec des ps -C si c'est nécessaire.
[^] # Re: apache-status
Posté par gaaaaaAab . En réponse au message comptage des process apaches. Évalué à 1.
ps --no-heading -C httpd | wc -lun pipe en moins et plus précis ! =)
[^] # Re: cron vs sleep() ?
Posté par gaaaaaAab . En réponse au message Cron ou sleep() ?. Évalué à 2.
joie dans la demeure ! qsort fait partie du C ansi ! \(^.^)/
# --null
Posté par gaaaaaAab . En réponse au message Problem avec les alias. Évalué à 2.
les --null de locate et xargs ont été écrit pour répondre spécifiquement à ton besoin. L'idéal serait de comprendre pourquoi ça ne marche pas chez toi.
Quels sont les symptomes ?
N'aurais-tu pas des alias qui redifiniraient déjà locate et xargs qui empécheraient l'option --null de bien se comporter ?
Tout autre solution serait du bricolage ...
# sed
Posté par gaaaaaAab . En réponse au message diverses questions : permissions, bash/exec, suid et sed. Évalué à 2.
parce que sed applique le remplacement sur le motif de recherche. Il se trouve que ton motif s'applique à une partie de la ligne, pas à toute la ligne. Sed effectue donc le remplacement sur ce bout de ligne, et laisse la fin de ligne inchangée.
Tu peux t'en sortir en rajoutant un .* à la fin de ton motif de recherche comme ça :
ls -ld /tmp/ | sed -n 's/\(^[a-z]*\)\(\).*/\1 __/gp'[^] # Re: une idée
Posté par gaaaaaAab . En réponse au message Application rassemblant des applications existantes. Évalué à 4.
Fonctionnellement, gérer des applications différentes dans des espaces de visualtisation différents (fenêtres, ou frame (qui n'est grossièrement qu'un cas particulier de fenetre)), c'est un peu ce que fait un window manager ...
[^] # Re: Discussion tres interessante
Posté par gaaaaaAab . En réponse au message Ces détails de l'interface windows qui manquent sous Linux.... Évalué à 1.
Y a déjà la LSB qui travaille à identifier et uniformiser certains trucs pour toutes les distribs qui veulent respecter la LSB [1].
Pour le desktop, le project freedesktop [2] travaille là dessus aussi.
A suivre ...
[1] : http://www.linux-foundation.org/en/LSB
[2] : http://www.freedesktop.org/wiki/
# mes deux centimes
Posté par gaaaaaAab . En réponse au message Ces détails de l'interface windows qui manquent sous Linux.... Évalué à 1.
2/ Concernant le drag'n'drop
Mon problème se pose dans la config classique, donc quand la fenêtre passe devant les autres lorsqu'on clique.
Est-ce que ça serait pas plutôt ça le problème ?
Pour Windows, le comportement par défaut (focus et mise au premier plan sur simple clic) est le seul comportement possible. Autrement dit, ce qui parait être une chouette solution (ne pas mettre la fenêtre en premier plan en cas de drag'n'drop) peut aussi être vu comme le contournement d'un problème de conception ...
Mais pour un gestionnaire de fenêtre sous Linux, c'est dommage si c'est la conf proposée par défaut. Je trouve la conf "focus sur curseur et mise au premier plan sur clic dans la barre de titre" plus confortable. Un début de preuve, c'est que le problème que tu décris n'existe pas dans cette conf ;-)
3/ Concernant la sélection sur clic dans la barre d'adresse
Le comportement actuel est peut-être lourd dans les barres d'url, mais il est bien pratique dans le shell. Mine de rien, il me semble que le débat sous jacent, c'est de savoir s'il faut que chaque application détermine sa propre façon de gérer le clic de souris ou s'il faut que le gestionnaire de fenêtre propose une interface homogène pour toutes les applis ... Pas simple comme question ...
Sinon, pour Firefox, Ctrl + l, ça marche nickel
pour la molette, je ne peux pas parler, en ce qui me concerne, elle ne sert que sur le Web :-)
[^] # Re: En perl
Posté par gaaaaaAab . En réponse au message head et tail deux en un ?. Évalué à 1.
perl -e 'read(STDIN,$p,10);read(STDIN,$b,20); print $b' < unfichier
[^] # Re: Hahahahahahaha
Posté par gaaaaaAab . En réponse au message Marre de linux pourri. Évalué à 0.
whoua le troll à tiroir hé !
'xcellent :D
[^] # Re: quelques idées
Posté par gaaaaaAab . En réponse au message comment devenir programmeur ? Et quelles études ?. Évalué à 1.
Il *faut* avoir lu ce livre !
[^] # Re: arf...
Posté par gaaaaaAab . En réponse au message Alternatives aux shells. Évalué à 1.
mais ton exemple est quand même le bienvenu si tu as le temps de remettre la main dessus !
[^] # Re: arf...
Posté par gaaaaaAab . En réponse au message Alternatives aux shells. Évalué à 1.
Mais quand les outils shell que tu utilises pour contrôler tes applications deviennent bien gros, ça devient compliqué à maintenir.
Un des points qui me gène le plus dans le scripting shell, c'est la gestion d'erreur, que je trouve trop couteuse par rapport à d'autres langages de script .
Pour finir, en guise d'illustration, deux lignes jetables pas optimisées à lancer dans un /usr/bin qui donne chez moi :
$ wc -l `file * | grep Bourne | cut -d ':' -f 1` | grep -v total | awk '{tot = tot + $1}END{print tot " / " NR " ; " tot / NR}'
30066 / 246 ; 122.22
$ wc -l `file * | grep perl | cut -d ':' -f 1` | grep -v total | awk '{tot = tot + $1}END{print tot " / " NR " ; " tot / NR}'
85325 / 111 ; 768.694
Soit une longueur moyenne de 122 lignes pour les scripts sh et de 768 pour les script perl, alors que la syntaxe de perl est beaucoup plus compacte que celle du shell.
Je n'ai pas calculé l'écart type, mais j'ai vérifié que c'est pas un script perl de 50000 lignes qui fait monter la moyenne.
maintenant, à chacun d'en tirer les conclusions qu'il veut :)
[^] # Re: arf...
Posté par gaaaaaAab . En réponse au message Alternatives aux shells. Évalué à 2.
C'est comme écrire un pilote de périphérique en java, on peut ... mais bon ... ;)
Et le troll rebonda.
# free ?
Posté par gaaaaaAab . En réponse au message Postfix n'écoute que sur 127.0.0.1. Évalué à 2.
par défaut, ils filtrent le port 25.
Il faut explicitement demander de le laisser passer depuis l'interface de config du compte free.
[^] # Re: Merci
Posté par gaaaaaAab . En réponse au message Guide Debian -> Red Hat. Évalué à 1.
pour ma culture, tu sais si rpm connait le net depuis ses débuts ou si c'est un ajout "récent" (c-a-d post-2000 ;-) ?
(oui, j'ai la flemme de chercher sur le net. Non, ce n'est pas la peine de perdre du temps à chercher l'info si tu ne l'as pas en tête :-)
[^] # Re: Merci
Posté par gaaaaaAab . En réponse au message Guide Debian -> Red Hat. Évalué à 1.
Yum, c 'est la surcouche qui connait le net, et qui sait télécharger des paquets en résolvant les problèmes de dépendance à ta place.
A noter aussi, il me semble, que rpm/yum ne gèrent pas la présence d'un même paquet dans plusieurs versions différentes aussi bien qu'apt. Du coup, une install d'un truc un peu récent peu forcer l'upgrade d'une tripotée de paquets. (genre un upgrade de python). Et quand l'espace disque est limitée sur la machine, ça peut devenir problèmatique (l'update de Fecora 3 à 5, puis de 5 à 7, c'est un peu sport :)