nms-cgi-devel — Developers discussion for NMS CGI programs

RE: Re[3]: [Nms-cgi-devel] Re: textcounter.pl bugs?!!

[Wizard <wi...@ne...>]

>     , nope, the
>     DOCUMENT_URI  still  doesn't show up.
I think it should be "REQUEST_URI", not "DOCUMENT_URI". Although both work
on Apache, only the "REQUEST_URI" is a documented SSI variable.
"REQUEST_URI" is also the same as "SCRIPT_NAME" when called from CGI script,
but I don't think it is passed in SSI.
Grant M.

Apache comes with 'printenv' (included below), you can run that to see all
of the accepted CGI variables, but just delete it when you're done.
============================================
#!/usr/bin/perl
##
##  printenv -- demo CGI program which just prints its environment
##

print "Content-type: text/plain\n\n";
foreach $var (sort(keys(%ENV))) {
    $val = $ENV{$var};
    $val =~ s|\n|\\n|g;
    $val =~ s|"|\\"|g;
    print "${var}=\"${val}\"\n";
}

Re: [Nms-cgi-devel] Formmail insecurities

[Dave C. <da...@da...>]

On Sun, Jan 27, 2002 at 02:22:39PM +1100, Jeremy Howard (jh_...@fa...) wrote:
> I don't know if you folks have seen this advisory:
>   http://www.monkeys.com/anti-spam/formmail-advisory.pdf
> 
> I've contacted the author and he claims that many of the listed
> vunerabilities are also present in the current NMS version of this script. I
> checked whether he had informed you and he told me that he hasn't, and that
> he doesn't plan to. I don't have any more details--I just figured I'd pass
> on this info...

This chap's site came up on the london.pm list earlier today which
galvanised me into contacting the author.

He seems to think that because he looked at nms Formmail a few weeks ago
he's not going to bother again. He seems to have the idea that we don't 
don'r really know what we're doing because we haven't fixed all of 
Formmail's insecurities.

One interesting thing tho' - he's now released his own version of Formmail
that patches _all_ of the insecurities (or so he claims). 

It's available from <ftp://ftp.monkeys.com/pub/formmail/1.9s/>. Might be
interesting if someone was to take a look.

He's got a more general rant about Formmail up at

<http://www.monkeys.com/anti-spam/filtering/formmail.html>

Dave...

-- 

  .sig missing...

Re[3]: [Nms-cgi-devel] Re: textcounter.pl bugs?!!

[Suresh S. <sur...@ya...>]

I believe my mails are being posted on the developer mailing
list, so  instead of replying to Jonathan & Grant separately
I'll  just  club the replies together in a single mail. Hope
you guys don't mind. :)

================================================================
>     Another  strange  thing  I noticed with Xitami is when i
>     used  <!--#echo  var="DOCUMENT_URI"-->  to print out the
>     variable,  I  get  the  desired output for DOCUMENT_URI,
>     somehow  as you can see from the script output above, it
>     just doesn't get passed on to the cgi program.
>

JS> This smells like a bug in Xitami, is there a mailling list or
JS> something
JS> you can check with then report it to the Xitami people ?  Does
JS> the
JS> variable appear if you run the program directly rather than via
JS> an SSI ?  (i.e. http://localhost/cgi-bin/whatever.pl)

    Well  Jonathan, I tried running the script straight from
    the  cgi-bin, instead of calling from the SSI, nope, the
    DOCUMENT_URI  still  doesn't show up. It may be a bug in
    Xitami  or  maybe  they  decided  not  to  implement it.
    However,  the  SCRIPT_NAME  variable  does  contain  the
    desired  value  so  I guess your assumption was correct.
    I  agree  you  guys have  Xitami pretty much covered but
    there are still quite a few other servers with their own
    little  idiosyncrasies.  :).  Plan  to  test some of the
    scripts  out  with  Savant as well.  Would  you like the
    output from that as well?!! :)

