- L'intégration de l'infrastructure d'internationalisation GNU gettext et libintl
- Un débogueur intégré (à invoquer via l'option --debugger)
- de nouveaux built-ins, rendant plus facile la manipulation de dates et des tableaux
- le support des expressions régulières dans les structures de test
D'autres choses encore sont à découvrir dans l'épais changelog.
Si Bash n'a pas toutes les fonctionnalités offertes par d'autres shells comme zsh (bien qu'il tende à s'en inspirer par moment), il n'en est pas moins un interpréteur de commande rapide et efficace, dont on est sûr de trouver une copie pour n'importe quel système *nix.
Souhaitons que sa francisation prochaine lui apporte de nouveaux utilisateurs...
Aller plus loin
- Le site officiel de Bash (15 clics)
- Résumé des nouveautés (4 clics)
- Changelog (2 clics)
- Source (3 clics)
- Annonce sur Freshmeat (1 clic)
# Faute dans le titre
Posté par Bouiaw . Évalué à 4.
[^] # Re: Faute dans le titre
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
# fuite un jour, fuite toujours
Posté par TazForEver . Évalué à 10.
- prendre son bash
- taper '$(seq 1000000)' (ou moins si vous avez pas 100Mo à filer à bash)
- sortir son top et constater le résultat
bon, c'est pas tout, faudrait que j'envoie un rapport de bugs, je savais même qu'il y avait un site officiel, je pensais que c'était comme les *-utils, un bordel sans nom, des machins ça et là ...
c'est un bon cru ce bash 3, la syntaxe {1..10} se faisait cruellement attendre.
[^] # Re: fuite un jour, fuite toujours
Posté par Pascal . Évalué à 3.
Non seulement, ca prend 100% du CPU, mais en plus ca bouffe toute la mémoire.
Et cela s'arrête lorsque bash n'arrive plus à allouer de mémoire.
D'ailleurs, je ne comprends pas pourquoi, le processus s'arrête alors qu'il me reste encore 400Mo de swap de libre.
Quelqu'un pourrait m'expliquer?
[^] # Re: fuite un jour, fuite toujours
Posté par TazForEver . Évalué à 5.
- après ça plante s'arrête sans doute à cause d'une limitation de bash.
Bref le problème existe et peur certainement en révéler d'autres.
[^] # Re: fuite un jour, fuite toujours
Posté par jeff110 . Évalué à 3.
Il genere sa liste de nombre puis s'arrette.
La consomation CPU ses situe entre 10 et 15 %, pour 2MO de memoire.
( Mandrake 10.0 officiel sur athlon 2500+/ 512Mo. )
[^] # Re: fuite un jour, fuite toujours
Posté par ʭ ☯ . Évalué à 3.
Mdk Cooker
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: fuite un jour, fuite toujours
Posté par yoho (site web personnel) . Évalué à 2.
N'importe quel programme est censé libérer la mémoire qu'il a demandé au système durant son exécution. Mais là, apparemment, il le fait pas (enfin, je dis ça, j'ai pas testé, moi)
[^] # Re: fuite un jour, fuite toujours
Posté par Thierry Vignaud . Évalué à 1.
contrairement a la libc4, les libc5 et libc6 ne rendent pas la memoire liberee par free() au systeme mais la conserve dans leur pool pour de futures allocations de memoire.
ce comportement est genant lorsqu'un programme alloue ponctullement une grande quantie de ram
[^] # Re: fuite un jour, fuite toujours
Posté par M . Évalué à 2.
for(;;)
char *p;
char c [100];
p = malloc(100*1024*1024);
gets(c);
free(p);
gets(c);
}
ca marche parfaitement (et meme si l'on rajoute une boucle qui ecrit dans la memoire allouer)
et pourquoi sur dash pas de pb aussi ?
[^] # Re: fuite un jour, fuite toujours
Posté par Mikaël Cordon . Évalué à 3.
La consommation du CPU était aux alentours de 70%-80% parce qu'il y a des processus concurrents, le partage du temps est impeccable...
La RAM est bouffée à hauteur de 100Mo en effet, mais est libérée...
Pas de plantage...
- Debian Sid,
- bash à jour,
- kernel 2.6.7 perso mais non patché (sauf pour NVidia),
- 512Mo de RAM,
- CPU P4 1,6GHz
La vérité est ailleurs :)
[^] # Re: fuite un jour, fuite toujours
Posté par M . Évalué à 4.
$ ps v && $(seq 1000000) || ps v
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
4134 pts/9 Ss 0:00 0 589 3886 1732 0.1 -bash
4143 pts/9 R+ 0:00 0 61 2270 672 0.0 ps v
-bash: 1: command not found
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
4134 pts/9 Rs 0:08 0 589 105798 103644 9.9 -bash
4153 pts/9 R+ 0:00 0 61 2270 672 0.0 ps v
[^] # Re: fuite un jour, fuite toujours
Posté par tgl . Évalué à 2.
[^] # Re: fuite un jour, fuite toujours
Posté par udok . Évalué à 1.
[^] # Re: fuite un jour, fuite toujours
Posté par Caeies . Évalué à 2.
Pour info un free ne libère pas la mémoire, il dit juste "je n'ai plus besoin d'elle" et si le même programme redemande la mémoire, il la retrouvera en général dans le même état si la charge est très faible...
M'enfin, ça demande vérification tout de même.
Caeies, mes 2cts
[^] # Re: fuite un jour, fuite toujours
Posté par ufoot (site web personnel) . Évalué à 4.
Dans tous les cas l'appel à la commande free renvoie "quasiment rien de libre" sur toute machine Linux ayant tourné plus d'1/2 journée. La politique de Linux est d'utiliser un max de ram pour le cache, pour "si jamais l'appli redemandait de la mémoire" etc. Rien de très surprenant à ce que Bash continue à faire semblant d'avoir besoin de 100 megs, je soupçonne que mon petit programme fasse pareil.
A sauver dans "mem.c", lancer avec "gcc mem.c -o mem && ./mem"
Je pense que ce vrai-faux problème de memory leak n'en est pas un, et que c'est tout bêtement lié à la façon dont le noyau gère la mémoire.
-------------8<----------------------------------------------------------------------
#include <stdlib.h>
#include <stdio.h>
#define N 10
#define S 10000000
void *my_malloc(int n)
{
void *ptr;
printf("Allocating %d bytes\n",S);
ptr=malloc(n);
if (ptr)
{
((char *) ptr)[0]=' ';
((char *) ptr)[n-1]=' ';
sleep(3);
}
else
{
printf("Failed...\n");
}
return ptr;
}
void my_free(void *ptr)
{
if (ptr)
{
printf("Freeing memory\n");
free(ptr);
}
}
int main(int argc, char *argv[])
{
void *ptr[N];
int i;
for (i=0; i<N;++i)
{
ptr[i]=my_malloc(S);
}
for (i=0;i<N;++i)
{
my_free(ptr[i]);
}
sleep(30);
return(0);
}
-------------8<----------------------------------------------------------------------
[^] # Re: fuite un jour, fuite toujours
Posté par M . Évalué à 2.
fork failed ...
[^] # Re: fuite un jour, fuite toujours
Posté par M . Évalué à 2.
ps v && $(seq 1000000) || sleep 5 && ps v
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
18140 pts/4 SN 0:02 112 77 1470 576 0.4 dash
18182 pts/4 RN+ 0:00 160 61 2230 676 0.5 ps v
dash: 1: not found
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
18140 pts/4 SN 0:04 112 77 1470 576 0.4 dash
18185 pts/4 RN+ 0:00 160 61 2230 676 0.5 ps v
sous bash
ps v && $(seq 100000) || sleep 5 && ps v
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
18301 pts/5 SNs 0:00 349 589 5114 2648 2.0 -bash
18382 pts/5 RN+ 0:00 160 61 2230 676 0.5 ps v
-bash: 1: command not found
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
18301 pts/5 SNs 0:01 349 589 14510 12044 9.4 -bash
18394 pts/5 RN+ 0:00 160 61 2230 676 0.5 ps v
A mon avis c'est bash qui essaye d'implemente un systeme de cache foireux ...
PS le sleep est pour permettre d'avoir des infos a jour
PS dash m'a pris quelques seconde pour faire le truc, j'ai du tue bash et recommencer avec moins de chiffres....
# Pas d'accord
Posté par fred point . Évalué à 4.
Connaissant les univers de deux grandes entreprises françaises, je n'ai jamais trouvé mon shell préféré sur leurs diverses environnments (allant de la prod au dev).
Par contre ksh, là oui, on le retrouve partout.
[^] # Re: Pas d'accord
Posté par Maillequeule . Évalué à 5.
Ceci dit il est vrai que Bash est loin d'être le shell le plus répandu.
M
[^] # Re: Pas d'accord
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Je pense qu'un shell doit rester un shell, si on continue à y ajouter des fonctionnalités, il faudra le doter qu'un compilateur ;-)
[^] # Re: Pas d'accord
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
[^] # Re: Pas d'accord
Posté par gnujsa . Évalué à 3.
Il faut quand même reconnaitre les qualitées de ksh, notement en matiere de programation: c'est une référence
$ GET http://cnswww.cns.cwru.edu/~chet/bash/NEWS(...) | grep ksh
v. New ksh93-like ${!array[@]} expansion, expands to all the keys (indices)
d. `select' was changed to be more ksh-compatible, in that the menu is
g. Added support for ksh93-like [:word:] character class in pattern matching.
z. New [n]<&word- and [n]>&word- redirections from ksh93 -- move fds (dup
l. The ksh-like `ERR' trap has been added. The `ERR' trap will be run
g. There is a new ksh-93 style arithmetic for command:
k. The ksh-93 ${!prefix*} expansion, which expands to the names of all
d. ksh-88 egrep-style extended pattern matching ([@+*?!](patlist)) has been
e. There is a new ksh-like `[[' compound command, which implements
controls whether or not the ksh extended globbing feature is included.
kkk. The ksh-like ((...)) arithmetic command syntax has been implemented.
Et ça c'est que pour les modifications entre bash 2.05b et 3. Ça fait bien longtemps que bash et d'autres shell (zsh, ...) mettent en oeuvre des fonctionalitées de ksh88 et ksh93. Et ksh88 et ksh93, c'est pour 1988 et 1993 !!
Mr Korn a plutot de quoi être fier ;-) En plus, ksh88 est libre (domaine public) et ksh93 est opensource, presque libre.
[^] # Re: Pas d'accord
Posté par ZeroHeure (site web personnel) . Évalué à 5.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Pas d'accord
Posté par Gilles Crebassa . Évalué à 1.
genre avec les "|read"
echo $var1 |while read var2
echo $var2
done
echo $var2
$var2 redevient vide !! et pas sous AIX et HPUX par exemple.
[^] # Re: Pas d'accord
Posté par Christophe Chailloleau-Leclerc . Évalué à 7.
[^] # Re: Pas d'accord
Posté par capicapio . Évalué à 3.
D'où l'utilisation répandue du public domain korn shell (pdksh).
[^] # Re: Pas d'accord
Posté par capicapio . Évalué à 3.
venuE
while ( ! cervelle.isPuree() )
{
tete.frapper( leMur );
}
[^] # Re: Pas d'accord
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Pas d'accord
Posté par gnujsa . Évalué à 3.
# Ouah, une nouvelle version de bash ;-)
Posté par spiral . Évalué à 0.
Est-ce que qqn sait quelles distros vont l'intégrer rapidement ?
Par ex. Est-ce qu'on va bientôt le trouver dans cooker et dans sid ?
Il me tarde de le tester, mais j'ai pas envie d'installer avc les sources... je veux pas casser mes jolies bases rpm ou apt...
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par Buf (Mastodon) . Évalué à 4.
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par Edouard Gomez (site web personnel) . Évalué à 0.
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par gnujsa . Évalué à 2.
apt-get install bash-static/unstable
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par DarkSilver (site web personnel) . Évalué à 1.
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par tgl . Évalué à 2.
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par yoho (site web personnel) . Évalué à 3.
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par Sébastien Bacher . Évalué à 5.
* PS1 regression between bash 2.05 and 3.0:
http://bugs.debian.org/261957(...)
* "trap 0" reports usage error:
http://bugs.debian.org/261948(...)
* bash-3 breaks % and %&":
http://bugs.debian.org/262095(...)
Et divers autres petits problèmes. La plupart sont des bugs, le second est un changement de comportement pour le respect posix qui casse pas mal de scripts ...
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par Sébastien Bacher . Évalué à 1.
.
* fix $BASH_VERSION check to accept bash 3.x (closes: #262762)
[^] # Re: Ouah, une nouvelle version de bash ;-)
Posté par spiral . Évalué à 0.
Cool ;-)
# hors sujet?
Posté par plagiats . Évalué à 8.
http://www.tldp.org/LDP/abs/html/(...)
http://tldp.org/LDP/abs/(...)
[^] # Re: hors sujet?
Posté par nazeman (site web personnel) . Évalué à 4.
http://perso.wanadoo.fr/gleu/absfr.tuxfamily.org/(...)
n'est plus tellement à jour mais c'est un bon début ;-)
[^] # Re: hors sujet?
Posté par Guillaume LELARGE . Évalué à 1.
Le nouveau site se trouve à l'adresse suivante :
http://abs.ptithibou.org/(...)
La dernière version traduite est la 2.8 (http://abs.ptithibou.org/abs-2.8-fr/(...)) mais elle n'a pas encore été entièrement relue.
Toute aide est la bienvenue :)
# Avantage zsh ?
Posté par Sixtiz (site web personnel) . Évalué à 3.
Mais que sont donc ces fameuses fonctionnalités offertes par zsh ?
[^] # Re: Avantage zsh ?
Posté par serial . Évalué à 4.
- Il permet la complétion avec les outils de gestion de paquets, apt-*, urpm*.
- De pouvoir désigner un chemin de répertoire par quelques lettres uniquement. Par exemple "/h/s/Do/emacs" sera complété, s'il n'y a pas d'ambiguité, par "/home/serial/Documents/emacs".
- Pas besoin de taper "cd" devant un nom désignant un répertoire accessible, il y va direct.
- Et plein, d'autres je crois même que la complétion sur les clés GPG est supportée. Tout ceci est customisable bien sûr.
[^] # Re: Avantage zsh ?
Posté par vieuxshell (site web personnel) . Évalué à 3.
http://www.caliban.org/bash/index.shtml(...)
[^] # Re: Avantage zsh ?
Posté par Stephen Amar . Évalué à 1.
la completion marche aussi pour emerge
sinon genre tu tape "tar " il t'affiche la description de tt les option
ensuite, il gere l'autocorrection
genre : acetik@quanta ~ % sl
zsh: correct 'sl' to 'ls' [nyae]?
[^] # Re: Avantage zsh ?
Posté par Pierre . Évalué à 2.
Ca fait chier surtout quand nfs rame..
[^] # Re: Avantage zsh ?
Posté par chl (site web personnel) . Évalué à 3.
Oui bien sur ! Cependant, il m'arrive d'utiliser bash + bash-completion, et j'ai parfois la completion qui met plus de 10 secondes a arriver. Je crois qu'avec zsh, il y a un systeme de cache, qui permet d'eviter ces desagreables secondes d'attente.
voir aussi le journal : https://linuxfr.org/~mat_/14767.html(...) qui parle de ca, et du fait que bash-completion n'est pas activé par defaut sur les distribs, car il prend trop de ressources, cf thread :
https://linuxfr.org/comments/453772.html#453772(...)
[^] # Re: Avantage zsh ?
Posté par vieuxshell (site web personnel) . Évalué à 0.
Le nombre de fois ou je me suis fait avoir avec un
$> man g
Ceci dit, à l'utilisation (sans complétion sur les commandes) bash me semble plus rapide que zsh (au lancement et à l'usage).
[^] # Re: Avantage zsh ?
Posté par peyo (site web personnel) . Évalué à 1.
:)
[^] # Re: Avantage zsh ?
Posté par yoho (site web personnel) . Évalué à 0.
[^] # Re: Avantage zsh ?
Posté par TazForEver . Évalué à 3.
zsh
find - #rien
find -n #rien
^D
bash
find -name
bon ça s'active comment cette completion qu'il y a dans bash sans rien faire ?
[^] # Re: Avantage zsh ?
Posté par Antoine Büsch . Évalué à 1.
si je ne m'abuse...
[^] # Re: Avantage zsh ?
Posté par gnujsa . Évalué à 4.
il suffit de retirer le exit 0 en début de fichier, de le recopier dans son home en .zshrc et de RTFM un p'tit peu quand même ;-)
comme pour bash:
/usr/share/doc/bash/examples/startup-files/bashrc
comme pas mal de programme d'ailleurs...
[^] # Re: Avantage zsh ?
Posté par nodens . Évalué à 1.
On notera également une amélioration majeure avec la version 3 : quand la completion contextuelle définie échoue, on retombe sur la completion classique.
C'est très utile par exemple quand on veut lire une video avec mplayer, qui n'a pas d'extension ou une extension foireuse... avant on n'avait pas de completion du tout puisque rien ne correspondait à la complétion contextuelle définie.
[^] # Re: Avantage zsh ?
Posté par Vincent ZOONEKYND . Évalué à 4.
[^] # Re: Avantage zsh ?
Posté par mickabouille . Évalué à 1.
[^] # Re: Avantage zsh ?
Posté par asailor . Évalué à 2.
Si jamais tu ne sais pas quoi taper dans ton terminal, essayes [TAB] ça te donneras peut être une idée ;o)
[^] # Re: Avantage zsh ?
Posté par Stephen Amar . Évalué à 2.
A -- append to an archive
c -- create a new archive
f -- specify archive file or device
t -- list archive contents
u -- update archive
v -- verbose output
x -- extract files from an archive
voila zsh ;)
et au niveau de la vitesse, bof bof, c'est vrai que bash est un cran plus rapide, mais pour une demi seconde hein ....
genre dans ssh, avec le parametre -l , il te sort la liste des utilisateurs sur ton poste.
[^] # Re: Avantage zsh ?
Posté par chl (site web personnel) . Évalué à 2.
Et si as configuré ssh pour ne plus avoir a tapper ton password, zsh complete aussi les fichiers de l'hote distant :
$ scp plop remote_host:/home/acetik/[TAB]
[^] # Re: Avantage zsh ?
Posté par Vincent . Évalué à 1.
[^] # Re: Avantage zsh ?
Posté par KiKouN . Évalué à 2.
Le tout étant de coder ces scripts.
[^] # Re: Avantage zsh ?
Posté par Bapt (site web personnel) . Évalué à 1.
:completion:*' hosts $_myhosts
ou alors tu compète la variable hosts
donc zsh compète aussi les hosts
deplus il gère les type mime, etc.
Le mieux c'est quand même la completion à partir d'un appel à la command genre mplyer -aoc [TAB] il appel mplayer -aoc help, le parse et t'affiche toutes les options ;)
[^] # Re: Avantage zsh ?
Posté par Stéphane Salès . Évalué à 3.
En effet je trouve bien plus pratique le système zsh "je tape le début de ma commande puis flèche haut"(et je n'ai l'historique que de *cette* commande) que le <ctrl>+<r> de bash bien moins pratique.
[^] # Re: Avantage zsh ?
Posté par tgl . Évalué à 6.
[^] # deux autres petites commandes
Posté par Jean-Max Reymond (site web personnel) . Évalué à 4.
- le raccourci ** qui veut dire tout en dessous de ce répertoire:
par exemple, echo /home/invite/**/*.pdf pour trouver tous les fichiers pdf dans l'arborescence /home/invite
- l'historique de cd.
cd -l donne une liste des répertoires précedemment visités et cd -5 va au répertoie numéroté 5
[^] # Re: Avantage zsh ?
Posté par TazForEver . Évalué à 7.
ftp://nephtys.lip6.fr/pub/unix/shells/zsh/LICENCE.gz(...)
[^] # Re: Avantage zsh ?
Posté par Bapt (site web personnel) . Évalué à 2.
http://linuxfr.org/~grom/3921.html(...)
http://linuxfr.org/2004/03/25/15827.html(...)
[^] # Puisqu'on en est aux comparaisons de shell
Posté par capicapio . Évalué à 2.
Quelqu'un aurait des nouvelles sur le gars qui avait recodé un shell à partir d'un autre... de mémoire je crois qu'il utilisait un csh pour développer un zsh.
Encore un ambitieux quoi!
# On peut voir ?
Posté par Migrec (site web personnel) . Évalué à 3.
C'est nul ? Bon ok...
[^] # Re: On peut voir ?
Posté par Antoine Büsch . Évalué à 5.
%
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.