Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/bin/sleep



On Fri, Jan 25, 2019 at 09:48:26 +0000, David Brownlee wrote:

> 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 :)

Thank you for demonstrating my point about the "ivory tower". :)

-uwe


Home | Main Index | Thread Index | Old Index