================================================================

GM> Try putting this in place of the "print header();" line of your
GM> script, and
GM> let me know if it still prints out the header:
GM>
GM> print "Content-type: text/html\n\n";
GM>    OR
GM> print "Content-type: text/plain\n\n";

    Nope,  Grant,  Xitami still simply outputs the header, I
    guess the SSI implementation in Xitami is a bit weird.

================================================================

-- 
Best regards,
Suresh.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re[2]: [Nms-cgi-devel] Re: textcounter.pl bugs?!!

[Jonathan S. <gel...@ge...>]

On Mon, 11 Feb 2002, Suresh Sundriyal wrote:
> On Mon, 11 Feb 2001, Jonathan Stowe wrote:
> JS>  I'm with Dave.
> JS>  First thing to bear in mind that SSI  is  only a 'de facto'
> JS>  standard really driven by the  first implementations which were
> JS>  the NCSA httpd and later Apache,   most  other  HTTP  servers
> JS>  follow these implementations but clearly
>
> Hi Jonathan,
>    I  tested  the  script with Xitami as well as Apache, the
>    $ENV{DOCUMENT_URI}  problem I mentioned only appears with
>    Xitami.
>

As I suspected :) It appears that in the case of Xitami the same
information (or nearly the same) is in SCRIPT_NAME so I have changed the
program to use the latter if DOCUMENT_URI isn't present.

>    Anyway,  to  answer  you  question,Yes, I am using "exec cgi"
>    command to call the script.
>

Ok,  I have added a new configuration variable ($ssi_emit_cgi_headers) to
the program, this will default to true.  If set to false it will not
output the header.

I have also put in a mechanism for auto-guessing whether this is likely to
be needed or not with an array @no_header_servers which will contain
patterns that match the names of servers that behave like this. Currently
this only has Xitami in but I am certain there will be others ;-}

I have updated the README with information about the above.

>    As,  for  the script you asked me to run as a cgi, well I
>

Thanks.  We now know how Xitami identifies itself :)

>     Another  strange  thing  I noticed with Xitami is when i
>     used  <!--#echo  var="DOCUMENT_URI"-->  to print out the
>     variable,  I  get  the  desired output for DOCUMENT_URI,
>     somehow  as you can see from the script output above, it
>     just doesn't get passed on to the cgi program.
>

This smells like a bug in Xitami, is there a mailling list or something
you can check with then report it to the Xitami people ?  Does the
variable appear if you run the program directly rather than via
an SSI ?  (i.e. http://localhost/cgi-bin/whatever.pl)

>     Another   strange  thing  you  might  notice is that the
>     content  header  is echoed in the script response, which
>     normally   shouldn't   happen.  This  again  is  Xitami
>     specific. :)
>

Some facet of the same 'exec cgi' implementation weirdness I would
imagine.

>     Hope all of this helps in some way or another.

Yep, you are helping us to make textcounter a better program by reporting
these problems :)

Thanks.

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

[Nms-cgi-devel] *counter

[Jonathan S. <gel...@ge...>]

I noticed this when I was looking at that other thing in textcounter but
the same thing goes for imagecounter as well - I really don't think that
we should be opening the counter file for reading, locking it, reading the
value, closing it, incrementing the value,opening it for
writing,locking,truncating and writing the new value back.  This really
isn't going to scale to well IMO :)  I have fixed textcounter.pl to do
what it should - that is open RW, lock exclusive, read, increment,
truncate, seek, write, close.  I haven't done so with imagecounter because
unless I am going completely crackers most of the program is missing, so
whoever gets round to remedying that can fix the locking on the counter
file :)

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

RE: Re[2]: [Nms-cgi-devel] Re: textcounter.pl bugs?!!

[Wizard <wi...@ne...>]

