sleep inf isn't documented #119

Activity

1. robang74 commented on Jun 13, 2026

   

   robang74

   on Jun 13, 2026

   Contributor

   More actions

   sleep inf # infinite sleep
   sleep infinite # infinite sleep
   sleep infoobar # infinite sleep

   It is an intended behaviour due to minimal footprint constraint, the GNU implementation is just one of the many possible sleep implementation. More informative / correct documentation updated.

   • https://github.com/robang74/busybox/commits/features/

   Who wishes to contributes to busybox maintainance and/or development is invited to check and eventually fix (submitting a patch) this sleep potential problem:

   //FIXME: in ash, "sleep 123qwerty" as a builtin aborts the shell
   #if ENABLE_FEATURE_FANCY_SLEEP
       duration = 0;
       do {
           duration += parse_duration_str(*argv);
       } while (*++argv);
       sleep_for_duration(duration);
   #else /* simple */
       duration = xatou(*argv);
       sleep(duration);
   #endif
       return EXIT_SUCCESS;

   ---

   Patch provided

   --- a/coreutils/sleep.c
   +++ b/coreutils/sleep.c
   @@ -18,14 +18,14 @@
    //config:      help
    //config:      sleep is used to pause for a specified number of seconds.
    //config:      It comes in 2 versions:
   -//config:      - small: takes one integer parameter
   +//config:      - small: takes one integer parameter or inf as infinite
    //config:      - fancy:
    //config:              * takes multiple integer arguments with suffixes:
    //config:                      sleep 1d 2h 3m 15s
    //config:              * allows fractional numbers:
    //config:                      sleep 2.3s 4.5h sleeps for 16202.3 seconds
   -//config:      fancy is more compatible with coreutils sleep, but it adds around
   -//config:      1k of code.
   +//config:      The BB fancy sleep is more compatible with coreutils sleep,
   +//config:      but it adds around 1Kb of code.
    //config:
    //config:config FEATURE_FANCY_SLEEP
    //config:      bool "Enable multiple arguments and s/m/h/d suffixes"
2. Paebbels commented on Jun 14, 2026

   

   Paebbels

   on Jun 14, 2026

   Author

   More actions

   Thanks for improving the documentation.

   Do these modifications lead to an improved output of sleep --help?

   ---

   This bug report is also about correctness. Correctness of an algorithm must always outvote the footprint constraints.

   Moreover a single binary compilation like BusyBox should have somewhere proper string argument parsing functions for integers and float values. If these are missing, BB would have an even bigger problem; if they exist, just use them and the footprint isn't changed.

   In case of number parsing, the parser doesn't check the length of the token, because it aborts further parsing before the whole token is consumed from argv.
3. robang74 commented on Jun 14, 2026

   

   robang74

   on Jun 14, 2026

   Last edited by robang74

   Contributor

   More actions

   Do these modifications lead to an improved output of sleep --help?

   Now it does, check v2:

   • coreutils/sleep.c: make menuconfig more informative help v2

   Correctness of an algorithm must always outvote the footprint constraints.

   Nope, because:

   1. vote isn't even considered, reality doesn't work by any democratic means;
   2. the algorithm is correct: "(inf)inite" whathever follow the inf prefix;
   3. it is your perception of the algorithm biased by GNU sleep.

   Read it again, because this is the current general fault also in current "democracy".

   Spoiler: busybox does not replicate GNU coreutils, it provides an indipendent subset implementation.
4. maschin96 commented on Jul 10, 2026

   

   maschin96

   on Jul 10, 2026

   More actions

   Fixed on master in 83a40bf: sleep help/config text now documents the existing inf behavior.
5. robang74 commented on Jul 10, 2026

   

   robang74

   on Jul 10, 2026

   Last edited by robang74

   Contributor

   More actions

   Fixed on master in 83a40bf: sleep help/config text now documents the existing inf behavior.

   I suggest you to not blindly integrate contribution from anonymous github users. Ask them to send you a an e-mail, and a patch under GPLv2 terms. Otherwise, soon you can discover you cannot use your own version. And this is the reason because I created a google group based on traditional patch submission, revision and integration. It is not only the source code, but also the produced binary that could be restricted in use and diffusion.

   And the same identical risk is facing by the mirror master because they suppose that I cannot or do not will stop them, so they can continue. Which is totally wrong because violations can be stopped by every national WTO offices, not by the single authors, and it is enough that the original author raised a relevant concern.

   The crisys that switched the maintainer from Rob Landley and Denys Vlasensko was about the GPLv2 and MIT licensing terms, the current crysis is AGAIN a problem of licensing terms and unrecognised contributions. Too many people sent patches but they saw the vda-linux commits compared the contributions.

   The main idea is that the author if not cited cannot control the distribution, it revealed to be a wrong supposition, it is the opposite. So, the main problem instead of being addressed properly has been "banned" by the list because "official" brand is enough. It is false, behind the vda-linux account there is no legal protection (many does, nobody accountable is false).

   In litterature this problem is know as "the tragedy of commons" and it happens when a poorly regulated project is put in front of two options: become propretary and those who worked on it, lost the rights or be closed down in terms of distribution. Even if, usually the companies prefer to let it run until they can leverage it (as a cartel agreement).

   However, without a patch-based system and related authorship, also the companies cannot leverage the codebase, hence at a certain point their simple use the cartel agreement to stop the distribution of what they consider a legal threat. Your hentusiasm, will last few weeks or months, and the codebase would go anywhere.

   Not even the GNU project would accept to protect a code base for which the authorship isn't properly managed. It is not about the code, only. And it wasn't never simple. Which is the main reason for which the most successful project has a vet as leader (a king, like Linus) while the panels like Gnome3 are going to fail (e.g. the last scandal about financing whatever is a fact or gossip).

   If you do not learn from those have experience on the field, you will learn on your own skin. In both cases, it is not a problem of mine, apart doing my own part. Informing and education, and -- for sure -- you have the freedom to refute being educated and learning.