You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2003/06/14 10:16:17 UTC
Re: cvs commit: httpd-apreq-2/glue/perl/t/response/TestApReq inherit.pm
request.pm
joes@apache.org wrote:
> joes 2003/06/13 02:46:52
>
> Modified: glue/perl/t TEST.PL
> glue/perl/t/apreq big_input.t cookie.t inherit.t request.t
> glue/perl/t/response/TestApReq inherit.pm request.pm
> Index: request.t
> ===================================================================
> RCS file: /home/cvs/httpd-apreq-2/glue/perl/t/apreq/request.t,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- request.t 9 Jun 2003 06:30:04 -0000 1.1
> +++ request.t 13 Jun 2003 09:46:52 -0000 1.2
> @@ -1,3 +1,4 @@
> +#!/usr/bin/perl
May I ask, why this path is hardcoded? This is certainly a bite for problems,
when people have several perl installs and they build with non-/usr/bin/perl
but get to test with it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-apreq-2/glue/perl/t/response/TestApReq inherit.pm
request.pm
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>Not to you. But users may try to run these as is, without using
>>$^X. I've pointed it out for this reason, just trying to minimize
>>support pains.
>
>
> If the shebang line is omitted, how will the users run the tests?
> The files in question don't even have an executable bit set.
That's *exactly* my point. They shouldn't do that. If they have more than one
perl on their system, and they have built apreq with non-/usr/bin/perl and
they run the tests with it, all kind weird errors will happen at best.
Users should either run 'make test' or 't/TEST' and pass the test files as
arguments if they want to run specific tests only. This is explained here:
http://perl.apache.org/docs/general/testing/testing.html#Individual_Testing
> I appreciate the support concern, and since I seem to be alone
> in my position, I'll concede that the shebang line should be
> taken out of the tests, but AFAICT there is no technical advantage
> on either side of this debate.
Technical, no. Confusion-wise, yes. The less guns you give to your users, the
less the chance that they will shoot themselves ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-apreq-2/glue/perl/t/response/TestApReq inherit.pm request.pm
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Not to you. But users may try to run these as is, without using
> $^X. I've pointed it out for this reason, just trying to minimize
> support pains.
If the shebang line is omitted, how will the users run the tests?
The files in question don't even have an executable bit set.
I appreciate the support concern, and since I seem to be alone
in my position, I'll concede that the shebang line should be
taken out of the tests, but AFAICT there is no technical advantage
on either side of this debate.
--
Joe Schaefer
Re: cvs commit: httpd-apreq-2/glue/perl/t/response/TestApReq inherit.pm
request.pm
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>joes@apache.org wrote:
>>
>>>joes 2003/06/13 02:46:52
>>> Modified: glue/perl/t TEST.PL
>>> glue/perl/t/apreq big_input.t cookie.t inherit.t request.t
>>> glue/perl/t/response/TestApReq inherit.pm request.pm
>>
>>> Index: request.t
>>> ===================================================================
>>> RCS file: /home/cvs/httpd-apreq-2/glue/perl/t/apreq/request.t,v
>>> retrieving revision 1.1
>>> retrieving revision 1.2
>>> diff -u -r1.1 -r1.2
>>> --- request.t 9 Jun 2003 06:30:04 -0000 1.1
>>> +++ request.t 13 Jun 2003 09:46:52 -0000 1.2
>>> @@ -1,3 +1,4 @@
>>> +#!/usr/bin/perl
>>
>>May I ask, why this path is hardcoded?
>
>
> It serves no practical purpose other than to inform emacs of the
> file type (as well as being conventional for perl scripts). The
> tests (.t files) aren't ever directly executed by a shell, so the
> actual path isn't important.
You don't need to change the file for that, I have this rule in .xemacs/init.el:
(setq auto-mode-alist
(append '(("\\.\\([pP][Llm]\\|al\\|cgi\\|pod\\|t\\)$" . perl-mode))
auto-mode-alist ))
(setq interpreter-mode-alist (append interpreter-mode-alist
'(("miniperl" . perl-mode))))
oh, I see David has already posted a similar one.
>>This is certainly a bite for problems, when people have several perl
>>installs and they build with non-/usr/bin/perl but get to test with
>>it.
>
>
> Nah, it won't cause any problems; the tests are always run with
> $^X, not #!.
Not to you. But users may try to run these as is, without using $^X. I've
pointed it out for this reason, just trying to minimize support pains.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-apreq-2/glue/perl/t/response/TestApReq inherit.pm request.pm
Posted by David Wheeler <da...@wheeler.net>.
On Saturday, June 14, 2003, at 01:44 AM, Joe Schaefer wrote:
> It serves no practical purpose other than to inform emacs of the
> file type (as well as being conventional for perl scripts). The
> tests (.t files) aren't ever directly executed by a shell, so the
> actual path isn't important.
I personally don't like to put editor-specific stuff into files. I use
this in my ~/.emacs, instead:
(setq auto-mode-alist
(append
'(("\\.\\([pP]\\([Llm]\\|erl\\)\\|al\\|pod\\|t\\)\\'" .
cperl-mode))
auto-mode-alist))
Gotta love lisp regexen, though, eh? ;-)
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: cvs commit: httpd-apreq-2/glue/perl/t/response/TestApReq inherit.pm request.pm
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> joes@apache.org wrote:
> > joes 2003/06/13 02:46:52
> > Modified: glue/perl/t TEST.PL
> > glue/perl/t/apreq big_input.t cookie.t inherit.t request.t
> > glue/perl/t/response/TestApReq inherit.pm request.pm
>
> > Index: request.t
> > ===================================================================
> > RCS file: /home/cvs/httpd-apreq-2/glue/perl/t/apreq/request.t,v
> > retrieving revision 1.1
> > retrieving revision 1.2
> > diff -u -r1.1 -r1.2
> > --- request.t 9 Jun 2003 06:30:04 -0000 1.1
> > +++ request.t 13 Jun 2003 09:46:52 -0000 1.2
> > @@ -1,3 +1,4 @@
> > +#!/usr/bin/perl
>
> May I ask, why this path is hardcoded?
It serves no practical purpose other than to inform emacs of the
file type (as well as being conventional for perl scripts). The
tests (.t files) aren't ever directly executed by a shell, so the
actual path isn't important.
> This is certainly a bite for problems, when people have several perl
> installs and they build with non-/usr/bin/perl but get to test with
> it.
Nah, it won't cause any problems; the tests are always run with
$^X, not #!.
--
Joe Schaefer