[29342] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 586 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jun 26 21:14:17 2007

Date: Tue, 26 Jun 2007 18:14:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Tue, 26 Jun 2007     Volume: 11 Number: 586

Today's topics:
    Re: strings with formatted characters in %ARGV <savagebeaste@yahoo.com>
    Re: strings with formatted characters in %ARGV <tadmc@seesig.invalid>
    Re: The Modernization of Emacs: terminology buffer and  <twisted0n3@gmail.com>
    Re: The Modernization of Emacs: terminology buffer and  <twisted0n3@gmail.com>
    Re: The Modernization of Emacs: terminology buffer and  <twisted0n3@gmail.com>
    Re: The Modernization of Emacs: terminology buffer and  <twisted0n3@gmail.com>
        timegm() <himagauri@gmail.com>
    Re: timegm() <noreply@gunnar.cc>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Tue, 26 Jun 2007 14:12:55 -0700
From: "Clenna Lumina" <savagebeaste@yahoo.com>
Subject: Re: strings with formatted characters in %ARGV
Message-Id: <5eddqtF382p1cU1@mid.individual.net>

mfrost8@gmail.com wrote:
> On Jun 25, 6:56 pm, Tad McClellan <t...@seesig.invalid> wrote:
>> mfro...@gmail.com <mfro...@gmail.com> wrote:
>>
>>> What do I need to do to make this work the way I expect it to?
>>
>>    $foo =~ s/\\n/\n/g;
>>
>> --
>> Tad McClellan
>> email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
>
> Thanks much for the many responses I received.  I genuinely appreciate
> you folks taking the time time help me out with this.
>
> After my last post, I played around some more and came up with the
> code shown above that I had found worked as well.  However, what I was
> hoping for was something more general purpose that allowed me to
> replace all or at least multiple metacharacters in one go.  I'm not
> quite able to come up with something that will work here.  I've tried
>
>    $foo =~ s/(\\[nrt])/$1/eeg;
>
> which yields a bunch of
>
>    Use of uninitialized value in substitution iterator at ...

If you really want to do it that way, something like the following 
should work:

   #!/usr/bin/perl

   use strict;

   my $foo = join (' ', @ARGV);

   $foo =~ s/\\([nrt])/"qq{\\$1}"/gee;

   print qq{"$foo"\n};

   __END__


   __OUTPUT__
   ./foo.pl '1 2\n3'
   "1 2
   3"

Note, I noticed that if I passed the arguements without any quoting 
(./foo.pl 1 2\n3) the "\" would get stripped (I'm guessing my the 
shell - linux, bash) so perl only sees '1 2n3'... why does the slash get 
stripped? 




------------------------------

Date: Tue, 26 Jun 2007 18:38:44 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: strings with formatted characters in %ARGV
Message-Id: <slrnf838s4.l7s.tadmc@tadmc30.sbcglobal.net>

mfrost8@gmail.com <mfrost8@gmail.com> wrote:
> On Jun 25, 6:56 pm, Tad McClellan <t...@seesig.invalid> wrote:
>> mfro...@gmail.com <mfro...@gmail.com> wrote:
>>
>> > What do I need to do to make this work the way I expect it to?
>>
>>    $foo =~ s/\\n/\n/g;
>>
>> --
>> Tad McClellan
>> email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"


[ it is bad form to quote .sigs (unless you are commenting on the .sig)]

> However, what I was
> hoping for was something more general purpose that allowed me to
> replace all or at least multiple metacharacters in one go.  I'm not
> quite able to come up with something that will work here.


I'd list the chars to be translated in a hash, and then look
them up in the s///


-----------------
#!/usr/bin/perl
use warnings;
use strict;

my %chars = (
   n => "\n",
   r => "\r",
   t => "\t",
);
my $foo = 'foo\tbar\nbaz\n';

$foo =~ s/\\([nrt])/$chars{$1}/g;

print $foo;
-----------------


-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"


------------------------------

Date: Wed, 27 Jun 2007 00:07:04 -0000
From:  Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182902824.736206.37010@m36g2000hse.googlegroups.com>

On Jun 26, 10:52 am, Bjorn Borud <borud-n...@borud.no> wrote:
> [Robert Uhl <eadmun...@NOSPAMgmail.com>]
> |
> | Agreed.  Stallman got sidetracked by Scheme, which IMHO was a
> | dead-end.
>
> too many people buying SICP and believing what they heard about it
> being an important book.  I too spent some time exploring Scheme, or
> should I say, wasted some time, years ago, and nothing came of it
> other than a profound irritation.  these people seemed to be
> completely disconnected from reality.
>
> Scheme, and thus Guile, might have been a viable path if these people
> had only been practical instead of stubbornly insisting on being odd.

Some people might say the same thing about emacs. A lot of unix tools
even. "Stubbornly insisting on being odd" appears to be a particularly
prevalent character flaw among the geeknoscenti.



------------------------------

Date: Wed, 27 Jun 2007 00:16:19 -0000
From:  Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182903379.098107.310320@k29g2000hsd.googlegroups.com>

