On Fri, Jun 15, 2007 at 07:35:55PM +0200, Gerfried Fuchs wrote:
> On Fri, Jun 15, 2007 at 09:44:00AM -0600, Neale Pickett wrote:
> > I decided not to use blosxom at all, and I haven't used Perl since
> > version 4, but it seems like it wouldn't be a ton of work to do both:
> > support Getopt::Long and look at $ENV. Then, nothing breaks for
> > anybody.
>
> Thanks for your opinion, it's appreciated. But, pulling in
> Getopt::Long would require yet another module which I would want to
> avoid, especially since it still isn't fully GNU Getopt compatible in
> that it insists on a space between a short option and its value, which
> is quite annoying.
Hi, thanks for your comments. I'm quite OK whatever route you take to
fix the hole. Myself I prefer using existing modules where possible but
I can see that Getopt::Long is not the smallest module around for what
it does. Using $ENV{BLOSXOM_CONFIG_FILE} would certainly be smaller
and it might make a difference in a small but well loaded server.
As to the syntax. The current way of specifying -f, using CGI param(),
requires -f=/etc/foo. I tested the syntax and found that it in the form
I used, Getopt accepts the same -f= syntax as the existing Debian patch.
So no user of -f (if there are any) would have to change. This usage
also accepts "-f /etc/foo"
If you want Getopt as GNU compatible with bundled short-options then
you can change the call to be
use Getopt::Long qw(:config pass_through bundling )
but now it will no longer accept -f= since the = sign will be taken
as part of the string parameter. For full GNU syntax use (:config
pass_through gnu_getopt).
If it were my program I would remove all the sloppy uses of param() to
pass command line options, and replace them with Getopt style processing
or introduce some other mechanism as you propose for the static rendering.
The analysis I did shows that there is no case where a command line
option should also be valid on CGI, nor vice versa. It's really bad:
as we've seen here it's so easy to copy the existing code and introduce
a security problem.
But that magnitude of change belongs upstream :-) If I continue using
Blosxom (it's one of the two blogs I've evaluated so far) then I may
see if I can help bring the main program's coding standards up to scratch.
Nick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
