...making Linux just a little more fun!
clarjon1 [clarjon1 at gmail.com]
Tue, 1 Aug 2006 20:50:57 -0400
Hello, gang! I've worked on my perl program a bit, and added stuff like command line switches to it. I've gotten it set up so that, if I don't enter a switch, it will display the contents of the 'calendar' file, and if there is a command line switch, it won't. Nothing fancy...
I've attatched it, because I don't want to spend a lot of time stripping out a lot of comments. Hope you don't mind. Here's what I want to do (other than update the TODO in it):
1) More interactive: Nothing like Ncurses, just something along the lines of if I add my -A switch (for Add), and I don't specify any input, that it will allow me to enter input rather than just add a blank line. 2) Make it use arrays! That is, be able to read arrays from disk. Or would I just be better off telling it to use postgres as a database? Either way, I don't know what to do. 3) Make it able to search for a specific item, and/or sort by specific items. Very useful, dunno if it's worth the time and effort, really.
That's all I can think of at the moment.
Oh yeah, the announcement!
I'm going to Los Angeles, California on the 8th this month, to attend the DCLA conference there. I'm going to be in a plane on Monday! Very nervous, I am. I believe that we will be driving a 2hr drive down to Toronto, Ontario, and then taking a flight from there all the way to LA (hope I get a window seat!!)
Any LG people in LA? Maybe we could meet (unlikely, but would be nice :D)
Apparently, the hotel is nearby the conference (a Hilton, I've heard)
* Clarjon1 at jon.clarjon1.linux goes off, being excited...
Benjamin A. Okopnik [ben at linuxgazette.net]
Wed, 2 Aug 2006 09:25:15 -0400
On Tue, Aug 01, 2006 at 08:50:57PM -0400, clarjon1 wrote:
> Hello, gang! > I've worked on my perl program a bit, and added stuff like command > line switches to it. I've gotten it set up so that, if I don't enter > a switch, it will display the contents of the 'calendar' file, and if > there is a command line switch, it won't. Nothing fancy... > > I've attatched it, because I don't want to spend a lot of time > stripping out a lot of comments.
Ah, the old "invisible attachment" trick...
> 2) Make it use arrays! That is, be able to read arrays from disk. Or > would I just be better off telling it to use postgres as a database? > Either way, I don't know what to do.
Actually, you should use hashes. They sound a lot cooler than stodgy old
arrays. 
(Hint: use programming structures because they're the best model for your data - not for the coolness factor.) Besides, you can't "read arrays from disk", unless you build some sort of a strange 'tie' binding to arrays... you can, however, read data from disk, and save it into arrays for further processing.
> 3) Make it able to search for a specific item, and/or sort by specific > items. Very useful, dunno if it's worth the time and effort, really.
Searching with Perl is pretty trivial. For data stored in an array, it's as simple as
/search_term/ && print for @data;Hmm. Perhaps I should unroll that just a little:
for ( @data ){
print if /search_term/
}
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://linuxgazette.net *
Thomas Adam [thomas.adam22 at gmail.com]
Wed, 2 Aug 2006 14:30:22 +0100
On Wed, 2 Aug 2006 09:25:15 -0400 "Benjamin A. Okopnik" <ben at linuxgazette.net> wrote:
> (Hint: use programming structures because they're the best model for > your data - not for the coolness factor.) Besides, you can't "read > arrays from disk", unless you build some sort of a strange 'tie' binding > to arrays... you can, however, read data from disk, and save it into > arrays for further processing.
You sort of can if you use YAML. I use this all the time in Ruby for storing
(to disk) data structures.
-- Thomas Adam
-- ThisWindow (thomas_adam) Destroy
Benjamin A. Okopnik [ben at linuxgazette.net]
Wed, 2 Aug 2006 09:52:42 -0400
On Wed, Aug 02, 2006 at 02:30:22PM +0100, Thomas Adam wrote:
> On Wed, 2 Aug 2006 09:25:15 -0400 > "Benjamin A. Okopnik" <ben at linuxgazette.net> wrote: > > > (Hint: use programming structures because they're the best model for > > your data - not for the coolness factor.) Besides, you can't "read > > arrays from disk", unless you build some sort of a strange 'tie' binding > > to arrays... you can, however, read data from disk, and save it into > > arrays for further processing. > > You sort of can if you use YAML. I use this all the time in Ruby for storing > (to disk) data structures.
Oh, you can definitely do it in Perl - I mean, heck, 'Tie::Array.pm' is part of the kit that comes with the default install. It's just that... well, you can store hashes just as easily, and there are a lot more methods that use Tie::Hash (e.g., NDBM_File) than Tie::Array.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://linuxgazette.net *
clarjon1 [clarjon1 at gmail.com]
Sun, 6 Aug 2006 20:00:10 -0400
> > Ah, the old "invisible attachment" trick... >
oops... Nope, that was just me not paying attention to what button I clicked when I was trying to save the Email as a Draft email in Gmail....
I didn't have it on me then, but I do now!
I forget if I told you yet what it can do...
calprog -A <text> Adds text (entry in calendar file in my case) calprog -s <text> searches for text in file calprog -h Help.If anything, I've got a little perl tool to search through a file for a word, anyways, a simple grep I suppose...
but yeah.
***Jonathan is now very excited... His trip is Tomorrow!!
Benjamin A. Okopnik [ben at linuxgazette.net]
Mon, 7 Aug 2006 14:46:08 -0400
On Sun, Aug 06, 2006 at 08:00:10PM -0400, clarjon1 wrote:
> > I forget if I told you yet what it can do... > > calprog -A <text> Adds text (entry in calendar file in my case) > calprog -s <text> searches for text in file > calprog -h Help.
This isn't Perl-specific, but in general, I find that text entry/selection on the command line is not a great idea; the following entries, for example, will create problems:
calprog -sIndeed, the last one will get you into a whole lot of trouble [1]. In my opinion, arbitrary user input is best confined to explicitly reading STDIN instead of taking chances with shell interpretation. Yes, you could surround the entire string in quotes (what kind? What if both the single and the double quotes are already contained in the string?), but it's a pain - and the penalties can be rather severe if you forget.
> If anything, I've got a little perl tool to search through a file for > a word, anyways, a simple grep I suppose...
As you probably expected, I have a few comments. As usual, mine will be preceded by '###' at the beginning of the line.
#!/usr/bin/perl
### Not having the computer check your code is an error committed by
### many new Perl users. You should always - yes, always - enable warnings,
### either via the '-w' option above, or via the 'use warnings' pragma.
use Getopt::Std;
### Loading 600+ lines worth of module for simple option processing is
### a bit of a waste, considering that Perl has this capability as a
### built in. See 'perldoc perlrun' and read about the '-s' option.
$ver = "0.2.3";
### Since this isn't a module, there's not a whole lot of point to this
### variable; it'll never be used.
use subs;
### [blink] This does exactly nothing without a parameter list - except
### loading a bunch of code that's never used.
$if_nothing_is_sel_print_file = 0;
### Setting flags like this is rather clumsy. Instead, arrange your
### program logic so that this action happens in a correct sequence.
getopts(Ahs);
$shift = shift;
### You're assuming that there's input following the option. That's
### going to bite you one day...
calsearch() if ($opt_s);
gethelp() if ($opt_h);
calwrite() if ($opt_A);
### These are not complex functions; using subroutines to invoke them
### contributes little to clarity. You may want to consider a more linear
### style of programming.
open(OUTFILE, "+>> calendar") or die "Cannot open the calendar for writing!$!";
### Why are you opening the file in 'read/append' mode? You're not
### reading anything from it in this subroutine.
#This just grabbed the search term from the command line. How do you get
#more than one term? Other than running the app again... what about if
#I stuck it into a loop, and it iterated through for each term? All in
#due time, I guess...
### The entire command line is available in @ARGV - but I've already
### mentioned the problems in that input mode. Consider a 'do/while' loop,
### perhaps, with an entry that terminates input (e.g., 'Quit'.)
sub gethelp
{
print "calprog v0.1 \nCopyright 2006 Jonathan Clark\n";
### Remember that version string I mentioned?... You're out of sync with
### yourself. Consider sticking with a comment, or even an SCCS ID string
### (e.g., '# $Id: calprog,v 0.2.3 2006/08/07 14:38:59 clarjohn Exp $'.)
#Wow, the todos and comments take up more space than the code itself! Now, that's documentation!
### [smile] If you had used POD (see 'perldoc perlpod'), it would be
### documentation. As is, it's just comments in a file that no user will
### ever read - looking at code tends to scare people.
[1] Due to the order of CLI processing, the command in backticks will be
executed even before your program runs; the above example will wreak
havoc in your current directory.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://linuxgazette.net *