Mais si tu devais réécrire sudo ou autre outil de ce style, je suis pas convaincu que le C serait le language le plus adapté.
Il l’est. Fondamentalement les outils Unix, le shell, et le C ont été pensé de concert pour fournir un environnement intégré (il y a souvent bijectivité entre les appels shell et les appels C). C’est sous Unix que le C révèle sa puissance (donc pas de bloatware, E/S au format texte, en ligne et facilement parsable, minimalisme, généricitié, orthogonalité, transparence).
À titre d’exemple, je suis en train d’écrire quelques petits utilitaires, dont rsu en ~1 journée à temps plein (un genre d’opposé à sudo : il diminue les privilèges d’un processus — j’espère bien pouvoir publier ma petite collection sur linuxfr un de ces jours) :
~ wc prog/rsu/rsu.c
1123172173 ~/prog/rsu/rsu.c
C’est tout riquiqui
~ man rsu
RSU(1) General Commands Manual RSU(1)
NAME
rsu – execute a command under restricted permissions
SYNOPSIS
rsu [-l res:limit] [-n nice] [-u mask] [NAME=VALUE ...] USER /CMD
[ARGS ...]
DESCRIPTION
rsu allows to set permissions, resource limits, niceness, environment,
and user of an executable called from root, without the overload of a
full shell interpreter.
The options are as follows:
-l res:limit
Set hard and soft limit of a resource identified by a number as
found in /usr/include/bits/resource.h, see getrlimit(2) for
documentation. This replaces the ulimit shell builtin. Can be
repeated.
-n nice
Increment sheduling priority (aka niceness).
-u mask
This replaces the umask shell builtin, ie. file mode creation
mask.
[NAME=VALUE ...]
A list of environment variables with their assigned value. The
format is not checked, passed as is.
USER The user who execute the command, appropriate groups are set
according to /etc/group.
/CMD An absolute path to an executable.
[ARGS ...]
Arguments for the called executable.
Même pas en rêve je fais ça dans un autre langage... Et à la base j’ai juste des connaissances de base du C (je montre pas le code d’ailleurs... y’a même des goto à l’ancienne) et je me suis lancé après lecture de The Art of UNIX Programming, avec à mon chevet The Linux Programming Interface, man 3p ... est devenu mon ami aussi.
Mais par exemple parser /etc/group. En C ça se fait très bien, parce que c’est un bête fichier tabulé (de fait mon code se résume à un strstr puis strtol pour avoir l’uid/gid de l’utilisateur, et pour des choses plus complexes l’approche traditionnelle est de passer par lex/yacc). En mode moderne, on aurait sorti un bazooka json-over-xml-over-transparentNetwork-over-sqldatabase avec minimum trois couches d’abstraction (j’exagère ?) pour storer le bousin...
La programmation en C d’outils pur Unix est plutôt agréable. C’est beaucoup de lecture, peu d’écriture. Ça peut être frustrant de ne pas pisser de la ligne de code, mais au final le résultat est là quand on prend bien le pli Unix.
Perso j’apprécie énormément cette manière de bosser. Le truc, c’est que c’est peu compatible avec un travail en entreprise dans l’ambiance ultra-autoritaire actuelle, il faut bien le dire, parce que cette semaine on a rien produit parce que lecture de n00 pages de doc mini... Non il faut juste montrer qu’on a pissé du code ou autre pour satisfaire la hiérarchie, il vaut mieux écrire 1000 lignes de codes qui seront caduques dans 6 mois plutôt que 100 lignes qui dureront 30 ans.
Le seul truc un peu relou, ce sont les tests de retours des fonctions (absence de mécanismes d’exceptions).
Pour ma part j’apprécie la rigueur de la documentation et la stabilité du bousin. Une méthode de travail qui manque à beaucoup (traumatisé par le passage de python 2 à 3 et par des collègues dont les bidouilles dégueulasses et non documentées se transforment en autant de peau de banane pour les autres...).
Et puis si le C est toujours là, c’est parce qu’en vrai, on n’a rien inventé de bien nouveau depuis en informatique... conceptuellement parlant. Les soit-disante innovations sont souvent des solutions à des problèmes que les ingénieurs se sont créés eux-mêmes (je te vois http1, 2, 3, je te vois...).
[^] # Re: Survivor
Posté par PR . En réponse au journal C, un âge remarquable. Évalué à 10.
Il l’est. Fondamentalement les outils Unix, le shell, et le C ont été pensé de concert pour fournir un environnement intégré (il y a souvent bijectivité entre les appels shell et les appels C). C’est sous Unix que le C révèle sa puissance (donc pas de bloatware, E/S au format texte, en ligne et facilement parsable, minimalisme, généricitié, orthogonalité, transparence).
À titre d’exemple, je suis en train d’écrire quelques petits utilitaires, dont rsu en ~1 journée à temps plein (un genre d’opposé à sudo : il diminue les privilèges d’un processus — j’espère bien pouvoir publier ma petite collection sur linuxfr un de ces jours) :
C’est tout riquiqui
Même pas en rêve je fais ça dans un autre langage... Et à la base j’ai juste des connaissances de base du C (je montre pas le code d’ailleurs... y’a même des goto à l’ancienne) et je me suis lancé après lecture de The Art of UNIX Programming, avec à mon chevet The Linux Programming Interface,
man 3p ...est devenu mon ami aussi.Mais par exemple parser /etc/group. En C ça se fait très bien, parce que c’est un bête fichier tabulé (de fait mon code se résume à un strstr puis strtol pour avoir l’uid/gid de l’utilisateur, et pour des choses plus complexes l’approche traditionnelle est de passer par lex/yacc). En mode moderne, on aurait sorti un bazooka json-over-xml-over-transparentNetwork-over-sqldatabase avec minimum trois couches d’abstraction (j’exagère ?) pour storer le bousin...
La programmation en C d’outils pur Unix est plutôt agréable. C’est beaucoup de lecture, peu d’écriture. Ça peut être frustrant de ne pas pisser de la ligne de code, mais au final le résultat est là quand on prend bien le pli Unix.
Perso j’apprécie énormément cette manière de bosser. Le truc, c’est que c’est peu compatible avec un travail en entreprise dans l’ambiance ultra-autoritaire actuelle, il faut bien le dire, parce que cette semaine on a rien produit parce que lecture de n00 pages de doc mini... Non il faut juste montrer qu’on a pissé du code ou autre pour satisfaire la hiérarchie, il vaut mieux écrire 1000 lignes de codes qui seront caduques dans 6 mois plutôt que 100 lignes qui dureront 30 ans.
Le seul truc un peu relou, ce sont les tests de retours des fonctions (absence de mécanismes d’exceptions).
Pour ma part j’apprécie la rigueur de la documentation et la stabilité du bousin. Une méthode de travail qui manque à beaucoup (traumatisé par le passage de python 2 à 3 et par des collègues dont les bidouilles dégueulasses et non documentées se transforment en autant de peau de banane pour les autres...).
Et puis si le C est toujours là, c’est parce qu’en vrai, on n’a rien inventé de bien nouveau depuis en informatique... conceptuellement parlant. Les soit-disante innovations sont souvent des solutions à des problèmes que les ingénieurs se sont créés eux-mêmes (je te vois http1, 2, 3, je te vois...).
Mort aux cons !