Re: sorting pathnames by basename
On Tuesday, August 20, 2002, at 12:39 AM, Erik Price wrote:
#!/usr/bin/python
#
# basenamesort.py
#
# Unix-style filter that sorts a newline-separated
# list of files by the file basename
#
# Example usage: cat files.txt | basenamesort.py
import sys
import os
tempDict = {}
for line in sys.stdin.xreadlines():
tempDict[os.path.basename(line)] = line.rstrip()
sorted = tempDict.keys()
sorted.sort()
for key in sorted:
print tempDict[key]
Whoops. It figures that I would forget the part that actually does the
sorting. I added it above (the sorted.sort() line).
Erik
--
Erik Price
email: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
___
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
File sizes
Hi All, Can the 2GB file size limit be changed? I need to store about 10GB worth of data in a single file, but it dies at 2GB. TIA, Kenny -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
Can any of the Python programmers on this list implement this as a one-liner? Just wondering. (with Python's indentation rules, I think that this would be difficult) Thanks, --kevin PS I could write a very similar program in Perl, obviously. -- 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: sorting pathnames by basename
In a message dated: Mon, 19 Aug 2002 17:17:43 EDT Bill Freeman said: [EMAIL PROTECTED] writes: Suggestions for improvement welcome. Use perl. -- Use Python Bill, [ Note: this is not intended as the beginning of a flame-fest! ] I'm curious what Python has to offer in this area. I know nothing about the language really, and am quite curious about it. The reason I offered the suggestion of Perl isn't because it's my favorite language, but because the language itself was developed to solve the exact type of text-munging problem mod was encountering. Is Python also a text-munging type language aimed at sysadmin type problems? Was it too, specifically designed to pick up where awk and sed fell short? 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
Test to gnhlug-discuss@mail.gnhlug.org
This is a test to [EMAIL PROTECTED] My previous messages are timing out from the Postfix program zcamail03.zca.compaq.com, and I don't know why. -- Bob Bell [EMAIL PROTECTED] - Suppose I want to take over the world. Simplicity says I should just take over the world by myself. -- Larry Wall, creator of the Perl programming language ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
First, thanks to Kevin and Erik (and all) for their examples and participation. Second, when I said that one example doesn't suck I was just trying to be high-larious, not implying that the other one DID suck. Apologies for any implied slight, and my allergies are my own problem. Third, just as I am a lifelong vi user but secretly believe that emacs users are superior, I am most comfortable with shell scripting but suspect that perl users will always be able to code circles around me. Just don't ask me to maintain their code...! ;- Thanks again. ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: File sizes
On Tue, Aug 20, 2002 at 09:10:58AM -0400, [EMAIL PROTECTED] wrote: On 20 Aug 2002, at 8:12am, Kenneth E. Lussier wrote: Sorry for the lack of description. I didn't want to get into too much detail, since it is a bit embarrassing I'm doing a Windows backup to a samba mount. I get write failures at the 2GB point. I believe that it is actually a limit in the ext2 FS. I don't know if ext3 changes this. The ext2 disk format is quite capable of handling files in the terabyte range. You may be encountering a limit in: - the ext2 driver in your kernel - the general file I/O routines in your kernel - your C library - Samba Samba and NFS(v2) don't like 2GB file sizes. http://www.suse.de/~aj/linux_lfs.html -Mark ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
In a message dated: Mon, 19 Aug 2002 19:18:32 EDT Derek D. Martin said: 1. Perl seems to favor supporting a variety of features with obscure, meaningless, two-character variables that might be clearer with flags or arguments to functions that make use of it. Define obscure please. Everything in the perl language is tediously and breathtakingly documented and quickly accessible to any system on which perl has been installed using either the 'man' or 'perldoc' commands. Whereas in many ways, Perl seems to have gone out of its way to work like other common Unix tools/languages (shell scripting, C, sed/grep), in others it seems to go out of its way to do things in such a way as to be as confusing as possible. Example? 2. The people who like to program Perl seem to have a propensity to prefer to write code which takes advantage of all the obscure features, and generally to write code which is unreadable. Well, I guess it depends upon how well you know the language. I can say the same for just about any language I've ever looked at. For example, the C code in libc is about as obscure undecipherable as it gets :) I reject the notion that it is not possible to write readable code in Perl. I prefer to think that Perlheads just like it that way. =8^) I think a lot also has to do with coding style. People who write unreadable code will do so in any language. I ardently comment my code far more than the average programmer, IMO. Partially because I can seldom remember what I did in 6 months, and partially because if I were to pass my code around, I want whomever I'm passing it to immediately be able to understand what I was thinking. I think the problem with JAPHs (or PerlHeads as you call them) forget that there may be others who don't know the language as well as they do. Additionally, they're also quite expert programmers who also don't believe in commenting their code, believing the code should speak for itself :) -- 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: [gnhlug-announce] MELBA Meeting Wednesday night
Whats a mini install fest? Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 3:21 PM To: [EMAIL PROTECTED] Subject: [gnhlug-announce] MELBA Meeting Wednesday night When: Wednesday, 21 August 2002, 19:30ish Where: Martha's Exchange, Nashua (2nd floor) Why:Because we haven't gotten together there in a while. (and to heckle Ben :) Topic: We have none, but if people want to attempt a mini-install fest, bring CDs of the distro of your choice, and we'll aim to help you install. Other than that, we'll just get together and hang out :) Dinner will be at 18:00ish in the usual corner. Walk in the front door and head towards the large copper kettles to the right. At the end of the bar turn left and go all the way to the back. The geeky looking crowd talking about bizarre and arcane stuff will be us. -- 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-announce mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-announce ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
I think the more interesting question is How dense is the resulting object code which implements the semantics of the program?. This has been an on-going language design/implementation question for most of the history of computing. For example, a particular program can be implemented in C which performs a certain action or actions intended to solve a problem. A high level language like Fortran for example might result in much tighter higher performance object code than the same C program. C was deliberately designed to inhibit compiler optimizations - the philosophy of the language designers was that the programmer should have more control. Fortran on the other hand performs many optimizations by default and a C programmer would need to modify their first iteration of their program to achieve some of the same optimizations. Personally, I prefer readability over terseness. The enemy of reliable, maintainable programs is the terse, clever programmer. Often these terse programs have subtle bugs that are quite difficult to ferret out. Additionally, good compiler designers can out-perform these terse unreadable programs using a myriad of object code optimizations. -Alex P.S. All bets are off however if the programmer implements a better algorithmn... - Original Message - From: [EMAIL PROTECTED] To: Greater NH Linux User Group [EMAIL PROTECTED] Sent: Tuesday, August 20, 2002 9:19 AM Subject: Re: sorting pathnames by basename On 20 Aug 2002, at 8:07am, Kevin D. Clark wrote: It was a one-liner. Take it for what it was. I am curious: If that Perl code was optimized for education (as opposed to source size), what would it look like? I am thinking, specifically, of the Python example that was posted. Without even knowing anything about Python, I suspect that code could be made denser, by eliminating temporary variables and nesting things instead. Can the reverse be done to the Perl code? -- 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 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: File sizes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, Mark Komarinski hath spake thusly: Samba and NFS(v2) don't like 2GB file sizes. http://www.suse.de/~aj/linux_lfs.html That page is a bit outdated. It talks about RH 6.2 as being current, and doesn't mention ext3 at all. I happened to be looking at the changelog for Samba the other day for something unrelated, and noticed that recent versions DO have support for large files as of 2.2.1: New option to allow new Windows 2000 large file (64k) streaming read/write options. Needs a 64 bit underlying operating system (for Linux use kernel 2.4 with glibc 2.2 or above). Can improve performance by 10% with Windows 2000 clients. Defaults to off. Not as tested as some other Samba code paths. http://us2.samba.org/samba/whatsnew/samba-2.2.5.html Haven't used this, so don't know how well it works. However, apparently if you're not using Win2k to transfer from, you're still limited to Windows 4GB SMB limit. Your best bet will probably be to remove the disk and mount it in the system you're going to back it up to, and do the copy locally. - -- 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 iD8DBQE9Yk2udjdlQoHP510RAlvKAJ9BGxujE5Vtd7YQEOSffZZn6U97igCfa9PJ OTi1RUHSAEvseoUfvoLanbQ= =v/dU -END PGP SIGNATURE- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: Somewhat OT: Information Wave bans RIAA
In a message dated: 19 Aug 2002 18:22:20 EDT Ryan T. McCarthy said: If you want the whole internet experience, I take it you don't filter spam. You are paying for access to it, after all. There is a huge difference between *me* choosing to filter spam and someone else *telling* me it won't allow it to come through to me. I don't disagree that connecting to the RIAA website could be considered a security issue, and I don't deny that the RIAA are an intrisically and inherently evil organization that doesn't care one whit about anyone else other than themselves and their own profits. However, I should have the choice to visit any site I want if I'm paying for internet access. I don't see anyone blacklisting web sites which launch 5000 pop-up ads, which could also be considered a security risk. The ISP deciding to block sites for my safety is the same as the gov't dictating I shall wear a seatbelt in *my* car, or that I can't smoke the plant leaf of my choice in *my* house. From a security perspective, I fully agree that the RIAA website probably shouldn't be visited. From a freedom of choice perspective, I fully believe that I should at least *have* the choice. If I were an IWT customer, I'd probably switch. Of course, it would also depend upon how good their service was, and whether or not they had previously pissed me off. As I've stated, I've never visited the RIAA website before, nor am I likely to in the future, so, this one move might not provoke me to switch my ISP. However, if they kept the practice up and did something like ban some of the hacker sites because *they* deemed them *potentially* dangerous, then I'd be outta there! Note: I'm arguing for the sake of arguing here. I don't like the practice, but I'm not directly affected by it, so I don't really care what IWT does :) -- 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: [gnhlug-announce] MELBA Meeting Wednesday night
In a message dated: Tue, 20 Aug 2002 07:17:55 EDT Jim Cadorette said: Whats a mini install fest? It's like a big install-fest, only smaller :) -- 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: File sizes
In a message dated: 20 Aug 2002 07:34:27 EDT Kenneth E. Lussier said: Hi All, Can the 2GB file size limit be changed? I need to store about 10GB worth of data in a single file, but it dies at 2GB. I don't know if ext2 supports big files. I think you need to turn something on in the kernel somewhere too. I was doing this with XFS on my amanda server at MCL and storing files between 3-6GB at the time. XFS is specifically designed to deal with large files (SGI, movie-making, yadda, yadda, yadda) as opposed to ReiserFS which was specifically designed to deal with lots and lots of small files. I'd try out XFS, recompile your kernel, and go from there. It can definitely be done. -- 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: sorting pathnames by basename
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, [EMAIL PROTECTED] hath spake thusly: 1. Perl seems to favor supporting a variety of features with obscure, meaningless, two-character variables that might be clearer with flags or arguments to functions that make use of it. Define obscure please. Try m-w.com. :) Or, I'll save you the trouble: 1 a : DARK, DIM b : shrouded in or hidden by darkness c : not clearly seen or easily distinguished : FAINT 2 : not readily understood or clearly expressed; also : MYSTERIOUS While definition 1 amuses me the most, definition 2 is what I'm talking about. It's not that the meaning isn't documented; it's that it's not clear from the reading, and memorizing the meanings of a couple of dozen two-character variables, particularly for use with a language which touts having no artificial limits, seems backward and archaic. Here are two ways to do (more or less) the same thing, one in C and one in Perl: setlinebuf( file ); $| = 1; Which is clearer to the inexperienced reader (but experienced programmer)? Which is easier to remember, for the average person? There is nothing to $| to attach any meaning to it... Programming Perl seems to almost, but not quite recognize how painful these things are to learn, by offering mnemonic devicess for each of them. But Perl hackers seem to favor this kind of variable, using them often when there's no need to. Everything in the perl language is tediously and breathtakingly documented and quickly accessible to any system on which perl has been installed using either the 'man' or 'perldoc' commands. Again, it's not about documentation. It's about design. Whereas in many ways, Perl seems to have gone out of its way to work like other common Unix tools/languages (shell scripting, C, sed/grep), in others it seems to go out of its way to do things in such a way as to be as confusing as possible. Example? 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. 2. The people who like to program Perl seem to have a propensity to prefer to write code which takes advantage of all the obscure features, and generally to write code which is unreadable. Well, I guess it depends upon how well you know the language. I can say the same for just about any language I've ever looked at. For example, the C code in libc is about as obscure undecipherable as it gets :) Well, there are certainly people who like to write obscure C as well. It just seems to be part of the Perl culture... I've seen far less readable Perl than C. In fact, I'd say the most readable Perl I've seen was in Learning Perl, and some of that I thought looked kinda gross too. It is as if unreadability was designed into the language. - -- 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 iD8DBQE9YlYbdjdlQoHP510RAujqAKCzFvzLIlnNViBmR3bnAuyUO2yAogCgjZv4 TH7aJx4+lIQCj74Bmp88ycU= =twNK -END PGP SIGNATURE- ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
I respond to Michael O'Donnell, Kevin Clark, Ben Scott, and [EMAIL PROTECTED] in this response: Michael O'Donnell wrote: Wow. That doesn't suck. Thanks! Well, I wrote it in a text editor called BBEdit on Mac OS X. BBEdit's advert blurb is, literally: It doesn't suck (http://barebones.com/). Which I agree with wholeheartedly, it is my favorite programming environment. Kevin Clark wrote: One-liners are not representitive of the readability of Perl code. I hope you agree. Definitely. Perhaps those who are new to Perl don't quite see it yet (although I admit that I am still new to Perl), but I find that the one-liners are very elegant and spare me the bother of dropping into an editor for something so simple. Like writing some bash code right there on the command line. For that matter, I have to defer to Kevin's one-liner as it was definitely more elegant than the Python code. I only posted it because he asked for it! Kevin Clark also wrote: Can any of the Python programmers on this list implement this as a one-liner? Just wondering. (with Python's indentation rules, I think that this would be difficult) It's antithetical to the Python Way. JAPHs like elegant and terse one-liners, but Pythoneers generally don't or can't use them. Larry Wall wrote Perl so that there is more than one way to do everything, including coding style (use strict or english, etc). Python's philosophy is there should generally be one obvious way to do something even if that isn't the most efficient-looking code. Kevin Clark finally added: OBTW, while I appreciate Erik's effort (because, in fact, I am learning Python), in actuality, I believe that his program contains a bug Good point! That Python script was a five-minuter. If I had written it properly, it should have taken this into account, and also been written as a module so that it could itself be reimplemented in other code later (import basenamesort.py). Also, instead of being limited to just a filter for standard input, it would also have had the ability to be executed directly as a standalone program, perhaps with an argument passed to it (filenames.txt or something). That would have made it a proper modular Python script, but I fell asleep during Clash of the Titans at a friends' house a short while before , and I just wanted to check/respond to email before I went to bed. Of course a Python script could be written to accommodate these extra functions. Ben Scott wrote: Without even knowing anything about Python, I suspect that code could be made denser, by eliminating temporary variables and nesting things instead. Actually, I tried to write it more densely but couldn't. I'm not a Python guru by any stretch, but I had thought that I could use for key in sorted.sort() instead of having the sort() method call on a separate line. Apparently I can't. I've been spending a LOT more time learning Perl than Python, lately (b/c I'm unemployed and there are dozens more Perl jobs than Python jobs out there right now). Ben Scott also wrote: This is an accident. In general, Perl was not designed -- it evolved. It started small, and then creeping featurism ran rampant on it. Much like Unix, there are a great many things in Perl that don't make a lot of sense unless you know the history behind them. That's right! Don't forget that Perl 6 is (supposed to be) completely redesigned from scratch for this very reason. [EMAIL PROTECTED] wrote: Is Python also a text-munging type language aimed at sysadmin type problems? Was it too, specifically designed to pick up where awk and sed fell short? Guido van Rossum originally wrote the language specifically for educational purposes, because of all of the shortcomings of BASIC. He wanted a fully object-oriented language that be difficult for programmers to develop bad habits from (note the lack of a GOTO, and the strict enforcement of whitespace and indenting). This is why Python has a nice interactive interpreter -- for real-time experimentation. Of course, programmers like the interactive interpreter because they can whip up a function or class definition and then play with it to see how it interacts with their code without having to execute an entire script, getting immediate feedback on their work. While I have seen some system-administration stuff written in Python, there isn't much. For one, Perl is far more widely-used and installed on more systems. Also, if I had to do extensive text munging, there is no question that I would use Perl to do it over Python unless I had some compelling reason not to. (This is just my opinion, but) Perl's text-munging abilities are more convenient to use than Python's. It's like, they're built into the syntax and mentality of Perl, whereas with Python you will probably end up importing a module like the string module and then executing various methods of the String object (or
Programming [was Re: sorting pathnames by basename ]
In a message dated: Tue, 20 Aug 2002 11:57:55 EDT Erik Price said: But at the point where I say to myself, I really think that I could write this better and more easily if I used an object-oriented methodology and designed some class definitions to help me, I would turn to Python and not look back. Not knowing much about OO technique and/or methodology other than what I've learned from Perl's bastardized attempt to rivet OO onto the backside of a language never meant for OO programming, I have to ask, is there a good, general, non-language specific text about OO design and/or methodology around? I'd like to understand the concepts and terminology used in OO programming before delving into something like Java or Python so that I can take better advantage of the OO features of these languages, but everything I've seen seems very language specific. 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: sorting pathnames by basename
In a message dated: Tue, 20 Aug 2002 10:45:48 EDT Derek D. Martin said: Here are two ways to do (more or less) the same thing, one in C and one in Perl: setlinebuf( file ); $| = 1; Which is clearer to the inexperienced reader (but experienced programmer)? Which is easier to remember, for the average person? There is nothing to $| to attach any meaning to it... 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. Programming Perl seems to almost, but not quite recognize how painful these things are to learn, by offering mnemonic devicess for each of them. But Perl hackers seem to favor this kind of variable, using them often when there's no need to. Well, I think it's more that they're lazy. Why type $OUTPUT_AUTOFLUSH when you can type $| instead? If someone who doesn't know the language needs to know what $| does, it's well documented. (Personally, I always try to accompany these types with a comment that explains what these types of args do. The exceptions being $_ and $!, since they're used so often as a Perl programmer, you should know what those are.) 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. I know C, but I'm not proficient at it. I can write small programs, and do a little damage. But if I were to look at code written by others on this list who are more proficient, I'd be lost. The same goes for Perl. I've been writing perl for 8+ years, which makes me far more proficient at it than I am in any other language. 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. The better you know a language, the less obscure it seems. Perl seems very obscure to those who don't know the language just as C seems quite obscure to those who don't know it. Example? 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. Well, there are certainly people who like to write obscure C as well. It just seems to be part of the Perl culture... I've seen far less readable Perl than C. In fact, I'd say the most readable Perl I've seen was in Learning Perl, and some of that I thought looked kinda gross too. It is as if unreadability was designed into the language. I guess it's all perspective. I look at the code in Learning Perl, and I see very clear and obvious code. -- 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: sorting pathnames by basename
In a message dated: Tue, 20 Aug 2002 10:55:00 EDT Hewitt Tech said: P.S. For many programmers, it's the language they use every day that they favor. What is obscure for the neophyte is business as usual for the experienced programmer in that language. Exactly the point I was trying to make! Thank you! -- 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: sorting pathnames by basename
On Mon, 19 Aug 2002, at 7:18pm, Derek D. Martin wrote: Perl seems to have gone out of its way to work like other common Unix tools/languages (shell scripting, C, sed/grep), in others it seems to go out of its way to do things in such a way as to be as confusing as possible. How is that different from any other language? Most languages borrow from other languages, and yet still do things their own way. Compare C++, Java, and C#, for example. An example of this would be the equivalent of a structure in C (or Pascal or whatever). This is an accident. In general, Perl was not designed -- it evolved. It started small, and then creeping featurism ran rampant on it. Much like Unix, there are a great many things in Perl that don't make a lot of sense unless you know the history behind them. The people who like to program Perl seem to have a propensity to prefer to write code which takes advantage of all the obscure features, and generally to write code which is unreadable. I think you put far too much weight on the recreational hackers who favor neat tricks. It is one thing to fire off one-liners because one can; it is quite another to do so in real life. It is quite possible to write professional-quality, well-documented, non-obscure Perl code. The fact that some people take pleasure from not doing so does not make Perl a bad language. And while it does seem like the Perl community has a large percentage of people who like recreational hacking, I think that just reflects Perl's roots as a language that was evolved through usage. -- 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: Programming [was Re: sorting pathnames by basename ]
On Tuesday, August 20, 2002, at 12:00 PM, [EMAIL PROTECTED] wrote: But at the point where I say to myself, I really think that I could write this better and more easily if I used an object-oriented methodology and designed some class definitions to help me, I would turn to Python and not look back. Not knowing much about OO technique and/or methodology other than what I've learned from Perl's bastardized attempt to rivet OO onto the backside of a language never meant for OO programming, I have to ask, is there a good, general, non-language specific text about OO design and/or methodology around? I'd like to understand the concepts and terminology used in OO programming before delving into something like Java or Python so that I can take better advantage of the OO features of these languages, but everything I've seen seems very language specific. There is a book written just for you, and it is excellent: Beginning Java Objects, by Jacquie Barker (Wrox). This book tends to be a bit pedantic (I think it is written for CS 100 students), often taking a few pages to explain some things that are more briefly explained in Bruce Eckels' Thinking in Java (Prentice Hall). But that is its only drawback, and I actually would rather have more information than I need than less. The book is divided into thirds: 1. The fundamentals and concepts of object oriented programming 2. Object modelling -- turning real life situations into abstract object-based representations 3. Case study -- putting the fundamentals and concepts together to write a full program in Java The book advertises that it does not emphasize one language over others for the most part, and this is entirely correct. While it says Java on the cover, that's obviously for marketing reasons, because you can get through the first two thirds of this book using Python, Java, or even PHP. I think you can use Perl too, though OO in Perl is something that I am still very very new to. (The last third of the book is applying the code in Java, so yes it does focus on Java.) The point is that it teaches the basics of OO programming and design, and not how to write in Java. This book should really be called Beginning Object Oriented Programming and Design for any language, with examples in Java. And I bet that if Python had *half* the mindshare that Java has, Barker would have written the book to use Python instead. Erik PS: I am still reading Bruce Eckel's book Thinking in Java and teaching myself Java, and already I am very glad that I read the first 2/3 of Jacquie Barker's book first. Eckel's book is good, but races through the fundamentals. Barker's book shines when it comes to fundamentals. -- Erik Price email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
On Tuesday, August 20, 2002, at 08:07 AM, Kevin D. Clark wrote: In fact, my one-liner is probably the cannonical way that an experienced Perl programmer would have solved that problem (or, at least, pretty close). For that matter, I find that the word cannonical is bandied about in Perl culture far more than anywhere else! ;) Interesting for a language in which there's more than one way to do things. (Programming Perl defines that word in its glossary as Reduced to a standard form to facilitate comparison.) -- Erik Price email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
Erik Price [EMAIL PROTECTED] writes: For that matter, I find that the word cannonical is bandied about in Perl culture far more than anywhere else! ;) Interesting for a language in which there's more than one way to do things. Well, I just used the word canonical in the canonical way... (-: --kevin -- ``Bob just used `canonical' in the canonical way.'' -- GLS ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
On Tue, 20 Aug 2002, at 10:45am, Derek D. Martin wrote: Programming Perl seems to almost, but not quite recognize how painful these things are to learn, by offering mnemonic devicess for each of them. use English; That is not just an idle comment; it refers to the fact that Perl does recognize that these variables *are* cryptic, and provides a mechanism to As for why many people still use the funny-character variables: It is partly because 'use English' carries a performance penalty for some implementations, but mostly because the funny-character variables came first. Here are two ways to do (more or less) the same thing, one in C and one in Perl: setlinebuf( file ); $| = 1; Here are two days to do (more or less) the same thing, one on Unix and one on MS-Windows: findstr foo myfile.txt grep foo myfile.txt Without knowing either of the two OSes, which is more self-documenting? Which is more obscure? Well, there are certainly people who like to write obscure C as well. It just seems to be part of the Perl culture... I've seen far less readable Perl than C. I think a large part of Perl's reputation for being line noise is that Perl makes heavy use of regular expressions, which *do* look like line noise. Fortunately, however, Perl provides a mechanism for that, too, and is the only languages I know of that does -- the /x modifier allows one to embed whitespace and comments in a regular expression. -- 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
-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
Interesting idea for fighting SPAM...
http://www.habeas.com/faq/index.htm ___ 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 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: Interesting idea for fighting SPAM...
On Tue, Aug 20, 2002 at 03:32:17PM -0400, Jeff Macdonald [EMAIL PROTECTED] wrote: http://www.habeas.com/faq/index.htm (We'll see if this post gets through; I'm 1 for 3 so far) Apparently a lot of people saw the Slashdot story and started coding their own Bayesian spam filters. There have been at least two such filters on the mutt developer's mailing list so far, including one written by ESR. -- Bob Bell [EMAIL PROTECTED] - Felten, who examined the secret source code for Windows 98 under a court order, said he had found 3,000 bugs marked by Microsoft programmers in the portion of Windows 98 he had examined -- and he had looked at only one-seventh of it. -- http://www.zdnet.com/zdnn/stories/news/0,4586,2273581,00.html ___ 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: Fwd: [Tutor] little something in the way of file parsing
On Tue, 20 Aug 2002, at 2:00pm, Erik Price wrote: code #!/usr/bin/python Heh. This is pretty ironic. One of the standard Luddite responses to Python is that whitespace is syntactically significant. Personally, I find it a bit weird, but I'm not used to it, and it certainly isn't a show-stopper. But in this case, this property of Python has come into conflict with something: The message was mangled by line-wrapping, and thus, the indentation is no longer sane. Any chance you can either (1) fixup the code to wrap 75 columns, or (2) post it on the web somewhere? -- 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) ]
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: sorting pathnames by basename
On Mon, Aug 19, 2002 at 03:46:40PM -0400, Michael O'Donnell [EMAIL PROTECTED] wrote: Given a list of pathnames, I'd like to be able to sort that list by the basename of each file in the list, ie. the pathname q/r/s/t/u/v/aaa ...would sort ahead of //bbb ...because the basename 'aaa' sorts lexicographically ahead of 'bbb'. My current approach is a bit clunky but works as long as the pathnames in question contain no spaces, thus: sed -e 's;/\([^/]*\)$; \1;' | sort -bfd +1 | sed -e 's; ;/;' ...which replaces the last slash in each pathname with a space, sorts that list of dual-field space-delimited records keyed on the second field, and then replaces the slashes. Suggestions for improvement welcome. '/' is an illegal character in a filename, right? sed -e 's;\(\(.*\)/\)*\(.*\);\3/\1\3;' | sort -fdt/k1 | sed -e 's;[^/]*/\(.*\);\1;' -- Bob Bell [EMAIL PROTECTED] - Digital files cannot be made uncopyable, any more than water can be made not wet. -- Bruce Schneier, CRYPTO-GRAM, May 15, 2001 ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
Re: sorting pathnames by basename
On Tue, 20 Aug 2002, at 12:30pm, Erik Price wrote: For that matter, I find that the word cannonical is bandied about in Perl culture far more than anywhere else! ;) Interesting for a language in which there's more than one way to do things. I suspect that is why. If there are many ways to do things, the community will likely want to settle on a subset of them. Hence the term idiom, which also gets a lot of use in Perl. Consider these three English sentences: - That is Fred's pencil. - That pencil belongs to Fred. - That is the pencil of Fred. All three mean the same thing, but the first is by far the most common in American English. Perl is a lot like English. (Hmmm, that could be considered an insult to Perl. grin) -- 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
Python (was: sorting pathnames by basename)
On Tue, 20 Aug 2002, at 9:54am, [EMAIL PROTECTED] wrote: Is Python also a text-munging type language aimed at sysadmin type problems? Was it too, specifically designed to pick up where awk and sed fell short? I know nothing about the Python language, but I do know a tiny bit about the design goals behind it (which I got mainly from discussions with Python fans). I would say the single biggest design goal of Python is elegance, in the Jargon File sense [1]. Take the quote A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away., apply it to a programming language, and you get Python. Other design goals include pervasive object-orientedness, a clean -- even sparse -- syntax, and interactive, dynamic operation. Python is not specialized for text munching the way Perl is. As I understand it, much of the functionality of Perl's text processing is available as standard library modules in Python, but the language itself is no more suited to that than it is to anything else. Myself, I would love to attend more LUG meetings about Python. [1] http://www.tuxedo.org/~esr/jargon/html/entry/elegant.html -- 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
Re: sorting pathnames by basename
On Tuesday, August 20, 2002, at 08:28 PM, [EMAIL PROTECTED] wrote: All three mean the same thing, but the first is by far the most common in American English. Perl is a lot like English. I couldn't agree more. Here's why: English is supposedly the hardest language in the world to learn. Why? Because there are so many ways to say the same thing! Yes, that is the reason AFAIK. I'm not just talking about synonyms, I'm talking about the way you can structure the grammar of the language to mean the same thing, but in so many ways. I studied Japanese for years when I was in college, almost double-majoring with it but not quite. And I was struck by how systematic that language is. Sure, a lot of people will naturally wonder if it's very hard, since there is a complex writing system based on Chinese that consists of tens of thousands of characters (the Kanji). But as far as learning the core, the very grammar of the language itself, it is amazingly straightforward! Although there is more than one way to do it, this generally has more to do with slang and formality than with the way that the language is structured. Perl is definitely English-like in this regard. Erik -- Erik Price email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
