Re: Perl Tech meeting Tues Oct 14th - Shell-Shocker CGI and Perl DoS bugs
While today is a holiday for some, tomorrow is Boston.PM anyway. (Worse, next month we're on 11/11.) And Boston Perl Monger's 2nd Tuesday comes as late as possible this month, so falls the day before BLU 3rd Wednesday. (I hear some operating system also issues patches that day, doesn't affect me.) TOPIC: Shell-Shocker CGI and Perl DoS bugs DATE: Tuesday, October 14 TIME: 7:00 – 10:00 PM ROOM: E51-376 SPEAKER: Bill Ricker (lead) We will examine the implications for the ShellShock BASH bug for Perl -- it's much wider than just about BASH CGI or even Perl CGI scripts -- and also a recently discovered/fixed but comparably long-lurking Perl DoS bug in a core module (Data::Dumper stack smash CVE-2014-4330) and how is it possibly remotely triggerable. The good news is ShellShocker was slightly over-hyped; unlike Heartbleed, this one does NOT generally affect the Internet of Things, you internet-enabled toaster is likely immune. But Windows and Mac are not entirely immune to this Linux bug. [ Anyone who has examined either bug or its implications is welcome to contribute or co-present - contacting me off-list is recommended, although in our interactive style I'll cheerfully include ambush collaborators. ] Boilerplate details Tech Meetings are held on the 2nd Tuesday of every month at MIT building E51, Sloan School Tang Center [not the other Tang building!] nearer to Kendall Sq than Mass Ave. (directions http://boston-pm.wikispaces.com/MIT+Directions). Talk begins at 7:30. Refreshments in the hallway prior. RSVP for count encouraged but not required, to bill.n1...@gmail.com or Boston-PM list, by 4pm Tuesday. (NOTE: we're staying in the wider room 376 where we were in summer, after being in squarish 372 for winter/spring.) website - boston.pm.org ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
On Mon, 2009-07-13 at 22:59 -0400, Paul Lussier wrote: Lloyd Kvam pyt...@venix.com writes: You've already gotten two useful responses. I'd just like to add that typically, the object attributes are referenced directly: rect.length * rect.width Lloyd, thanks. But what if the attribute isn't set yet? If I have self.foo, and self.foo hasn't yet been set, I want it to go and get set, then return the correct value. If the initial set value is a simple constant, make it a class attribute with the default value. The object can override the attribute with a different value when that value is determined. I get the impression the __getattr__() method helps here, If the value will be computed on demand, __getattr__ is one way to go. def __getattr__(self, attr): if attr == 'foo': return self.compute_foo() elif else: raise AttributeError( attr + ' is invalid name') This is the 'traditional' approach. __getattr__ is *only* called when an attribute is not found. If you wanted to save the computed value, so that __getattr__ was no longer used: self.__dict__['foo'] = self.compute_foo() return self.foo The simplistic self.foo = self.compute_foo() will trigger a call to __getattr__, so you can't use that within __getattr__. The new-style python classes allow for cleaner dispatching of your attribute computations using properties, but for a small number of names, __getattr__ will do just fine. If there is no setter method and foo is always computed, your class could be coded: foo = property( compute_foo) I just don't quite get it yet. HTH -- Thanks, Paul -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
Lloyd Kvam pyt...@venix.com writes: If the value will be computed on demand, __getattr__ is one way to go. def __getattr__(self, attr): if attr == 'foo': return self.compute_foo() elif else: raise AttributeError( attr + ' is invalid name') This is the 'traditional' approach. __getattr__ is *only* called when an attribute is not found. If you wanted to save the computed value, so that __getattr__ was no longer used: self.__dict__['foo'] = self.compute_foo() return self.foo HTH Very much so! -- Thanks, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
On Tue, 2009-07-14 at 15:32 -0400, Joshua Judson Rosen wrote: The simplistic self.foo = self.compute_foo() will trigger a call to __getattr__, so you can't use that within __getattr__. That's not true; it *will*, however, trigger a call to __settattr__, if it exists; that's what you're thinking of :) cf. http://docs.python.org/reference/datamodel.html#object.__setattr__ __getattr__, however, is free to just do `self.foo = ...'. Thanks for the correction. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
On Sat, 2009-07-11 at 23:44 -0400, Paul Lussier wrote: How do I create dynamically created methods in python classes? For example, if I have a number of member variables which I want to get or set, I don't want to have to create getters and setters for each attribute, since the code would largely be the same, just the variable I'm dealing with would be different. You've already gotten two useful responses. I'd just like to add that typically, the object attributes are referenced directly: rect.length * rect.width to compute area. Do not use: rect.get_length() * rect.get_width(). getter/setter methods get created when you some code is needed to control access: room.celsius room.fahrenheit computes the proper value from a single stored temperature (in Kelvin?). The code still looks like a direct reference to the attribute. You have a choice of using __getattr__/__getattribute__/__setattr__ or properties as suggested in the other email responses. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
On 07/11/2009 11:44 PM, Paul Lussier wrote: In perl, I can use the AUTOLOAD feature to dynamically create methods, something like this: It looks like in perl6 you get this for free. I'm just getting started with it though. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
Lloyd Kvam pyt...@venix.com writes: You've already gotten two useful responses. I'd just like to add that typically, the object attributes are referenced directly: rect.length * rect.width Lloyd, thanks. But what if the attribute isn't set yet? If I have self.foo, and self.foo hasn't yet been set, I want it to go and get set, then return the correct value. I get the impression the __getattr__() method helps here, I just don't quite get it yet. -- Thanks, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
Paul Lussier p.luss...@comcast.net writes:
Hi Folks,
How do I create dynamically created methods in python classes?
For example, if I have a number of member variables which I want to get
or set, I don't want to have to create getters and setters for each
attribute, since the code would largely be the same, just the variable
I'm dealing with would be different.
Rather than implementing a whole bunch of similar `get_*()' and
`set_*()' methods in Python, you can just define __getattr__() and
__setattr__():
http://docs.python.org/reference/datamodel.html#object.__getattr__
How's that? Perfect fit? :)
Alternately (e.g.: something other than `getters and setters'): can't
you just create a single method that takes an `extra' parameter?
Even if you really do really want to `lots of methods' interface, I'd
still start with unified dispatcher-method--then the other methods
would just be simple wrappers, e.g.:
class C:
def do_stuff(self, key, *args):
print 'doing %s stuff...' % key
do_x = lambda self, *args: self.do_stuff('x', *args)
do_y = lambda self, *args: self.do_stuff('y', *args)
do_z = lambda self, *args: self.do_stuff('z', *args)
You could even set all of those `C.do_*' attributes (which become
methods) automatically, e.g.:
for key in ('xray', 'yankee', 'zulu'):
def do_predispatched_stuff_stuff(self, *args):
return self.do_stuff(key, *rags)
setattr(C, key, do_predispatched_stuff)
--
Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl vs. Python question...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/11/09 23:44, quoth Paul Lussier:
Hi Folks,
How do I create dynamically created methods in python classes?
For example, if I have a number of member variables which I want to get
or set, I don't want to have to create getters and setters for each
attribute, since the code would largely be the same, just the variable
I'm dealing with would be different.
In perl, I can use the AUTOLOAD feature to dynamically create methods,
something like this:
sub AUTOLOAD {
my ($self, @args) = @_;
my $method = $AUTOLOAD;
$method =~ s/.*:://;
if ($method ne 'DESTROY') {
# Return the structure/value pointed to by $self-{KEY}, or, set it
# if it's not a ref to something else.
if (exists $self-{_$method} !ref($self-{_$method})) {
eval(*$AUTOLOAD =
. sub {
. my (\$self, \$value) = assertMinMaxArgs(1, 2, \...@_);
. if (\$value) {
. \$self-{\_\$method\} = \$value;
. }
. return \$self-{\_\$method\}
. });
}
goto $AUTOLOAD;
}
}
What this AUTOLOAD sub does is this:
- First, it strips everything before the :: leaving just the methodname
(in perl, method names look like: CLASS::method() )
- Then, it looks to see if there exists a member variable
$self-{_foo}, and that it's not a reference to something
- Then, it creates an anonymous sub (== a lambda in python I think)
Each anonymous sub looks like this:
sub {
my ($self, $value) = assertMinMaxArgs(1, 2, @_);
if ($value) {
$self-{_$method} = $value;
}
return $self-{_$method}
Essentially, it works like this. If I have a member variable _foo, and
I want to either set or get _foo, I call a method $self-foo(). If I
call it as $self-foo(bar), the _foo gets set to bar, otherwise, I get
back the current value of _foo. So, the anonymous sub above, gets
re-written as:
sub foo {
my ($self, $value) = assertMinMaxArgs(1, 2, @_);
if ($value) {
$self-{_foo} = $value;
}
return $self-{_foo}
I can basically create 1 method which will automagically create for me,
getter and setter methods for any member variable I create in my class.
(this is extremely similar, if not identical, to lisp macros!)
For some reason I didn't think python had this capability, but someone
mentioned to me it did, but I'm not quite sure how I'd write it.
Does anyone have any ideas?
In the Python Coookbook, on (my) page 252 is a section called Section 6.8:
Avoiding Boilerplate Accessors for Properties.
http://www.ubookcase.com/book/Oreilly/Python.Cookbook.2nd.edition/0596007973/pythoncook2-chp-6-sect-8.html
The code they provide is this:
def xproperty(fget, fset, fdel=None, doc=None):
if isinstance(fget, str):
attr_name = fget
def fget(obj): return getattr(obj, attr_name)
elif isinstance(fset, str):
attr_name = fset
def fset(obj, val): setattr(obj, attr_name, val)
else:
raise TypeError, 'either fget or fset must be a str'
return property(fget, fset, fdel, doc)
but the discussion is important to read and fully understand before you think
you can just plug it in.
- --
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkpaP+kACgkQRIVy4fC+NyRqtQCeLV5oscJqOGQ0zME7KXjvM8n2
HZsAn1OcpB0aif6K1rTbchwdV7GDzn7k
=gJni
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
On 9/13/07, Paul Lussier [EMAIL PROTECTED] wrote:
For all those just tuning in, Ben and I are in violent and vocal
agreement with each other, and at this point are merely quibbling over
semantics :)
Hey, now, I came here for an argument, and I demand to get one! And
it better be more than just simple contradiction, too. I expect a
connected series of statements intended to establish a proposition!
;-)
(And they say Perl and Python have nothing in common. ;-) )
To avoid LTS and backslashitis in a regexp, I tend to do something like:
m|/foo/bar|/bar/baz|g;
The pipe (|) is another often-used regexp syntax character, though.
If I was going to use a single alternate character for m//, I'd prolly
use a bang (!). But I like balanced pairs -- {} or or [] or or ()
-- because they nicely identify the start and end of the thing, rather
than simply delimiting it. And if it's a substitution, they let you
separate the pattern from the replacement with whitespace. I
frequently use that to line things up for visual structure (e.g., that
condense_type() function I posted).
Agreed, though, we ... do things like this slightly differently,
completely avoiding the $_ dilemma:
That actually wouldn't work for the code I posted, which is
performing multiple transformations on the same string repeatedly.
The fact that you missed that concerns me. *That's* a sign of
inadequate clarity. Looking at the code, I don't see a way to make
that clearer in the code itself, so I guess it needs a comment to that
effect. Phooey. (In my thinking, ideal code needs *no* comments,
because it's so obvious what's going on. Obviously, that's a
theoretical ideal, and not something that happens in practice, but I
think it makes a good goal.)
Unrelated to the above, I think there is an observation to be made
here about sophisticated solutions also adding complexity. KISS, as
the saying goes. By introducing variables and loops and control
structures, you're making things more complex, to no gain that I can
see. A simple list of s/// operations does the same thing, and does
not require any additional cognition on the part of the reader. (It
might even be more efficient at runtime, although that would depend on
how smart Perl's optimizer is.)
... by we, I mean the company which currently puts food on my table ...
I didn't know Stop and Shop used Perl... ;-)
Once readability has been achieved, the next
priority ought to be future maintenance and extensibility, IMO.
Yup.
Alas, assertNumArgs() is a part of a huge
home-grown library of routines we have.
Everybody has these. They're extremely useful.
The compelling argument is this: It should be blatantly obvious to
whomever is going to be maintaining your code in 6 months what you
were thinking
I do not think I could agree with you more here. The thing you seem
to be ignoring in my argument is that clarity is subjective and
often depends on context. :)
I'm not ignoring it. I'm saying that where you have stopped because
you think it is sufficiently clear can in fact be made cleaner and
clearer for the sakes of both clarity and future maintenance.
No, I'm saying that clarity is subjective and depends on context,
and what you deem clearer I deem less clear.
There are only a finite number of options for any given command [such as
tar]. The
same is not true for writing perl code.
True, but I think my point still stands. Verbosity does not equal
clarity, and indeed, verbosity sometimes interferes with readability.
(My choice of tar was, perhaps, a bad example, because I do agree
with your argument WRT to your AMANDA example.)
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
On Thu, 2007-09-13 at 23:58 -0400, Paul Lussier wrote: For all those just tuning in, Ben and I are in violent and vocal agreement with each other, and at this point are merely quibbling over semantics :) As an old Python guy who knows just enough Perl to get it wrong, this has been educational (and even fun). Thanks. -- Lloyd Kvam Venix Corp ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
I highly recommend Damian Conway's book of same title, Perl Best Practices, which recommends a much tamer, consistent readable style within a workgroup than he uses in his own code (depending on context) -- he suggests one style but encourages each group to decide for themselves and take his list of 255 practices as a template for their own local standard. http://www.oreilly.com/catalog/perlbp/ -- Bill [EMAIL PROTECTED] [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
Bill Ricker writes: I highly recommend Damian Conway's book of same title, Perl Best Practices, which recommends a much tamer, consistent readable style within a workgroup than he uses in his own code (depending on context) -- he suggests one style but encourages each group to decide for themselves and take his list of 255 practices as a template for their own local standard. I will second this. Great book by a great author. Regards, --kevin -- GnuPG ID: B280F24E Error messages alumni.unh.edu!kdc strewn across my terminal. A vein starts to throb. -- Coy.pm ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
[EMAIL PROTECTED] (Kevin D. Clark) writes: Bill Ricker writes: I highly recommend Damian Conway's book of same title, Perl Best Practices, which recommends a much tamer, consistent readable style within a workgroup than he uses in his own code (depending on context) -- he suggests one style but encourages each group to decide for themselves and take his list of 255 practices as a template for their own local standard. I will second this. Great book by a great author. Ahm, fellas, we've got a fence-post error here :) This response to Ben is what started all it all: Paul Lussier [EMAIL PROTECTED] writes: Ben Scott [EMAIL PROTECTED] writes: You don't need to put parenthesis around arguments to split, and you don't need to explicitly specify the default pattern match target ($_). Unfortunately, you both don't *need* to and *can* do anything in perl. Often at the same time! This is what leads to very difficult to read, and more difficult to maintain perl code. [...] I highly recommend Damian Conway's book Perl Best Practices, which outlines these and many other useful pieces of advice. So, Kevin is really thirding ;) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
Lloyd Kvam [EMAIL PROTECTED] writes: On Thu, 2007-09-13 at 23:58 -0400, Paul Lussier wrote: For all those just tuning in, Ben and I are in violent and vocal agreement with each other, and at this point are merely quibbling over semantics :) As an old Python guy who knows just enough Perl to get it wrong, this has been educational (and even fun). I'm glad you enjoyed it! That's why I wrote it. I feel that perl has a bad reputation for being ugly. I believe it's a myth. One can write ugly code in any language. Python went so far as to put white space restrictions place to enforce clean code. While that may work to some extent, I've seen ugly python code. I, by no means, claim my way is the best or only way. I don't even claim what I posted will work completely correctly. I was merely trying to demonstrate that there are better ways to write any code such that it is both elegant and pleasing to look at as well as maintain and extend. I would love to see other's interpretations of Ben's code, in any language. How would you accomplish the same in awk, python, ruby, java, C, etc.? -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
On 9/13/07, John Abreau [EMAIL PROTECTED] wrote: s/^[\x20\t]*//; # trim leading space s/[\x20\t]*$//; # trim trailing space Any particular reason to use [\x20\t] instead of \s ? \s would also eat newlines and similar. At a minimum, it would have to explicitly print with \n and use the -n switch instead of the -p switch. Which would be fine. But if the file contains non-native line endings, it can result in those getting mangled, or so I've found. I've got a lot of such files hanging around on my system. Just eating space and tab worked better for me. OTOH, \s should eat other kinds of in-line whitespace that might be encountered, including anything Unicode dishes up. So that might be better for some situations. YMMV. Or, since this is Perl we're talking about: TIMTOWTDI. ;-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
Ben Scott [EMAIL PROTECTED] writes:
Personally, in the proper context, I find this:
When writing code which will be used, looked at, modified, and
maintained by no one else, doing whatever makes you happy and more
efficient makes sense, and is more efficient and expedient.
When writing code which will be used, looked at, modified, and
maintained by a group of people, it is best to agree upon and strictly
adhere to a common set of coding standards. This makes the entire
group more eficient. The personal likes and/or dislikes of anyone
person may or may not bother anyone else in the group.
@foo = split m{blah};
to be easier to read and comprehend at a glance than this:
@foo = split (m{blah}, $_);
I find both of these bothersome :) *I* prefer:
@foo = split (/blah/);
or: @foo = split (/blah/, $actualVariableName);
The former implies $_, which need not be explicitly stated in this case.
The latter clearly denotes where you're getting your data from.
$_ has a *lot* of magical properties which can really screw things up,
especially in cases like:
map { grep { ... $_ } $_ } @foo;
Which $_ is which, and where is each getting it's data from? This is
where the use of named variables I find to be better than just
depending upon built-ins like $_.
Explicitly specifying $_ over and over again just clutters up the
code with pointless syntax. It's one more thing my brain has to
recognize and process.
Right, which is why you shouldn't depend upon $_ in these contexts and
explicitly state a variable name (which should also be my'ed into the
proper scope :)
I don't arbitrarily assign to $_ and use it at random, the way some
people do. And I do make use of parenthesis, braces, and such, even
when they are not needed, when I find it makes the code clearer. But
I also leave them out when I find it makes the code clearer.
No arguments with that. In general, IMO, clarity is of the utmost
importance. There are many best practices which can help aid
clarity though. I find one such practice is to always use func(args)
because it makes it blatantly obvious you're calling a function.
(perhaps the one exception is with print, but even then, I find myself
very often using it there too. To me:
print (join(\s, Some text, func(args), more text,),
\n
);
is far more readable than
print join , Some text, func(args), more text, \n;
In the former, if I need to add stuff to the join, it's blatantly
obvious where it goes. In the latter, it is not.
For a slightly less contrived example, take a script which trims
leading and trailing whitespace from each line in an input file. I
already have one implementation, and I just wrote up another one.
[...]
Assuming the reader is familiar with the language, which do you
think will be easier/quicker to comprehend?
Both of these hurt my eyes! :)
This one is short and sweet:
#!/usr/bin/perl -wp
s/^[\x20\t]*//; # trim leading space
s/[\x20\t]*$//; # trim trailing space
but I'd rewrite it as:
#!/usr/bin/perl -p
s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
For a script which optionally took stdin, I'd write it as:
#!/usr/bin/perl -w
use English;
my $file = shift;
my $FH;
if (!$file) {
*FH = *STDIN;
} else {
open(FH, $file) || die(Could not open $file: $ERRNO\n;
}
while (my $line = FH) {
$line =~ s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
print($line\n);
}
close(FH);
It may be true that someone who *isn't* familiar with Perl would
find it easier to puzzle out the meaning of the longer version.
I'm fairly comfortable with perl. I could puzzle out the meaning
fairly easily. And I'll even concede that as far as most perl, it's
pretty good. But, as is true I'm sure even with my own code, there's
always room for improvement :)
(/me waiting for Kevin to pipe in here in 4...3...2...1... ;)
But I don't find that a particularly compelling argument.
The compelling argument is this: It should be blatantly obvious to
whomever is going to be maintaining your code in 6 months what you
were thinking :) The easier you make it up front to read your code and
discern your mindset, the less time it take the maintainer in 6
months. Many times, that future maintainer is *you* :)
I write Perl programs with the assumption that the reader
understands Perl, the same way I am assuming readers of this message
understand English. :)
Ahh, yes. But as the superintendent of the Lawrence, MA, School
system has recently shown, even those who *claim* to know the
language, often times are just fooling themselves. Just axe him :)
This may mean Perl, as practiced, is harder to learn than a language
which is more rigid and always verbose.
I think perl is incredibly easy to learn if you learn from a good
source. The documentation is one such source. Other people's code is
most often NOT a good source!
Many say similar things
Re: Perl best practices
Paul Lussier writes: (/me waiting for Kevin to pipe in here in 4...3...2...1... ;) Ben and Paul are competent Perl programmers. They write good code. Code should be written to be clear. While it is nice if code written in a given language is understandable by people who don't know the language, this property isn't guaranteed. Cryptic one-liners can be hard to follow, but they can also be beautiful and useful. If I write anything else, it would just be a combination of me nit-picking for no purpose and hot air. Kind regards, --kevin -- GnuPG ID: B280F24E It is best to forget the great sky alumni.unh.edu!kdc And to retire from every wind -- Mumon ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
On 9/13/07, Paul Lussier [EMAIL PROTECTED] wrote:
When writing code which will be used, looked at, modified, and
maintained by a group of people, it is best to agree upon and strictly
adhere to a common set of coding standards.
Yes. But when the designated group of people is all of humanity,
the problem of agreeing on said standards becomes difficult. :)
I find both of these bothersome :) *I* prefer:
@foo = split (/blah/);
Er, yes. blah in this case was meta-syntactic, and I was still
thinking of the first example in this discussion, which had LTS
(Leaning Toothpick Syndrome). I will use // if the regexp doesn't
suffer from LTS. I use m{} or s{}{} when the regexp otherwise
contains slashes.
@foo = split (/blah/);
@foo = split (/blah/, $actualVariableName);
The former implies $_, which need not be explicitly stated in this case.
Right. That's exactly what I was saying. ;-)
map { grep { ... $_ } $_ } @foo;
Which $_ is which, and where is each getting it's data from?
Like I said, I use things like parenthesis, braces, named variables,
etc., liberally when I find the meaning/intent is not obvious in
context. But it's a case-by-case call, not an absolute, inviolable
rule.
A foolish consistency is the hobgoblin of little minds. -- Ralph
Waldo Emerson
As a completely non-contrived example, here is an illustration of
when I think implicit use of $_ is very appropriate. It's from a
Squid log analysis tool I wrote, where I wanted to condense the MIME
content type into something smaller and more appropriate for a log
report. Here's the code (as usual, view in a monospace font to get
this to line up properly):
sub condense_type($) {
# condense a MIME content type to something shorter, for people
$_ = $_[0];
s{^text/plain$} {text};
s{^text/html$} {html};
s{^text/css$} {css};
s{^text/javascript$}{jscript};
s{^text/xml$} {xml};
s{^text/} {};
s{^image/.*}{image};
s{^video/.*}{video};
s{^audio/.*}{audio};
s{^multipart/byteranges}{bytes};
s{^application/}{};
s{^octet-stream$} {binary};
s{^x-javascript$} {jscript};
s{^x-shockwave-flash$} {flash};
s{\*/\*}{stars};# some content gets marked */*
return $_;
}
I could have used a regular named variable (say, $type) and repeated
$type =~ over and over again for 14 lines. I believe that would
actually harm the readability of the code. I find it clearer with use
of implicit $_, because it puts the focus on the fact that I'm doing a
bunch of transformations on the same thing, over and over again.
As a counter-example from the same script, here's something using
explicit names and grouping which isn't strictly needed, because I
find it clearer:
sub condense_size($) {
# consense a byte-count into K/M/G
my $size = $_[0];
if($size $gigabyte) { $size = ($size / $gigabyte) . G; }
elsif ($size $megabyte) { $size = ($size / $megabyte) . M; }
elsif ($size $kilobyte) { $size = ($size / $kilobyte) . K; }
return $size;
}
Explicitly specifying $_ over and over again just clutters up the
code with pointless syntax. It's one more thing my brain has to
recognize and process.
Right, which is why you shouldn't depend upon $_ in these contexts and
explicitly state a variable name ...
A named variable would be *two* more things. ;-)
s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
Er, yah, that would be even better. Not sure why I didn't just use
s/// with /g when I wrote that the first time around.
(The actual script in my ~/bin/ has several lines of comments
explaining certain design decisions, but that's one one of them.)
my $file = shift;
You're using an implicit argument to shift there. ;-)
The compelling argument is this: It should be blatantly obvious to
whomever is going to be maintaining your code in 6 months what you
were thinking
I do not think I could agree with you more here. The thing you seem
to be ignoring in my argument is that clarity is subjective and
often depends on context. :)
I write Perl programs with the assumption that the reader
understands Perl ...
... even those who *claim* to know the language, often times are
just fooling themselves.
I'm not going to penalize the competent because there are others who
are incompetent.
Many say similar things about Unix. Or Emacs. :-) I'm don't argue
that one approach is right and the other wrong, but I do think that
both approaches have their merits.
Which approaches are you talking about? Approaches to learning, or to
writing?
Yes. :)
Let me restate: A pattern which is powerful and easy-to-use is
sometimes unavoidably non-obvious.
Or perhaps an example of a similar principle in a different context:
When invoking tar from a shell script, which of the following do you
prefer?
tar --create --gzip --verbose --preserve-permissions
--file=/path/to/file.tar.gz /etc
tar
Re: Perl best practices
On 13 Sep 2007 12:10:58 -0400, Kevin D. Clark [EMAIL PROTECTED] wrote: If I write anything else, it would just be a combination of me nit-picking for no purpose and hot air. Welcome to the Internet! ;-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices
For all those just tuning in, Ben and I are in violent and vocal
agreement with each other, and at this point are merely quibbling over
semantics :)
Ben Scott [EMAIL PROTECTED] writes:
Er, yes. blah in this case was meta-syntactic, and I was still
thinking of the first example in this discussion, which had LTS
(Leaning Toothpick Syndrome). I will use // if the regexp doesn't
suffer from LTS. I use m{} or s{}{} when the regexp otherwise
contains slashes.
Something about the use {} and () in regexps really bothers me. I
think it's because in general, perl overloads too many things to begin
with. To use {} for regexp delimiting is confusing and completely
non-intuitive to me. They are meant to denote either a hash element or
a code block. Trying to make my mind use them for regexps hurts :)
To avoid LTS and backslashitis in a regexp, I tend to do something like:
m|/foo/bar|/bar/baz|g;
The | is close enough to / that it's instantly clear to me.
A foolish consistency is the hobgoblin of little minds. -- Ralph
Waldo Emerson
Yeah, what the old, dead guy said :)
As a completely non-contrived example, here is an illustration of
when I think implicit use of $_ is very appropriate.
[...]
sub condense_type($) {
# condense a MIME content type to something shorter, for people
$_ = $_[0];
s{^text/plain$} {text};
s{^text/html$} {html};
s{^text/css$} {css};
s{^text/javascript$}{jscript};
s{^text/xml$} {xml};
s{^text/} {};
s{^image/.*}{image};
s{^video/.*}{video};
s{^audio/.*}{audio};
s{^multipart/byteranges}{bytes};
s{^application/}{};
s{^octet-stream$} {binary};
s{^x-javascript$} {jscript};
s{^x-shockwave-flash$} {flash};
s{\*/\*}{stars};# some content gets marked */*
return $_;
}
I could have used a regular named variable (say, $type) and
repeated $type =~ over and over again for 14 lines. I believe
that would actually harm the readability of the code.
Agreed, though, we (by we, I mean the company which currently puts
food on my table :) do things like this slightly differently,
completely avoiding the $_ dilemma:
$match = shift;
%mimeTypes =
('^text/plain$' = text ,
'^text/html$' = html ,
'^text/css$'= css ,
'^text/javascript$' = jscript,
'^text/xml$'= xml ,
'^text/'= ,
'^image/.*' = image ,
'^video/.*' = video ,
'^audio/.*' = audio ,
'^multipart/byteranges' = bytes ,
'^application/' = ,
'^octet-stream$'= binary ,
'^x-javascript$'= jscript,
'^x-shockwave-flash$' = flash ,
'*/*' = stars ,# some content gets marked */*
);
foreach my $mtype (keys %mimeTypes) {
if ($mtype =~ /$match/)
return $mimeType{$mtype};
}
}
Also, the foreach could be written as:
map { ( $match =~ /$_/) return $mimeTypes{$_}} keys %mimeTypes
Though I find this completely readable, it suffers from the problem
that it's not easily extensible. If you decide you need to do more
processing within the loop, the foreach is much easier to extend. You
just plonk another line in there and operate on the already existing
variables. With the map() style loop, this becomes more difficult.
So, though I love map(), I would have to argue this is not the best
place to use it. Once readability has been achieved, the next
priority ought to be future maintenance and extensibility, IMO.
As a counter-example from the same script, here's something using
explicit names and grouping which isn't strictly needed, because I
find it clearer:
sub condense_size($) {
# consense a byte-count into K/M/G
my $size = $_[0];
if($size $gigabyte) { $size = ($size / $gigabyte) . G; }
elsif ($size $megabyte) { $size = ($size / $megabyte) . M; }
elsif ($size $kilobyte) { $size = ($size / $kilobyte) . K; }
return $size;
}
I tend to like this style too, though I'd use a slightly different
syntax. It's otherwise exactly the same.
my $size = shift;
($size $gigabyte) { return (($size/$gigabyte) . G)};
($size $megabyte) { return (($size/$megabyte) . M)};
($size $kilobyte) { return (($size/$kilobyte) . K)};
Or, perhaps, if you wanted to be a little more cleverer:
my %units = ($gigabyte = sub { int($_[0]/$gigabyte) . 'G'},
$megabyte = sub { int($_[0]/$megabyte) . 'M'},
$kilobyte = sub { int($_[0]/$kilobyte) . 'K'},
);
foreach my $base (sort {$b = $a } keys %units) {
if ($size $base) {
print ($units{$base}-($size),\n);
last;
}
}
This last approach is both too clever by 1, but also, slightly easier
to maintain, given that to add another size, you add one line. You
can even add the one line anywhere you want in the hash.
Re: Perl best practices (was: question ... Split operator in Perl)
On Wed, September 12, 2007 9:37 pm, Ben Scott said: s/^[\x20\t]*//; # trim leading space s/[\x20\t]*$//; # trim trailing space Any particular reason to use [\x20\t] instead of \s ? -- John Abreau / Executive Director, Boston Linux Unix IM: [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: perl - sometimes it *does* resemble line noise... (long)
Paul Lussier writes:
And there you have it. 'return map {...} map {...} grep {...}
split(...);' Short, concise, no need for a bunch of temp variables
that only get used once and thrown away. I like it. Others, well,
not so much :)
If this is production code (not write-once code) in my opinion the
original version of the code that you presented is preferable.
I say this, of course, as somebody who is an enthusiastic Perl
programmer. Code that is hard to understand and maintain will
eventually either get rewritten or junked.
Just another Perl hacker,
--kevin
--
GnuPG ID: B280F24E And the madness of the crowd
alumni.unh.edu!kdc Is an epileptic fit
-- Tom Waits
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl - sometimes it *does* resemble line noise... (long)
[EMAIL PROTECTED] (Kevin D. Clark) writes:
Paul Lussier writes:
And there you have it. 'return map {...} map {...} grep {...}
split(...);' Short, concise, no need for a bunch of temp variables
that only get used once and thrown away. I like it. Others, well,
not so much :)
If this is production code (not write-once code) in my opinion the
original version of the code that you presented is preferable.
As I stated earlier on in the post, what I started with and ended up
with was largely the same. The multi-map/grep/split thing was the
result of a couple refactorings before I came to the same conclusion
:)
I say this, of course, as somebody who is an enthusiastic Perl
programmer. Code that is hard to understand and maintain will
eventually either get rewritten or junked.
Yep, that's why I ended up using a bunch of temp. variables in the
end. Readability/maintainability was enhanced greatly at little/no
cost.
--
Seeya,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Stephen Ryan writes: Ooh, here's something interesting. I first tried a test with constants, and got the warning: left shift count = width of type out of gcc. Then I rewrote the thing to use a loop, and I got correct results out of it. (This is all on an Athlon64X2.) When you described getting the same results for 0 and 32, I tried it again on my wife's laptop, a Celeron M, and got the same results you did; just out of curiosity, I looked it up, and gcc generates a 'sall' instruction to do the actual bit-shift, which on the 80386, PIII and Celeron M (according to Intel's documentation, your test, and my test, respectively) all ignore everything but the low 5 bits on the shift count. The 64-bit Athlon64 apparently doesn't, though, even though I'm supposedly running in 32-bit compatibility mode. Huh. Yet another demonstration of the dangers of of assuming specific bit-sizes for int, I suppose. Another thing to be aware of (but which hasn't come up...yet...in this thread) is that all of the test code that I see here uses signed integers for the bit operations (~ etc.). The C spec. specifically states that the results of such expressions is system dependent (and hence unportable). That warning message you saw was gcc doing an OK job warning you of a possible problem. When you added the loop you bamboozled the compiler, but the underlying issue (however small) still remained. Just another compiler guy... --kevin -- GnuPG ID: B280F24E And the madness of the crowd alumni.unh.edu!kdc Is an epileptic fit -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Thu, 2006-03-30 at 20:35 -0500, Jason Stephenson wrote:
Paul Lussier wrote:
Yes, more or less. Between you and Jason I've been able to come up
with exactly what I need. Thanks a lot for all your help. Why I
couldn't see this for myself is beyond me. Of course, this week has
been full of me missing the details to the point where I somehow
managed to mail my taxes to myself from work the other day rather than
to my accountant :) So, just in case you wondered, the USPS system is
working at peak efficiency !
You're very welcome to the help, and we all have those weeks. It took me
a while to realize what your real question was.
Once I figured out your question, it was actually rather interesting:
adding network addresses to interpolate between different networks.
Trying to answer it allowed me to discover some facts about IPv4
addresses and masks, so I got to learn something, too.
The thing that I found most interesting is if you use the one or two
digit kind of mask, i.e. /19, you can determine how many addresses are
on the network via the following C code: addresses = 1 (32 - n).
Where n is the part of the mask after the /.
I wish I could find a faster way to blit the bits to make the real
mask from the /N style than using a for loop. Only alternative I can
think of is to use a switch on the 33 possibilities (0-32).--Of course,
anything /8 and /30 doesn't make a real network.
Can anyone think of a better way to blit an arbitrary number of bits
from 0 to 1?
Well, let's see
Taking advantage of the fact that all of the '1' bits are at the end of
the hostmask, you've actually almost gotten it already.
hostmask = (1 (32 - n)) - 1
netmask = ~ hostmask
1 (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0'
bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1'
bits. The 'not' operator flips all the bits for the netmask.
This works for /1 through /32 networks, even though some of those are
nonsensical. A /0 might break this because of overflow (1 (32 -n)
overflows a 32-bit integer); theoretically, it should work even for /0
so long as 1 (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop
computes this correctly, but complains 'warning: left shift count =
width of type' while compiling. Anyway, if you're running a /0, you've
got other, bigger problems.
Now, I'm working on a network calculator application that will support
IPv6 as well. I should probably do it in JavaScript, uh, sorry, AJAX, so
that the Web 2.0 people will notice. ;)
Cheers,
Jason
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
#include stdio.h
int main()
{
int n;
int netmask,hostmask;
for (n=0;n=32;n++)
{
hostmask = (1 (32 -n)) - 1;
netmask = ~hostmask;
printf(n: %d netmask: 0x%08x hostmask: 0x%08x\n,n,netmask,hostmask);
}
return 0;
}
Re: perl and network addresses
Stephen Ryan wrote: Can anyone think of a better way to blit an arbitrary number of bits from 0 to 1? Well, let's see Taking advantage of the fact that all of the '1' bits are at the end of the hostmask, you've actually almost gotten it already. hostmask = (1 (32 - n)) - 1 netmask = ~ hostmask Doh! That's so obvious, so obviously, I overlooked it. ;) 1 (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0' bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1' bits. The 'not' operator flips all the bits for the netmask. This works for /1 through /32 networks, even though some of those are nonsensical. A /0 might break this because of overflow (1 (32 -n) overflows a 32-bit integer); theoretically, it should work even for /0 so long as 1 (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop computes this correctly, but complains 'warning: left shift count = width of type' while compiling. Anyway, if you're running a /0, you've got other, bigger problems. Using gcc 3.4.4 on a 32-bit Pentium III, I get no warnings when compiling your test program, even with -Wall. When it runs, 0 gives the same result as 32, so it overflows (silently) on my machine. If you're running a /0, you really must be Root. ;) I'm going to limit the input on my network calculator and throw an error on IPv4 net masks that are not between /8 and /30 inclusive. The reason being that /8 and /30 don't really give valid IPv4 networks. Cheers and thanks, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Fri, 2006-03-31 at 21:00 -0500, Jason Stephenson wrote: Stephen Ryan wrote: hostmask = (1 (32 - n)) - 1 netmask = ~ hostmask Doh! That's so obvious, so obviously, I overlooked it. ;) Well, yes, of course :-) 1 (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0' bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1' bits. The 'not' operator flips all the bits for the netmask. This works for /1 through /32 networks, even though some of those are nonsensical. A /0 might break this because of overflow (1 (32 -n) overflows a 32-bit integer); theoretically, it should work even for /0 so long as 1 (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop computes this correctly, but complains 'warning: left shift count = width of type' while compiling. Anyway, if you're running a /0, you've got other, bigger problems. Using gcc 3.4.4 on a 32-bit Pentium III, I get no warnings when compiling your test program, even with -Wall. When it runs, 0 gives the same result as 32, so it overflows (silently) on my machine. Ooh, here's something interesting. I first tried a test with constants, and got the warning: left shift count = width of type out of gcc. Then I rewrote the thing to use a loop, and I got correct results out of it. (This is all on an Athlon64X2.) When you described getting the same results for 0 and 32, I tried it again on my wife's laptop, a Celeron M, and got the same results you did; just out of curiosity, I looked it up, and gcc generates a 'sall' instruction to do the actual bit-shift, which on the 80386, PIII and Celeron M (according to Intel's documentation, your test, and my test, respectively) all ignore everything but the low 5 bits on the shift count. The 64-bit Athlon64 apparently doesn't, though, even though I'm supposedly running in 32-bit compatibility mode. Huh. Yet another demonstration of the dangers of of assuming specific bit-sizes for int, I suppose. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Ben Scott [EMAIL PROTECTED] writes: The 10.0.32/19 is an interesting beast. The systems which live on it have 2 NICs, the primary eth0, which *always* have a 10.0.32/19 based address (currently restricted to 10.0.33/24 for some reason?!), As far as that restriction goes, I've read of crufty old code which assume everything follows the old classful model, with strict boundaries even for subnets. It might be that. To be honest, I think it's more that we just don't have more 255 hosts on that network... yet. We're about to get 50 more systems in which will bring us up to 251. After that, things may well get interesting :) As for the rest... wow... funky. I do hope all that multi-homing to the same network is for test/simulation procedures. :) Pretty much. It's to simulate how our product actually works. Though, our product uses this type of setup in a very restricted and controlled manner on a backend, completely separate and private network. In theory, one installation of our product could approach 255+ hosts in a single installation, in practice, the number of hosts in a single install is rarely more than 10. Okay, in return for taking the time and effort to explain all that, I took the time to figure out how to get Perl to convert IP addresses. Hopefully the following sample code will help you out: [ code elided ] Is that even close to what you were thinking of? Yes, more or less. Between you and Jason I've been able to come up with exactly what I need. Thanks a lot for all your help. Why I couldn't see this for myself is beyond me. Of course, this week has been full of me missing the details to the point where I somehow managed to mail my taxes to myself from work the other day rather than to my accountant :) So, just in case you wondered, the USPS system is working at peak efficiency ! -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Yes, more or less. Between you and Jason I've been able to come up with exactly what I need. Thanks a lot for all your help. Why I couldn't see this for myself is beyond me. Of course, this week has been full of me missing the details to the point where I somehow managed to mail my taxes to myself from work the other day rather than to my accountant :) So, just in case you wondered, the USPS system is working at peak efficiency ! You're very welcome to the help, and we all have those weeks. It took me a while to realize what your real question was. Once I figured out your question, it was actually rather interesting: adding network addresses to interpolate between different networks. Trying to answer it allowed me to discover some facts about IPv4 addresses and masks, so I got to learn something, too. The thing that I found most interesting is if you use the one or two digit kind of mask, i.e. /19, you can determine how many addresses are on the network via the following C code: addresses = 1 (32 - n). Where n is the part of the mask after the /. I wish I could find a faster way to blit the bits to make the real mask from the /N style than using a for loop. Only alternative I can think of is to use a switch on the 33 possibilities (0-32).--Of course, anything /8 and /30 doesn't make a real network. Can anyone think of a better way to blit an arbitrary number of bits from 0 to 1? Now, I'm working on a network calculator application that will support IPv6 as well. I should probably do it in JavaScript, uh, sorry, AJAX, so that the Web 2.0 people will notice. ;) Cheers, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Paul Lussier [EMAIL PROTECTED] wrote:
It's confusing.
Sure is! Wow, that's one wacky setup. :)
The 10.0.32/19 is an interesting beast. The systems which live on it
have 2 NICs, the primary eth0, which *always* have a 10.0.32/19
based address (currently restricted to 10.0.33/24 for some reason?!),
As far as that restriction goes, I've read of crufty old code which
assume everything follows the old classful model, with strict
boundaries even for subnets. It might be that.
As for the rest... wow... funky. I do hope all that multi-homing to
the same network is for test/simulation procedures. :)
Okay, in return for taking the time and effort to explain all that,
I took the time to figure out how to get Perl to convert IP addresses.
Hopefully the following sample code will help you out:
!/usr/bin/perl -w
use Socket qw(inet_aton inet_ntoa);
# address and mask in ASCII decimal dotted-quad notation
$addr = '10.0.32.42';
$mask = '255.255.224.0'; # 19
print (addr: $addr/$mask\n);
# convert to string (which is really the four bytes of a 32-bit int)
$addr = inet_aton($addr);
$mask = inet_aton($mask);
# convert to native integers
# the 'N' tells unpack the string is 32-bit int, network order)
$addr = unpack('N', $addr);
$mask = unpack('N', $mask);
# use binary math to mask out net and host parts
$net = $addr $mask;
$host = $addr ~$mask; # ~$m = complement of mask (binary NOT)
# convert to string form
$net = pack('N', $net);
$host = pack('N', $host);
# convert to ASCII dotted-quad notation
$host = inet_ntoa($host);
$net = inet_ntoa($net);
# survey says...
print (net : $net\n);
print (host: $host\n);
Is that even close to what you were thinking of?
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Python [EMAIL PROTECTED] writes: Would it help to convert to 32-bit integers? I might. I'll try that. I think I understand the arithmetic. I do not really understand what you are trying to do. That's okay, neither do I ;) (If you really want the long convoluted discussion, I'll be glad to post it, I just figured no on would care. Of course, I also often misunderstimate the intellectual curiosity of fellow geeks :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Ben Scott [EMAIL PROTECTED] writes: I tried perl -we '$a = inet_addr(192.0.2.42);' but it complained that inet_addr is not defined. I suspect there's a module somewhere you need to pull in. Hopefully this is enough to get you started. You likely need to use -MSocket, and then figure out which of the correct functions in there are analogous to inet_addr. The ones which leap to mind are inet_ntoa and inet_aton. There doesn't seem to be an inet_addr. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Python [EMAIL PROTECTED] writes: Would it help to convert to 32-bit integers? I might. I'll try that. It will definitely help. If you get the netmask and address both in 32-bit integers, then calculating the network and broadcast addresses is very straightforward. Here's some sample code: network = address netmask; broadcast = address | ~netmask; The above is C, but should work in Perl, too. Of course, after looking back through the thread, I see Ben has already pretty much answered the above. ;) I think I understand the arithmetic. I do not really understand what you are trying to do. That's okay, neither do I ;) (If you really want the long convoluted discussion, I'll be glad to post it, I just figured no on would care. Of course, I also often misunderstimate the intellectual curiosity of fellow geeks :) I think Paul explained it pretty well in his first post. Let me explain to see if I really understand. Paul is using a network that is restricted to using a /19 netmask for addressing, but it is really using a /16 when configured. So, he wants to limit address to 10.0.32.0/19 but needs to configure broadcast and network addresses for 10.0.32.0/16. Why he needs to do that, I have no idea and wouldn't need to know. ;) Ben's previous message pretty much explains how to solve this. It seems to me that the answer is that your IP addresses are limited to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network address and 10.255.255.255 being the broadcast address, no? Cheers, Jason ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Paul Lussier [EMAIL PROTECTED] wrote: If you really want the long convoluted discussion, I'll be glad to post it, I just figured no on would care. Well, everyone here knows *I* thrive on long, convoluted discussions. I'm also curious if you're trying to route packets through a non-existant gateway again. ;-) perl -we '$a = inet_addr(192.0.2.42);' but it complained that inet_addr is not defined. You likely need to use -MSocket, and then figure out which of the correct functions in there are analogous to inet_addr. The ones which leap to mind are inet_ntoa and inet_aton. There doesn't seem to be an inet_addr. Hmmm Well, I just tried that quickly, but it looks like Perl's inet_aton() function results in something that Perl thinks is a string, not a long integer. (Probably because inet_aton() is defined in terms of a pointer to character(s), in typical C fashion.) I don't know how to tell Perl to treat the result as the integer it is (so I can do binary operations on it). Or maybe I'm using it wrong. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/28/06, Jason Stephenson [EMAIL PROTECTED] wrote: Of course, after looking back through the thread, I see Ben has already pretty much answered the above. ;) Repetition is the very soul of the net. -- from alt.config Paul is using a network that is restricted to using a /19 netmask for addressing, but it is really using a /16 when configured. So, he wants to limit address to 10.0.32.0/19 but needs to configure broadcast and network addresses for 10.0.32.0/16. Why he needs to do that, I have no idea and wouldn't need to know. ;) Well... okay... but it's the *why* that makes me wonder. :) I hope it's something interesting, and not just that he's trying to say that he's been assigned the addresses in the range 10.0.32.0/19 on the 10.0.0.0/16 network. That would be *so* boring. :) It seems to me that the answer is that your IP addresses are limited to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network address and 10.255.255.255 being the broadcast address, no? Well, /16 means the first two octets are the network portion and the last two octets are the host portion. So the broadcast address (with CIDR) would be 10.0.255.255. Of course, 10.0.32.0/16 would normally be written 10.0.0.0/16, because, again, the third octet is part of the host portion. The host portion is really irrelevant when talking about network numbers. Convention says we fill the host portion with zeros. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Jason Stephenson [EMAIL PROTECTED] writes: It seems to me that the answer is that your IP addresses are limited to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network address and 10.255.255.255 being the broadcast address, no? Err, you've got the IP addresses wrong. It's 10.32.0.0/16, but segmented on a /19 boundary. I need to be able to calculate the next network, which for 10.32.0.0/19, would be 10.64.0.0/19, then take the host portion and add it to this new network such that any given host has the same host portion on all networks it may exist on. -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Ben Scott [EMAIL PROTECTED] writes: Well... okay... but it's the *why* that makes me wonder. :) I hope it's something interesting, and not just that he's trying to say that he's been assigned the addresses in the range 10.0.32.0/19 on the 10.0.0.0/16 network. That would be *so* boring. :) Well, since you've asked, I'm sure you'll regret it :) I'll try to be as brief and concise, yet clear as possible. It's confusing. We have no internal router. Just a legacy BSD box acting as a firewall. The internal network, for there really is only one, is 10.0.0.0/16. When it was set up, the 10.0.0 space was allocated along CIDR boundaries on the premise that someday we would have a router to separate un-like network traffic. As a result, we have something like this: Address/CIDR block| Function | Address Range Defined -- 10.0.0/22 | Dev/infrastructure servers | 10.0.0.0 - 10.0.3.255 10.0.4/22 | Mgmt/admin desktops, Mac laptops | 10.0.4.0 - 10.0.7.255 10.0.8/22 | Dev desktops | 10.0.8.0 - 10.0.11.255 10.0.12/24| Network hardware | 10.0.12.0 - 10.0.12.255 10.0.13/24| Printers | 10.0.13.0 - 10.0.13.255 10.0.14/24| MS-OS systems| 10.0.14.0 - 10.0.14.255 10.0.32/19| Dev lab systems | 10.0.32.0 - 10.0.63.255 This allocates a generous portion of addresses to various uses, and, if need be, subdivide based on /24 boundaries if we wanted to. The 10.0.32/19 is an interesting beast. The systems which live on it have 2 NICs, the primary eth0, which *always* have a 10.0.32/19 based address (currently restricted to 10.0.33/24 for some reason?!), and a secondary eth1 which has a primary address of 10.106.XX.YY where XX.YY are the same as the 10.0.XX.YY, and where XX is currently always 33. i.e. host 10.0.33.124 has an eth1 IP of 10.106.33.124. Here's the *really* confusing part. Every system's eth1 *also* has 10 virtual/alias IPs of 10.[96-105].XX.YY. If you recall, I mentioned not having a router. Have I mentioned that the number of hosts in the 10.33/16 range is somewhere around 300, with another 50-100 being added in the next 2 months? :) Both NICs in all systems are essentially on one ethernet network! At any given time, these hosts can have both eth0 and eth1 up, plus any number of the 10 alias IPs up. We are actually about to cut over to a new network configuration this week. However, as the saying goes, There's nothing more permanent than a temporary solution. and dev has basically evolved their testing infrastructure to *require* this flat network scheme. I'm currently testing things to make sure nothing breaks in the transition. One of the things our product does is look at the list of currently configured interfaces, take the highest IP and add 1 to the network portion to obtain a new IP on a different network, but retaining the host portion of the IP. Basically, there's a multi-host negotiation which takes place and figures out a back-channel to communicate over. Since name resolution is not possible either via DNS, /etc/hosts, or other means, the only reliable means any two hosts have of reliably talking to each other is making sure that any given host keeps the same host portion of it's IP address on all networks. Does this help clarify things? Ultimately, the ability to support network addition using something wacky like a /19 is entirely my own intellectual curiosity, since in-house everything is on a /16 making it trivial. But it's one of those problems I can neither figure out, nor let go of :) As someone said to me yesterday, IP addresses were never designed to be manipulated, merely assigned and used! :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Ben Scott [EMAIL PROTECTED] writes: On 3/28/06, Paul Lussier [EMAIL PROTECTED] wrote: If you really want the long convoluted discussion, I'll be glad to post it, I just figured no on would care. Well, everyone here knows *I* thrive on long, convoluted discussions. I'm also curious if you're trying to route packets through a non-existant gateway again. ;-) Errr, no, just the opposite actually. Trying to *prevent* routing from a very existent router :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Jason Stephenson [EMAIL PROTECTED] writes: It seems to me that the answer is that your IP addresses are limited to the range of 10.0.32.0 to 10.0.63.255 with 10.0.0.0 being the network address and 10.255.255.255 being the broadcast address, no? Err, you've got the IP addresses wrong. It's 10.32.0.0/16, but segmented on a /19 boundary. I need to be able to calculate the next network, which for 10.32.0.0/19, would be 10.64.0.0/19, then take the host portion and add it to this new network such that any given host has the same host portion on all networks it may exist on. Doesn't matter. I got the network address wrong, too. ;) You want to interpolate the address of one host to another network, is that it? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Paul Lussier wrote: Errr, no, just the opposite actually. Trying to *prevent* routing from a very existent router :) Sounds to me like what you really need is a router with VLAN capability. If I understand correctly, it sounds like you're trying to implement VLANs. Your setup actually sounds very similar to something that we're designing for all the libraries in our consortium. Right now, each site has a Class C (/24) on a 10.10.*. In the near future, we plan to implement each site having a Class B (/16) with different class Cs for each VLAN. For example, if a site is now on 10.10.32.0, it will move to 10.32.0.0 with something like 10.32.0.0/24 reserved for network equipment, 10.32.10.0/24 for the staff, 10.32.20.0/24 for the public, 10.32.30.0/24 for staff wireless, 10.32.40.0/24 for public wireless, etc.--The Dracut Public Library will be our first test case, since they're moving (back) into their renovated building next month. Without VLANs setup in the router, I can't imagine how that would work to prevent traffic among the various 10.32.0.0 subnets. I suppose you could simulate it with some really complicated routing rules. At this point, my knowledge on the matter of networking begins to recede into nothingness. I can set up a simple Linux or *BSD router/firewall. I can do the math (poorly, but that's what computers are for). I can even use the socket() interface, but configuring fancy-shmancy, complicated network topologies is beyond my current abilities. I didn't design the above mentioned topology, nor did I figure out the configuration in the Cisco routers that we buy. However, I'm promised by our contractor that they'll show me enough so I can break things. ;) Long story made slightly longer, I'd suggest looking up how to configure VLANs on whatever you're using for a router.--I know you mentioned a FreeBSD firewall earlier. Cheers, Jason Can't-the-network-for-the-wires Stephenson ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
Jason Stephenson [EMAIL PROTECTED] writes: I'd suggest looking up how to configure VLANs on whatever you're using for a router.--I know you mentioned a FreeBSD firewall earlier. You must have missed the part where I said we don't have a router, we're migrating to a comletely new network, and, most importantly: Ultimately, the ability to support network addition using something wacky like a /19 is entirely my own intellectual curiosity :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On Mon, 2006-03-27 at 14:25 -0500, Paul Lussier wrote:
Hi all,
I'm stumped. I've got a network address space of 10.0.32/19. How
ever, this space is carved up using a /16 netmask. In otherwords, the
/19 netmask was simply used to *allocate* the space from 10.0.32.0 to
10.0.63.255, but we actually *use* the space with a /16 netmask (yes,
this means that 10.0.8.10 is in the *same* physical network as
10.0.33.93!).
Given an address, say 10.0.33.189, I want to get the network and
host portion of the address. given that I'm really on a /16, it's
fairly easy to split the IP at 10.0 and 33.189. However, I want to be
able to do the same thing on the /19 as well. Once I have the network
and host portions of the address, I need to increment the network
portion by 1 block, then re-apply the host portion.
For example, given the address 10.0.33.189/16:
Network = 10.0 Host = 33.189
+ 1
-
10.1 + $HOST = 10.1.33.189
Would it help to convert to 32-bit integers?
When you add 1 here, you are really adding 2 ** 17. Your host mask is
int('1' * 16, 2)
So newIP = oldIP + 2 ** 17
newhost = newIP hostmask
And, given the address 10.0.33.189/19:
With a /19, you are adding 2**14
hostmask = int('1' * 13, 2)
Converting a.b.c.d (base 256) to integer is left as an exercise for the
reader. Perhaps you do not really care about the host mask. You can
simply convert the newIP back to base-256 notation.
I think I understand the arithmetic. I do not really understand what
you are trying to do.
Network = 10.0.32 Host = 1.189
+ 1
-
10.0.64 + $HOST = 10.1.65.189
And, given the address 10.0.35.189/19:
Network = 10.0.32 Host = 3.189
+ 1
-
10.0.64 + $HOST = 10.1.67.189
Getting the next network block isn't too tough, Net::Netmask does
that for me. What I can't quite figure out is how to get the host
portion, and then add it to the new network portion. For a classful
address it's fairly simple, for CIDR address, not so much...
All ideas are welcome and appreciated :)
Thanks,
--
Lloyd Kvam
Venix Corp
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: perl and network addresses
On 3/27/06, Paul Lussier [EMAIL PROTECTED] wrote:
I'm stumped. I've got a network address space of 10.0.32/19. How
ever, this space is carved up using a /16 netmask.
HUH?
Given an address, say 10.0.33.189, I want to get the network and
host portion of the address.
(1) Red Hat provides a nifty utility called ipcalc that will do
that for you. E.g.:
$ ipcalc -b -m -n -p 10.0.33.189/19
NETMASK=255.255.224.0
PREFIX=19
BROADCAST=10.0.63.255
NETWORK=10.0.32.0
$
(2) I find it's a lot easier to conceptualize this stuff if you
write it out in binary notation (view using a fixed-width font):
/19 = 255.255.224.0
010.000.033.189 = 1010 0011 1001
255.255.224.000 = 1110
Net portion = 1010 0010
Node portion= 0001 1001
(3) You mentioned Perl, but this is the same in most programming
languages: It's simple binary arithmetic and Boolean logic. All you
need are AND and NOT (complement). The trickier part is usually
converting from dotted-quad notation to binary storage. Fortunately,
Unix provides a function for that: inet_addr(2). C code looks like
this:
/* includes */
#include stdio.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
/* main program */
int main() {
/* variables */
unsigned int a; /* address */
unsigned int m; /* mask */
unsigned int n; /* node */
/* get address and mask, in network byte order */
a = inet_addr(192.0.2.42);
m = inet_addr(255.255.255.0);
/* find node portion by AND'ing with complement of net-mask */
n = a (~m);
/* convert to host byte order */
n = ntohl(n);
/* print result as decimal integer */
printf(node=%d\n, n);
}
I tried
perl -we '$a = inet_addr(192.0.2.42);'
but it complained that inet_addr is not defined. I suspect there's a
module somewhere you need to pull in. Hopefully this is enough to get
you started.
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
It depends upon the minds you're citing. Google cites 290 million hits on Python versus 365 million on Perl, so you could argue that's an edge or around a 4:5 ratio. Possibly. Of course, those stats might also be an indication that Perl is (or many Perl programs are) so much more confusing than Python that it results in that many millions more desperate WWW searches for help in understanding it.;- N.B. I'm just fanning the flames since I don't know either language... ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
Google: Python vs. Perl Of course python is also a normal English-language word... --DTVZ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
On Fri, Mar 17, 2006 at 12:56:13PM -0500, Drew Van Zandt wrote: Google: Python vs. Perl Well Python wins, of course. Google uses Python in way more places than it uses Perl... Oh, you probably were using Google as a verb, and not a noun... -- Christopher Schmidt Web Developer ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
On 3/17/06, Ted Roche [EMAIL PROTECTED] wrote: Nor did I take it as such. And I was merely observing that, though the languages are both roughly the same age, Perl has significantly more mind-share than Python. OTOH, other development circles I hang out in are all abuzz about Python and Ruby. Perl just sort of is. Lots of *innovative* things seems to be showing up in Python. The feeling I have is that Python has only started to get mainstream attention in the past few years, while Perl became popular sooner. If true, one wonders why. And if true, that might also account for some of the buzz around Python; Perl isn't as interesting, being more established. It might also be that Perl is seen more as a boring every-day problem solver. Do note that the objective factual content of the above paragraph is zero. :) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl v. Python (was OO.o, was METRO, was...)
Ben Scott wrote: The feeling I have is that Python has only started to get mainstream attention in the past few years, while Perl became popular sooner. If true, one wonders why. And if true, that might also account for some of the buzz around Python; Perl isn't as interesting, being more established. It might also be that Perl is seen more as a boring every-day problem solver. Perl leveraged a lot from shell scripting; for someone already proficient in ksh, awk, and sed, it was extremely simple to transition to perl. Essentially, you didn't have to start from scratch; perl felt like the same old familiar shell scripting, minus the pain of wrestling with awk and sed. -- John Abreau / Executive Director, Boston Linux Unix ICQ 28611923 / AIM abreauj / JABBER [EMAIL PROTECTED] / YAHOO abreauj Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
Dan Coutu [EMAIL PROTECTED] writes: Piece of cake. You need to use the FindBin module that is included in the default Perl distribution. Do this: #!/usr/bin/perl use FindBin qw($Bin); use lib $Bin; use myinclude; This assumes that your module is named myinclude.pm and is in the same directory as your perl script. I was just about to make this same recommendation. We've got hundreds of thousands of lines of perl code here at work, and this is where I first discovered the FindBin module. We use it extensively here, and probably wouldn't be able to do things nearly as easily without it. Almost every script we write has: use FindBin; use lib /build/perl/lastrun/lib; use lib $FindBin::Bin/../../../perl/lib; use lib $FindBin::Bin; It's really nice to not have to worry about your modules not being found :) -- Seeya, Paul ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
On Mon, 2005-12-05 at 15:59 -0500, Thomas Charron wrote: use lib '.'; Thomas Note that this will use your current directory as the place it looks for your module. The current directory would happen to depend on wherever you happen to have last done a cd to. That may not be what you really want. Chances you really want the module to be in the same directory as the perl script itself, or a directory relative to it. For that FindBin is the way to go. Dan On 12/5/05, Cole Tuininga [EMAIL PROTECTED] wrote: How can I set up my include path (within the perl script) to make sure that the directory of the executable is in the include path? I can't hard code it because the location might be different on different machines (different mount points). ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
Cole Tuininga writes:
I have a module (call it MyMod.pm) that I want to use in a program, but
I can't install it in with the rest of the perl libraries. For reasons
that are too boring to get into, the only guarantee I have is that it
will be in the same directory as the executable script.
How can I set up my include path (within the perl script) to make sure
that the directory of the executable is in the include path? I can't
hard code it because the location might be different on different
machines (different mount points).
Try this:
#!/usr/bin/perl
BEGIN {
$dirname = $0;
$dirname =~ s#(.*/).*#$1#;
eval use lib qw($dirname);
}
use MyMod;
Hope this helps,
--kevin
--
GnuPG ID: B280F24E
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl include question
On 12/5/05, Cole Tuininga [EMAIL PROTECTED] wrote: On Mon, 2005-12-05 at 15:59 -0500, Thomas Charron wrote: use lib '.';Doesn't this assume you're executing the script from its own directory? In other words, wouldn't this break if I did something like:../otherpath/script.pl Yeppers.. ;-) It was a quick reply, didn't have time to fully explain it. But it's all in the use lib line. ;-) Thomas
Re: Perl include question
On 12/5/05, Dan Coutu [EMAIL PROTECTED] wrote: use FindBin qw($Bin); use lib $Bin; use myinclude; all of my perl code does basically this, but I stick things in a lib directory: /some/directory/myapp /some/directory/myapp/lib so the use lib line above would turn into use lib $Bin/lib; makes things a little easier to manage. -- Jeff Macdonald Ayer, MA ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
[EMAIL PROTECTED] writes: What's the relationship between Perl and C99? I don't think that there is a strong relationship. The Perl source code is amazingly portable; it runs on well over 100 platforms. Most of these platforms probably aren't C99 conformant, and so the Perl source doesn't depend on C99 features. Perl could be enhanced to support these features on C99 conformant platforms, probably most easily by writing a module. Regards, --kevin -- Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA) cetaceannetworks.com!kclark (GnuPG ID: B280F24E) alumni.unh.edu!kdc ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
On Tue, 2003-07-22 at 16:36, Erik Price wrote: Cole Tuininga wrote: Got a perl question for y'all. I rarely have to do anything with perl, and I'm sure perl has a good reason for behaving like the following, but heck if I can figure it out. The perl cookbook suggestions using sprintf for rounding floats. This seemingly works fine: [EMAIL PROTECTED]:~$ perl -e 'print sprintf( %.2f\n, 0.562 )' 0.56 [EMAIL PROTECTED]: perl -e 'print sprintf( %.2f\n, 0.567 )' 0.57 However, I'm extremely confused by the following: [EMAIL PROTECTED]:~$ perl -e 'print sprintf( %.2f\n, 0.565 )' 0.56 I don't have an answer, Cole, but the same happens in Python and I'd bet in C as well -- must be a convention of the printf routines: Python 2.2.2 (#1, Mar 9 2003, 08:18:26) [GCC 3.2 20020927 (prerelease)] on cygwin Type help, copyright, credits or license for more information. print %.2f\n % 0.562 0.56 print %.2f\n % 0.567 0.57 print %.2f\n % 0.565 0.56 Aha! Google for round to even -- it's an IEEE floating point computation rule. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
Erik Price said: Cole Tuininga wrote: Got a perl question for y'all. I rarely have to do anything with perl, and I'm sure perl has a good reason for behaving like the following, but heck if I can figure it out. The perl cookbook suggestions using sprintf for rounding floats. This seemingly works fine: [EMAIL PROTECTED]:~$ perl -e 'print sprintf( %.2f\n, 0.562 )' 0.56 [EMAIL PROTECTED]: perl -e 'print sprintf( %.2f\n, 0.567 )' 0.57 However, I'm extremely confused by the following: [EMAIL PROTECTED]:~$ perl -e 'print sprintf( %.2f\n, 0.565 )' 0.56 I don't have an answer, Cole, but the same happens in Python and I'd bet in C as well -- must be a convention of the printf routines: Python 2.2.2 (#1, Mar 9 2003, 08:18:26) [GCC 3.2 20020927 (prerelease)] on cygwin Type help, copyright, credits or license for more information. print %.2f\n % 0.562 0.56 print %.2f\n % 0.567 0.57 print %.2f\n % 0.565 0.56 It's kind of a kludge, but perhaps adding some very small value such as 0.1 just prior to the rounding will get the result you want? [EMAIL PROTECTED]:~$ perl -e 'print sprintf( %.2f\n, 0.56501 )' 0.57 -- Bill Mullen [EMAIL PROTECTED] MA, USA RLU #270075 MDK 8.1 9.0 Giving money and power to the government is like giving whiskey and car keys to teenage boys. - P.J. O'Rourke ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
On Tue, 2003-07-22 at 16:41, Stephen Ryan wrote: On Tue, 2003-07-22 at 16:36, Erik Price wrote: Cole Tuininga wrote: Got a perl question for y'all. I rarely have to do anything with perl, and I'm sure perl has a good reason for behaving like the following, but heck if I can figure it out. The perl cookbook suggestions using sprintf for rounding floats. This seemingly works fine: [EMAIL PROTECTED]:~$ perl -e 'print sprintf( %.2f\n, 0.562 )' 0.56 [EMAIL PROTECTED]: perl -e 'print sprintf( %.2f\n, 0.567 )' 0.57 However, I'm extremely confused by the following: [EMAIL PROTECTED]:~$ perl -e 'print sprintf( %.2f\n, 0.565 )' 0.56 I don't have an answer, Cole, but the same happens in Python and I'd bet in C as well -- must be a convention of the printf routines: Python 2.2.2 (#1, Mar 9 2003, 08:18:26) [GCC 3.2 20020927 (prerelease)] on cygwin Type help, copyright, credits or license for more information. print %.2f\n % 0.562 0.56 print %.2f\n % 0.567 0.57 print %.2f\n % 0.565 0.56 Aha! Google for round to even -- it's an IEEE floating point computation rule. Errm. I take it back. $ perl -e 'print sprintf( %.2f\n, 0.575 )' 0.57 Dunno what's up with that. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
Stephen Ryan [EMAIL PROTECTED] writes: Aha! Google for round to even -- it's an IEEE floating point computation rule. Note that many systems *can* do IEEE floating point, but by default don't, since using the native floating point implementation can yield better performance. Regards, --kevin -- I'm on the bike and I go into a rage -- I shriek for about five seconds, I shake like mad, my eyes kind of bulge, and I'd never quit. That's heart. That's soul. That's guts -- Lance Armstrong ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
On Tue, Jul 22, 2003 at 05:13:03PM -0400, Kevin D. Clark [EMAIL PROTECTED] wrote: *3* Interesting fact of the day: Using binary, it is possible to exactly represent some numbers that cannot be exactly represented in base-10. Can you name such a number? This is un-intuitive to me, since 2 is a factor of 10. -- Bob Bell [EMAIL PROTECTED] - I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams, author of _A Hitchhiker's Guide to the Galaxy_ ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl help
Bob Bell [EMAIL PROTECTED] writes: On Tue, Jul 22, 2003 at 05:13:03PM -0400, Kevin D. Clark [EMAIL PROTECTED] wrote: *3* Interesting fact of the day: Using binary, it is possible to exactly represent some numbers that cannot be exactly represented in base-10. Can you name such a number? This is un-intuitive to me, since 2 is a factor of 10. I think I goofed: I didn't mean to write base-2 above. Instead I meant to type different base. If the statement is amended this way, then I'm sure that I'm correct. Damn. I need some sleep. --kevin -- I'm on the bike and I go into a rage -- I shriek for about five seconds, I shake like mad, my eyes kind of bulge, and I'd never quit. That's heart. That's soul. That's guts -- Lance Armstrong ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Discussed that last night at the BLU meeting. Many of the PDP-8s did not come with a ROM. To load the executive, you would key in the RIM(ReadInMode) loader on the front panel switches. The RIM loader was a very simple paper tape reader program whose purpose was to read in the real paper tape loader. From there you could reload the PDP-8. Burger King's point of Sale system in the early 1970s was a PDP-8M with 4 attached registers. No disk, no paper tape, core memory. For the modem, we had to time the 1200 baud with timing loops and send a bit at a time. No UART. We also had to strike the hammers on the printer drum. Keyboard required to reads (row and column). If the system crashed, a service guy had to come in, plug in the paper tape board, and reload the program. On 22 Aug 2002 at 8:36, [EMAIL PROTECTED] wrote: Okay, I have to ask: What's a RIM loader? -- Jerry Feldman [EMAIL PROTECTED] Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] said: AFAIK, no. I believe that the original development was on some PDP-11's (11/45's?) No, the original development was on a PDP-7, and in assembler. The second machine it ran on was a PDP-11, also in assembler. It was after that port that Dennis wrote C, to make the next port easier. I think that for the most part he succeeded. [EMAIL PROTECTED] said: Okay, I have to ask: What's a RIM loader? O.K.: First you toggle in the BIN loader. On the PDP-8 this was seventeen twelve-bit instructions, so you have to flip (and get ABSOLUTELY CORRECT) 204 switches, and this was AFTER you toggled in the correct starting address. That BIN loader then loaded in a paper tape that had the RIM loader on it, which (hopefully) stayed in memory to load in things like an Editor, Assembler and (eventually) your program. However, with only 4K words (and poor programming skills) you usually overwrote the RIM loader with your program bombing (er, ah) running, so you had to start ALL OVER AGAIN. Ah, the good old days. :-) md -- = Jon maddog Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] said: All this in 4K memory. Yeah, but Burger King was not selling as many hamburgers back in those days. :-) md -- = Jon maddog Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Wed, 21 Aug 2002 19:30:45 EDT [EMAIL PROTECTED] said: I'm just curious... was Unix ever developed on any of those? I was pretty much under the impression that Unix assumes an 8-bit byte, but I don't really have anything to back that up... It was originally *developed* on a PDP-7 if my memory banks are correctly ECC'ed :) I believe it was ported to the PDP-8 at one point, but I don't remember for sure. I can check my copy of 25 years w/ UNIX tonight when I get home if you wish :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Tue, 20 Aug 2002 16:43:36 EDT [EMAIL PROTECTED] said: I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. Okay, I'll buy that, but why create a linker that only supports 5 character function names? What was it which caused this scenario? I guess I don't fully understand the role of linkers, if this should be an obvious thing :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
In a message dated: Tue, 20 Aug 2002 16:52:35 EDT
Steven W. Orr said:
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
=In a message dated: Tue, 20 Aug 2002 15:16:58 CDT
=Thomas Charron said:
=
=For example, in shell, the construct:
=
= cd /tmp rm foo
Whotchoo talkin 'bout Willis?
cd == chdir is a builtin command. But point taken.
Okay, bad example :) How about:
PID=`ps -ef | grep foo | awk '{print $2}'`
kill -9 $PID
That's 4 sub-processes :)
Actually, debugging bash isn't all that bad.
I'm not saying it can't be done, but...
set -x
isn't the same as a debugger with break points, watches, etc.
And there is a full blown
debugger available for ksh with breakpoints and everything. :-)
Ooh, now *that's* cool! Thanks!
--
Seeya,
Paul
--
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Back in the early days of computers there weren't as many characters to go around and folks had to be very conservative with their use. Since then, more have been pulled out of the ground so we can use them more liberally. -- __ | 0|___||. Andrew Gaunt *nix Sys. Admin., etc. _| _| : : } [EMAIL PROTECTED] - http://www-cde.mv.lucent.com/~quantum -(O)-==-o\ [EMAIL PROTECTED] - http://www.gaunt.org [EMAIL PROTECTED] wrote: In a message dated: Tue, 20 Aug 2002 16:43:36 EDT [EMAIL PROTECTED] said: I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. Okay, I'll buy that, but why create a linker that only supports 5 character function names? What was it which caused this scenario? I guess I don't fully understand the role of linkers, if this should be an obvious thing :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Good thing more colors other than green and amber were invented too. -Mark On Wed, Aug 21, 2002 at 11:00:10AM -0400, Andrew W. Gaunt wrote: Back in the early days of computers there weren't as many characters to go around and folks had to be very conservative with their use. Since then, more have been pulled out of the ground so we can use them more liberally. -- __ | 0|___||. Andrew Gaunt *nix Sys. Admin., etc. _| _| : : } [EMAIL PROTECTED] - http://www-cde.mv.lucent.com/~quantum -(O)-==-o\ [EMAIL PROTECTED] - http://www.gaunt.org ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Wed, 21 Aug 2002, at 10:10am, [EMAIL PROTECTED] wrote: Okay, I'll buy that, but why create a linker that only supports 5 character function names? Okay, some Google searches eventually tracked down this explanation: Way back when 16 kilobytes was a lot of memory, a method for encoding five characters into a single 32-bit machine word was developed. It was called Radix-50, or RAD50. The 50 is octal, or 40 decimal. The character set was 26 monocase letters, 10 digits, three special characters, and a null (a total of 40). This encoding was used in the linkers of various DEC PDP operating systems, which is where Unix was born. (That could, of course, be incorrect, but I did find references to Radix-50/RAD50 in some old DEC migration documentation.) I guess I don't fully understand the role of linkers, if this should be an obvious thing :) A compiler/assembler turns source code into object code modules. Those modules are not working programs yet; they have symbolic names instead of addresses for variables and functions in many places. You then need to link the modules together, which includes replacing symbolic names with machine addresses everywhere. The output of the linking process is an executable program. Run-time dynamic linking makes things more complex. *hand wave* -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Mark Komarinski writes: Good thing more colors other than green and amber were invented too. Newcommer! We only had black print on those cards and listings. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
To throw a bit (pun un-intentional) more into this discussion, don't assume that a byte was eight bits. The PDP-8, Linc-8 and PDP-12 for instance, were all twelve bit words, broken down into two six-bit characters. Nevertheless, back in those days saving a few bits for every entry in a symbol table was worth the time and effort. md -- = Jon maddog Hall Executive Director Linux International(SM) email: [EMAIL PROTECTED] 80 Amherst St. Voice: +1.603.672.4557 Amherst, N.H. 03031-3032 U.S.A. WWW: http://www.li.org Board Member: Uniforum Association, USENIX Association (R)Linux is a registered trademark of Linus Torvalds in several countries. (SM)Linux International is a service mark of Linux International, Inc. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
[EMAIL PROTECTED] asked: was Unix ever developed on any of those? (meaning the 12-bit PDP-8/PDP-12 architectures) AFAIK, no. I believe that the original development was on some PDP-11's (11/45's?) that Bell Labs had at the time. Those, of course, are 16-bit machines. But, I don't ever hearing about any back-porting to the PDP-8's. At the time, it would have been a real PITA, because the I/O architectures were totally different. Also, by the time that UNIX was more or less working well enough to distribute to its users, the PDP-8 was rapidly approaching end-of-life; DEC had jumped through some really wierd hoops to get it to address 128kb of memory, and it was clear that that was it. The PDP-11s, on the other hand, could do that much fairly easily and was obviously much more extendible. Much of the development in the mid-70's was to meet some interesting requirements that customers had voiced, and obviously some of those customers were running UNIX. HTH, Bayard, who tried, but failed to find his old copy of the RIM loader... ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, [EMAIL PROTECTED] hath spake thusly: Hmmm, if you don't like $|, as Kevin already pointed out, you can: Use English; $OUTPUT_AUTOFLUSH = 1; which I actually find far more readable and understandable than even your C example above. Yes, you *CAN* do that. The problem is absolutely no one does. So it hardly matters that it's available. Well, I think it's more that they're lazy. Why type $OUTPUT_AUTOFLUSH when you can type $| instead? Precisely. If someone who doesn't know the language needs to know what $| does, it's well documented. Of course it is. But the documentation does nothing to make the *program* more readable. Again, it's not about documentation. It's about design. Right, and perl was designed to be as flexible or as rigid as you'd like it to be. I think it's more about learning the language. Which is a task that many (like me, and apparently mod, given he started this thread) find more difficult to do than with many other languages, due to it having a lot of these kinds of things. I've learned quite a few languages: Basic: easy Logo: easy Pascal: easy Fortran: easy C: slightly harder than above, but still pretty easy Bourne shell: easy (though getting a grip on regex is a challenge) scheme: moderate (strange syntax, no looping, everything is recursive[1]. Oh yeah, and all the damned parentheses!) Perl: difficult, largely due to obscure syntax and unreadable example code, IMO Obviously, YMMV. Pointers (and pointers to pointers!) were probably the most difficult part of most of those (that had them). But once you get them down in one language... [1] strictly speaking, this isn't true. But this was the way we were made to learn it, and use it I would say that you're quite a bit more proficient at C than I am, but less so at Perl. Things like $_, $!, $|, etc. are second nature to me, where as things like setlinebuf are second nature to you. You still seem to be missing the point. Certainly, proficiency plays a role. But the point is that there is no meaning inherent in $! (the use of which BTW, I have no idea, despite having seen and I'm pretty sure even used)... This, in combination with the fact that there are dozens of these variables, in combination with the fact that most Perl programmers seem to be delighted to use $a and $b, makes it very difficult to remember what they all do, and read code that uses them. Even were I to use Perl regularly, I would have a hard time remembering which was which, and hence avoid them whenever possible. They do not lend themselves to being learned, and I've never been good at memorizing. Structures come to mind, though they're not as bad as some things I've come across (can't recall what though). I thought I already gave that, but I guess I didn't. Perl doesn't have structures, it has hashes. Different concept. They can be used to emulate a structure, but they are not structures. Precisely. Programming languages manipulate data, very often involving multiple types of information; data structures. This is a fundamental part of programming, so much so that it's taught to all first year CS students. Perl makes manipulating data structures harder than it needs to be. IMO, this is a weakness of Perl. I'm not saying Perl is a bad language. I am merely saying that I found/find it reletively difficult to learn, for reasons I've stated, and can definitely see why others balk at the prospect. Or said another way: I like perl. It makes shell scripting easier. =8^) - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9Ym+ndjdlQoHP510RAq1PAJ95+KuOUBvPAFS55FpPtk1NR1ZrvACgluAm M24a6F28uQcptmKQqixBCNQ= =isIU -END PGP SIGNATURE- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, Erik Price hath spake thusly: there is no meaning inherent in $! Right. Just like there is no meaning inherent in #! but we all know what it means when it comes at the top of a script. Yes, but again, it is not that these things exist, but that there are too many of them to easily keep them all straight. Mnemonics or not. - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9YnwMdjdlQoHP510RAnajAJ9mY5j8JEe9LdV3Z6dTHRnn6qWmYACgjkXv s+XMSR7hQvFhIUjtrjRrVOY= =C1Ue -END PGP SIGNATURE- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl
In a message dated: Tue, 20 Aug 2002 12:34:47 EDT Derek D. Martin said: But the point is that there is no meaning inherent in $! (the use of which BTW, I have no idea, despite having seen and I'm pretty sure even used)... Actually, there is. The meaning of $! is what just blew up. I.e., when something blows up, it goes 'bang'. This variable tells you that. This, in combination with the fact that there are dozens of these variables, in combination with the fact that most Perl programmers seem to be delighted to use $a and $b, makes it very difficult to remember what they all do, and read code that uses them. $a and $b are not chosen at random. They are very specifically chosen because they are used by perl's sort(). Even were I to use Perl regularly, I would have a hard time remembering which was which, and hence avoid them whenever possible. They do not lend themselves to being learned, and I've never been good at memorizing. I disagree. The more you use something the better you know it. There is a huge diffence between knowing and memorizing. In general, the human brain is not good at memorizing, and it's generally accepted with in those who study how the brain works that memorization is the least effective way to teach something. Knowing something is entirely different. Ultimately, I feel that it's useless to know what all the magic variables in perl do off the top of my head. If I need to use one, I read the docs to figure out which one I need and make a comment in my code saying what I did. I don't have them all memorized, and I doubt most perl programmers do either. There are maybe 3 or 4 which are used with any sort of regularity. No, it may not make the code overly readable to those who don't know the language, but to those who do, it's as clear as it can be. You're complaints seem to stem more from the fact that you don't know the language proficiently than anything else. Structures come to mind, though they're not as bad as some things I've come across (can't recall what though). I thought I already gave that, but I guess I didn't. Perl doesn't have structures, it has hashes. Different concept. They can be used to emulate a structure, but they are not structures. Precisely. Programming languages manipulate data, very often involving multiple types of information; data structures. This is a fundamental part of programming, so much so that it's taught to all first year CS students. Perl makes manipulating data structures harder than it needs to be. IMO, this is a weakness of Perl. But Perl is meant to manipulate TEXT, therefore, why should it need structures? There are inherently only 3 data types in perl: scalars, arrays of scalars, and hashes of scalars. That's a very different paradigm than other traditional languages. It's not a weakness, it's a strength, it just happens to be one you're not accustomed to. I'm not saying Perl is a bad language. I am merely saying that I found/find it reletively difficult to learn, for reasons I've stated, and can definitely see why others balk at the prospect. Or said another way: I like perl. It makes shell scripting easier. =8^) That's only because you're looking at it wrong. Perl is a language meant to manipulate text. It's not C and it's not shell. It does have facets of both, but it is a replacement for neither one. There are problems Perl is very good at solving, and there are problems which perl *can* solve, but would probably be better off written in C, python, lisp, or even sh. The problem I think you're having is that you think in C, know shell very well, and attempt to make too many parallels with those two languages. Perl is not a hard language to learn the basics of, and one can easily write very complicated perl programs in a very straitforward and readable manner without ever touching the magic variables. It just so happens that those who know the language choose to use them because it's shorter. It's the same with the '?:' construct in C. That is not even close to readable unless you know the language, but yet people persist in using it despite the fact that it offers no more functionality than a simple if...then construct. -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Tue, 20 Aug 2002 15:01:45 EDT Derek D. Martin said: I don't believe there was ever a name-length limitation on filenames. Then you believe incorrectly. Many variants of Unix had a 14-character filename limit. There is still a limit today, though it's ridiculously large, so as not to matter practically. Ahh, 14 characters, that does sound familiar. You're right. It was the mention of 4 character file names which threw me. Sorry. I may only be imagining this, but I could swear it was a predecessor to Unix, from whence many of these commands originally came (possibly multics? anyone?) that did have a four character filename limit. I don't know a lot about multics. Perhaps you're thinking of the 6 character limitations of node names in DECNET, from whence came the famous 'decvax' et. al.? OTOH, I haven't been getting much sleep lately... =8^) What else have you to do? ;) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
In a message dated: Tue, 20 Aug 2002 15:01:45 EDT
Derek D. Martin said:
At some point hitherto, [EMAIL PROTECTED] hath spake thusly:
In a message dated: Tue, 20 Aug 2002 12:37:34 EDT
Derek D. Martin said:
I never claimed Unix commands weren't obscure; they ARE. I prefer
them to Microsoft commands because in general I find they do more and
work better. However, Unix has man pages.
But man pages and documentation aren't going to help a shell script
be more readable! (at least by your own argument).
Which is specifically why I made that point immediately after what you
quoted. Now you're just trolling...
No, I'm using your own argument against you. You state that UNIX has
man pages as if that excuses the obscure command names of the OS.
Yet when I stated that all of Perl's magic variables are clearly
documented, your first reaction was that it doesn't make a perl
program any more readable just because they're documented somewhere.
And my argument all along was
not that Perl has obscurities; it's that it has TOO MANY, and the
people who write perl (in my experience) have a propensity to use them
TOO OFTEN, being not conducive to actually learning perl.
Yes, perl has a lot of obscurities. However, I don't feel that it's
an obstruction to learning the language. I've been programming perl
for about 8+ years now, and can't claim to know more than 4 or 5 of
these off the top of my head. You seem to be implying that to learn
the language one must memorize all of the variables, which is
ridiculous. In common practice, most of these variables aren't used.
If you need to read someone elses code in order to maintain it, then
look the variable up in the docs, and make a comment in the code.
Enhancement *is* part of maintainence.
I'm inclined to think you're being intentionally obtuse.
I'm inclined that you just feel like complaining about something :)
Hundreds of thousands of people have learned to program perl. Many
of them know no other language, so it can't be that difficult.
Of course, that may well be *why* their code is relatively
unreadable, as they've never learned much in the way of proper coding
style (whatever that can be defined as).
I'll try to sum up the reasons for this succinctly, so we can put this
to bed. Preface with IMO, wherever you think it might be appropriate.
- Perl grew rather than being designed. Its syntax is a
mish-mash of features from several other languages and/or utilities
all glued together, and as such sometimes seems to be inconsistent
with itself
Okay, no debate there.
- Perl does some things which are commonly done in programming
languages very, very differently from the rest
Like what? Other than structures which don't need to exist in perl.
- Perl has a lot of obscure features and syntax, like the so-called
magic variables, that don't lend themselves to readable code
I don't see how this is any different than any other language. I've
seen plenty of unreadable C. I've even seen unreadable sh!
The use of obscure features and syntax is available in any language,
and there for the programmer to abuse to their heart's content. This
is a people problem, not a language problem.
- The people who write Perl by and large seem to prefer a style (if
you can call it that) that promotes neither code readability nor
education
This I'll grant you to some extent. However, it's a people problem,
not one with the language.
- For all its wiz-bang features that make many tasks which are
difficult on other languages much easier in perl, it lacks the
ability to easily manipulate data structures; one of the most
common things done with computer programs. Dealing with arrays of
hashes of hashes is somewhat clumsy, by comparison to other
languages
Agreed, and in most cases where you need to deal with arrays of
hashes of hashes, or hashes of arrays of hashes, etc. you're probably
better off using something like C.
Of course, if you've mucked about with this type of thing long
enough, it becomes rather natural and understandable, and therefore,
simpler to deal with than using C.
- learning to do certain common programming tasks in perl is
unneccessarily hard
You keep mentioning this, yet you haven't mentioned what any of these
common programming tasks are. Can you provide examples?
- understanding some of perl's syntax is counterintuitive, and
unnecessarily hard
Other than the magic variables, which for the most part, are
irrelevant, what are some examples of perl syntax which you find
counter-intuitive? I ask not to be difficult, but because I've never
encountered anything in the language I've considered
counter-intuitive. Essentially, all the syntax is based around
performing an operation on a scalar or on lists of scalars and follow
the basic syntax:
commandname {block of code} list of scalars to operate on
- reading and maintaining other people's code
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Tue, 20 Aug 2002, at 3:09pm, [EMAIL PROTECTED] wrote: Then you believe incorrectly. Many variants of Unix had a 14-character filename limit. There is still a limit today, though it's ridiculously large, so as not to matter practically. Ahh, 14 characters, that does sound familiar. You're right. It was the mention of 4 character file names which threw me. Sorry. The 14-character filename limit *did* exist in some early Unix or Unixes. I do knot know exactly which ones, but it is an oft-cited limit when worrying about greatest common factors for heterogeneous systems. I am pretty sure there was never a 4-character filename limit. I can think of many things that would not fit: passwd, login, mount, mkdir, rmdir, issue, fstab ... I may only be imagining this, but I could swear it was a predecessor to Unix, from whence many of these commands originally came (possibly multics? anyone?) that did have a four character filename limit. I don't know a lot about multics. Perhaps you're thinking of the 6 character limitations of node names in DECNET, from whence came the famous 'decvax' et. al.? I think he is thinking of the five-character limit in the original linker(s) used to develop Unix (which very well may have come from Multics). That five-character limit gave us the infamous creat(2) system call. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
[EMAIL PROTECTED] writes: Agreed, and in most cases where you need to deal with arrays of hashes of hashes, or hashes of arrays of hashes, etc. you're probably better off using something like C. Of course, if you've mucked about with this type of thing long enough, it becomes rather natural and understandable, and therefore, simpler to deal with than using C. I've been avoiding getting involved with this thread because I consider Derek's whole line of reasoning to be pretty innane, but I thought I'd comment on this issue. In my opinion, after you learn how to use references in Perl, and after you learn how to use lists of refs and hashes of refs, you'll cry the next time that you have to implement anything similar in C/C++/Java. --kevin -- Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA) cetaceannetworks.com!kclark (GnuPG ID: B280F24E) alumni.unh.edu!kdc ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
In a message dated: Tue, 20 Aug 2002 16:20:29 EDT [EMAIL PROTECTED] said: I think he is thinking of the five-character limit in the original linker(s) used to develop Unix (which very well may have come from Multics). That five-character limit gave us the infamous creat(2) system call. H, I don't believe that's correct either. I remember a discussion with either Brian Kernighan or Dennis Ritchie, who, when asked what he would do different if he had a chance to go back and change anything in UNIX, stated, I'd spell creat(2) with an 'e' on the end.[1] [1] This quote is not necessarilly verbatim, but it's close :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
In a message dated: Tue, 20 Aug 2002 15:16:58 CDT Thomas Charron said: I do occasionally use Perl, but I find that it's usually when I want to do a lot of regexp work, or shell-script-like work, but don't want to take the performance hit of using a shell script. Otherwise, bash or C suit me better. Performance hit. Thats kinda funny. And what kind of benchmarks have you performed as a basis for this judgement? I guess I dont see what this means, as to why you do it. Well, in Derek's defense, using perl for something similarly written in bash is likely to perform better since bash or any of the traditionall 'shell' languages need to spawn a separate process for everything. For example, in shell, the construct: cd /tmp rm foo creates 2 sub-shell processes, whereas, in perl: chdir (/tmp) unlink(foo); creates 0 sub-shell processes. Therefore, perl is, technically, more efficient in this regard. Does it really matter with todays ridiculously overpowered CPUs and gobs of memory? Probably not in most cases. Though, perl does have a debugger one can use vs. bash which doesn't. That right there is a plus in the perl column for me! :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Tue, 20 Aug 2002, at 4:14pm, [EMAIL PROTECTED] wrote: I think he is thinking of the five-character limit in the original linker(s) used to develop Unix (which very well may have come from Multics). That five-character limit gave us the infamous creat(2) system call. H, I don't believe that's correct either. I remember a discussion with either Brian Kernighan or Dennis Ritchie, who, when asked what he would do different if he had a chance to go back and change anything in UNIX, stated, I'd spell creat(2) with an 'e' on the end.[1] I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
The 14 character limit did exist in Unix versions 6 and 7. Version 6 was used as a basis for the BSD releases. Version 7 was the basis for what became System 3 followed by System V. Long file names I think came out for the first time in BSD 4.3 (or possibly 4.2). Unlike MS DOS, which had a limit of 8 for the file name and 3 for the extension, the file extension was (and is) a convention, and the dot (.) could appear anywhere in the 14 characters. Filenames beginning with a dot are uninteresting, and not generally displayed by ls. On 20 Aug 2002 at 16:20, [EMAIL PROTECTED] wrote: The 14-character filename limit *did* exist in some early Unix or Unixes. I do knot know exactly which ones, but it is an oft-cited limit when worrying about greatest common factors for heterogeneous systems. -- Jerry Feldman [EMAIL PROTECTED] Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
=
=In a message dated: Tue, 20 Aug 2002 15:16:58 CDT
=Thomas Charron said:
=
=For example, in shell, the construct:
=
= cd /tmp rm foo
Whotchoo talkin 'bout Willis?
cd == chdir is a builtin command. But point taken.
=
=creates 2 sub-shell processes, whereas, in perl:
=
= chdir (/tmp) unlink(foo);
=
=creates 0 sub-shell processes. Therefore, perl is, technically, more
=efficient in this regard. Does it really matter with todays
=ridiculously overpowered CPUs and gobs of memory? Probably not in
=most cases.
=
=Though, perl does have a debugger one can use vs. bash which doesn't.
=That right there is a plus in the perl column for me! :)
Actually, debugging bash isn't all that bad.
set -x
will solve lots of problems and if that doesn't get you going, then
set -xv
will probably do the rest of it. Another great debugging technique is to
set
PS4='.+${0##*/} line $LINENO: '
Also, while bash is arguably the best *login* shell, the best shell
scripting language (aside from perl, but I don't consider that to be a
scripting language in the first place) is ksh. And, BTW, the real ksh93 is
available for free in rpm format, no less. And there is a full blown
debugger available for ksh with breakpoints and everything. :-)
--
-Time flies like the wind. Fruit flies like a banana. Stranger things have -
-happened but none stranger than this. Does your driver's license say Organ
-Donor?Black holes are where God divided by zero. Listen to me! We are all-
-individuals! What if this weren't a hypothetical question? [EMAIL PROTECTED]
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
I think you are correct. Create(2) is a system call. Linkage editors those days were rather primitive. I think the name limit was either 7 or 8, but external names in C were many times autoprefixed with __, such that creat became __creat. The C language had a limit of 8 characters for a variable name (KR 2.1). (Actually a name could be longer, but only the first 8 were significant). I think the only other programmer on this list who might have been writing C back then is my granduncle, Alex Hewitt ;-) On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. -- Jerry Feldman [EMAIL PROTECTED] Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
On Tue, 20 Aug 2002, Jerry Feldman wrote: =I think you are correct. Create(2) is a system call. Linkage editors those =days were rather primitive. I think the name limit was either 7 or 8, but =external names in C were many times autoprefixed with __, such that creat =became __creat. =The C language had a limit of 8 characters for a variable name (KR 2.1). =(Actually a name could be longer, but only the first 8 were significant). =I think the only other programmer on this list who might have been writing =C back then is my granduncle, Alex Hewitt ;-) = =On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: = I believe it was Ken Thompson, and I believe the remark was intended to be = humorous. Step back and ask: Why would he spell create as creat in the = first place? If you are going to type five characters, you might as well = type six. The reason it was spelled creat in the first place was the = linked only supported five characters. That has caused much = head-scratching, question-asking, and recompiling-due-to-typos; hence the = remark about the spelling. I have to jump in with an old arcana of my own. I used to work at Data General during Soul of a New Machine days. Their AOS operating system actually had roots originating from earliest Unix. The deal there was that all external variables (by convention) were coded in uppercase. Why? Because sometimes we needed to assign values at linktime to symbols. This was done on the commandline. And the Data General Command Line Interface (CLI) was case insensitive. So if the symbol wasn't uppercase, then the linker would be monkeying with the wrong symbol. :-) -- -Time flies like the wind. Fruit flies like a banana. Stranger things have - -happened but none stranger than this. Does your driver's license say Organ -Donor?Black holes are where God divided by zero. Listen to me! We are all- -individuals! What if this weren't a hypothetical question? [EMAIL PROTECTED] ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
You had C? All we had was assembler! You had assembler? All we had was ones and zeros! You had ones and zeros? ... -Alex - Original Message - From: Jerry Feldman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 20, 2002 4:53 PM Subject: Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ] I think you are correct. Create(2) is a system call. Linkage editors those days were rather primitive. I think the name limit was either 7 or 8, but external names in C were many times autoprefixed with __, such that creat became __creat. The C language had a limit of 8 characters for a variable name (KR 2.1). (Actually a name could be longer, but only the first 8 were significant). I think the only other programmer on this list who might have been writing C back then is my granduncle, Alex Hewitt ;-) On 20 Aug 2002 at 16:43, [EMAIL PROTECTED] wrote: I believe it was Ken Thompson, and I believe the remark was intended to be humorous. Step back and ask: Why would he spell create as creat in the first place? If you are going to type five characters, you might as well type six. The reason it was spelled creat in the first place was the linked only supported five characters. That has caused much head-scratching, question-asking, and recompiling-due-to-typos; hence the remark about the spelling. -- Jerry Feldman [EMAIL PROTECTED] Associate Director Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
On Tue, 20 Aug 2002, at 12:37pm, Derek D. Martin wrote: [ Several paragraphs of completely irrelevant and bogus argument deleted. I will provide explicit debunking of said argument if so requested. ] There are very few Unix commands whose names are completely unintelligible, and learning them is much easier than learning the difference between $^P and $^B. At least for me, and I suspect most people. [ ... snip ... ] Perhaps. But I have a very good grasp of regexp and that's definitely not what *I* am talking about. Okay, so, you have no trouble understanding the Unix environment, which is inconsistent, obscure, and cryptic. You have no trouble with regular expressions, which have, arguably, the most cryptic syntax of any popular language construct, ever. Yet you complain about Perl being hard to learn and use, for the same reasons, and not just for you, but for everyone? That does not add up. Is Perl cryptic? Sure. So are many other things which *you have no problem with*, which was my point. I am willing to bet, dollars to donuts, that the real reason you find Unix easy while Perl is hard is that you use Unix every day, day in, and day out, while Perl is something you only dabble in. Of course, I cannot prove that assertion, but I ask you consider it as objectively as you can (if that is not a complete logical impossibility, which I rather suspect it is). On Tue, 20 Aug 2002, at 3:01pm, Derek D. Martin wrote: - Perl grew rather than being designed. Its syntax is a mish-mash of features from several other languages and/or utilities all glued together, and as such sometimes seems to be inconsistent with itself. Agreed. But, again, Unix is the same way, and so is MS-Windows, yet we have no problem telling people they can/should learn those. Why does Perl get singled out? - Perl does some things which are commonly done in programming languages very, very differently from the rest True, but irrelevant. Compare Python, C, and Scheme, and you'll get a far bigger diff. All programming languages are different. - Perl has a lot of obscure features and syntax, like the so-called magic variables, that don't lend themselves to readable code Marginal. Mechanisms are in place to eliminate the magic variable problem, because said magic variables are recognized as cryptic. What I find more telling is that, at least in my experience, few of those magic variables are needed in practice. I certainly rarely use them. It is like complaining about trigraphs in C. Yes, they are obscure and cryptic, but nobody uses them, so who cares? Can you give an example of anything *other* than the magic variable problem? I am starting to think you're just hung up on magic variables, the way some people get wedged on whitespace in Python. - The people who write Perl by and large seem to prefer a style (if you can call it that) that promotes neither code readability nor education Can you back that up with any kind of real evidence? My personal theory on this is a bit different. There are people who like to write dense, terse, cryptic code. Perl, being the flexible beast that it is, lets those people do that to the extreme. So those people tend to gravitate to Perl. You see a lot more such code written in Perl, because Perl is the best tool to do it in -- a dubious distinction, I'll agree. However, just because there are a large number of hacks writing line-noise in Perl doesn't mean every Perl coder on the planet does it. I certainly don't find much of that stuff in the Camel books, other than deliberate instances of it. For all its wiz-bang features that make many tasks which are difficult on other languages much easier in perl, it lacks the ability to easily manipulate data structures ... True, and a recognized problem, and one that is being worked on in Perl 6. However, I don't think anyone was suggesting that Perl is the universal fix to all programming problems. Perl excels at munching text, working with dynamic lists of flat data, and associative lookups (among other things). The tasks Perl does well are all tasks done frequently in computer programs as well. But many of the features of Perl compound [the problem of reading other people's code], making for naturally ugly code. I find that Perl often leads to naturally elegant code, when used properly. I have to wonder if your problem is just that you hang around too many lousy Perl hackers. :-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: UNIX Arcana [was Re: Perl (or Unix vs. MS, actually) ]
Didn't you work with Grace Hopper :-) Hewitt Tech wrote: You had C? All we had was assembler! You had assembler? All we had was ones and zeros! You had ones and zeros? ... -- -- Gerald Feldman [EMAIL PROTECTED] Boston Computer Solutions and Consulting ICQ#156300 PGP Key ID:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Perl (or Unix vs. MS, actually)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, [EMAIL PROTECTED] hath spake thusly: Yet you complain about Perl being hard to learn and use, for the same reasons, and not just for you, but for everyone? I absolutely said no such thing. Let's make this even simpler. Mike O'Donnell commented about finding the prospect of learning Perl daunting. I attempted to convey to the perlheads here who responded with incredulity that I too had the same reaction, attempted to learn it, found that learning *facile* use of it was more difficult than any other language I'd tried to learn. I then proceeded to attempt to explain why *I* found it that way, apparently to no one's satisfaction. Suffice it to say that the reasons don't much matter. Whatever the reason, that was my experience, and so I can sympathize with anyone who voices those kinds of opinions. I'm done with this topic. - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9YvRKdjdlQoHP510RAmxvAKCK63cngoBI1lKJMYC1IV7dK/+CMwCdHpEY DHiXcd02zX933Gi4VoyFNJQ= =gng9 -END PGP SIGNATURE- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
