Re: CVS commit: src/bin/sleep

[David Brownlee <abs%absd.org@localhost>]

On Fri, 25 Jan 2019 at 09:30, Valery Ushakov <uwe%stderr.spb.ru@localhost> wrote:
>
> On Fri, Jan 25, 2019 at 10:43:10 +0700, Robert Elz wrote:
>
> >     Date:        Thu, 24 Jan 2019 16:18:49 +0100
> >     From:        Joerg Sonnenberger <joerg%bec.de@localhost>
> >     Message-ID:  <20190124151849.GA10743%britannica.bec.de@localhost>
> >
> >   | This is overcomplicated and fragile, IMO. Can we just go back to the old
> >   | code and switch the strtod to strtod_l with LC_C_LOCALE? That solves the
> >   | input problem.
> >
> > We could certainly do that, but while it is a little complicated, I do not
> > really think it is fragile.  Using a locale specific decimal radix in a
> > script is fragile - but the only way to avoid that is either to effectively
> > give up on non-C locales entirely for scripts, or drop all support for
> > fractional numbers as args to any command.
> >
> > Note: the arg to "sleep" might come as ...
> >       echo -n "How many seconds do you want to sleep? "
> >       read secs
> >       sleep "${secs}"
> > (with some error checking).
> >
> > I have no idea why sleep() was made to parse its arg in a locale
> > specific way, but that was done long long ago, and was (according
> > to the comments) done quite deliberately.
> >
> > I think changing that decison (rather than just avoiding the problem,
> > as the current "fix" does) needs more discussion than a few comments
> > on the source-changes-d list.
>
> As someone who actually have to ecnoutner locales in daily life and
> not just think about them sitting in an ivory tower I don't understand
> why do we even have this argument. Locale-specific argument to sleep
> is pure madness, period (no pun intended).

Granted, and no-one is arguing that sleep should not handle the
standard '.' separator.

The only question is what it should do if it is ever called with a
locale specific separator instead - error or take Postel's law and "be
liberal in what you accept".

I think it might be nice to have a way to control behaviour like this
in tools - maybe an environment variable for "disable various
extensions and be more strict in what is accepted", but that is a
separate bikeshed :)

David