Re: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning

> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>>>> Most portable likely would be Perl, however, that's probably too
>>>> heavyweight inside a loop like this, even if called only once each N
>>>> iterations.
>
> I think that is true.  Now, when it is too heavy to spawn perl,
> would it be light enough to spawn awk, I have to wonder.  Even if
> the implementation uses awk, I think the time measurement should be
> done only once each N iterations (e.g. every 1000 commits measure
> the rate and divide the remaining commits with that rate while
> displaying the progress; if you are chewing 100 commits per minute
> and have 2000 commits to go, you know it will take 20 more minutes).
>
>>> http://stackoverflow.com/questions/2445198/get-seconds-since-epoch-in-any-posix-compliant-shell
>>> Found this,
>>>
>>> awk 'BEGIN{srand();print srand()}'
>>>
>>> srand() in awk returns the previous seed value, and calling it without
>>> an argument sets it to time of day, so the above sequence should
>>> return seconds since the epoch, or at least something in seconds that
>>> is relative to a fixed point which is all that's needed in this
>>> thread.
>
> In practice this should work, but it makes me feel somewhat uneasy.
>
> POSIX says "Set the seed value for rand to expr or use the time of
> day if expr is omitted. The previous seed value shall be returned."
> but I do not see anything that says that "the time of day" is
> counted in seconds around there (which is the crucial bit for this
> application).
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
> (4.15 Seconds since the Epoch) says "The relationship between the
> actual time of day and the current value for seconds since the Epoch
> is unspecified."
>