>     Another   strange  thing  you  might  notice is that the
>     content  header  is echoed in the script response, which
>     normally   shouldn't   happen.  This  again  is  Xitami
>     specific. :)
Try putting this in place of the "print header();" line of your script, and
let me know if it still prints out the header:

print "Content-type: text/html\n\n";
   OR
print "Content-type: text/plain\n\n";

depending on which you want.
Grant M.
P.S.> The reason that I ask, is that I've may have had some problems with
this before that I was unable to track to anything else.

Re[2]: [Nms-cgi-devel] Re: textcounter.pl bugs?!!

[Suresh S. <sur...@ya...>]

On Mon, 11 Feb 2001, Jonathan Stowe wrote:
JS>  I'm with Dave.
JS>  First thing to bear in mind that SSI  is  only a 'de facto'
JS>  standard really JS> driven by the  first implementations which were the NCSA httpd
JS>  and later
JS>  Apache,   most  other  HTTP  servers follow these
JS>  implementations but clearly
============================================================
Hi Jonathan,
   I  tested  the  script with Xitami as well as Apache, the
   $ENV{DOCUMENT_URI}  problem I mentioned only appears with
   Xitami.

   Anyway,  to  answer  you  question,Yes, I am using "exec cgi"
   command to call the script.

   As,  for  the script you asked me to run as a cgi, well I
   already  ran  a  script on Xitami that prints out all the
   environment variables. Here's the script:-
==================================
#!c:/perl/bin/perl.exe

use CGI qw(:standard);

print header();
print'<br>';

foreach $env (sort (keys %ENV) )
{
   print "$env => $ENV{$env}<br>";
}   
===================================

   And here is the output when it's run as a cgi program:-
