Re: [PATCH] sleep: allow ms suffix for milliseconds

[Rasmus Villemoes]

On 29/11/2019 23.02, Bernhard Voelker wrote:
> On 2019-11-29 21:58, Kaz Kylheku (Coreutils) wrote:
>> Sleeping for 15500 milliseconds is valid.
>>
>> But in any case, we can already do that with "sleep 15.500".
>>
>> The issue is that it's cumbersome to convert from 15500 to 15.500
>> in a shell script.

Exactly.

> This can easily be done ... with the shell's integer arithmetic
> and due to the fact the GNU sleep adds all arguments to the final
> nanosleep(2) time:
> 
>   $ x=15500
>   $ sleep  $((x/1000))  0.$((x%1000))

wrong, that's why the printf %03d was involved. Otherwise
$((x/1000).$((x%1000)) would be just as good.

> I'm still not convinced - especially since the suggested suffix "ms"
> is a 2-character suffix and therefore would change the 1-character
> rule of suffix.  I'm not sure if this could be a problem somewhere,
> though.

Why would it? Fortunately sleep(1) has always been strict about what it
accepts, so one cannot have relied on "5mGARBAGE" meaning "5m".

> If we want to support a suffix meaning a sub-second multiplier,
> then - as the underlying system call is nanosleep(2) - I'd rather
> go for using the single-char 'n' as suffix for nanoseconds.

I considered adding "ns" and "us", but decided against it because the
overhead of just calling the sleep binary is probably in the millisecond
(or at least tenths of milliseconds) range.

And yes, the point is exactly that when I want to sleep for 1700
milliseconds [1], I need to do some cumbersome shell yoga with either
printf or calling dc or whatnot. But as you so kindly demonstrate above,
getting that yoga right actually requires a bit of thought, and when I
have a concrete debugging job to do where I want to start by throwing
together a shell script to reproduce the thing, I'd much rather spend my
brain cycles thinking about the high-level "how can I trigger and
capture that bug" than having to worry about how to get my individual
tools to do their thing.

[1] Of course, my requirement in this concrete case is not "1700
milliseconds", as I could just write 1.7 then. No, it's some variable
amount of time, expressed in milliseconds.

Rasmus