Sur n'importe quel OS orienté utilisateur normal et pas orienté gourou barbu autiste, tu appuis sur une touche et ça recompile ce qu'il faut, sans faire un makemachin.
Les EDI ça existe aussi sous UNIX, tu sais ?
Accessoirement, il n'y a guère que sur les systèmes UNIX que tu as une chance de trouver un compilateur installé par défaut.
Sinon, pour revenir un peu sur le fond de ton argumentaire :
- shells merdiques incompatibles les uns avec les autres, sémantique de ' vs " vs $ incompréhensible, splitting incompréhensible, les gens qui disent que c'est simple en général n'y comprennent RIEN
Quoique tu puisses en penser, la variété des shells disponibles fait partie des avantages du système.
Le choix est laissé à l'utilisateur d'utiliser celui qui lui convient le mieux, tant du point de vue ergonomie que fonctionnalités.
Même si ça induit de fait des incompatibilités, c'est toujours mieux que ne pas avoir de choix et devoir subir un truc comme cmd.exe.
Produire des scripts shell portables d'un système à l'autre, ça nécessite un effort intellectuel, mais c'est tout à fait possible.
La plupart de ceux que j'écrivais il y a une dizaine d'années fonctionnaient de la même manière sous Linux, Solaris, AIX et UnixWare.
Je devais juste m'assurer qu'il sache sur quel système il tournait, et d'utiliser les commandes et options adéquates.
- philosophie moisie des outils en ligne commande qui font une chose et qui la font bien mais qui ne marche jamais
Si ça ne marchait jamais, ces outils auraient été abandonnés depuis bien longtemps.
- utilitaires moisies qu'on n'arrive pas à combiner
Comme ?
- scripts moisis qui se chient dessus dès qu'un nom de fichier contient caractère aussi bizarre qu'un espace (for x in *)
Mauvais développeur(s) ?
seb@gaston:~/tmp$ cat ../test
#!/bin/sh
for x in *
do
echo "x=\"$x\""
done
seb@gaston:~/tmp$ ../test
x="fichier
avec retour chariot"
x="fichier avec espace"
x="fichier_normal"
- traitement de groupe de fichiers qui ne sont pas robustes (quels que soient les caractères des noms de fichier) qu'avec les extensions GNU à find et xargs
C'est un vrai problème quand on multiplie les tubes et qu'on traite des fichiers contenant des espaces dans leurs noms, mais il y a de nombreux moyens de le contourner, même sans faire appel aux outils GNU.
- le moindre traitement très simple de fichiers demande une super ligne de commande contenant une dizaines de commandes différentes
Comme par exemple ?
- 36 syntaxes différentes selon les utilitaires
Tous les utilitaires classiques peuvent être appelés en utilisant leur variante POSIX.
Dans ce cas, la syntaxe et les résultats sont identiques partout.
- énormèment d'implicites qui rendent l'apprentissage plus difficile
De quelle nature ?
Et plus difficile que quoi ?
- univers impénétrable réservé aux gourous
Uniquement à ceux qui sont barbus et autistes.
Quand tu n'es ni gourou, ni barbu, ni autiste, comme moi, tu ne peux à l'évidence rien y comprendre.
- difficulté extrême à rendre robuste un executable SUID
J'ai trouvé 16 exécutables avec le bit SUID positionné sur ma machine (sur un total de 2426 exécutables).
Ce n'est donc pas comme si cette problématique de sécurité, par ailleurs largement documentée, concernait le premier développeur venu.
Les autres savent normalement comment gérer l'affaire au niveau de leur code.
- sémantique Unix de open qui ne permet même pas d'ouvrir un fichier seulement s'il est ordinaire
Parce que c'est si compliqué que ça de le tester par toi même avant de chercher à l'ouvrir ?
Tu cherches vraiment la petite bête là.
- merdicité extrême de make (je vous mets au défi d'écrire un makefile faisant correctement ce que fait automatiquement n'importe quel compilateur intégré à la base : recompiler ce qu'il faut recompiler - même avec les extensions GNU)
Ça faisait 10 ans que je n'avais plus touché de Makefile ou de code C, et il m'a fallu 10 minutes pour écrire cette beauté :
seb@gaston:~/tmp$ cat main.c
#include "defs.h"
#include "hello.h"
void main( int argc, char *argv[] )
{
Hello(WORLD);
}
seb@gaston:~/tmp$ cat hello.c
#include <stdio.h>
#include "defs.h"
#include "hello.h"
void Hello( char *msg )
{
printf( "%s, %s.\n", HELLO, msg );
}
seb@gaston:~/tmp$ cat hello.h
void Hello( char *msg );
seb@gaston:~/tmp$ cat defs.h
#define HELLO "Hello"
#define WORLD "world"
seb@gaston:~/tmp$ cat Makefile
all: hello
hello: hello.o main.o
cc hello.o main.o -o hello
hello.o: hello.c hello.h defs.h
cc -c hello.c -o hello.o
main.o: main.c hello.h defs.h
cc -c main.c -o main.o
clean:
rm -f hello *.o
seb@gaston:~/tmp$ make
cc -c hello.c -o hello.o
cc -c main.c -o main.o
cc hello.o main.o -o hello
seb@gaston:~/tmp$ ./hello
Hello, world.
seb@gaston:~/tmp$ vi hello.c
seb@gaston:~/tmp$ make
cc -c hello.c -o hello.o
cc hello.o main.o -o hello
seb@gaston:~/tmp$ ./hello
Hello, world!
seb@gaston:~/tmp$ vi defs.h
seb@gaston:~/tmp$ make
cc -c hello.c -o hello.o
cc -c main.c -o main.o
cc hello.o main.o -o hello
seb@gaston:~/tmp$ ./hello
lol, corrector!
- discours prétentieux sur la séparation du noyau et des logiciels alors qu'un composant monstrueux comme X a accès à tout
Je ne comprends pas cette remarque, car X n'a accès qu'à ce que le noyau veut bien lui monter.