==============================================
Content-Type: text/html; charset=ISO-8859-1
BLASTER : A220 I5 D1 H1 P330 T6
CGI_ROOT : C:/XITAMI/cgi-bin
CGI_STDERR : cgierr.log
CGI_STDOUT : C:\WINDOWS\TEMP\pipe0007.cgo
CGI_URL : /cgi-bin
CMDLINE : WIN
COMSPEC : C:\WINDOWS\COMMAND.COM
CONTENT_LENGTH : 0
CONTENT_TYPE : 
DOCUMENT_ROOT : C:/XITAMI/webpages
GATEWAY_INTERFACE : CGI/1.1
HTTP_ACCEPT : */*
HTTP_ACCEPT_ENCODING : gzip, deflate
HTTP_ACCEPT_LANGUAGE : en-us
HTTP_CONNECTION : Keep-Alive
HTTP_CONTENT_LENGTH : 0
HTTP_HOST : localhost
HTTP_USER_AGENT : Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
PATH : C:\PERL\BIN;C:\PERL\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND
PATH_INFO : /index.shtm
PATH_TRANSLATED : C:/XITAMI/webpages/index.shtm
PROMPT : $p$g
QUERY_METHOD : GET
REMOTE_ADDR : 127.0.0.1
REMOTE_HOST : 127.0.0.1
REMOTE_USER : -
REQUEST_METHOD : GET
SCRIPT_NAME : /index.shtm
SCRIPT_PATH : 
SERVER_NAME : localhost
SERVER_PORT : 0
SERVER_PROTOCOL : HTTP/1.1
SERVER_SECURITY : -
SERVER_SOFTWARE : Xitami
SERVER_URL : http://localhost/
SERVER_VERSION : 2.5b4
TEMP : C:\WINDOWS\TEMP
TMP : C:\WINDOWS\TEMP
WINBOOTDIR : C:\WINDOWS
WINDIR : C:\WINDOWS
==============================================

    Another  strange  thing  I noticed with Xitami is when i
    used  <!--#echo  var="DOCUMENT_URI"-->  to print out the
    variable,  I  get  the  desired output for DOCUMENT_URI,
    somehow  as you can see from the script output above, it
    just doesn't get passed on to the cgi program.

    Another   strange  thing  you  might  notice is that the
    content  header  is echoed in the script response, which
    normally   shouldn't   happen.  This  again  is  Xitami
    specific. :)

    Hope all of this helps in some way or another.

-- 
Best regards,
Suresh.
                            mailto:sur...@ya...


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [Nms-cgi-devel] Re: textcounter.pl bugs?!!

[Jonathan S. <gel...@ge...>]

On Sun, 10 Feb 2002, Dave Cross wrote:

> On Fri, Feb 08, 2002 at 11:56:40PM +0530, Suresh Sundriyal (sur...@ya...) wrote:
> >    1)   On   line   119   of   textcounter script you have a
> >    "print  header;"  .  Since  a  textcounter script will be
> >    called  with  SSI  only  the output of the script will be
> >    included in the HTML that calls the script. So apart from
> >    the count you will also get an etra line stating "Content-
> >    Type: text/html; charset=ISO-8859-1".
>
> My understanding is that an SSI script _should_ return a Content-type
> header. I assume you're using <!--#exec cgi="..."-->.
>

I'm with Dave.

First thing to bear in mind that SSI is only a 'de facto' standard really
driven by the first implementations which were the NCSA httpd and later
Apache, most other HTTP servers follow these implementations but clearly
there is no real 'standard' apart from that described in:

    http://httpd.apache.org/docs/mod/mod_include.html

Now there is a clear distinction made here between 'exec cgi' and 'exec
cmd' - obviously as CGI program must (as per the specification for that
interface) return a set of headers and not just the plain content, whereas
something executed via 'exec cmd' could quite easily be a shell command
such as 'ls' which will not emit any CGI headers.

If however your web server is transmitting the headers for an 'exec cgi'
that is non-standard and counter intuitive IMO.  I see that we have two
options (not necessarily mutually exclusive) here - we can have a
configuration option (say $emit_headers) that can control the output of
the headers, thus allowing people to choose which of the 'cgi' or 'cmd'
behaviours they would like or we can build in some logic so that if the
program is being run be certain specified servers it will not be
outputting the headers anyway - of course to achieve this we will need to
discover the $ENV{SERVER_SOFTWARE} (or whatever) of all of the servers
that behave like this.

So in the first instance could you confirm to us that you are using 'exec
cgi' and if so could you send us the output of:

use CGI qw(:standard);

print header('text/plain');

foreach $env ( keys %ENV )
{
   print "$env => $ENV{$env}\n";
}


When run as a CGI program.

Thanks

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

[Nms-cgi-devel] Re: textcounter.pl bugs?!!

[Dave C. <da...@da...>]

On Fri, Feb 08, 2002 at 11:56:40PM +0530, Suresh Sundriyal (sur...@ya...) wrote:
> Hi,
>    I  was  testing  your  textcounter script & I found a few
>    bugs,  don't  know  whether  these  bugs  were  platform
>    specific or not. well, here goes anyway:-

Thanks for the mail. I've copied this reply to the nms developers' list
so someone will take a closer look at your suggestions.
 
>    1)   On   line   119   of   textcounter script you have a
>    "print  header;"  .  Since  a  textcounter script will be
>    called  with  SSI  only  the output of the script will be
>    included in the HTML that calls the script. So apart from
>    the count you will also get an etra line stating "Content-
>    Type: text/html; charset=ISO-8859-1".

My understanding is that an SSI script _should_ return a Content-type
header. I assume you're using <!--#exec cgi="..."-->.

It may be that Xitami is giving non-standard behavior. We'll look into it.
 
>    2)I  believe $ENV{DOCUMENT_URI} is not implemented by all
>    the  servers.  I  tried  the script on Xitami & it didn't
>    support  it.  I  also  checked  out  Savant's environment
>    variables  &  it  wasn't  there  as  well.  Is  there any
>    standard variable that could be used to get the filename?

This is another case where it's probably Xitami that's doing the wrong thing.
Again, we'll look into it.

>    3)This  one  isn't  exactly  a bug but causes DZsoft perl
>    editor  to  act a bit crazy, here it goes anyway, on line
>    91  $sub  is  used,  DZsoft assumes it to be the reserved
>    word SUB & starts acting weird.

I suggest you pass that back to the developers at DZsoft as a bug in
their editor :)
 
>    4)  This  one is more of a question, is caller() function
>    supported on windows98?

Yes it is.
 
>    And  sice  you  guys  are  trying to make secure scripts,
>    shouldn't   you   guys   disable   Uploads   by   using
>    "$CGI::DISABLE_UPLOADS = 1" or something?

That's certainly something we should think about.

Thanks for your comments.

Dave...

-- 

  "Don't you boys know any _nice_ songs?"

Re: [Nms-cgi-devel] nms advocacy

[Dave C. <da...@da...>]

On Thu, Feb 07, 2002 at 04:28:08PM -0500, Joseph F. Ryan (rya...@os...) wrote:
> I also mentioned it in an upcoming article for A List Apart (upcoming 
> meaning tomorrow).  You can take an early peak at it here:
> 
> http://www.alistapart.com/stories/perl/

That looks great. I hope you don't mind if I make a couple of comments on
your code :)

* Personally, I'd have broken the "find" sub out into a real subroutine. The
  idea of anonymous subs might be a little weird for your target audience.

* Just doing "undef $/" like that is bad practice. You should never change
  one of Perl's special variables without "local"ising the change. In this
  case it doesn't matter, but people may cut and past your oode into other
  scripts. In this example, the perfect place to localise the change is
  in the "find" sub. I'd do "local $/ = undef" (or even just "local $/"
  which does the same thing.

* You call "stat" in void context. Doesn't that give you an error? In any
  case, it's not achieving anything useful.

* Do the links in the results list work? Looks to me like you're using
  file paths, not URLs. This may work in your specific circumstances, but
  it won't in the general case.

Hope this is useful,

Dave...

-- 

  .sig missing...

Re: [Nms-cgi-devel] nms advocacy

[Joseph F. R. <rya...@os...>]

I also mentioned it in an upcoming article for A List Apart (upcoming 
meaning tomorrow).  You can take an early peak at it here:

http://www.alistapart.com/stories/perl/

At 04:21 PM 2/7/2002 +0000, you wrote:
>Nice to see someone else mentioning nms at
>
><http://www.gorski.net/scripts/lists/www-scripts/2002/02/msg00005.html>
>
>but some of the replies are a bit disappointing.
>
>If anyone wants to join in the discussion, please join the list at
>
><http://www.gradwell.com/help/www-scripts/>
>
>Dave...
>
>--
>
>   Drugs are just bad m'kay
>
>
>_______________________________________________
>Nms-cgi-devel mailing list
>Nms...@li...
>https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel

[Nms-cgi-devel] nms advocacy

[Dave C. <da...@da...>]

Nice to see someone else mentioning nms at

<http://www.gorski.net/scripts/lists/www-scripts/2002/02/msg00005.html>

but some of the replies are a bit disappointing.

If anyone wants to join in the discussion, please join the list at

<http://www.gradwell.com/help/www-scripts/>

Dave...

-- 

  Drugs are just bad m'kay

[Nms-cgi-devel] Re: [Nms-cgi-commits] CVS Commit

[Joseph F. R. <rya...@os...>]

I added some stuff to search.pl, all of it guarded by an $emulate_matts_code.
First off, I added sorted results, sorted by hits. Next, I added a config 
variable that could let the user filter out 1 hit searches (the number is 
set by the user, the default limit is 1). Finally, I moved the html output 
functions to the end as they are the most likely candidates that a user 
will want to mess with.

At 08:24 PM 2/4/2002 -0800, you wrote:
 >uid=68187(jfryan) gid=100(users) groups=100(users),40625(nms-cgi)
 >search search.pl,1.19,1.20
 >Mon Feb 4 20:24:38 PST 2002
 >Update of /cvsroot/nms-cgi/search
 >In directory usw-pr-cvs1:/tmp/cvs-serv23763
 >Modified Files:
 >search.pl
 >Log Message:
 >Added $hit_threshhold config var and also moved output functions to end

_______________________________________________
Nms-cgi-commits mailing list
Nms...@li...
https://lists.sourceforge.net/lists/listinfo/nms-cgi-commits

[Nms-cgi-devel] Summary of last checkins

[Olivier D. <dr...@sh...>]

This is just a summary report of the last checkins I've done.

These are for wwwboard:
* Complete re-write of the README.
* Partial re-write of the ADMIN_README. This includes standard stuff
  like license, etc. as well as configuration and installation. I've
  left usage since I don't know how it behaves and what it does.
* added headers to both wwwboard.pl and wwwadmin.pl

If you wish to review/modify, especially for typos, please do. 
-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

[Nms-cgi-devel] CVS help

[Olivier D. <dr...@sh...>]

Hi all,

I need a clarification or help on CVS' behavior.

1. Is it possible to commit an entire directory? If so how? My directory
   commits seem to stop after the first file found different.
2. I keep getting this error whenever I commit and I would like to know
   if there is something bad about it:

   cvs [server aborted]: can't chdir(/home/users/d/dr/dragonoe): No such file or
   directory
   cvs commit: saving log message in /tmp/cvseV7KmI

   Checkins still seem to go through fine as the update returns the
   right thing.

Thank you,
-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

Re: [Nms-cgi-devel] wwwboard.pl security + headers

[Jonathan S. <gel...@ge...>]

On Sun, 3 Feb 2002, Olivier Dragon wrote:
>
> Which brings another one. I've noticed, in the scripts I've gone through
> so far, that $emulate_matts_code is set to 1 by default. Don't we want
> to educate users to better security and set this off by default? I mean
> what's the point of advertising security if we by default emulate code
> or features that are insecure?
>

Because one of the prime aims is for people to be replace their existing
programs and the purpose of $emulate_matts_code is to toggle possibly
incompatible features in our code it was felt that it should be on by
default.

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

Re: [Nms-cgi-devel] wwwboard.pl security + headers

[Joseph F. R. <rya...@os...>]

Because the goal of the project was to create drop-in replacements for 
people using Matt Wright's Scripts. Therefore, we need to emulate his code 
by default; extra features are up to the user.

At 07:10 PM 2/3/2002 -0500, Olivier Dragon wrote:
>First, I'd like to let everyone know that I'm working on getting
>headings in all the scripts. There didn't seem to be any objections to
>the last proposed header scheme so I've taken upon its implementation.
>
>Second, I've noticed a possible security issue wwwboard.pl:
>-> $allow_html should be set to 0 by default (IMHO). It's currently set
>to 1.
>
>Which brings another one. I've noticed, in the scripts I've gone through
>so far, that $emulate_matts_code is set to 1 by default. Don't we want
>to educate users to better security and set this off by default? I mean
>what's the point of advertising security if we by default emulate code
>or features that are insecure?
>
>-Oli
>
>--
>+----------------------------------------------+
>| Olivier Dragon        dr...@sh... |
>| Software Engineering II, McMaster University |
>+----------------------------------------------+
>
>_______________________________________________
>Nms-cgi-devel mailing list
>Nms...@li...
>https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel

[Nms-cgi-devel] wwwboard.pl security + headers

[Olivier D. <dr...@sh...>]

First, I'd like to let everyone know that I'm working on getting
headings in all the scripts. There didn't seem to be any objections to
the last proposed header scheme so I've taken upon its implementation.

Second, I've noticed a possible security issue wwwboard.pl:
-> $allow_html should be set to 0 by default (IMHO). It's currently set
to 1.

Which brings another one. I've noticed, in the scripts I've gone through
so far, that $emulate_matts_code is set to 1 by default. Don't we want
to educate users to better security and set this off by default? I mean
what's the point of advertising security if we by default emulate code
or features that are insecure?

-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

[Nms-cgi-devel] wwwboard documentation and MWS

[Olivier D. <dr...@sh...>]

Hi,

Just to let everyone know, wwwboard's documentation is still from MWS
and should be changed asap. Especially the ADMIN_README which still
contains the MWS header, and the README which contains a lot of
information about v2.0 and v2.0 ALPHA 2 while we are still at v1.xx

-Olivier

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

[Nms-cgi-devel] Coding style

[Olivier D. <dr...@sh...>]

Hi Everyone,

Just like to know if there is any concensus on indentation; tabs, no
tabs, how many spaces of indent, etc...

I usually code with tabs but I have nothing against putting it through
expand before committing.

Thanks,
-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

[Nms-cgi-devel] Changelog again

[Jonathan S. <gel...@ge...>]

This was mentioned on the advocacy list :

   http://www.red-bean.com/cvs2cl/

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

[Nms-cgi-devel] Re: [Nms-cgi-commits] CVS Commit

[Jonathan S. <gel...@ge...>]

On Sat, 2 Feb 2002, Nick Cleaton wrote:

>
> uid=68644(nickjc) gid=100(users) groups=100(users),40625(nms-cgi)
> search search.pl,1.15,1.16
> Sat Feb  2 05:57:54 PST 2002
> Update of /cvsroot/nms-cgi/search
> In directory usw-pr-cvs1:/tmp/cvs-serv10923
>
> Modified Files:
>       search.pl
> Log Message:
> match the empty string as a valid directory name
>


But it's not a valid directory name is it ?  Or rather I can't work out
how to make one ...The worrying directories are things like '. ' and so
forth however ;-}


/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

[Nms-cgi-devel] Re: [Nms-cgi-support] Textcounter

[Jonathan S. <gel...@ge...>]

On Fri, 1 Feb 2002, Rob Anna wrote:
>
> I've installed the textcount.pl and I keep getting an error :Can't open
> count file: Permission denied." Permissions are wide open for the data
> folder. A count file hasn't been created for this .pl yet.
> Any idea why I'm getting this error?
>

Could you try uploading an empty file to your data directory and try that
out ?  Also could you show us the top half of your configuration section ?

Thanks

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

Re: [Nms-cgi-devel] CVS logging and scripts headers

[Olivier D. <dr...@sh...>]

On Sat, Feb 02, 2002 at 10:13:12AM +0000, Jonathan Stowe wrote:
> Now this possibly at variance with the other aims of the project, so I
> would suggest that we keep the Log entries in the file and have them
> removed to a Changes file when a release - the average punters shouldn't
> be using the CVS versions as they are probably broken and almost certainly
> incomplete ...

This sounds like a reasonable and convenient idea.

So we leave the scripts the way they are, change the headers (after the
log) and whenever we make a release we take out the log and put it in a
seperate file so we end up with a clean, easy to configure script AND
developers know what's going on.

Good suggestion. I'm for it.

-Oli


-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

Re: [Nms-cgi-devel] Simple Search problems

[Nick C. <ni...@cl...>]

On Fri, Feb 01, 2002 at 06:38:53PM -0500, Joseph F. Ryan wrote:
> >
> >If detaint_dirname is killing the script it should be telling you
> >the name of the directory it doesn't like.
> 
> It was returning an empty string...

That's strange, File::Find shouldn't be trying to chdir to the
empty string.  I've made the detatint pattern match the empty
string - see if that helps.

> also, should the script die if it hits a bad filename, or just skip it?

It should probably skip it - but it's too late once File::Find
tries to chdir into it.  Maybe we could add code to do_search
that sets $File::Find::Prune for directories that would fail the
taint check ?

--
Nick