Journal Challenge: Écrire la plus petite implémentation de /bin/true

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
54
7
avr.
2022

Bonjour Nal,

/bin/true est un programme qui ne fait rien et retourne le code de sortie 0.

Par exemple, en C :

int main() {
    return 0;
}

Si on compile ce dernier avec la commande suivante:

$ gcc true.c -o true
$ wc -c true
16464
$ ./true && echo $?
0

On obtient un binaire d'environ 16kb.

Si on pousse plus loin avec la version assembleur:

bits 64
global _start
section .text

_start:
  mov eax, 1  ; exit syscall
  mov ebx, 0  ; exit code
  int 0x80

Après compilation :

$ nasm -felf64 true.asm -o true.o
$ ld -s true.o -o true
$ wc -c true
4320
$ ./true && echo $?
0

On obtient un binaire d'environ 4kb. Il y a du progrès !

Mais vous ne battrez jamais cette implémentation qui produit un binaire de 0 octets :

$ touch true
$ chmod +x true
$ wc -c true
0
$ ./true && echo $?
0

  • # Fun fact

    Posté par  (site web personnel) . Évalué à 10.

    En plus d'être un binaire, c'est également un script python, nodeJS, bash, … :

    $ python ./true && echo $?
0
$ bash ./true && echo $?
0
$ node ./true && echo $?
0

    Si ça c'est pas de la portabilité !!

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

    • [^] # Re: Fun fact

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      La vérité ne vaut pas un clou… c'est nul :-D

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Fun fact

        Posté par  (site web personnel) . Évalué à 10.

        La vérité c'est qu'on a enfin un programme sans bug, vu qu'il n'y a pas de code source

        https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Et le code source il fait quoi ?

    Posté par  (Mastodon) . Évalué à 10. Dernière modification le 07 avril 2022 à 08:36.

    Du coup par curiosité je suis allé voir le code source du GNU true : quel bordel !

    Alors déjà c'est amusant parce que le même code source fait true et false : allez voir le code source de false.

    Ensuite ce qui coûte beaucoup c'est la simple gestion des quelques options style --help et l'affichage sur stdout qui va avec. D'ailleurs je ne comprends pas la différence entre printf() et fputs(stdout).

    Quelqu'un a une idée ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Et le code source il fait quoi ?

      Posté par  (site web personnel) . Évalué à 7.

      fputs affiche une chaîne de caractères là où printf formatte la chaîne (%s et compagnie) avant de l'afficher.

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: Et le code source il fait quoi ?

        Posté par  . Évalué à 6. Dernière modification le 07 avril 2022 à 08:41.

        fputs ajoute également un retour à la ligne automatiquement.

        • [^] # Re: Et le code source il fait quoi ?

          Posté par  (site web personnel) . Évalué à 9.

          fputs ajoute également un retour à la ligne automatiquement.

          Euh… Non. la chaîne en paramètre, par exemple HELP_OPTION_DESCRIPTION a un retour à la ligne parce que…

          "fputs does not write additional characters, while puts appends a newline character at the end automatically."
          (source)

          (à quel niveau de n'importe quoi de détail on est la? :) )

          • [^] # Re: Et le code source il fait quoi ?

            Posté par  . Évalué à 6. Dernière modification le 07 avril 2022 à 10:27.

            Ah oui, effectivement, c'est bien puts qui ajoute un caractère de fin de ligne et pas fputs. Vu qu'on comparait printf et fputs je me suis mélangé les pinceaux.. (et il y a aussi fprintf)

            dans le man puts:

            fputs() writes the string s to stream, without its terminating null byte ('\0').

            puts() writes the string s and a trailing newline to stdout.

            • [^] # Re: Et le code source il fait quoi ?

              Posté par  . Évalué à 0.

              C’est pour ça qu’on aime la libc, ce petit côté sadique¹ de ses rédacteurs pour pouvoir balancer du RTFM aux newbies.

              Dans le même genre tu as les codes retour des fonctions, ou l’ordre des arguments de fputs & fprintf.

              —
              ¹ En vrai c’est probablement une question de compatibilité ascendante.

              Mort aux cons !

              • [^] # Re: Et le code source il fait quoi ?

                Posté par  (site web personnel, Mastodon) . Évalué à 0.

                C'est pourtant un classique qu'on trouve un peu partout. Quand j'ai commencé le Pascal par exemple, j'ai appris les couples write/writeln et read/readln et je n'ai jamais trouvé ça sadique.

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                • [^] # Re: Et le code source il fait quoi ?

                  Posté par  (site web personnel) . Évalué à 6. Dernière modification le 07 avril 2022 à 22:04.

                  Le sadisme est dans le nommage, ton exemple est donc hors sujet ("écrit" et "écrit une ligne", ça se comprend que l'un a une notion de ligne et pas l'autre et que sinon c'est pareil, "affiche dans un fichier" et "dans un fichier pousse une chaîne de caractère" on n'a ni la notion de ligne ni la notion de similitude).

                  Et OK il y a besoin de compatibilité mais on pourrait avoir une API propre et l'ancien pour la compatibilité. Le C/C++ a des avantage de pérennité mais excuse pour ne pas évoluer non plus…

            • [^] # Re: Et le code source il fait quoi ?

              Posté par  . Évalué à 4.

              Fun fact: GCC remplace un appel à printf() par un appel à puts() lorsque la chaîne de format n'est constituée que de caractères sans élément de formatage et se termine par un '\n'. Optimisations actives s'entend.

              • [^] # Re: Et le code source il fait quoi ?

                Posté par  (Mastodon) . Évalué à 5. Dernière modification le 07 avril 2022 à 22:49.

                Oui, c'est à dire que dans ce cas, écrire printf("%s", str) est un peu comme cat file | grep toto : c'est bien, mais peut mieux faire.

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                • [^] # Re: Et le code source il fait quoi ?

                  Posté par  . Évalué à 1.

                  Sauf que si on fait juste printf(str) et qu'on sait pas trop d'où vient str… on prends des risques avec la stack !

                  • [^] # Re: Et le code source il fait quoi ?

                    Posté par  (Mastodon) . Évalué à 3. Dernière modification le 11 avril 2022 à 07:40.

                    Si tu vas par là, tu prends aussi un risque avec printf("%s", str) : si ta string n'est pas correctement formatée (terminaison par \0), tu vas aller lire la RAM jusqu'à ce que ça pète (ou qu'on trouve un \0 par chance).

                    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                    • [^] # Re: Et le code source il fait quoi ?

                      Posté par  . Évalué à 3.

                      Disons que la question du \0 se pose pour n'importe quelle fonction C qui manipule des char* sans taille explicite. L'histoire de la chaine accidentellement formatée passée à printf est un problème de plus à penser. Heureusement, les compilateurs avertissent.

              • [^] # Re: Et le code source il fait quoi ?

                Posté par  (site web personnel) . Évalué à 2.

                La chaîne de caractères du source oui. Mais si c'est traduit…

                bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);

                Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

                • [^] # Re: Et le code source il fait quoi ?

                  Posté par  (site web personnel) . Évalué à 3.

                  On parle de remplacer printf par puts quand il s'agit d'une chaine littérale, rien à voir avec gettext puisque c'est complètement déterminé à l'exécution.

                  git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Et le code source il fait quoi ?

      Posté par  (site web personnel) . Évalué à 4.

      D'ailleurs je ne comprends pas la différence entre printf() et fputs(stdout).

      fputs est plus rapide (ne regarde pas la chaine de caractère fournie et la balance directement à la sortie), mais ne formate pas en fonction de options dans la chaîne de caractères, ce que fait printf.

      Et comme ils veulent réutiliser USAGE_BUILTIN_WARNING, une chaîne générique qui a une option (le nom du programme), ils ne s'emmerdent pas et plutôt que de stocker statiquement la chaîne qui ne changera jamais il l'adapte dynamiquement à chaque appel (oui, si on regarde l'écologie à l’électron près on bouffe un peu de CPU pour rien à refaire toujours le même calcul; mais c'est déjà bien de en as appeler printf quand on sait que pas d'option dans la chaîne de caractères).

      • [^] # Re: Et le code source il fait quoi ?

        Posté par  (Mastodon) . Évalué à 3. Dernière modification le 07 avril 2022 à 08:43.

        Clair, merci à tous les deux trois !

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Et le code source il fait quoi ?

        Posté par  (Mastodon) . Évalué à 5. Dernière modification le 07 avril 2022 à 08:40.

        Hop un petit lien sur l'écriture des coreutils.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Et le code source il fait quoi ?

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Mon préféré c'est l'implémentation de "yes" dans les coreutils.

          Ce programme doit juste envoyer des 'y' sur la sortie standard. L'implémentation triviale ressemble à ceci:

          void main() {
          while(puts("y"));
          }
          La version GNU le fait beaucoup plus rapidement que toutes les autres, elle est capable de générer 10 milliards de 'y' par seconde.

          • [^] # Re: Et le code source il fait quoi ?

            Posté par  . Évalué à 0.

            Juste une remarque, sur la conclusion du lien :

            Vraisemblablement l’overhead vient du syscall et de la bascule de contexte entre noyau, yes et pv.

            Mort aux cons !

          • [^] # Re: Et le code source il fait quoi ?

            Posté par  . Évalué à 4.

            La version en Rust est plus rapide chez moi :

            
coreutils on  main is 📦 v0.0.13 via 🦀 v1.57.0 ⏰6s491ms[32] ❯ /usr/bin/yes | pv > /dev/null
^C,3GiO 0:00:03 [5,25GiB/s] [            <=>                         

coreutils on  main is 📦 v0.0.13 via 🦀 v1.57.0 ⏰17s327ms❯ ./target/release/yes | pv > /dev/null
^C52GiO 0:00:08 [19,1GiB/s] [                                <=>

            C'est peut-être lié aux options de compilation de ma Debian, va savoir…

    • [^] # Re: Et le code source il fait quoi ?

      Posté par  (site web personnel) . Évalué à 5.

      Oui c'est même pour ça que lors d'un hackaton FreeBSD (si je me trompe pas) les développeurs en ont fait une petite blague.

      Tout ça pour rajouter des standard --help et copyright.

      git is great because linus did it, mercurial is better because he didn't

  • # Runtime

    Posté par  (site web personnel) . Évalué à 5.

    Ne serait-ce pas parce-que le runtime est porté par quelqu'un d'autre ?

    Le bash ?

    Il me semble qu'il y a moyen en c de faire plus petit : gcc -nostdlib -m32
    Mais cela a des conséquences (pas de main)

    • [^] # Re: Runtime

      Posté par  (site web personnel) . Évalué à 6.

      Oui c'est bien le shell qui ne trouvant pas de shebang ou de code exécutable va pas faire grand chose de plus.

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • # Citer la source

    Posté par  (site web personnel) . Évalué à 10.

    Ça serait chouette de citer la source ayant inspiré ce billet : http://rachelbythebay.com/w/2022/04/06/text/

    Ou alors c'est un hasard mais dans ce cas il est absolument extraordinaire ;-)

    • [^] # Re: Citer la source

      Posté par  (site web personnel) . Évalué à 10.

      Merci pour le lien,

      Il s'agissait d'un ami qui m'a parlé d'un article qu'il avait lu parlant de ça (très certainement cet article). J'ai testé en local et fut étonné que cela fonctionne et j'ai souhaité partager sans réfléchir plus que ça.

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

    • [^] # Re: Citer la source

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Ce programme de 0 octets est également la plus courte implémentation possible d'une "quine", un programme qui affiche son propre code source.

      Cela a conduit à modifier les règles de l'IOCCC (le concours international de programmes C illisibles) pour obliger les candidats à proposer un programme d'au moins 1 octet.

      • [^] # Re: Citer la source

        Posté par  (site web personnel) . Évalué à 10.

        Du coup, cette implémentation de true n'est pas bonne : true est censé ne rien faire, hors ici il affiche son code source.

        Ok je sors…

        https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

    • [^] # Re: Citer la source

      Posté par  . Évalué à 3.

      Et l'article est actuellement en première page de Hackernews : https://news.ycombinator.com/item?id=30936333

  • # Benchmark

    Posté par  . Évalué à 5.

    Préparatifs:

    /tmp ❯ touch ahah
/tmp ❯ chmod +x ahah

    Et c'est parti

    /tmp ❯ hyperfine "./ahah" "/bin/true"
Benchmark #1: ./ahah
  Time (mean ± σ):       1.4 ms ±   0.3 ms    [User: 0.4 ms, System: 0.1 ms]
  Range (min … max):     1.0 ms …   4.8 ms    1409 runs

  Warning: Command took less than 5 ms to complete. Results might be inaccurate.
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark #2: /bin/true
  Time (mean ± σ):       0.1 ms ±   0.1 ms    [User: 0.2 ms, System: 0.0 ms]
  Range (min … max):     0.0 ms …   1.2 ms    3048 runs

  Warning: Command took less than 5 ms to complete. Results might be inaccurate.
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  '/bin/true' ran
   17.52 ± 25.03 times faster than './ahah'

    Donc en fait, ça marche plus vite avec un gros fichier. Va savoir pourquoi.

    • [^] # Re: Benchmark

      Posté par  (site web personnel) . Évalué à 5.

      /bin/true est un exécutable, ./ahah est """interprété""" par le shell. Je vous ai un peu induit en erreur en disant qu'il s'agissait d'un binaire de 0 octets.

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: Benchmark

        Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 07 avril 2022 à 22:50.

        Oui, un coup de strace ou de gdb sur le fichier montre qu'il n'est pas exécuté…

        Et pour l'interpréteur de commande, POSIX dit « If the execve() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of IEEE Std 1003.1-2001, the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of "$0" in the new shell may be set to the command name. If the executable file is not a text file, the shell may bypass this command execution. In this case, it shall write an error message, and shall return an exit status of 126. »

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # La même avec un, presque vrai, ELF

    Posté par  . Évalué à -2.

    http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

    https://nathanotterness.com/2021/10/tiny_elf_modernized.html

    Mis à part ça :

    ~ gcc -O2 -x c -S -o - - << .
int main() {
        return 0;
}
.
...
        xorl    %eax, %eax   # eax mis à 0
        ret
...

    Mort aux cons !

    • [^] # Re: La même avec un, presque vrai, ELF

      Posté par  . Évalué à 0.

      D’ailleurs y’a une typo dans le journal:

      _start:
  mov eax, 1  ; exit syscall
  mov e/a/b/x, 0  ; exit code
  int 0x80

      Mort aux cons !

      • [^] # Re: La même avec un, presque vrai, ELF

        Posté par  (site web personnel) . Évalué à 4.

        Ah effectivement, merci!

        Si les modos passent par la et peuvent corriger.

        (Il serait grand temps de pouvoir éditer ou du moins avoir un système pour ne pas passer par les commentaires pour apporter les corrections)

        https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

        • [^] # Re: La même avec un, presque vrai, ELF

          Posté par  (Mastodon) . Évalué à 5. Dernière modification le 07 avril 2022 à 13:38.

          Fait, c'est bon comme ça ? (je ne pratique pas l'ASM et les instructions pour la modification ne sont pas très claires)

          (Il serait grand temps de pouvoir éditer ou du moins avoir un système pour ne pas passer par les commentaires pour apporter les corrections)

          Je pense que c'est plus ou moins voulu, pour éviter que les modifications n'impactent trop le sens du journal alors que les commentaires ont démarré.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: La même avec un, presque vrai, ELF

            Posté par  (site web personnel) . Évalué à 4.

            Parfait merci !

            Je pensais a un système ou l'auteur peu soumettre une demande de modification aux modérateurs, en arrivant sur linuxfr ils auraient une sorte de notification "machin a demandé a modifier prout".

            https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

            • [^] # Re: La même avec un, presque vrai, ELF

              Posté par  . Évalué à 3.

              Voir un système pour signaler les typos, pas nécessairement par l'OP…

              • [^] # Re: La même avec un, presque vrai, ELF

                Posté par  (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 07 avril 2022 à 17:35.

                Il manque un système qui devrait être en place (et qui est obligatoire pour certains sites) qui permettrait de signaler un message directement à la modération. Idéalement cela pourrait être un bouton avec une liste déroulante et les types d'item :

                • signaler une erreur (code, lien, orthographe etc.),
                • alerte spam,
                • attention dérapage,
                • contenu illicite.

                Et, évidemment, une zone de saisie pour indiquer précisément et brièvement ce qui cloche. Ça arriverait par exemple dans la tribune Modération. Sauf que, si on a besoin d'un complément d'information, il n'est pas évident de contacter les gens qui ont émis le signalement (parce que les adresses de courriel du compte peuvent être obsolètes).

                « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

              • [^] # Re: La même avec un, presque vrai, ELF

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                Oui, un truc séparé des commentaires sur le fond pour discuter sur certaines formes.

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # true=0 ?

    Posté par  . Évalué à 0.

    /bin/true est un programme qui ne fait rien et retourne le code de sortie 0.

    je trouve perturbant que true renvoie 0, puisque 0 c'est false en général

    • [^] # Re: true=0 ?

      Posté par  (site web personnel) . Évalué à 7.

      /bin/true, et tout programme POSIX retournent un code d'erreur (int de 8 bits), et non un booléen.

      Le code d'erreur 0 signifie qu'il n'y a eu aucune erreur. Le code 255 (ou -127) signifie que le programme a été stoppé par un signal. La signification des codes de 1 à 254 est déterminée par le programme.

      Tu peux aussi considérer que /bin/true renvoi 0 car il est faux de dire qu'il a échoué à ne rien faire.

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: true=0 ?

        Posté par  . Évalué à 6. Dernière modification le 07 avril 2022 à 14:19.

        Le code d'erreur 0 signifie qu'il n'y a eu aucune erreur.

        c'est pas un code d'erreur du coup ;-)

        il est faux de dire qu'il a échoué à ne rien faire.

        waouh, quelle formulation ! à la réflexion je me sens très proche de true : je réussis parfaitement à ne rien faire !

        Merci pour la réponse

        • [^] # Re: true=0 ?

          Posté par  . Évalué à 3.

          Voilà, en débogage, il doit écrire:

          Error: Success

          -------> [ ]

          • [^] # Re: true=0 ?

            Posté par  . Évalué à 2.

            Ça, c'est la couche de compatibilité windows, non ?

            Ferme pas trop vite la porte, j'arrive !

            Matricule 23415

            • [^] # Re: true=0 ?

              Posté par  (site web personnel) . Évalué à 5.

              Tu confonds avec :

              failed successfully

              https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

              • [^] # Re: true=0 ?

                Posté par  . Évalué à 3. Dernière modification le 09 avril 2022 à 09:11.

                Pourtant, il me semblait que c'était aussi documenté :
                Error: success

                Toutes mes confuses…

                Matricule 23415

              • [^] # Re: true=0 ?

                Posté par  . Évalué à 2.

                Bof, nous aussi on a ça ^^ : echec: success (Oui, un de mes vg se nomme Null, ça me faisait rire)

                • [^] # Re: true=0 ?

                  Posté par  (site web personnel) . Évalué à 3.

                  Toi t'es confiant de jamais risquer un ptit cat >/dev/Null

                  Cela dit, c'est cohérent avec ton nom d'utilisateur :D

                  https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: true=0 ?

        Posté par  . Évalué à 1.

        Hum…

        ~ sleep 60
zsh: terminated  sleep 60
~ echo $?
143
~ sleep 60
zsh: quit       sleep 60
~ echo $?
131

        Le retour chez moi c’est 128 + numéro du signal (ça va dépendre du système et de la machine)

        Les seules garanties sont 0 <=> succès, et l’exit code est sur l’octet de poids faible quand il existe. En C Posix il y a des macros, que zsh utilise manifestement.

        man 7 signal
man 3p wait || man 2 wait

        Mort aux cons !

      • [^] # Re: true=0 ?

        Posté par  . Évalué à 10. Dernière modification le 07 avril 2022 à 14:54.

        La signification des codes de 1 à 254 est déterminée par le programme.

        En fait, pas tout à fait. Il vaut mieux rester de 0 à 127. Sous Linux, généralement, si un processus est tué par un signal, tu retrouves le code de retour : 128 + numéro du signal.

        capello:~$ cat >toto.c
int main()
{
while(1);
return 0;
}
capello:~$ gcc toto.c
capello:~$ ./a.out
^C
capello:~$ echo $?
130
capello:~$ kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX
capello:~$

        Ici, 130 == 128 + 2 => SIGINT qui correspond bien au <Ctrl>+c.

        Édit: Arg, grillé !

        • [^] # Re: true=0 ?

          Posté par  . Évalué à 2.

          Édit: Arg, grillé !

          C’est ce qui arrive aux CPU qui font des while(1); :p

          Mort aux cons !

    • [^] # Re: true=0 ?

      Posté par  (site web personnel) . Évalué à 5.

      true ne renvoi pas 0, le code de retour est 0 (ce n'est pas la meme chose).
      Le code retour des applications qui n'ont pas de problème est "0".

      # true && echo "ok"
ok
# false && echo "ok"

    • [^] # Re: true=0 ?

      Posté par  . Évalué à 3.

      Il n’y a pas que toi :) différentes considérations sur ce thème dans cette question Stack Overflow https://stackoverflow.com/questions/2953646/how-can-i-declare-and-use-boolean-variables-in-a-shell-script

      • [^] # Re: true=0 ?

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        La réponse est simple pour moi : le shell POSIX ne connait que des chaînes de caractères… D'autres, à l'instar de Korn, ont des declare mais là c'est une autre affaire (RTFM) et sinon ça peut être le signe que ce qu'on cherche à faire gagnerait à être fait dans un langage plus avancé…

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Même un simple return lève des questions.

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 07 avril 2022 à 15:41.

    1) Même sur un simple return, il peut y avoir question apparemment.

    Cf le manuel de pngcrush http://manpages.ubuntu.com/manpages/focal/en/man1/pngcrush.1.html

    -exit     Forces pngcrush to call exit() rather than return() when it is finished.  It  is
                 unclear to this writer why this option exists.

    Meme

    2) true peut échouer

    Cf https://twitter.censors.us/jfbastien/status/1357878585361530882
    et son /bin/true --help &> /dev/full ; echo $?

  • # Rachel en parle

    Posté par  (Mastodon) . Évalué à 3.

    https://rachelbythebay.com/w/2022/04/07/empty/

    Okay, wow, my post about an empty file has generated a lot of feedback, mostly for the throwaway line at the bottom about an empty file being the smallest version of /bin/true possible.

    Rachel by the Bay, un blog à suivre…

  • # Licence d'un fichier vide

    Posté par  . Évalué à 2.

    Par contre ton fichier vide, tu ne peux pas lui mettre de licence. Parce que s'il y a une licence GPL3 par exemple, ça poserait des problèmes à pas mal de projets qui ne sont pas en GPL3.

  • # Verdure

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Ce code est aussi remarquablement écologique. Il serait difficile d'avoir une consommation énergétique plus faible.

    • [^] # Re: Verdure

      Posté par  (site web personnel) . Évalué à 4.

      Bof, on stocke quand même une entrée dans la "table des matières" du système de fichier pour référencer un fichier vide.

      De mémoire, un inode sur ext4 c'est 256 octets, alors que :

      $ sh -c "exit 0"

      C'est 14 octets pour la commande complète.

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: Verdure

        Posté par  (site web personnel) . Évalué à 4.

        Lancer un shell doit coûter énergétiquement plus que le binaire statique du return 0 par contre. Mais sa compilation a ponctuellement coûté aussi. Et puis il est potentiellement dans les sauvegardes du système.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.