On Jun 26, 10:37 am, Bjorn Borud <borud-n...@borud.no> wrote:
> ...and of course, in addition you have access to history so you can
> easily find previous parameters and edit them.  this makes it very
> efficient when you need to fiddle about in deep directory trees in a
> way no GUI can yet offer.
>
> ...and then there's bookmarking, which is very good for keeping a set
> of files (and locations) handy for quick access.

Good thing it has these. Bookmarking is quite natural and is THE way
in GUIs to cope with deep directory structures. Bookmarking in a GUI
is simple: you just open file-browser windows and park them in oft-
visited places, to flip to whenever needed. Multitasking window
systems are neat that way. Current versions of Windoze Explorer have a
history and back and forward navigation buttons reminiscent of a Web
browser, too.

None of them turn into as big a PITA when lots of files have a
lengthy, identical prefix either, which is a fairly common situation.
That only causes difficulty at all when some column or window is sized
too narrowly to show parts of the name past the prefix, forcing
scrolling. Resizing it is then easy, thanks to the GUI, so unless the
prefix is wide enough to cross the entire screen even if you set the
font size down to 3... contrast that with tab completion, where to
disambiguate you'll have to type the entire prefix and then part of
the rest, THEN hit tab. If the prefix is long, you might be saving 3
keystrokes reducing 47 to 44, a gain in productivity of about 7%, a
figure I'm sure you'll agree is somewhat underwhelming. Of course with
a GUI it's spot-the-right-file-and-click, and just as fast whether the
prefix is 4 characters long or 40.



------------------------------

Date: Wed, 27 Jun 2007 00:37:11 -0000
From:  Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182904631.083783.170640@o61g2000hsh.googlegroups.com>

On Jun 26, 6:06 am, Gian Uberto Lauri <s...@spammer.impiccati.it>
wrote:
> >> > HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO
> >> ENTER > THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT
> >> WOULD TELL > THEM THOSE ARE THE KEYS TO REACH THE HELP?!
>
> >> What's your problem ?
>
> >> Ofcourse a mere program-consumer would not look what was being
> >> installed on his/her system in the first place ...  So after some
> >> trivial perusing what was installed and where : WOW Look, MA !
> >> .... it's all there!
>
> >> lpr /usr/local/share/emacs/21.3/etc/refcard.ps or your
> >> install-dir........^ ^ or your
> >> version.............................^
>
> n> So now we're expected to go on a filesystem fishing expedition
> n> instead of just hit F1? One small step (backwards) for a man; one
> n> giant leap (backwards) for mankind. :P

[snipping some thinly-veiled insults and irrelevancies throughout]

> There's a program called find, not this intuitive but worth learning
>
> It could solve the problem from the root with something like
>
> find / -name refcard.ps -exec lpr {} \; 2> /dev/null

Let me get this straight.

In this corner, we have just about every Windows application ever
developed. When a user needs help, a click on the "help" menu or tap
of the F1 key is all it takes to obtain some. Sometimes the help is
not of the greatest quality, but that is another issue we won't
concern ourselves with here.

In the other corner, we have just about every Unix application ever
developed. When a user needs help, they may do such things as manually
explore the directories where the application was installed
(equivalent to rooting around in C:\Program Files\Appname for .hlp
files, because F1 didn't work and there was no "help" menu, if such a
thing ever happened on Windoze). Or alternatively it can just
magically come to them as a divinely inspired insight, or in a dream
or a burning bush or stone tablets from heaven or something, that
something useful might happen if the unlikely combination of symbols
"find / -name refcard.ps -exec lpr {} \; 2> /dev/null" were typed at
the console, which otherwise would obviously never occur to them. Even
if they knew the find tool and its syntax, it would still have to
somehow occur to them that "refcard.ps" might be a useful search
target. On Windows, if push came to shove, clicking Start->Search and
putting in ".hlp" and "C:\Program Files\Appname" would quickly find
any help files. If they were given the usual file extension. If not,
good luck, but most usually the help files would be named to end
with .hlp. Moreover, once found, a quick double click and they're in a
hypertext browser viewing the help. Unless I miss my guess, refcard.ps
would require mucking about installing and configuring Ghostscript and
GSView, which for Joe Winblows User is daunting enough. Trying to read
anything serious and navigate in GSView is no picnic either. A
hypertext browser it ain't. Adobe Acrobat Reader *might* be able to do
more with a .ps file, but it's proprietary. On a Unix box, if you
don't know exactly how to get some app viewing a .ps file and how to
navigate in it I'm guessing you're SOL. The original suggestion with
"lpr" implies printing it rather than viewing it online, which a)
costs money and b) requires configuring a printer and a Postscript
interpreter, given that unless the printer cost more than the
computer's CPU it surely won't natively grok Postscript. We're back to
configuring Ghostscript, only this time on the Unix box where I have
no doubt it's even more painful than it is on a Windoze box, as well
as configuring a printer on a Unix box, itself a recurring nightmare
of mine for years now since one night in the nineties when I got
caught in the crossfire between someone's Epson inkjet and their
Mandrake 7.somethingorother Linux.

