wismerhill a écrit 2605 commentaires

Comme je ne prévoit pas de faire un shell intéractif (le langage jam ne s'y prete pas bien je pense, trop d'espaces), je vais passer sur la completion.

Si ton truc n'est pas interractif alors ce n'est pas un shell, c'est juste un language de script de plus.

Microsoft a payé plusieurs hébergeurs pour migrer de IIS vers Apache.

Tu voulais dire le contraire j'imagine.

C'est vrai que les aveugles on en a rien à foutre hein, ils ont qu'a avoir des tablettes braille qui supportent le javascript.
Et les personnes déficientes moteur n'ont qu'à apprendre à pointer avec la langue, la navigation au clavier c'est un truc du siècle dernier!

Aucune chance:
Si c'est un gros pays les lobby des constructeurs empêcherons qu'une telle loi passe, si c'est un petit pays qui arrive à le faire passer plus ou moins de force, ben les multi-nationnales arrêterons tout simplement de vendre dans ce pays et ils n'obtiendront plus aucune innovation et se rétracteront vite.
Ça pourrait marcher si un truc du niveau de l'union européenne décidait ça, mais quand on voit comment ça évolue pour les brevets il y a de quoi être pessimiste :-(

Ben, à la place du -ne

while [ "$comp" == "$ident" ] ; do

> l'erreur est "integer expression expected"

-ne est un opérateur arithmétique, et "ident" n'est pas un nombre.
Si tu veux comparer deux cahînes de caractères, il faut utiliser == (ou simplement = si tu veux être POSIX compliant).

Pas du tout, comme dit plus haut, recompile ton noyau et active l'option CONFIG_HIGHMEM64G. J'ai déjà fait une installation en 32 bits d'un serveur avec 8Go de RAM et avec cette option activée toute la RAM est disponible.

Supprimer un fichier (un répertoire est un fichier) dépend des droits sur le répertoire qui le contient (sauf si le sticky bit est utilisé). Donc si tes utilisateurs n'ont pas le droit d'écriture sur le répertoire qui contient ton répertoire commun il ne pourront pas le supprimer.

Il y a un paquet d'histoires dans le genre sur ce site, avec une nouvelle presque chaque jour:
http://worsethanfailure.com/

Ça remonte le moral sur ses propres compétences ;-)

C'était très lent dans la 2007.0, il faut dire qu'ils avaient alors fait une grosse réécriture de leur rpmdrake (l'ancienne version était d'ailleurs fournie). Mais la vitesse s'est considérablement améliorée dans la 2007.1 (au jugé c'était de l'ordre de 4 ou 5 fois plus rapide), et je le trouve encore légèrement plus rapide dans cette 2008.0.

Mandriva est et a toujours été basée sur urpmi.
urpmi est écrit en perl (ce qui est assez fréquent pour des outils système).

Mais ça ne donne pas le même résultat.
Le "while read" va te lire l'entrée standard ligne par ligne, alors que ton "for in cat" lit mot pas mot (au sens du shell).
Pour avoir le même résultat il faut combiner un while et un for:

while read line;do
for i in line;do
#stuff
done
done < toto

Il y avait des problèmes de résolution de dépendance dans la 2007.0 si on mélangeait les sources i586 et x86_64, mais je peux dire d'expérience que ça fonctionne bien sur la 2007.1.

http://openjdk.java.net/
http://iced-tea.org/wiki/Main_Page

Pour dogmazic c'est juste du contenu audio sur le DVD.
Pour geexbox il faut le choisir au démarrage.

Essaye mplayer avec l'option -dumpstream (cf man mplayer)

Permettez-moi de jouer mon inculte: C'est quoi un cube dans ce contexte?
(moi je ne connais que la figure géométrique)

Les calques de Gimp peuvent aussi être filtrants, dans la boîte à outil des calques c'est la combobox mode.
Pareil pour les scripts, beaucoup des outils de gimp sont écrit dans des langages de script externes.
Et dans les deux cas ça existe depuis avant la version 2.

Il s'appelle comment le paquet de icedtea dans la cooker?
Je ne vois pas de paquet de ce nom-là.

Va plutôt voir de ce côté-là
http://easyurpmi.zarb.org/
pour ajouter des source supplémentaires.

Regarde du côté de keychain (http://www.gentoo.org/proj/en/keychain/ ) c'est fait exactement pour ça.

Non, chez moi (sur plusieurs ordinateurs différents) les mails sont dans ~/.Mail et seule la configuration de kmail se trouve dans le ~/.kde

(Sauf parfois, hélas, les "cheats" obligatoires pour avoir le même affichage sous IE que les autres)

C'est bien le problème (je le vois au boulot aussi), c'est de vouloir que ça s'affiche de la même façon dans tous les navigateurs (enfin, quelques dominants) alors que le HTML n'avait pas été fait pour ça. Il faudrait se contenter que ça s'affiche bien dans la plupart des navigateurs et ne pas essayer de faire des interfaces au pixel près.

Avec l'inode (un peu plus haut) tu n'étais pas loin d'une solution: Plutôt que de renommer tes fichiers, fais des liens physiques (ln sans le -s), ensuite, rsync avec l'option -H va préserver à l'autre bout ces liens physiques (donc normalement juste création du lien, pas de nouveau transfert) ensuite tu n'a plus qu'à supprimer les anciens noms des fichiers (que tu peux avoir stocké dans un fichier pour faire plus simple) et re-rsync avec l'option --delete pour supprimer à l'autre bout. PS: je n'ai pas testé, rsync ne se comporte peut-être pas aussi bien que je le suppose ici vis-à-vis des liens physiques.

Et oui, c'est un résultat empirique qui ne peut pas vraiment être prouvé.

Ce n'est donc pas un théorème mais un principe.

cf http://fr.wikipedia.org/wiki/Theoreme et http://fr.wikipedia.org/wiki/Principe_physique