Je débarque de la planète Windows et je suis complètement irradié par
Bill Gates et compagnie. Je commence donc un long processus de
décontamination, mais je crois que cela va prendre un certain temps.
J'ai réussi à installer RedHat9 ainsi que Firefox et Thunderbird.
Voici les questions basiques que je me pose:
- quel est le dossier équivalent à 'Program Files', ou celui dans lequel
les logiciels doivent être installés ?
- Comment faire une recherche sur tout le disque ? Cette question paraît
vraiment idiote mais je ne sais pas comment faire une recherche dans un
sous-dossier. :-/
- J'ai décompressé et compilé CenterICQ http://thekonst.net/centericq/
mais je ne trouve pas le fichier qui permet de lancer le programme.
Quelqu'un aurait-il une idée ?
Je vous remercie pour votre aide - grâce à vous, je serai un petit moins
igorant. ;-)
Le Wed, 20 Oct 2004 22:24:45 +0200, chmod 777 a écrit :
(...)
Le plus "Waou, je fais comme les grands!": la commande find en ligne de commande ;o)
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers, qui est mis à jour chaque nuit (par un appel à updatedb dans le crontab). Pour un PC qui n'est pas allumé tout le temps, cet index peut être obsolète. Et même quand il est mis à jour, cet index ne contient que les fichiers de la veille.
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule, on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme shell). Zsh parcourt alors le disque comme le ferait un find.
Cordialement
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Bonsoir,
On 2004-10-20, Jerome Lambert <jerome.lambert@swing.be> wrote:
Le Wed, 20 Oct 2004 22:24:45 +0200, chmod 777 a écrit :
(...)
Le plus "Waou, je fais comme les grands!": la commande find en ligne de
commande ;o)
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers,
qui est mis à jour chaque nuit (par un appel à updatedb dans le
crontab). Pour un PC qui n'est pas allumé tout le temps, cet index
peut être obsolète. Et même quand il est mis à jour, cet index ne
contient que les fichiers de la veille.
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule,
on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très
pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme
shell). Zsh parcourt alors le disque comme le ferait un find.
Cordialement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
Le Wed, 20 Oct 2004 22:24:45 +0200, chmod 777 a écrit :
(...)
Le plus "Waou, je fais comme les grands!": la commande find en ligne de commande ;o)
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers, qui est mis à jour chaque nuit (par un appel à updatedb dans le crontab). Pour un PC qui n'est pas allumé tout le temps, cet index peut être obsolète. Et même quand il est mis à jour, cet index ne contient que les fichiers de la veille.
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule, on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme shell). Zsh parcourt alors le disque comme le ferait un find.
Cordialement
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net 8, rue de la Faïencerie, 92340 Bourg La Reine, France
Jerome Lambert
Le Wed, 20 Oct 2004 20:56:18 +0000, Basile Starynkevitch [news] a écrit :
Bonsoir,
On 2004-10-20, Jerome Lambert wrote:
Le Wed, 20 Oct 2004 22:24:45 +0200, chmod 777 a écrit :
(...)
Le plus "Waou, je fais comme les grands!": la commande find en ligne de commande ;o)
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers, qui est mis à jour chaque nuit (par un appel à updatedb dans le crontab). Pour un PC qui n'est pas allumé tout le temps, cet index peut être obsolète. Et même quand il est mis à jour, cet index ne contient que les fichiers de la veille.
En effet, mais mes recherches sont plutot du genre "ou avais-je planqué ce *$ùµ@& de fichier?", donc le critère temps joue moins, et puis question vitesse de recherche, il est plus rapide de parcourir une base de donnée qu'une arborescence.
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule, on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme shell). Zsh parcourt alors le disque comme le ferait un find.
Effectivement, c'est assez puissant.
Mais bon, je débute en zsh après des années de bash, et voilà une raison de plus de me féliciter de mon choix ;-)
Merci pour l'info,
Jerome.
-- Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles ou non. Lire la doc, c'est le Premier et Unique Commandement de l'informaticien. -+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
Le Wed, 20 Oct 2004 20:56:18 +0000, Basile Starynkevitch [news] a
écrit :
Bonsoir,
On 2004-10-20, Jerome Lambert <jerome.lambert@swing.be> wrote:
Le Wed, 20 Oct 2004 22:24:45 +0200, chmod 777 a écrit :
(...)
Le plus "Waou, je fais comme les grands!": la commande find en ligne de
commande ;o)
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers,
qui est mis à jour chaque nuit (par un appel à updatedb dans le
crontab). Pour un PC qui n'est pas allumé tout le temps, cet index
peut être obsolète. Et même quand il est mis à jour, cet index ne
contient que les fichiers de la veille.
En effet, mais mes recherches sont plutot du genre "ou avais-je planqué
ce *$ùµ@& de fichier?", donc le critère temps joue moins, et puis
question vitesse de recherche, il est plus rapide de parcourir une base de
donnée qu'une arborescence.
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule,
on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très
pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme
shell). Zsh parcourt alors le disque comme le ferait un find.
Effectivement, c'est assez puissant.
Mais bon, je débute en zsh après des années de bash, et voilà une
raison de plus de me féliciter de mon choix ;-)
Merci pour l'info,
Jerome.
--
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
Le Wed, 20 Oct 2004 20:56:18 +0000, Basile Starynkevitch [news] a écrit :
Bonsoir,
On 2004-10-20, Jerome Lambert wrote:
Le Wed, 20 Oct 2004 22:24:45 +0200, chmod 777 a écrit :
(...)
Le plus "Waou, je fais comme les grands!": la commande find en ligne de commande ;o)
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers, qui est mis à jour chaque nuit (par un appel à updatedb dans le crontab). Pour un PC qui n'est pas allumé tout le temps, cet index peut être obsolète. Et même quand il est mis à jour, cet index ne contient que les fichiers de la veille.
En effet, mais mes recherches sont plutot du genre "ou avais-je planqué ce *$ùµ@& de fichier?", donc le critère temps joue moins, et puis question vitesse de recherche, il est plus rapide de parcourir une base de donnée qu'une arborescence.
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule, on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme shell). Zsh parcourt alors le disque comme le ferait un find.
Effectivement, c'est assez puissant.
Mais bon, je débute en zsh après des années de bash, et voilà une raison de plus de me féliciter de mon choix ;-)
Merci pour l'info,
Jerome.
-- Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles ou non. Lire la doc, c'est le Premier et Unique Commandement de l'informaticien. -+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"
Nicolas Ecarnot
Le Wed, 20 Oct 2004 21:25:30 +0200, kael disait :
Comment maîtriser la RAM et l'optimiser ?
Je vois clairement que le système ne peut faire qu'une seule chose à la
Hum, linux est plutôt multi-taches.
fois; mais là, c'est du ralenti avec 192 Mo de Ram sur un P3 733 Mhz. :-/
Je ne sais pas trop quoi désinstaller, quels sont les programmes indispensables et ceux qui sont optionnels.
Dans une console, tu peux lancer la commande 'top' qui te permet de voir les process qui prennent le plus de ressources
En général, ce sont les applications graphiques qui prennent le plus de ressources sur un ordinateur bureautique (non serveur), donc voir kde, gnome...
Enfin 'top' te le dira tout de suite (A noter, il est possible de modifier le critère de tri de 'top'. Pour voir ça, lancer 'top' et taper 'h', ou lire la page de manuel) (ces derniers mots te seront rabachés 6000 fois avant l'année 2005, autant t'habituer ;o)
Si tu as installé gnome, je crois qu'il existe un équivalent de top sous forme graphique qui s'appelle gtop. Souvent, gtop montre que ce qui prend le plus de ressource, c'est... gtop ;o)
-- Nicolas Ecarnot
Le Wed, 20 Oct 2004 21:25:30 +0200,
kael <kael@alussinan.org> disait :
Comment maîtriser la RAM et l'optimiser ?
Je vois clairement que le système ne peut faire qu'une seule chose à la
Hum, linux est plutôt multi-taches.
fois; mais là, c'est du ralenti avec 192 Mo de Ram sur un P3 733 Mhz. :-/
Je ne sais pas trop quoi désinstaller, quels sont les programmes
indispensables et ceux qui sont optionnels.
Dans une console, tu peux lancer la commande 'top' qui te permet de voir
les process qui prennent le plus de ressources
En général, ce sont les applications graphiques qui prennent le plus de
ressources sur un ordinateur bureautique (non serveur), donc voir kde,
gnome...
Enfin 'top' te le dira tout de suite (A noter, il est possible de
modifier le critère de tri de 'top'. Pour voir ça, lancer 'top' et taper
'h', ou lire la page de manuel) (ces derniers mots te seront rabachés
6000 fois avant l'année 2005, autant t'habituer ;o)
Si tu as installé gnome, je crois qu'il existe un équivalent de top sous
forme graphique qui s'appelle gtop.
Souvent, gtop montre que ce qui prend le plus de ressource, c'est...
gtop ;o)
Je vois clairement que le système ne peut faire qu'une seule chose à la
Hum, linux est plutôt multi-taches.
fois; mais là, c'est du ralenti avec 192 Mo de Ram sur un P3 733 Mhz. :-/
Je ne sais pas trop quoi désinstaller, quels sont les programmes indispensables et ceux qui sont optionnels.
Dans une console, tu peux lancer la commande 'top' qui te permet de voir les process qui prennent le plus de ressources
En général, ce sont les applications graphiques qui prennent le plus de ressources sur un ordinateur bureautique (non serveur), donc voir kde, gnome...
Enfin 'top' te le dira tout de suite (A noter, il est possible de modifier le critère de tri de 'top'. Pour voir ça, lancer 'top' et taper 'h', ou lire la page de manuel) (ces derniers mots te seront rabachés 6000 fois avant l'année 2005, autant t'habituer ;o)
Si tu as installé gnome, je crois qu'il existe un équivalent de top sous forme graphique qui s'appelle gtop. Souvent, gtop montre que ce qui prend le plus de ressource, c'est... gtop ;o)
-- Nicolas Ecarnot
Nicolas Ecarnot
Le Wed, 20 Oct 2004 20:56:18 +0000 (UTC), Basile Starynkevitch [news] disait :
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers, qui est mis à jour chaque nuit (par un appel à updatedb dans le crontab). Pour un PC qui n'est pas allumé tout le temps, cet index peut être obsolète. Et même quand il est mis à jour, cet index ne contient que les fichiers de la veille.
Et encore il peut ne contenir que les fichiers accessibles par l'utilisateur qui a mis à jour cette base de données, et il est possible que ce ne soit pas root.
Enfin bref, toute une série d'hypothèses qui font qu'il faut se méfier de ce que répond locate.
-- Nicolas Ecarnot
Le Wed, 20 Oct 2004 20:56:18 +0000 (UTC),
Basile Starynkevitch [news] <basile-news@starynkevitch.net> disait :
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers,
qui est mis à jour chaque nuit (par un appel à updatedb dans le
crontab). Pour un PC qui n'est pas allumé tout le temps, cet index
peut être obsolète. Et même quand il est mis à jour, cet index ne
contient que les fichiers de la veille.
Et encore il peut ne contenir que les fichiers accessibles par
l'utilisateur qui a mis à jour cette base de données, et il est possible
que ce ne soit pas root.
Enfin bref, toute une série d'hypothèses qui font qu'il faut se méfier
de ce que répond locate.
Le Wed, 20 Oct 2004 20:56:18 +0000 (UTC), Basile Starynkevitch [news] disait :
Le plus efficace: locate ;-)
Non, pas forcément. la commande locate utilise un index des fichiers, qui est mis à jour chaque nuit (par un appel à updatedb dans le crontab). Pour un PC qui n'est pas allumé tout le temps, cet index peut être obsolète. Et même quand il est mis à jour, cet index ne contient que les fichiers de la veille.
Et encore il peut ne contenir que les fichiers accessibles par l'utilisateur qui a mis à jour cette base de données, et il est possible que ce ne soit pas root.
Enfin bref, toute une série d'hypothèses qui font qu'il faut se méfier de ce que répond locate.
-- Nicolas Ecarnot
Nicolas George
Nicolas Ecarnot wrote in message :
Et encore il peut ne contenir que les fichiers accessibles par l'utilisateur qui a mis à jour cette base de données, et il est possible que ce ne soit pas root.
La plupart des distributions désormais utilisent slocate, qui met à jour la base de données avec les pleins droits, et vérifie ensuite que l'utilisateur qui fait la requête aurait pu voir le fichier par lui-même.
Nicolas Ecarnot wrote in message
<slrncnds27.48d.nicolas.pas.de.spam@siffly.nicolas.fr>:
Et encore il peut ne contenir que les fichiers accessibles par
l'utilisateur qui a mis à jour cette base de données, et il est possible
que ce ne soit pas root.
La plupart des distributions désormais utilisent slocate, qui met à jour la
base de données avec les pleins droits, et vérifie ensuite que l'utilisateur
qui fait la requête aurait pu voir le fichier par lui-même.
Et encore il peut ne contenir que les fichiers accessibles par l'utilisateur qui a mis à jour cette base de données, et il est possible que ce ne soit pas root.
La plupart des distributions désormais utilisent slocate, qui met à jour la base de données avec les pleins droits, et vérifie ensuite que l'utilisateur qui fait la requête aurait pu voir le fichier par lui-même.
Hugues
Ce cher "Basile Starynkevitch [news]" a dit :
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule, on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme shell). Zsh parcourt alors le disque comme le ferait un find.
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer d'«expandre» le '**' et de trouver tous ces fichiers. Essaie à la racine par exemple, tu verras ton zsh se plaindre allègrement qu'il a trop de références.
un ' find -type f -name "truc" ' est nettement plus propre et plus puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en résultat.
l'expansion de zsh (qui est très très puissante) est à utiliser avec parcimonie et dans des cas bien particuliers.
-- Hugues - Linux Addict
Ce cher "Basile Starynkevitch [news]" <basile-news@starynkevitch.net> a dit :
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule,
on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très
pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme
shell). Zsh parcourt alors le disque comme le ferait un find.
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer
d'«expandre» le '**' et de trouver tous ces fichiers.
Essaie à la racine par exemple, tu verras ton zsh se plaindre
allègrement qu'il a trop de références.
un ' find -type f -name "truc" ' est nettement plus propre et plus
puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en
résultat.
l'expansion de zsh (qui est très très puissante) est à utiliser avec
parcimonie et dans des cas bien particuliers.
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule, on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme shell). Zsh parcourt alors le disque comme le ferait un find.
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer d'«expandre» le '**' et de trouver tous ces fichiers. Essaie à la racine par exemple, tu verras ton zsh se plaindre allègrement qu'il a trop de références.
un ' find -type f -name "truc" ' est nettement plus propre et plus puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en résultat.
l'expansion de zsh (qui est très très puissante) est à utiliser avec parcimonie et dans des cas bien particuliers.
-- Hugues - Linux Addict
Stephane Chazelas
2004-10-21, 15:13(+02), Hugues: [...]
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer d'«expandre» le '**' et de trouver tous ces fichiers. Essaie à la racine par exemple, tu verras ton zsh se plaindre allègrement qu'il a trop de références.
C'est le execve(2) de "ls" qui va se plaindre sur les systemes ou il y une limite sur la taille des arguments+environnement (dont Linux fait partie)
Tu peux remplacer par une commande interne:
print -rl /**/... # pas de execle(2) ici
ou utiliser zargs.
un ' find -type f -name "truc" ' est nettement plus propre et plus puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en résultat.
Parce que tu utilises -print ou xargs. Le find de GNU ne sait pas lancer de commandes avec plusieurs arguments malheureusement -exec ls {} + n'est pas supporté et -exec ls {} ; lancera un ls par fichier.
l'expansion de zsh (qui est très très puissante) est à utiliser avec parcimonie et dans des cas bien particuliers.
Dans les cas ou on peut atteindre la limite de ARG_MAX, on peut utiliser zargs
autoload -U zargs # dans le ~/.zshrc zargs ./**/... -- ls
Le probleme du globbing de zsh, c'est qu'il construit la liste entiere, puis qu'il la trie, puis qu'il lance la commande, ce qui peut prendre du temps.
Voir aussi tw (tree walker) pour un remplacement de find.
-- Stephane
2004-10-21, 15:13(+02), Hugues:
[...]
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer
d'«expandre» le '**' et de trouver tous ces fichiers.
Essaie à la racine par exemple, tu verras ton zsh se plaindre
allègrement qu'il a trop de références.
C'est le execve(2) de "ls" qui va se plaindre sur les systemes
ou il y une limite sur la taille des arguments+environnement
(dont Linux fait partie)
Tu peux remplacer par une commande interne:
print -rl /**/... # pas de execle(2) ici
ou utiliser zargs.
un ' find -type f -name "truc" ' est nettement plus propre et plus
puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en
résultat.
Parce que tu utilises -print ou xargs. Le find de GNU ne sait
pas lancer de commandes avec plusieurs arguments malheureusement
-exec ls {} + n'est pas supporté et -exec ls {} ; lancera un ls
par fichier.
l'expansion de zsh (qui est très très puissante) est à utiliser avec
parcimonie et dans des cas bien particuliers.
Dans les cas ou on peut atteindre la limite de ARG_MAX, on peut
utiliser zargs
autoload -U zargs # dans le ~/.zshrc
zargs ./**/... -- ls
Le probleme du globbing de zsh, c'est qu'il construit la liste
entiere, puis qu'il la trie, puis qu'il lance la commande, ce
qui peut prendre du temps.
Voir aussi tw (tree walker) pour un remplacement de find.
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer d'«expandre» le '**' et de trouver tous ces fichiers. Essaie à la racine par exemple, tu verras ton zsh se plaindre allègrement qu'il a trop de références.
C'est le execve(2) de "ls" qui va se plaindre sur les systemes ou il y une limite sur la taille des arguments+environnement (dont Linux fait partie)
Tu peux remplacer par une commande interne:
print -rl /**/... # pas de execle(2) ici
ou utiliser zargs.
un ' find -type f -name "truc" ' est nettement plus propre et plus puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en résultat.
Parce que tu utilises -print ou xargs. Le find de GNU ne sait pas lancer de commandes avec plusieurs arguments malheureusement -exec ls {} + n'est pas supporté et -exec ls {} ; lancera un ls par fichier.
l'expansion de zsh (qui est très très puissante) est à utiliser avec parcimonie et dans des cas bien particuliers.
Dans les cas ou on peut atteindre la limite de ARG_MAX, on peut utiliser zargs
autoload -U zargs # dans le ~/.zshrc zargs ./**/... -- ls
Le probleme du globbing de zsh, c'est qu'il construit la liste entiere, puis qu'il la trie, puis qu'il lance la commande, ce qui peut prendre du temps.
Voir aussi tw (tree walker) pour un remplacement de find.
-- Stephane
Basile Starynkevitch [news]
On 2004-10-21, Hugues wrote:
Ce cher "Basile Starynkevitch [news]" a dit :
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule, on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme shell). Zsh parcourt alors le disque comme le ferait un find.
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer d'«expandre» le '**' et de trouver tous ces fichiers. Essaie à la racine par exemple, tu verras ton zsh se plaindre allègrement qu'il a trop de références.
Oui, si je fais ls /usr/**/* le zsh parcourt le disque puis construit une liste d'arguments trop longue pour execve
Pour ma part, quand je recompile un noyau, je modifie linux-2.6.9/include/linux/limits.h en y modifiant #define ARG_MAX 1048576 /* # bytes of args + environ for exec() */
la valeur par défault est 2^17, ce qui est trop peu pour moi.
un ' find -type f -name "truc" ' est nettement plus propre et plus puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en résultat.
Oui mais j'ai le meme probleme sous bash si je faisais ls $(find /usr -type f -name '*') et il faut en effet utiliser xargs dans ce cas
l'expansion de zsh (qui est très très puissante) est à utiliser avec parcimonie et dans des cas bien particuliers.
En pratique je l'utilise souvent, en ayant un noyau avec un ARG_MAX augmenté.
Cordialement
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net 8, rue de la Faïencerie, 92340 Bourg La Reine, France
On 2004-10-21, Hugues <hugues@contact.me> wrote:
Ce cher "Basile Starynkevitch [news]" <basile-news@starynkevitch.net> a dit :
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule,
on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très
pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme
shell). Zsh parcourt alors le disque comme le ferait un find.
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer
d'«expandre» le '**' et de trouver tous ces fichiers.
Essaie à la racine par exemple, tu verras ton zsh se plaindre
allègrement qu'il a trop de références.
Oui, si je fais ls /usr/**/* le zsh parcourt le disque puis construit
une liste d'arguments trop longue pour execve
Pour ma part, quand je recompile un noyau, je modifie
linux-2.6.9/include/linux/limits.h en y modifiant
#define ARG_MAX 1048576 /* # bytes of args + environ for exec() */
la valeur par défault est 2^17, ce qui est trop peu pour moi.
un ' find -type f -name "truc" ' est nettement plus propre et plus
puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en
résultat.
Oui mais j'ai le meme probleme sous bash si je faisais
ls $(find /usr -type f -name '*')
et il faut en effet utiliser xargs dans ce cas
l'expansion de zsh (qui est très très puissante) est à utiliser avec
parcimonie et dans des cas bien particuliers.
En pratique je l'utilise souvent, en ayant un noyau avec un ARG_MAX
augmenté.
Cordialement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
Sinon, pour trouver un fichier truc dans un répertoire /home/bidule, on peut aussi avec zsh faire ls /home/bidule/**/truc et c'est très pratique (c'est *le* gadget de zsh qui a fait que je l'ai adopté comme shell). Zsh parcourt alors le disque comme le ferait un find.
Pas nécessairement une bonne idée, car dans ce cas Zsh va essayer d'«expandre» le '**' et de trouver tous ces fichiers. Essaie à la racine par exemple, tu verras ton zsh se plaindre allègrement qu'il a trop de références.
Oui, si je fais ls /usr/**/* le zsh parcourt le disque puis construit une liste d'arguments trop longue pour execve
Pour ma part, quand je recompile un noyau, je modifie linux-2.6.9/include/linux/limits.h en y modifiant #define ARG_MAX 1048576 /* # bytes of args + environ for exec() */
la valeur par défault est 2^17, ce qui est trop peu pour moi.
un ' find -type f -name "truc" ' est nettement plus propre et plus puissant, puisqu'il ne se plaindra jamais d'avoir trop de fichiers en résultat.
Oui mais j'ai le meme probleme sous bash si je faisais ls $(find /usr -type f -name '*') et il faut en effet utiliser xargs dans ce cas
l'expansion de zsh (qui est très très puissante) est à utiliser avec parcimonie et dans des cas bien particuliers.
En pratique je l'utilise souvent, en ayant un noyau avec un ARG_MAX augmenté.
Cordialement
-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net 8, rue de la Faïencerie, 92340 Bourg La Reine, France
