Re: problems with intel architecture
On Apr 3, 2006, at 3:56 PM, Joel Rees wrote: Even though it's not as necessary as it was when the system perl was at v5.6 and we all wanted the Unicode stuff in v5.8, I'm still inclined to build a separate install of perl for application use. That way I don't have to worry as much about fine-tuning what gets installed, and I find it's easier to get cpan to behave, as well. (Not that you can ever ignore what gets installed, but it's easier to protect the server if you keep the OS clean.) Are there OS functions that rely on perl? What sorts of things? Are there nice directions somewhere for setting up a separate install? Also, how does CPAN module determine what's installed? I hesitated to just remove stuff from /Library/Perl until Ed told me to do so, because I figured that CPAN was keeping some state info about what was there. Thanks, Cheryl
Re: problems with intel architecture
On Tue, April 4, 2006 11:44 am, Cheryl Chase said: Are there OS functions that rely on perl? What sorts of things? Just to answer: yes, there are OS functions that rely on perl. If I was on my Mac I could probably pull up quite a few. One I'm fairly sure that uses perl is installers. (Not always, but often.) XCode makes it relatively simple to embed basic scripts (perl, shell, or otherwise) into a project. It wouldn't surprise me to find Perl is all kinds of odd applications, for some quick thing. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: problems with intel architecture
On Apr 4, 2006, at 2:16 PM, Dominic Dunlop wrote: On 2006–04–04, at 17:44, Cheryl Chase wrote: Are there OS functions that rely on perl? What sorts of things? Yes. Not many, though. You can see what's there if you type $ locate *.pl in a terminal window. That will only show the files ending in .pl. Scripts use the #! line to determine the interpreter to run them with, not the filename extension. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: problems with intel architecture
On Apr 4, 2006, at 11:44 AM, Cheryl Chase wrote: On Apr 3, 2006, at 3:56 PM, Joel Rees wrote: Even though it's not as necessary as it was when the system perl was at v5.6 and we all wanted the Unicode stuff in v5.8, I'm still inclined to build a separate install of perl for application use. That way I don't have to worry as much about fine-tuning what gets installed, and I find it's easier to get cpan to behave, as well. (Not that you can ever ignore what gets installed, but it's easier to protect the server if you keep the OS clean.) Are there OS functions that rely on perl? What sorts of things? Obviously the low-level kernel stuff like task switching, memory management, etc. aren't in Perl. But higher-level functions like cron jobs, startup scripts, installation scripts, etc. are often written in Perl. Unix admins had been using it for that sort of thing for years before web developers started using it. Installing a single perl may seem normal to users who are more accustomed to MacPerl and/or ActiveState's Perl for Windows, but it's *not* normal to install *nix perl that way. Sun even ships Solaris with two versions already installed, the latest version as /usr/bin/ perl, and whatever version they've verified their scripts against as / opt/sun/perl5.x.y/bin/perl. Are there nice directions somewhere for setting up a separate install? They're included with Perl. Actually, doing so is the path of least resistance, as the default is to install under /usr/local, which will not disturb Apple's perl. Also, how does CPAN module determine what's installed? It looks in @INC. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: problems with intel architecture
Are there OS functions that rely on perl? What sorts of things? Yes. Not many, though. You can see what's there if you type $ locate *.pl in a terminal window. That will only show the files ending in .pl. Scripts use the #! line to determine the interpreter to run them with, not the filename extension. I was thinking, let's write a script to check the first lines. But I'm lazy. file /*bin/* | grep perl file /usr/*bin/* | grep perl gets everything in the usual places for system executables. Of course it misses utility scripts in odd places, including all those found by the locate *.pl command. Since I'm a little weak with one-liners and with File::Find, I should try to work up a one-liner that would do a recursive descent, and log out and back in as a user that can sudo so I can descend all the places my working user can't. But I'm lazy. ;-/
Re: problems with intel architecture
Not a one-liner and not even pretty, but since I needed the practice:
-
#! /usr/bin/perl
use File::Find;
@l = ( / );
sub w
{
if ( -d $_ )
{ my $dir = $File::Find::dir;
if ( system( file * | grep perl ) == 0 )
{ print *** from: $dir ***\n;
}
}
}
find( \w, @l );
-
Overkill.
Gets a lot of can't cd errors, of course, since I'm not running it as
root, and it takes a while to run, too.
Finds a bit more than scripts, too, so it really doesn't serve the
original question, Heh.
A bunch of people wrote
Are there OS functions that rely on perl? What sorts of things?
Yes. Not many, though. You can see what's there if you type
$ locate *.pl
in a terminal window.
That will only show the files ending in .pl. Scripts use the #! line
to determine the interpreter to run them with, not the filename
extension.
I was thinking, let's write a script to check the first lines. But I'm
lazy.
file /*bin/* | grep perl
file /usr/*bin/* | grep perl
gets everything in the usual places for system executables. Of course
it misses utility scripts in odd places, including all those found by
the locate *.pl command. Since I'm a little weak with one-liners and
with File::Find, I should try to work up a one-liner that would do a
recursive descent, and log out and back in as a user that can sudo so
I can descend all the places my working user can't.
But I'm lazy. ;-/
When does a hash of lists get defined?
While messing with CGI POSTed data I got trapped by this one.
Version 5.8.1-RC3 for Mac OS 10.3.9
It appears that the hash element D gets defined in the process of testing to
see if an element in the associated string is defined. The last if below takes
the else route.
Is that normal? Does it somehow make sense?
%phash = ();
foreach $jill (A, B, C)
{
for ($lynn = 0; $lynn3; $lynn++)
{
$phash{$jill}[$lynn] = $jill$lynn;
print \$phash{$jill}[$lynn] = $phash{$jill}[$lynn]\n;
}
}
if (! defined $phash{D})
{
print \$phash{D} is undefined, We expected that.\n;
}
if (! defined $phash{D}[3])
{
print \$phash{D}[3] is undefined. We expected that too.\n;
}
if (! defined $phash{D})
{
print \$phash{D} is undefined\n;
}
else
{
print \$phash{D} got defined - why?\n;
}
__END__
--
Applescript syntax is like English spelling:
Roughly, but not thoroughly, thought through.
Re: When does a hash of lists get defined?
On 2006.4.5, at 09:36 AM, Doug McNutt wrote:
While messing with CGI POSTed data I got trapped by this one.
Version 5.8.1-RC3 for Mac OS 10.3.9
It appears that the hash element D gets defined in the process of
testing to see if an element in the associated string is defined. The
last if below takes the else route.
Is that normal? Does it somehow make sense?
%phash = ();
foreach $jill (A, B, C)
{
for ($lynn = 0; $lynn3; $lynn++)
{
$phash{$jill}[$lynn] = $jill$lynn;
print \$phash{$jill}[$lynn] = $phash{$jill}[$lynn]\n;
}
}
if (! defined $phash{D})
{
print \$phash{D} is undefined, We expected that.\n;
}
I should run the code before hazarding guesses, but I'm guessing you
find it is not defined above,
if (! defined $phash{D}[3])
{
print \$phash{D}[3] is undefined. We expected that too.\n;
}
... but defined after this one is done, So that the above two would
show is undefined, but the next would show got defined.
The reason I would guess this is that perl does automagically define
things in a lot of cases where other languages (like java) would throw
fits, I mean, throw exceptions. Perl is designed from the point of view
that the programmer thought he knew what he was doing, which, from a
purely mathematical point of view, is dangerous, but in the real world
is often the desired path.
Leaving the deep philosophy aside, if $phash{D) is not defined, there
are three or four ways to parse $phash{D}[3]. The java way would be
(I think) to throw the conniption, I mean, exception: Can't access an
array off a null pointer. Another way might be to short-circuit the
test, if $phash{D} is not defined, no way can anything referenced off
it be defined. But that path requires intelligence which we have not
yet been able to give programming languages and expect them to
completely parse any program in anything approaching determinant time.
{Oh. Wait. One more path I gotta check before I call this either valid
or invalid. Oh, wait, ...}
So perl simply defines the thing so that the rest of the test can
complete, as I understand it.
if (! defined $phash{D})
{
print \$phash{D} is undefined\n;
}
else
{
print \$phash{D} got defined - why?\n;
}
__END__
--
Applescript syntax is like English spelling:
Roughly, but not thoroughly, thought through.
Yeah, and Applescript does a bit more than perl on the trying to read
the programmer's mind, but it was a really bizarre programmer's mind it
was trained, I mean programmed to read.
8-*
File:Find-ing perl stuff on a mac (Re: problems with intel architecture)
Hmm.
On 2006.4.5, at 08:48 AM, Joel Rees wrote:
Not a one-liner and not even pretty, but since I needed the practice:
-
#! /usr/bin/perl
use File::Find;
@l = ( / );
sub w
{
if ( -d $_ )
{ my $dir = $File::Find::dir;
if ( system( file * | grep perl ) == 0 )
{ print *** from: $dir ***\n;
}
}
}
find( \w, @l );
-
After about two hours of running (on an old clamshell iBook) and
dredging up some really interesting stuff, it seems to have completed
without descending into /usr/bin.
Anyone have any ideas why?
Re: When does a hash of lists get defined?
On 4/4/06 Doug McNutt wrote:
While messing with CGI POSTed data I got trapped by this one.
Version 5.8.1-RC3 for Mac OS 10.3.9
It appears that the hash element D gets defined in the process of
testing to see if an element in the associated string is defined. The
last if below takes the else route.
Is that normal? Does it somehow make sense?
%phash = (); foreach $jill (A, B, C)
{ for ($lynn = 0; $lynn3; $lynn++) { $phash{$jill}[$lynn] =
$jill$lynn; print \$phash{$jill}[$lynn] = $phash{$jill}[$lynn]\n;
}
}
if (! defined $phash{D})
{ print \$phash{D} is undefined, We expected that.\n;
}
if (! defined $phash{D}[3])
It happened right here.
See perldoc perlref, especially autovivification.
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: When does a hash of lists get defined?
...
if (! defined $phash{D})
{
print \$phash{D} is undefined, We expected that.\n;
}
Instead of
defined $phash{D}
use
exists $phash{D}
This has bitten me before.
Stewart
--
Stewart Leicester | JenSoft Technologies, LLC
Per Ardua Ad Astra | mailto:[EMAIL PROTECTED]
Re: When does a hash of lists get defined?
On 4/4/06 Stewart Leicester wrote:
if (! defined $phash{D})
{
print \$phash{D} is undefined, We expected that.\n;
}
Instead of
defined $phash{D}
use
exists $phash{D}
Actually, those mean different things. Neither autovivifies, which was
what Doug was seeking to understand.
Both
defined $phash{D}[3]
and
exists $phash{D}[3]
autovivify $phash{D}.
1;
- Bruce
__bruce__van_allen__santa_cruz__ca__
