On 8/27/2018 11:54 AM, Robert Elz wrote:
From:L A Walsh
| POSIX moved away from their original mission statement of being
| "descriptive" to one that is "prescriptive" a long time ago
I don't think that's true - certainly not as much as other (related)
standards (like those f
Date:Mon, 27 Aug 2018 10:57:56 -0700
From:L A Walsh
Message-ID: <5b843ba4.4030...@tlinx.org>
| I certainly would not take the ever-changing POSIX spec as
| a guide to what actually exists or is implemented in the field.
| POSIX moved away from their original mis
On 8/25/2018 3:16 PM, Bob Proulx wrote:
Greg Wooledge wrote:
If true, that would actually violate POSIX.
You might be remembering it wrong.
Naw...just the marginalia that Bob mentions...
I also remember that at one time the Unix sleep was implemented by
polling a second granularity cloc
Greg Wooledge wrote:
> L A Walsh wrote:
> > I remember some implementations only wait till the clock reaches the
> > new time in seconds -- meaning that the actual sleep time could be
> > .001 seconds.
>
> If true, that would actually violate POSIX. The sleep time must be
> "at least" as long as
On Wed, Aug 22, 2018 at 03:54:44PM +0300, Ilkka Virta wrote:
> [...] and Bash already supports handling
> subsecond times in at least 'read -t', so it's not that far fetched to
> implement it in 'sleep' too.
Ah, excellent point! OK, that plus the ksh compatibility definitely wins
me over.
On 22.8. 15:22, Greg Wooledge wrote:
Just for the record, the POSIX sleep command only accepts an "integral
number of seconds specified by the time operand." Sub-second sleep(1)
is a GNUism.
Or ksh-ism? (Or does it even matter which one it is originally, since
Bash is GNU Bash with features c
On Tue, Aug 21, 2018 at 06:11:14PM -0700, L A Walsh wrote:
> sleep .001 (ms sleep)...not practical if loaded each time)
> I often use sleep .1/.3/.5 ... if the builtin doesn't support sleep times
> < 1 second, then it's probably not worth it.
>
> Also, needs to actually sleep for the listed time.
On Tue, Aug 21, 2018 at 10:32 PM, don fong wrote:
> wouldn't it be less confusing if the proposed built-in sleep function were
> given a new name instead of overloading "sleep"?
That will complicate the migration effort for people who want to
switch to using the built-in sleep, no?
--
Best regar
Clint Hepner wrote:
On Aug 19, 2018, at 10:25 AM, konsolebox wrote:
Hi Chet,
The sleep command is often used in loops and using the external sleep
is expensive.
Expensive is relative, as the time spent actually sleeping probably dwarfs the
startup time. If not, you probably want t
wouldn't it be less confusing if the proposed built-in sleep function were
given a new name instead of overloading "sleep"?
On Tue, Aug 21, 2018 at 4:34 AM, konsolebox wrote:
> On Tue, Aug 21, 2018 at 4:23 PM Ilkka Virta wrote:
> >
> > On 21.8. 02:35, Chet Ramey wrote:
> > > I don't think ther
On 21.8. 14:34, konsolebox wrote:
Also it's basically
people's fault for not reading documentation. One should be aware
enough if they enable the builtin.
Yes, if it's not enabled by default.
--
Ilkka Virta / itvi...@iki.fi
On Tue, Aug 21, 2018 at 4:23 PM Ilkka Virta wrote:
>
> On 21.8. 02:35, Chet Ramey wrote:
> > I don't think there's a problem with a `syntax conflict' as long as any
> > builtin sleep accepts a superset of the POSIX options for sleep(1).
>
> The sleep in GNU coreutils accepts suffixes indicating mi
On 21.8. 02:35, Chet Ramey wrote:
I don't think there's a problem with a `syntax conflict' as long as any
builtin sleep accepts a superset of the POSIX options for sleep(1).
The sleep in GNU coreutils accepts suffixes indicating minutes, hours
and days (e.g. sleep 1.5m or sleep 1m 30s for 9
On Tue, Aug 21, 2018 at 7:35 AM Chet Ramey wrote:
> I'm going to wait until after bash-5.0 is released before considering
> this. In the meantime, there is the loadable version, which is now built
> and installed by default when you run `make install'.
I see, thanks. That's good enough for now.
On 8/19/18 10:25 AM, konsolebox wrote:
> Hi Chet,
>
> The sleep command is often used in loops and using the external sleep
> is expensive. Perhaps we can add the sleep builtin but have it
> disabled by default to avoid syntax conflict with the external one.
I don't think there's a problem with
Additionally, for simple uses, using:
read -t
Works for pseudo built-in sleep. Not easy to use in subshells, or with any
forks.
On Sun, Aug 19, 2018, 12:12 PM konsolebox wrote:
> On Mon, Aug 20, 2018 at 12:26 AM, Clint Hepner
> wrote:
> >
> >> On Aug 19, 2018, at 10:25 AM, konsolebox wrote:
>
On Mon, Aug 20, 2018 at 12:26 AM, Clint Hepner wrote:
>
>> On Aug 19, 2018, at 10:25 AM, konsolebox wrote:
>>
>> Hi Chet,
>>
>> The sleep command is often used in loops and using the external sleep
>> is expensive.
>
> Expensive is relative, as the time spent actually sleeping probably dwarfs
>
> On Aug 19, 2018, at 10:25 AM, konsolebox wrote:
>
> Hi Chet,
>
> The sleep command is often used in loops and using the external sleep
> is expensive.
Expensive is relative, as the time spent actually sleeping probably dwarfs the
startup time. If not, you probably want to find an alterna
18 matches
Mail list logo
