X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <1ff86f510902020634g49262880s20929642e46a9a33@mail.gmail.com> References: <4982FB77 DOT 7020505 AT byu DOT net> <5 DOT 2 DOT 0 DOT 9 DOT 1 DOT 20090130164221 DOT 01ec8dd0 AT localhost> <1ff86f510902020634g49262880s20929642e46a9a33 AT mail DOT gmail DOT com> Date: Mon, 2 Feb 2009 15:27:59 -0500 Message-ID: Subject: Re: Finding either boot time or login time From: "Mark J. Reed" To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Mon, Feb 2, 2009 at 9:11 AM, Ronald Fischer wrote: > Would you mind explaining the ~~ trick? Not at all, but I'll do so offlist. Perl-fu is not on-topic for Cygwin. On Mon, Feb 2, 2009 at 9:34 AM, Jerry D. Hedden wrote: > Clever tricks are interesting, but definitely are an obfuscation. It's a one-liner; the goal is compactness/expressiveness, not intentional obfuscation. Sure, in a standalone script (or larger system) I would have used scalar() instead of ~~. I also would have explicitly opened, read, and split the contents of /proc/uptime instead of using the -a and -n options, and explicitly terminated the output string with "\n" instead of using the -l option. In other words, ~~ is a common Perl idiom, whose use is no more obfuscating than that of those command-line options. Different methods for different goals. On Mon, Feb 2, 2009 at 11:54 AM, Cooper, Karl (US SSA) wrote: > I did try both of these one-liners on my > Cygwin 1.7 setup, and the output differs (by one second). I thought > that was interesting. Rounding difference. Besides replacing my ~~ with scalar(), Jerry added an int() call to truncate the value read from /proc/uptime - and that change was more than cosmetic. Since the return value of time() is only accurate to the nearest integer, my script would return different values depending on how far into the current second you were when running it; Jerry's should behave more consistently. Another option is to correct in the other direction by using the Time::HiRes module to cause the return value of time() to have millisecond accuracy: $ perl -MTime::HiRes=time -lane 'print ~~localtime(time - $F[0])' /proc/uptime But it seems silly to worry about a one-second error on a call that is apparently subject to much larger error due to the effect of hibernation. :) -- Mark J. Reed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/