Reexamining that "find" line it looks like it tries to automatically
"lpr" the file(s) found. That is cause for concern, since I can easily
see something like this going into Sorceror's Apprentice mode and
costing you a fortune in ink and paper if there's either a misspelling
or other mistake (easy enough to make in a complex arcane command line
like that one) or more "refcard.ps" matches than you expected there'd
be in the target directory and its descendants.



------------------------------

Date: Wed, 27 Jun 2007 00:50:43 -0000
From:  Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182905443.074236.128290@w5g2000hsg.googlegroups.com>

On Jun 26, 6:17 am, Gian Uberto Lauri <s...@spammer.impiccati.it>
wrote:
> Children pick  up other language without any  conscious effort because
> either they learn  it by using with parents,  relatives and friends or
> they are involved in a game-like style of learning.

Actually, it's proven that there's a critical period for language
learning "coming naturally" that ends around age seven. Children
actually have enhanced learning abilities due to brain physiology and
plasticity.

> T> I know people who find all kinds of vehicles easy to learn but
> T> never mastered a bicycle (despite trying). People, plural, as in
> T> more than one of them.
>
> Again, fear, or maybe, some  malfunction in the balancing organs.  But
> fear mainly. You do not see what keeps a bike upright and running, you
> have to trust that you can.

Oh, come off it. One of those people is a physics professor, who knows
the mechanics of gyroscopic stability and things of that nature
backwards and forwards. And his sense of balance is fine -- he has no
trouble with that except when he's quite drunk. He told me the problem
was the bike tipping over before it could get up enough speed to
become stable. My own guess being there's a "knack" you may or may not
eventually get, for getting past that initial hurdle and getting it up
to speed when it becomes stable.

Of course, this "knack" isn't something found in any instruction
manual. I'm wondering if getting your head around unix arcana is also
dependent on an iffy "knack" where you "get it" and somehow know where
to look for documentation and problem fixes, despite everything having
its own idiosyncratic way, and "get" some sort of workflow trick
going, or you don't. Personally, the thing I always found most
irritating was the necessary frequent trips to the help. Even when the
help was easy to use (itself rare) that's a load of additional task
switching and crap. Of course, lots of the time the help was not easy
to use. Man pages and anything else viewed on a console, for example
-- generally you could not view it side by side with your work, but
instead interrupt the work, view it, try to memorize the one next
step, go back to your work, perform that next step, back to the help
to memorize another step ... that has all the workflow of a backed-up
sewer, yet until and unless the commands become second nature it's
what you're typically forced to do without a proper GUI. Navigating
also being a pain -- generally it's easy to get it to scroll down, or
exit; hard but usually possible to scroll up in case you overshoot;
and there's some arcane search capability, but it isn't
straightforward to use so you can't use it because you'd need to be
open to the help for the help viewer or other tool instead of the help
you're trying to search, and then your search would come up empty. The
searching-help instructions not being in the same help file as the
target of your search proves to be the final straw, and you throw up
your hands in disgust after going a few rounds with "thetool", "man
thetool", and "man man" and make an inch of progress in an hour, most
of it spent on typing, scrolling, or memorizing rather than on working
with "thetool".

Maybe the thing I really, REALLY deplore is simply having 99% of my
attention forced to deal with the mechanics of the job and the
mechanics of the help viewer and only 1% with the actual content of
the job, instead of the other way around.



------------------------------

Date: Tue, 26 Jun 2007 20:29:14 -0000
From:  Gauri <himagauri@gmail.com>
Subject: timegm()
Message-Id: <1182889754.235592.51830@k79g2000hse.googlegroups.com>

This is the time I have in GMT
time: 6/26/2007 12:00:26 AM

I want to convert it to epoch format in CST timezone:
Using the timegm() function, this is the answer I get:
GMT_epochtime: 1182859226

Is CST_epochtime same as GMT_epochtime for any given time?

Also when I try to convert the above epoch time back to readable time,
using function gmtime()
		($r_sec,
		 $r_min,
		 $r_hour,
		 $r_day,
		 $r_month,
		 $r_year,
		 $r_weekday,
		 $r_yearday,
		 $r_isdst) = gmtime($GMT_epochtime);

I get $r_hour = 12.

I'm expecting 00 since the time given above is 12 AM.

Where am I going wrong? else how do I know if $r_hour =12 is AM or PM?

-Gauri



------------------------------

Date: Wed, 27 Jun 2007 01:24:20 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: timegm()
Message-Id: <5edlmmF37d9h5U1@mid.individual.net>

Gauri wrote:
> This is the time I have in GMT
> time: 6/26/2007 12:00:26 AM
> 
> I want to convert it to epoch format in CST timezone:
> Using the timegm() function, this is the answer I get:
> GMT_epochtime: 1182859226

Then you don't pass the correct values to timegm().

C:\home>type test.pl
use Time::Local;
print timegm( 26, 0, 0, 26, 6-1, 2007 ), "\n";

C:\home>test.pl
1182816026

C:\home>

> Is CST_epochtime same as GMT_epochtime for any given time?

Yes.

-- 
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc.  For subscription or unsubscription requests, send
#the single line:
#
#	subscribe perl-users
#or:
#	unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.  

NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice. 

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 586
**************************************


home help back first fref pref prev next nref lref last post