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 :)
Si tu arrives à écrire la liste des options qui t'intéressent dans celles que propose la commande indent, tu peux aussi faire : :%!indent <tes options d'indent>
Après, si tu es motivé, ça doit être possible de mapper cette commande dans ton .vimrc, et tu pourras indenter tout un fichier sur une simple pression de touche ! =)
Je sais qu'ils ont un bout de soft pour choisir les paquets cygwin que tu veux installer. Par contre, je ne sais pas si tu peux t'en servir pour accéder à des repository cygwin "non officiels".
tu sauves juste ta base de données, et en cas de crash, ça remarche rapidement.
ça se discute ... le souci, c'est qu'en cas de crash, tu vas restaurer chaque fichier corrompu de ta DB, quand bien même seul 5 % d'un fichier serait endommagé. Et un fichier de DB, ça peut devenir très gros, et restaurer un truc très gros, c'est trèèès long ... :/
En conservant les photos sur le FS, si 5 % du FS est naze, tu ne restaures que ces 5 % là.
ouais, il a pas du relire sa phrase. P-e que le deuxième point, ça serait "comment the default theme so its better documented for people to build new
themes from and learn Edje" du coup ...
[^] # 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 :)
# indent
Posté par gaaaaaAab . En réponse au message vim & indentation fichiers source. Évalué à 1.
:%!indent <tes options d'indent>
Après, si tu es motivé, ça doit être possible de mapper cette commande dans ton .vimrc, et tu pourras indenter tout un fichier sur une simple pression de touche ! =)
# Cygwin !
Posté par gaaaaaAab . En réponse au message apt-get windows. Évalué à 1.
Je sais qu'ils ont un bout de soft pour choisir les paquets cygwin que tu veux installer. Par contre, je ne sais pas si tu peux t'en servir pour accéder à des repository cygwin "non officiels".
Apparemment, (merci google), il y a un apt pour cygwin :
http://donc.wordpress.com/2006/08/04/apt-for-cygwin/
(pas été voir si c'est un port un du from scratch).
'fin, peut-être une piste à creuser quoi.
--
gab
[^] # Re: Raison pragmatique de ne pas le faire...
Posté par gaaaaaAab . En réponse au message Stocker des photos dans une base de données. Évalué à 1.
J'aurais moins bien dit :-)
[^] # Re: Je suis pas un expert, mais ...
Posté par gaaaaaAab . En réponse au message Stocker des photos dans une base de données. Évalué à 1.
ça se discute ... le souci, c'est qu'en cas de crash, tu vas restaurer chaque fichier corrompu de ta DB, quand bien même seul 5 % d'un fichier serait endommagé. Et un fichier de DB, ça peut devenir très gros, et restaurer un truc très gros, c'est trèèès long ... :/
En conservant les photos sur le FS, si 5 % du FS est naze, tu ne restaures que ces 5 % là.
# auto ?
Posté par gaaaaaAab . En réponse au message Pb interface eth0 down. Évalué à 3.
auto lo eth0
mais je suis surpris qu'eth0 soit montée au boot du coup ...
[^] # Re: E17
Posté par gaaaaaAab . En réponse au sondage Pour 2008 vous attendez surtout.... Évalué à 1.
+ 1 pour e17 en 2008
[^] # Re: _deux_ gros chantiers ?
Posté par gaaaaaAab . En réponse à la dépêche Enlightenment : c'est reparti. Évalué à 2.
themes from and learn Edje" du coup ...
[^] # Re: gna.org ?
Posté par gaaaaaAab . En réponse à la dépêche gna.org à la recherche de machines hébergées. Évalué à 2.