Vincent ZOONEKYND a écrit 18 commentaires

Le shell propose la commande "cd -" pour retourner dans le repertoire dans lequel on etait precedemment -- mais il ne garde qu'un seul repertoire en memoire. Les commandes pushd et popd permettent de faire cela avec plusieurs repertoire, et pas necessairement le dernier. Le probleme, c'est qu'il faut prealablement empiler le repertoire dont on aura besoin plus tard -- et si on en a besoin plusieurs fois, il faut aussi le prevoir.
Certains proposent, plus simplement, d'etendre le "cd -" afin de garder les 10 derniers repertoires: http://linuxgazette.net/109/marinov.html(...)

Sur la meme ligne (on ne demande pas a ssh de lancer un shell mais un processus) :

ssh machine.fr top -bn1 | head -15

(ici, seule la commande top sera lancee sur la machine distance, head sera lance en local.)

Il y a la même chose pour TeX : D. Knuth donne une prime à chaque nouveau bug découvert, et la prime double tous les ans.
http://truetex.com/knuthchk.htm(...)
http://www-cs-faculty.stanford.edu/~knuth/abcde.html(...)

Il y a aussi des caractères génériques plus puissants, par exemple

  konqueror **/*.html

pour voir le contenu de tous les fichiers HTML dans le répertoire courrant ou dans l'un de ses sous-répertoires. Sous Bash, on pourrait taper

  konqueror `find -name "*.html"`

ou (s'il y a des fichiers avec des caractères bizarres)

  find -name "*.html" -print0 | xargs -0 konqueror

Autre exemple, quand on a tout une ribambelle de fichiers dans une arborescence compliquée, on peut vouloir les mettre tous dans un seul répertoire puis effacer les répertoires désormais vides :

  mv **/*(.) ./
  rm -rf */

Toutefois, sur de très gros répertoires, ça peut être lent. De plus, on se heurte assez vite à la taille limite de la ligne de commande. Mais ça va beaucoup plus vite à taper.

Pour des fichiers PDF, on peut simplement faire "less toto.pdf" : le fichier est aussitôt convertit en texte.

Ces problèmes de compatibilité "des" navigateurs (pourquoi un pluriel ?) obligent effectivement à utiliser des tables. Pas plus pard que la semaine dernière, on m'a demandé de faire le site Web d'une entreprise en train de se monter : j'ai commencé par écrire le contenu, sans aucune mise en forme, puis j'ai décrit la mise en forme dans une feuille de style. Sur Konqueror ou Mozilla, j'obtenais bien le résultat attendu -- mais Internet Explorer ne reconnaissant pas complètement CSS2 (j'avais un menu horizontal qui se retrouvait vertical...), j'ai du tout changer et mettre des tables.

Avec toutefois un gros problème, si je me souviens bien : les dépendances supposent que Java (le JDK) a été installé à partir des RPM de JPackage -- or, pour des raisons de licence, ces RPMs ne sont pas là : il n'y a que les RPMs sources, à partir desquels il faut construire les RPM binaires, après être allé fouiller sur le site de Sun (par exemple) pour récupérer le JDK sous une autre forme. C'était très pénible...

Sous Zsh, on peut faire encore plus court :
cat **/*.php | wc -l

Les fichiers d'Ant me semblent peu lisibles (le XML n'a pas été conçu pour être lu par des êtres humains, mais par des machines), et je crois qu'on est assez limité quand aux commandes qu'on peut lui faire exécuter (alors qu'on peut mettre quelques lignes de shell dans un Makefile).

Pour ne pas avoir à chercher le numéro du processus, on peut simplement taper : killall -USR1 X

LaTeX est beaucoup plus utilisable et lisible que MathML : ainsi, pour dire a=b, on écrit $a=b$ au lieu de <apply> <eq/><ci>a</ci> <ci>b</ci> </apply>. Je vous laisse imaginer ce que peuvent devenir des formules plus complexes... (Cela dit, il existe peut-être des éditeurs permettant de taper ce genre de chose sans trop de peine.)
Par ailleurs, les convertisseurs XML/PDF qui donnent des résultats typographiquement corrects commencent par convertir le XML en TeX, qui est ensuite compilé...
A titre d'exemple, l'année dernière j'avais converti un dictionnaire en XML vers du PostScript : LaTeX m'offrait beaucoup plus de flexibilité que FOP.
http://www.math.jussieu.fr/~zoonek/LaTeX/Dictionnaire_japonais/docu(...)

Il n'y a pas de frais d'entrée à Paypal : ils retirent un dollar sur ton compte pour vérifier que c'est bien le tiens, mais ce dollar se retrouve sur ton compte paypal. Si tu te contentes d'envoyer de l'argent, ou si tu reçois des sommes modérées, tu ne payes pas. Par contre, si tu es commerçant et si tu te fais payer par Paypal (il y en a plein sur Ebay), ils prélèvent une commission (à peu près 3%). Bien sûr, ils font aussi travailler l'argent qui reste chez eux.

150 euros pour la version pirate, c'est très cher : on doit pouvoir trouver le box chinois (6 DVDs, 11 films, probablement copiés d'après un LD) sur EBay pour 60 dollars.

Je précise : il y a des caractères chinois et japonais qui ont la même origine et se ressemblent beaucoup. Ils ne diffèrent souvent que par un seul trait ou un seul point -- mais dans ces langues, se tromper sur ce genre ce chose constitue une faute d'orthographe, un peu comme une faute d'accent en français. Si un fichier UTF8 contient une seule langue, et si on a un moyen extérieur de savoir laquelle (extension du fichier, etc.), ça ne pose pas de problème : le texte sera affiché correctement ; si le fichier contient plusieurs langues et s'il utilise un balisage indiquant clairement les changements de langue (XML ou autre), cela ne pose pas de problème non plus. Par contre, on ne peut pas imaginer de fichier "texte" multilingue en Unicode : il ne pourrait pas être affiché correctement, l'ordinateur n'ayant aucun moyen de savoir de quelle langue il s'agit.

Voici un autre format (BTPC), qui permet à la fois la compression des photos (plus efficacement qu'en JPEG) et des schémas : http://www.engr.mun.ca/~john/btpc.html(...)
(mais je ne sais pas à quel point c'est libre : l'auteur précise "No patents, free use", mais il y a par la suite quelques références à JPEG pour la gestion des couleurs).

Pour ceux qui seraient perdus dans ces listes qui s'efforcent d'être exhaustives, en voici une plus sélective, et commentée. http://freshmeat.net/articles/view/354/(...)

Il est faux d'affirmer que "L'ajout de l'entrée TeX/LateX ne pose pas, a priori, de problème puisque si ces langages sont utilisés correctement, on a déjà un document structuré".

Car quelqu'un qui utilise TeX correctement risque de ne pas adopter la structure "standard" d'un document LaTeX, par exemple en redéfinissant certaines des macros couremment utilisées pour le structurer. Il existe de nombreux programmes pour convertir du LaTeX en HTML : aucun ne marche sur mes fichiers.

Le logiciel de conversion le plus satisfaisant (pour les gens autour de moi) est tex4ht (http://www.cis.ohio-state.edu/~gurari/TeX4ht/mn.html(...) ). Je crois qu'il peut aussi produire du XML avec MathML.

Le LaTeX japonais, ce n'est pas du tout latex+CJK. Ils ont une distribution de LaTeX bien à eux (jtex), avec des classes bien à eux (jarticle, jbook) complètement inconnues en occident, et même absente des archives CTAN. Pour avoir essayé, je peux dire que leurs fichiers LaTeX sont incompilables chez nous.