On Wed, Aug 21, 2002 at 11:43:43AM -0700, drieux wrote:
> On Wednesday, August 21, 2002, at 10:06 , Paul Tremblay wrote:
>
> > I am writing a script that converts RTF to XML, and this script needs
> > to read an external data file to form a hash. I plan to make this
> > script available to anyone who needs it, and am wondering what to do
> > with this external data file.
>
> when you say 'external data file' - do you mean things
> that are required for the script itself to work? if so,
> you may want to look at the traditional solution of
> getting those to install into the site_perl as a perl module,
> hence you will most likely want to look at h2xs as a
> first round for how to do that....
Okay, I'm getting closer to finishing the d**n beast of a script, so I
need to think about how to distribute it. This script will be a
command line utility. Right now it has no switches:
rtf2xml <file>
I want to make it easy to use for people who don't know perl. Should I
still use a module?
My understanding of a module is that it provides code for other perl
scripts, rather than being a stand alone utility by itself.
I am thinking that if I distribute this script as a module, I will
have to write a wrapper for it? That is, say I have a script like
this:
#!perl
print "hello world";
I have to re-write it so it looks like:
sub main{
print "hello world";
}
Now I call this module hello_world.pm. This installs in the proper
places. I write another script that looks like this:
#!perl
use hello_world;
&main();
Thanks
Paul
>
> or do you mean, as seems to be suggested below,
> any 'temporary files' that are created in transit?
>
> > Should I simply make the data file available with the script and tell
> > the user where to put it? Right now, I have it in
> > /usr/share/rtf2xml/char_data.data.
>
> a reasonable alternative plan - but going with the
> traditional perl module approach will mean that
> they can then just do the usual
>
> perl Makefile.PL
> make
> make test
> make install
>
> and let it go at that...
>
> This way if you need to upgrade along the way - and it's
> all nice and neatly in a perl module - you can then distribute
> a new release of it - and not need to upgrade the core code itself.
>
> [..]
>
> > Also, the script outputs to standard output. Future versions might
> > require that the script make one run through the file, write to a temp
> > file, then make a run through the temp file. Where should I put this
> > temp file (if I need to make one, that is)?
>
> [..]
>
> you might want to look at
>
> IO::File
>
> and use the new_tmpfile method to create a temp file
> 'for the duration' - before sending it to stdout....
>
> also IF in this future upgrade you start doing the
>
> myCode Infile Outfile
>
> then you could use the file named as Outfile as the temp file,
> unless you allow things like
>
> myCode Infile - | doFoo
>
> where you expressly allow '-' as the 'cheat' that you want
> the output to finally go to stdout....
>
> ciao
> drieux
>
> ---
>
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
************************
*Paul Tremblay *
*[EMAIL PROTECTED]*
************************
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
