castorpilot a écrit 98 commentaires

En effet, ce que tu decris est probablement la principale raison qui pousse beaucoup d'entre nous à utiliser un autre langage que le shell pour des programmes "plus gros".

Pour ce qui est des autres shells, il me semble que zsh a la pretention de permettre de faire un peu plus de chose, de proposer plus de fonctionnalités pour les scripts, mais personnellement, je ne depasserais pas une vingtaines de lignes.
Il y a aussi BashDiff, qui rajoute des trucs sur bash, mais, euh, ça me fait peur :)

Ensuite, ben il vaut mieux se tourner vers un langage de script, comme ceux que tu mentionnes : Perl, Python, Ruby sont les plus utilisé.

Il y a aussi PHP (mais je pense que c'est surtout utilisé pour le web), Lua, TCL, ... (Il doit y en avoir des centaines !)

Pour ce qui est du C, des compilo rapides comme tcc permettent de l'utiliser comme langage de script, j'ai meme vu des "interpreteurs" de C qui proposaient une sorte de C amélioré comme langage de script. Mais franchement, ça ne me semble pas pratique, vu qu'en general, il faut pas mal de ligne de C pour avoir l'equivalent fonctionnel d'une ligne de script.

Personnellement, apres avoir utilisé/essayé plusieurs langages, j'utilise plutot Ruby. C'est evidemment une affaire de gout, et les autres langages sont tout aussi valables.
Donc en gros, pour quelques lignes, voire pour faire un one-liner direct au prompt, c'est bash, mais des que ça devient "compliqué", je le fais en Ruby. Le bonus, c'est qu'avec ces langages, on a directement acces à des librairies reseau, XML, graphiques, ....

Désolé, je ne connais pas assez bien ta distribution pour répondre si, comme tu l'as écrit, tu n'as pas trouvé de paquets. En revanche, il reste toujours possible de les compiler toi meme à partir des sources (probablement disponibles sur le web), en utilisant -m32

pour les erreurs avec la compilation en 32 bits, c'est bien un probleme d'incompatibilité :

/usr/bin/ld: skipping incompatible /usr/bin/../lib/libGLEW.so when searching for -lGLEW

En gros, tu libGLEW.so est en 64 bits, donc ld ne peut pas l'utiliser pour linker sur du code 32 bits.

Sinon, question bete, tu fais un make clean entre tes essais ? Pour ne pas te retrouver avec certains .o en 32 bits, d'autres en 64 ...

var1=n;until [ ${var1:-O} = "O" ]; do echo -n "Alors ? "; read var1;done

Voila en vite fait degueux.

O ou rien : arret de la boucle
Toute autre reponse (y compris n) : ça recommence à poser la question

J'ai peur de ne pas comprendre vraiment le but du script.
En gros, tant que la personne ne tape pas "n" (CONDITION FINALE), tu lui reposes la question ?
Est ce que tu ne voudrais pas plutot :

- poser la question
- faire comme si une response vide valait "O"
- reposer la question si ce n'est ni "n" ni "O" qui est tapé

Si c'est le cas, et comme tu utilises bash, tu peux regarder du coté des substitutions de variables ${variable:-default} : si variable n'est pas definie ou si elle est vide, alors on utilise la valeur par defaut. Ici, on peut utiliser

read reponse
echo ${reponse:-Oui}

qui vaudra Oui si l'utilisateur tape juste sur Entrée.

read var1 (sans le $).

Pas par magie, mais c'est en effet un "thread dd'assistance". D'apres l'article :

"This scout thread (ST) is a hardware entity that's totally invisible to the operating system, hypervisor, or whatever else has control of the processor, and in the course of execution it predicts and resolves branches, prefetches code and data, and saves its speculative state in a shadow register file."

@khivapia: ton avis personnel ressemblerait plus à du VLIW non ?

Ben deja, il me semble, la transparence.
Apparement, les threads du Rock sont completement transparents pour le programmeur. Ils sont crées par le processeur directement. Donc un programme "classique" devrait pouvoir en beneficier.
Pour le SMT, si je me souviens bien, il faut quand meme explicitement avoir 2 threads au départ.

Y'a quand meme surtout un probleme au niveau des pilotes de cartes graphiques non ?

Je vois un petit peu mieux de quoi il s'agit. Au risque de dire un truc bete, pourquoi ne pas utiliser des threads au lieu de forker ?
L'avantage, c'est que les threads partagent la memoire, et que tu pourras utiliser ton tableau commun, contrairement au processus qui ont chacuns leur zone mémoire séparée, et donc les pointeurs de l'un ne sont pas valides chez l'autre.
Il faut quand meme faire gaffe aux acces concurrents, avec des semaphores (sem_wait et sem_post autour des acces).

Je ne sais pas si tu as déjà regardé, mais tout ça est dans man IPC (puis man shmget, man semget, ...).

Je ne suis pas sur d'avoir bien compris ce que tu voulais faire, mais l'idée serait d'avoir une zone de mémoire partagée (shm). C'est le pere qui la crée (avec shmget).

Puis chaque processus peut lire/ecrire dans cette zone (regarde man shmop).

Pour eviter les probleme d'acces concurrent, tu fais passer tous les acces à cette zone par un semaphore unique (man semget / semop, ou alors les semaphores POSIX, man 7 sem_overview). Par exemple, les acces seront du genre :

sem_wait
READ or WRITE
sem_post

Voila, c'est super vague, mais je sais pas trop ce que tu cherches à faire. Il me semble aussi que n'importe quel bouquin/tutorial sur la programmation système unix explique toutes ces notions en détail.

Super !
J'avais trouvé declare -p $1 | IFS='=' egrep -o '\[(:digit:+)\]' pour lister les index, mais evidemment, ta solution est bien mieux :)

Merci

Vu la syntaxe un peu maladroite de ton message, je présume que tu ne sais pas vraiment ce qu'est un 'script shell en linux'. Le mieux, avant de vouloir en ecrire un, serait peut etre d'apprendre :

1) ce qu'est un shell
2) ce qu'est un script
3) ce qu'est linux

