ftnpl-develop Mailing List for Perl for FTN Systems (Page 5)
Brought to you by:
jame
Menu
▾
▴
ftnpl-develop — Developing Perl for FTN systems
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(51) |
Sep
(33) |
Oct
(27) |
Nov
(3) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Russ J. <ru...@di...> - 2001-08-27 02:10:08
|
At 07:00 PM 8/26/2001 -0400, you wrote: > I can certainly see possibilities with that, but it will defintely need >a more flexible way of doing the command line parameters...<g> From what I've read here, it should be easy to use -f [text|html] in the getopts section. Doing both could be a little tricky. Russ Johnson Stargate Online http://www.dimstar.net telnet://telnet.dimstar.net ICQ: 3739685 |
|
From: Robert J. C. <rj...@ho...> - 2001-08-26 23:26:17
|
Russ, > I'm going to add three command line parameters; one for defineing the > logfile, one for defineing the "$INDIR" parameter, & one for defineing the > "$OUTDIR" variable. Once I have the logfile defined by a command line > parameter or by default, I'll clean up the logging subroutine as neccessary. I think I'm going to do that in two different steps... I'm going to work on the logging first, then merge that back in. Then do those two parameters for the $INDIR & $OUTDIR (& perhaps the one to keep input files) as part of the change over to the long parameters... Jame |
|
From: Robert J. C. <rj...@ho...> - 2001-08-26 23:02:43
|
Russ,
> .... We'll need a command line parameter to specify what output.
That can be done with the existing way of handling parameters; if set
(whatever parameter is used), it outputs html, otherwise it defaults to
outputting text.
> Another concern is what if someone wants multiple forms of output?
I can certainly see possibilities with that, but it will defintely need
a more flexible way of doing the command line parameters...<g>
That's what I'll work on next, changing the command line processing over
to useing the longer parameters...
> We also should have the option (command line parameter) of NOT deleting
the
> input files.
I've added that to the todo list, but that could be done later...
Jame
|
|
From: Russ J. <ru...@di...> - 2001-08-26 21:22:17
|
OK, and my main area of concern will be the output filename, and adding HTML output. This will involve adding at least one new subroutine. We have &printtext for the text output. I'll be using &printhtml for the new subroutine. We'll need a command line parameter to specify what output. Another concern is what if someone wants multiple forms of output? I'm thinking the newmsg (I'll be changing this too :) ) routine could call each version of output. We also should have the option (command line parameter) of NOT deleting the input files. This will be useful for testing, but someone may also want to do this in a production environment. I'm probably missing something here, but that's what I'm thinking right now. At 04:36 PM 8/26/2001 -0400, you wrote: >Russ, > > I've added some files, as follows: > >README - A readme file giving a brief description of what the script >does, & lists what the files > in the directory are for. > >file_id.diz - standard file_id.diz file (I hope...<g>) describeing >this script > >pk2txt.sh - an example shell script for running pkt2txt.pl. Not >real important now, but it will be > when there are more parameters... > > > I also updated the TODO list. What I'm going to be working on is adding >some parameters & cleaning up the logging subroutine (likely including a >name change for the subroutine). I'll be doing this, btw, by using doing a >branch to work on the changes & then merge the changes back in once they're >working; the kind of changes I'm going to do perhaps does not neccessitate >an actual branch, but OTOH I need practice on how to do branching & >merging...<g> > > I'm going to add three command line parameters; one for defineing the >logfile, one for defineing the "$INDIR" parameter, & one for defineing the >"$OUTDIR" variable. Once I have the logfile defined by a command line >parameter or by default, I'll clean up the logging subroutine as neccessary. >And I'll be changeing the example shell script as neccessary as I go >along... > > Once that's all done, I'll see about merging it back in to the main >branch... I'll mostly be working only on the commandline subroutine & what >is currently called the logmsg subroutine, so it should merge back in with >no real problems; assuming I do it right, at least...<g> > > > >Jame > > > > > >_______________________________________________ >Ftnpl-develop mailing list >Ftn...@li... >http://lists.sourceforge.net/lists/listinfo/ftnpl-develop Russ Johnson Stargate Online http://www.dimstar.net telnet://telnet.dimstar.net ICQ: 3739685 |
|
From: Robert J. C. <rj...@ho...> - 2001-08-26 20:38:15
|
Russ,
I've added some files, as follows:
README - A readme file giving a brief description of what the script
does, & lists what the files
in the directory are for.
file_id.diz - standard file_id.diz file (I hope...<g>) describeing
this script
pk2txt.sh - an example shell script for running pkt2txt.pl. Not
real important now, but it will be
when there are more parameters...
I also updated the TODO list. What I'm going to be working on is adding
some parameters & cleaning up the logging subroutine (likely including a
name change for the subroutine). I'll be doing this, btw, by using doing a
branch to work on the changes & then merge the changes back in once they're
working; the kind of changes I'm going to do perhaps does not neccessitate
an actual branch, but OTOH I need practice on how to do branching &
merging...<g>
I'm going to add three command line parameters; one for defineing the
logfile, one for defineing the "$INDIR" parameter, & one for defineing the
"$OUTDIR" variable. Once I have the logfile defined by a command line
parameter or by default, I'll clean up the logging subroutine as neccessary.
And I'll be changeing the example shell script as neccessary as I go
along...
Once that's all done, I'll see about merging it back in to the main
branch... I'll mostly be working only on the commandline subroutine & what
is currently called the logmsg subroutine, so it should merge back in with
no real problems; assuming I do it right, at least...<g>
Jame
|
|
From: Robert J. C. <rj...@ho...> - 2001-08-26 18:31:16
|
Russ,
> I might not get to the html stuff this weekend.
If not now, then later...<g>
I'd recommend changing the way the message file nameing is done first,
any way... The way it's being done now does work, but is not particularly
expandable...
I propose that the message file nameing be changed to the format of
msgnumber.txt, instead of echoname.msgnumber... I.E; from "testecho.1"
to "1.txt". The directory they're in is already named for the echo, so
it's not needed in the message file name; & an extension like "txt" can
easily be changed to something like "html" (as a for instance <g>) as part
of an extension to the script for what type of text files it outputs...
What do you think?
>I've just spent most of the weekend cleaning up loose ends.
> See my cvs notes for specifically what I did.
Yep, saw that... Particularly liked your correction about processing
unarchive packet files; that's something I'd noticed in testing, but
wasn't sure if it wasn't an artifact of what I was doing, & in anycase I
kept on forgetting to ask you about it...
Jame
|
|
From: Robert J. C. <rj...@ho...> - 2001-08-26 17:44:47
|
Russ,
> > For the first two, $PKTvar & $attrib in the newsmsgs subroutine, I
> > just put in a couple of lines that "drop" the variables right after
they're
> > used...
>
> Don't worry about any errors/warnings about the use of those "drop"
> methods; I've added a line to localize them in that subroutine that
takes
> care of it.
And upon further testing, I found that that still didn't take care of
it; so I changed the "drop" to an "undef"...
That works fine on my test point...
Jame
|
|
From: Robert J. C. <rj...@ho...> - 2001-08-26 17:34:47
|
Russ,
> For the first two, $PKTvar & $attrib in the newmsgs subroutine, I
just
> put in a couple of lines that "drop" the variables right after they're
> used...
Don't worry about any errors/warnings about the use of those "drop"
methods; I've added a line to localize them in that subroutine that takes
care of it.
Jame
|
|
From: Robert J. C. <rj...@ho...> - 2001-08-26 17:06:53
|
Russ,
> I need to figure out what I want to do with those four variables that are
> only used once. There's really nothing I want to do with them at this
> point. They're unused for the most part.
You're referring to the $PKTvar, $attrib, $c, & $progid2?
For the first two, $PKTvar & $attrib in the newmsgs subroutine, I just
put in a couple of lines that "drop" the variables right after they're
used... They're needed in that unpack statement, so we can't get rid of
them altogether; but you're right, they're otherwise not being used at the
momemt. Doing the drop takes care of the warning about them being used
only once without affecting the unpack statement.
That variable $c is also in the newsmsgs subroutine (& I just noticed
this; shouldn't that be newmsgs? "new", not "news"> <g>) & is not used at
all... Just take it out of that 'local statement? I didn't change that
because I'm not sure what it might have been originally for...
The $progid2 variable is in the logmsg subroutine; it's looks like
it's part of where it's setting up a logfile name apparantly based on the
script name... What I recommend for that is that that part of the
subroutine be dropped altogether & a command line option added to define a
log file name & path, with a default of something like "pkt2txt.log" in the
current directory...
I've updated cvs with the changes for the first two.
Jame
|
|
From: Russ J. <ru...@di...> - 2001-08-26 07:13:36
|
I might not get to the html stuff this weekend. I've just spent most of the weekend cleaning up loose ends. See my cvs notes for specifically what I did. pkt2txt does now require another module. It uses the File::Copy module, which should be standard on every perl. I need to figure out what I want to do with those four variables that are only used once. There's really nothing I want to do with them at this point. They're unused for the most part. Russ Johnson Stargate Online http://www.dimstar.net telnet://telnet.dimstar.net ICQ: 3739685 |
|
From: Russ J. <ru...@di...> - 2001-08-25 23:16:57
|
OK, I checked, it works fine on my system. At 03:31 PM 8/25/2001 -0400, Robert J. Clay wrote: >Russ, > > > > That error came up before, on the old version I had from you before >we > > >started useing the cvs. The error that comes up is "Not enough >arguements > > >for mkdir ..., near ""$OUTDIR/$area";" When I checked that I found >that, > > >at least on my system, that mkdir command also requires a mode entry of >some > > >sort; I used 0750. > > > > That "should" work on my system too. I'll test it out. Did you upload it? > > Yes, indeed! What I did is make a copy of the line, commented out the >original copy & added the 2nd argument to the uncommented copy of the >line... If you've done a 'cvs update' today, you should already have it... > > >Jame > > >_______________________________________________ >Ftnpl-develop mailing list >Ftn...@li... >http://lists.sourceforge.net/lists/listinfo/ftnpl-develop Russ Johnson Stargate Online http://www.dimstar.net telnet://telnet.dimstar.net ICQ: 3739685 |
|
From: Robert J. C. <rj...@ho...> - 2001-08-25 19:34:31
|
Russ, > > That error came up before, on the old version I had from you before we > >started useing the cvs. The error that comes up is "Not enough arguements > >for mkdir ..., near ""$OUTDIR/$area";" When I checked that I found that, > >at least on my system, that mkdir command also requires a mode entry of some > >sort; I used 0750. > > That "should" work on my system too. I'll test it out. Did you upload it? Yes, indeed! What I did is make a copy of the line, commented out the original copy & added the 2nd argument to the uncommented copy of the line... If you've done a 'cvs update' today, you should already have it... Jame |
|
From: Russ J. <ru...@di...> - 2001-08-25 17:23:06
|
At 04:56 AM 8/25/2001 -0400, you wrote: >Russ, > > > Do another get, and you'll have the updated version > > What are running on? I mean, which linux distro & which version of perl? >Because I did do an update & got your changes, & I made some changes to the >command line processing & was trying to test 'em; but ended up with errors >again at the "mkdir" line... I'm using redhat 7.0. With perl 5.6.0. I see the mode in "Programming Perl". It says something about "if mkdir is not built in to your C library, Perl emulates it by calling the mkdir program." I think one of use might have that problem. > That error came up before, on the old version I had from you before we >started useing the cvs. The error that comes up is "Not enough arguements >for mkdir ..., near ""$OUTDIR/$area";" When I checked that I found that, >at least on my system, that mkdir command also requires a mode entry of some >sort; I used 0750. That "should" work on my system too. I'll test it out. Did you upload it? > >. *I* think it's easier to read and understand this way. :) > > Indeed it is...<g> Glad to hear it. It's a format I adopted after starting this particular script. Russ Johnson Stargate Online http://www.dimstar.net telnet://telnet.dimstar.net ICQ: 3739685 |
|
From: Robert J. C. <rj...@ho...> - 2001-08-25 16:03:54
|
Russ,
> Make the archive name descad10.zip.
Since you apparantly hadn't had the time to do it yet, & I wanted it in
there before it gets hatched out; I've added that script as
"scripts/BBBS/descadd" to the cvs repository, & also tagged it as
"descad10_20010822"...
Wanted to actually test it out, but I don't have the time right
now...<g>
Jame
|
|
From: Robert J. C. <rj...@ho...> - 2001-08-25 08:58:14
|
Russ,
> Do another get, and you'll have the updated version
What are running on? I mean, which linux distro & which version of perl?
Because I did do an update & got your changes, & I made some changes to the
command line processing & was trying to test 'em; but ended up with errors
again at the "mkdir" line...
That error came up before, on the old version I had from you before we
started useing the cvs. The error that comes up is "Not enough arguements
for mkdir ..., near ""$OUTDIR/$area";" When I checked that I found that,
at least on my system, that mkdir command also requires a mode entry of some
sort; I used 0750.
I've made a copy of that line, commented out the original with a note
about the error, & changed the duplicate to the version that works on my
system...
>. *I* think it's easier to read and understand this way. :)
Indeed it is...<g>
Jame
|
|
From: Russ J. <ru...@di...> - 2001-08-25 07:31:02
|
Do another get, and you'll have the updated version. *I* think it's easier to read and understand this way. :) Let me know what you think. I guess I'm quicker than I thought... :) At 03:09 AM 8/25/2001 -0400, Robert J. Clay wrote: >Russ, > > > I just took another look at the main part of pkt2txt, and realized that I > > wrote this very sloppy. > > As compared to what?<g>' > > > > I need to redo some of it. I'll be doing that this weekend instead of > > anything else, as I think this will make it easier to extend the code >later. > > Please at least sumarize it (if not list by subroutine) in the TODO >file, even if you figure you'll get it all done this weekend... > > > > The main functions will remain the same, but there's some major clean-up I > > can do on some of this. > > I would recommend that you put a tag on what it currently is before >makeing any changes... (Even if it's only something like "cvs tag >20010825", although more than just the date could be useful also...) > > > > I'll leave the command line parsing alone, so that you can plug it into >what I get done. :) > > That's the only thing I'll work on in there, then; especially to get >a simple debug option working...<g> > > > >Jame > > > > > >_______________________________________________ >Ftnpl-develop mailing list >Ftn...@li... >http://lists.sourceforge.net/lists/listinfo/ftnpl-develop Russ Johnson Stargate Online http://www.dimstar.net telnet://telnet.dimstar.net ICQ: 3739685 |
|
From: Robert J. C. <rj...@ho...> - 2001-08-25 07:11:42
|
Russ,
> I just took another look at the main part of pkt2txt, and realized that I
> wrote this very sloppy.
As compared to what?<g>'
> I need to redo some of it. I'll be doing that this weekend instead of
> anything else, as I think this will make it easier to extend the code
later.
Please at least sumarize it (if not list by subroutine) in the TODO
file, even if you figure you'll get it all done this weekend...
> The main functions will remain the same, but there's some major clean-up I
> can do on some of this.
I would recommend that you put a tag on what it currently is before
makeing any changes... (Even if it's only something like "cvs tag
20010825", although more than just the date could be useful also...)
> I'll leave the command line parsing alone, so that you can plug it into
what I get done. :)
That's the only thing I'll work on in there, then; especially to get
a simple debug option working...<g>
Jame
|
|
From: Russ J. <ru...@di...> - 2001-08-25 06:42:55
|
I just took another look at the main part of pkt2txt, and realized that I wrote this very sloppy. I need to redo some of it. I'll be doing that this weekend instead of anything else, as I think this will make it easier to extend the code later. The main functions will remain the same, but there's some major clean-up I can do on some of this. I'll leave the command line parsing alone, so that you can plug it into what I get done. :) Russ Johnson Stargate Online http://www.dimstar.net telnet://telnet.dimstar.net ICQ: 3739685 |
|
From: Robert J. C. <rj...@ho...> - 2001-08-25 03:48:07
|
Russ,
> Don't add any BBBS related perl scripts to cvs just yet; such scripts
will
> go into the scripts/BBBS path, & I will be createing that when I add a
BBBS
> related script of mine to cvs this weekend...
Actually, it's done now...<g>
So, any Perl scripting that is BBBS specific should go into
scripts/BBBS
> It's a script I've had for awhile, but havev't gotten around to
distributing yet...
The script I added is perl script to read the mrtg standard port on
BBBS, for use when running mrtg to generate the html pages. I finally got
around to putting it together for a release & decided I'd better import it
here before I made too many changes from what I have working...<g>
Because of course, looking at it now I notice some changes I want to
do... And the item I already had in the todo list, I haven't had a chance
to actually work on ...<g> And thinking about it, I've also realized I
left something out of what I've put together; that being an example bbbsd
command line for it...
So I already have changes...<g> Better check out a copy to a
working directory, before I forget what I want to add...
Jame
|
|
From: Robert J. C. <rj...@ho...> - 2001-08-25 02:23:20
|
Don't add any BBBS related perl scripts to cvs just yet; such scripts will go into the scripts/BBBS path, & I will be createing that when I add a BBBS related script of mine to cvs this weekend... It's a script I've had for awhile, but havev't gotten around to distributing yet... Jame |
|
From: Robert J. C. <rj...@ho...> - 2001-08-25 01:42:04
|
Russ,
> And if we do make changes to the same line(s), it can display that in the
source & you
>(or I, or whomever...<g>) can decide how to reconcile the changes and then
commit those changes...
>>>> Russ Johnson <ru...@di...> 08/24/01 02:02AM >>>
>>Assuming you update pkt2txt prior to my working on it again, would I just
>>download a new copy prior to working on it again?
As a for instance; I just ran "cvs update" in the pkt2xt working
directory I have here & it updated my version of it to the current version
from the repository... 'Course, I hadn't done any changes at my end as yet;
but if there had been a problem, it would have said so & it could then be
taken care of...
Jame
|
|
From: Robert C. <JC...@te...> - 2001-08-24 20:24:43
|
Got the word a little while ago from support at sourceforge; looks like = they've taken care of that issue with all of the extra directories! >>> Russ Johnson <ru...@di...> 08/23/01 06:32PM >>> As I delete the files, they and the directories go away on my side, and = it=20 says, "updating blah" when I update with -P option. But the empty = directory=20 is still in the web view. |
|
From: Robert C. <JC...@te...> - 2001-08-24 17:36:16
|
Yeah, I noticed that as well... I have to do the same thing with my = mail client here at work (GroupWise...), so I've been manually redirecting = my replies to just the mailing list... >>> Russ Johnson <ru...@di...> 08/24/01 01:26PM >>> Ack, this list is set to reply to the author, not the list. I may forget = to=20 remove your personal email from the TO: field. I'm using Eudora and have = to=20 hit 'Reply to all' to get it to go to the list. |
|
From: Robert C. <JC...@te...> - 2001-08-24 17:30:08
|
Russ,
No, in general I don't think we'll need to worry about locking =
files... As long as we make sure we keep up to date with what's current =
(at least, before doing commits), we should be all right. cvs seems to =
be pretty good at doing merges, so as long as we're not working on the =
same lines of code it should be able to handle it. And if we do make =
changes to the same line(s), it can display that in the source & you (or =
I, or whomever...<g>) can decide how to reconcile the changes and then =
commit those changes...
(I've only started using CVS with this project; I've been trying to =
figure out why it took me so long to getting around to actually using it, =
rather than just thinking about it...<g> I'm going to set up a repository=
on my systems at home also, if only for things like config files...<g>)
>>> Russ Johnson <ru...@di...> 08/24/01 02:02AM >>>
Assuming you update pkt2txt prior to my working on it again, would I =
just=20
download a new copy prior to working on it again? Should we be "locking"=20=
the file when we're actively working on things? I'd hate to overwrite =
what=20
you add or vice versa.
|
|
From: Russ J. <ru...@di...> - 2001-08-24 17:26:15
|
Ack, this list is set to reply to the author, not the list. I may forget to remove your personal email from the TO: field. I'm using Eudora and have to hit 'Reply to all' to get it to go to the list. At 01:11 PM 8/24/2001 -0400, Robert Clay wrote: > Well, you're right that there's not much difference outputing text & > outputing html; html is just a special form of text, after all... I'm > just anticipating things a bit too much; if it really ends up becoming > too much, it could always be split then. But you're right, that's not > likely to be any time soon.... > >I plan on working on the beginnings of the html stuff some this weekend. Russ Johnson Stargate Online http://www.dimstar.net telnet://telnet.dimstar.net ICQ: 3739685 |
