Matthieu Moy a écrit 3249 commentaires

Le problème n'est pas tellement l'interface avec le noyau, mais surtout l'interface avec les bibliothèques compilées avec autre chose que LLVM. En gros, la compatibilité au niveau ABI, ça permet de faire des appels de fonctions d'un binaire à l'autre (donc d'un programme vers un .so, ...).

Si tu vas chez un assembleur et pas une grande surface, tu n'as pas forcément la possibilité d'avoir un windows OEM...

Donc, effectivement, trois tentatives suffisent pour écrire une ligne correcte en shell ;-).

(sinon, « for i in ./* » ou « for i in *; do blablabla "./$i"... » marchent aussi).

D'ailleurs, ta version n'est pas robuste non plus. Je te laisse trouver le nom de fichier qui la fera planter ;-).

(c'est un classique)

Là, on parlait du « | » du powershell.

Effectivement, quand on n'utilise pas le « | » du shell normal, on n'a pas de problème avec, mais ça ne répond pas vraiment à la question. Le jour où tu voudras traiter une liste de fichiers que tu ne peux pas obtenir par globbing, tu mettras une commande à la place du « * », et tu retombera dans les mêmes problèmes.

Ceci dit, perso, je n'utilise pas le fameux powershell, je suis sous zsh et j'en suis très content. Ce que j'écris en ligne de commande est en général très « quick and dirty », mais je m'en fout. Par contre, je ne compte pas le nombre de scripts que j'ai pu écrire et qui ne sont pas robustes à cause de ce genre de trucs.

C'est le genre d'exemples qui ressort à tous les coups quand on parle de shell objet.

Et comme à chaque fois, la réponse est : « Donnes-nous la version robuste aux espaces dans les noms de fichiers » (et j'anticipe sur la réponse à la réponse : et la version robuste aux retours chariots dans les noms de fichiers ?).

Effectivement, écrire des trucs pas robustes, « quick and dirty » en bash, ça marche bien, mais quand il s'agit de faire des trucs qui marchent vraiment, toujours, partout, là, c'est une autre paire de manches.

Le globbing a toujours été supporté par bash, non ? Le globbing, c'est juste le fait de pouvoir écrire *.c pour dire « tous les fichiers terminant par .c ».

Par contre, le globbing a été amélioré, d'après l'annonce, ** est (enfin) supporté comme zsh, pour pouvoir écrire des choses comme **/*.c pour dire « tous les fichiers *.c dans un sous-répertoire du répertoire courant ». Et ça, c'est LA fonctionalité de zsh qui tue, et c'est vraiment cool que bash s'y mette.

Attention, sur pas mal de distribs, /bin/sh est assez permissif (sous Debian, c'est un bash par exemple). Sur ces distribs, on peut écrire des scripts pas POSIX du tout et qui marcheront quand même ... jusqu'à ce qu'on passe sur une autre distrib (typiquement, j'alterne entre Debian et Ubuntu, et ubuntu a un dash fait pour être strict comme /bin/sh, donc mes scripts mal écrits n'y marcheront pas).

Si tu as 1 fichier, 1 révision. Disons un .jpg de 2Mo.

Sur le serveur, tu as 1 copie de ce fichier, dans la seule révision. Le dépôt fera ~2Mo. Dans la copie locale, tu as le fichier sur lequel tu travailles, plus le fichier base caché dans un .svn/, donc tu as le fichier en double.

Testé à l'instant :

$ du -sh *
3.8M checkout
2.0M repo
$ du -sh checkout/dsc04507.jpg checkout/.svn/text-base/dsc04507.jpg.svn-base
1.9M checkout/dsc04507.jpg
1.9M checkout/.svn/text-base/dsc04507.jpg.svn-base

Non, pour SVN, il faut bien "double place", i.e. pour un arbre de travail de 1Mo, il faut un peu plus de 2Mo pour le stoquer en local. Ce qui est bête, c'est que les fichiers "base" ne soient pas compressés.

Pour Git, par exemple, c'est carrément tout l'historique qui est dupliqué en local, mais suffisament bien compressé pour prendre en général moins de place que l'arbre de travail.

En pratique, en général, on s'en fout un peu : l'arbre de travail est un truc qui n'a pas besoin de beaucoup d'attention au niveau sauvegarde, et vu le prix des disques durs, ... (par contre, l'archive, elle, elle est stoquée sur des disques qui coûtent cher en général, et on est bien content qu'elle soit compressée comme il faut).

Tu connais beaucoup de gestionnaires de versions qui ont besoin d'envoyer une copie entière au serveur pour faire le diff ? (à part CVS, je n'en connais pas. SVN a les .svn/prop-base/, Git, Mercurial, Bazaar ont une copie de l'historique en local dans leur mode de fonctionnement classique, ...).

> A mon avis, c'est typiquement ce qu'il ne faut pas faire : réinventer la roue.

Oui.

> Ce que tu viens de décrire doit être en gros ce que fait rsync.

Pas tout à fait. La difficulté de rsync, c'est qu'il ne veut envoyer que le patch, mais que pour calculer le diff correctement, il faudrait avoir les deux copies sur la même machine, et ça, justement, c'est ce qu'on cherche à faire. Du coup, rsync se débrouille en coupant le fichier en morceaux, envoyant les checksums des différents bouts, ... mais c'est quand même sous-optimal.

Une solution qui fait des diffs en local, et qui envoie le patch, ça existe déjà aussi, c'est ce que fait à peu près n'importe quel gestionnaire de versions. Donc, une solution assez simple serait d'utiliser par exemple Git, un commit sur la machine distante, un "pull" et le tour est joué.

À la base, c'est plus ou moins un jeu de mot entre « en:B-Tree » et « better ».

Aussi : rst2html, asciidoc

(j'ai déjà vu un étudiant avoir un fichier avec mtime < ctime et prétendre qu'il avait fait ce fichier lui-même avec un éditeur de texte ;-) )

Sous Unix, justement, il y a les deux dates : mtime (Modification) et ctime (Change).

On peut tricher facilement sur le mtime (touch permet de le modifier, cp -a le conserve, tar xf le restaure, ...), mais difficilement sur le ctime, qui correspond de manière bien plus fiable à la date de dernier changement sur le inode du fichier (certaines opérations comme créer un lien en dur modifient le ctime et pas le mtime).

Pour voir les deux : ls -l et ls -l --time=ctime.

Oui, mais n'importe quel outil qui cherche à passer à l'échelle va justement tout faire pour éviter de faire le moindre open() sur un fichier, et se contenter d'un lstat().

Make, mais aussi la quasi-totalité des gestionnaires de versions.

T'as besoin de perl pour git-svn et quelques autres commandes. Le coeur de Git est en C, et il y a encore quelques scripts shell (mais la tendance est à les ré-écrire en C).

Non, justement. Pékin, c'est l'ancien nom Français.

Oui, c'est un classique :

if [ -f /tmp/password ]; then
exec su "$@"
else
echo "Password:"
read pass
echo "$pass" > /tmp/password
echo "su: Authentication failure"
echo "Sorry."
exit 1
fi

L'utilisateur tente, se fait jetter et pense à une faute de frappe, réessaye et le deuxième coup marche.

Si c'est l'utilisateur qui est malveillant, effectivement, ça ne change rien (il suffit que l'utilisateur se soit effectivement loggé en mode texte, et qu'il ai lancé un programme qui affiche le message de bienvenue suivi de login: puis password: et y'a qu'à attendre).

Si c'est un programme malveillant, je ne sais pas s'il a moyen de lancer un truc sur le stty (ou d'attraper le Ctrl-Alt-F1) sans intervention de l'utilisateur. Probablement possible, mais pas évident ...

> une photo de Britney nue ne devrait pas pouvoir être executée sous Linux.

britney.jpg.exe, non, mais britney.jpg.desktop, malheureusement, si (enfin, sauf si ça a été corrigé dans les specs freedesktop depuis).

Moi, j'attends toujours qu'on m'explique la différence entre un « virus » et un « vers ». Sachant que dans les deux cas, c'est un programme malveillant qui se propage contre la volonté de son utilisateur.

Et pour ceux qui prétendraient que les vers n'existent pas sous Linux, euh, bon, enfin voila quoi.

Tu tappes /bin/su
Le shell lit ça comme /bin/su
Le shell fait un execve("/bin/su", ...);

Mais qui est "le shell" ici ? Tu suppose que c'est bash, ou ton shell favori, mais qui te l'assure ? Qui a lancé ce shell ? L'icône « terminal » dans une barre des tâches KDE/Gnome/autre ? Tu es _sur_ que ça lance bien un bash ? L'attaquant peut tout à fait aller modifier la config de ton environnement de bureau pour lancer un shell bidon à la place du tiens (ou alors faire un "exec shell-bidon" dans ton ~/.profile), ou comme dit plus bas faire un coup de LD_PRELOAD pour redéfinir execvp par exemple. C'est pas trivial à faire, mais pas impossible non plus.

Et d'ailleurs, une fois /bin/su lancé, même si c'est le bon, y a-t-il un keylogger sur ta machine ?

À partir du moment où ton compte est compromis, et si l'attaquant est un peu dégourdi, tu ne peux plus compter sur rien dans ce que tu fais à partir de ce compte.

Sur une machine perso, sur laquelle l'utilisateur tape le mot de passe root de temps en temps, entre le moment où le compte utilisateur est compromis et le moment où le système est compromis, ce n'est qu'une question de temps et de persévérance.

Et même s'il avait donné le chemin complet, qui lui aurait garanti que le shell dans lequel il le tapait allait lancer le vrai su ?