Nul besoin d'etre expert dans ces domaines pour ecrire un script, mais il faut quand meme avoir une vague idée de ce que ça veut dire.
Il y a un paquet de documentation sur chacun de ces sujets : (une recherche très rapide me donne)

pour le shell http://lea-linux.org/cached/index/Admin-admin_env-shell.html#

pour linux http://lea-linux.org/cached/index/Intro-index.html#

pour le script http://lea-linux.org/cached/index/Dev-shell_script.html#

Evidemment, il y a plein d'autres sites qui expliquent tout ça.
Bon courage

C'est en partie expliqué dans man 3 daemon non ?

pour la prog, j'utilise maintenant Sun Studio (ou netbeans). Avec le plugin jvi (jvi.sourceforge.org). Tu as quasiment toutes les fonctionnalités de vi, plus un vrai IDE derrière.
Pratique ...

peut etre qu'avec ulimit et les options -m ou -d, tu peux approximer ce comportement. De toute façon, il n'est pas possible de lancer un processus completement en SWAP. Si le processus tourne, il y aura forcement une partie en RAM.
Ce que je ne sais pas, c'est si ulimit permet de differencier la RAM et la SWAP, ou si on parle juste de "memoire".

Avec un peu de bol, tu as l'entrée /proc/config.gz, qui contient la config de ton noyau.

Je ne sais pas si cette information est toujours valable, mais j'avais lu il y a un moment sur un forum que le modem Numericable opérait un filtrage MAC.
En gros, le périphérique qui y étais branché lors de l'allumage était reconnu, mais pas ceux qui étaient branchés ensuite "à chaud". Pour vérifier, tu pourrais essayer de debrancher le modem, brancher le portable au modem, rebrancher le modem.

Si c'est bien le cas, alors la solution du routeur (environ 30 euros) pourrait s'averer pratique (avec en plus la possibilité du Wifi).

Ok, je corrige juste une faute de frappe (un $ en trop)

ps -eo user,pcpu,pmem | tail -n +2 | awk '{num[$1]++; cpu[$1] += $2; mem[$1] += $3} END{printf("NPROC\tUSER\tCPU\tMEM\n"); for (user in cpu) printf("%d\t%s\t%.2f%\t%.2f%\n",num[user], user, cpu[user], mem[user]) }'

Au temps pour moi, j'avais mal compris le sens de "agréger". En effet, bien pratique ce prstat ...
Je ne vois pas d'autre moyen qu'une ligne du genre

ps -eo user,pcpu,pmem | tail -n +2 | awk '{num[$1]++; cpu[$1] += $2; mem[$1] += $3} END{printf("NPROC\tUSER\tCPU\tMEM\n"); for (user in cpu) printf("%d\t%s\t%.2f%\t%.2f%\n",num[user], user, $cpu[user], mem[user]) }'

Si quelqu'un a une meilleure idée (sans script) .

Sinon, avec top, en jouant avec les touches < et >, on doit également pouvoir retrouver ce comportement.

(reponse un peu à coté de la plaque)
La commande htop, en plus d'etre jolie avec tout plein de couleurs, permet de faire un "sort by user".

Sun Studio marche pas trop mal pour ça. Et avec le plugin jvi (jvi.sourceforge.net), on retrouve l'ergonomie vi (pour ceux qui aiment).