I have done some research on this issue. The "correct" behavior seems
to be to match what Windows would do in cmd.exe. That would provide
the users with the least surprise.
Michael Kaplan's guidance[1] on file names seems to also describe how
Windows handles names of environment va
I am not sure what the right strategy is ... Perl 5 seems to work
mainly because they use the ANSI interfaces to get environment
variables ... which means you can't get the value of $ENV{iş}.
I opened this issue because I am going to think about it and thought
there should be somethi
On Mon, 13 Feb 2017 14:38:03 -0800, na...@cpan.org wrote:
> $ echo %windir%
> C:\WINDOWS
>
> $ echo %WINDIR%
> C:\WINDOWS
>
> $ c:\opt\perl6-mingw\bin\perl6 -e "say %*ENV"
> (Any)
>
> $ c:\opt\perl6-mingw\bin\perl6 -e "say %*ENV"
> C:\WINDOWS
>
> $ c:\opt\perl6-mingw\bin\perl6 -v
> This is Raku
On Mon, 13 Feb 2017 14:38:03 -0800, na...@cpan.org wrote:
> $ echo %windir%
> C:\WINDOWS
>
> $ echo %WINDIR%
> C:\WINDOWS
>
> $ c:\opt\perl6-mingw\bin\perl6 -e "say %*ENV"
> (Any)
>
> $ c:\opt\perl6-mingw\bin\perl6 -e "say %*ENV"
> C:\WINDOWS
>
> $ c:\opt\perl6-mingw\bin\perl6 -v
> This is Raku
# New Ticket Created by A. Sinan Unur
# Please include the string: [perl #130776]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130776 >
$ echo %windir%
C:\WINDOWS
$ echo %WINDIR%
C:\WINDOWS
$ c:\opt\perl6-mingw\bin\perl6 -
On Sunday 17 June 2007 11:21:22 Ron Blaschke wrote:
> Attached patch should take care of tickets #37301 and #40972.
Thanks, applied as r19068.
-- c
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #43235]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43235 >
Attached patch should take care of tickets #37301 and #40972.
Windows XP - Visual C++ 8
d which can be seen by callers.
If they both have "env"-ish stuff in the name, let's use the same
name for both. If they are far enough apart that they should be
distinct, call them something different.
But to have %*ENV be called "environment variables" while "env
On Sat, Apr 29, 2006 at 07:50:02AM -0700, Randal L. Schwartz wrote:
> Please, let us agree to use the traditional name of "environment variables" in
> the docs, and not re-introduce its bastardized cousin, which hurts my ears.
> Thanks.
I think they are different things. An &q
Please, let us agree to use the traditional name of "environment variables" in
the docs, and not re-introduce its bastardized cousin, which hurts my ears.
Thanks.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
http://www.stonehenge.com/merlyn/&
hat way,
it would be very easy to turn on/off logging to a file for all tests at
once.
Is there a way to specify environment variables that should be set
during the 'make test'?
-kolibrie
On Tue, Feb 22, 2005 at 04:17:53PM +0100, Rafael Garcia-Suarez wrote:
> Here's a patch to add this. It's heavily cargo-culted, I need to read
> some docs about haskell some day. As I wasn't able to get FiniteMaps to
> work I implemented my own kludgy function to flatten pairs for the hash.
> Also I
Autrijus Tang wrote:
> jn Tue, Feb 22, 2005 at 10:54:26AM -, Rafael Garcia-Suarez wrote:
> > I had this silly idea, to try to add %ENV to pugs. That would be an
> > interesting exercise. So I can write CGI scripts. Maybe. But I don't
> > know what's the Right way to do it in Perl 6. Any hints ?
On Tue, Feb 22, 2005 at 06:51:24AM -0600, Patrick R. Michaud wrote:
> This might initially work for read-only access/testing, but in
> the long run I suspect that %*ENV will be tied directly to the
> C putenv/getenv calls or their Parrot/other equivalents.
> Assigning to %*ENV should change the e
On Tue, Feb 22, 2005 at 08:35:49PM +0800, Autrijus Tang wrote:
> jn Tue, Feb 22, 2005 at 10:54:26AM -, Rafael Garcia-Suarez wrote:
> > I had this silly idea, to try to add %ENV to pugs. That would be an
> > interesting exercise. So I can write CGI scripts. Maybe. But I don't
> > know what's the
jn Tue, Feb 22, 2005 at 10:54:26AM -, Rafael Garcia-Suarez wrote:
> I had this silly idea, to try to add %ENV to pugs. That would be an
> interesting exercise. So I can write CGI scripts. Maybe. But I don't
> know what's the Right way to do it in Perl 6. Any hints ?
In Perl6 I think you do it
I had this silly idea, to try to add %ENV to pugs. That would be an
interesting exercise. So I can write CGI scripts. Maybe. But I don't
know what's the Right way to do it in Perl 6. Any hints ?
--
#!/usr/bin/pugs
say "Just another Pugs hacker";
On Wed, Nov 19, 2003 at 07:17:46AM -0800, Randal L. Schwartz wrote:
> Michael> For that reason I'd agree with Curtis and say that
> Michael> everything is always run by default and users can then elect
> Michael> what to turn off. PERL_SKIP_LONG_TESTS seems like a clear
> Michael> name.
>
> As
> "Michael" == Michael G Schwern <[EMAIL PROTECTED]> writes:
Michael> Disabling tests for subjective reasons (they take "too long",
Michael> they don't test critical functionality, etc...) is a slippery
Michael> slope.
But there are clearly tests that are "tip of the iceberg" as a safety
chec
On Wed, Nov 19, 2003 at 01:45:31PM +1100, Andrew Savige wrote:
> I think the two environment variables can happily coexist as
> shown in the table below:
>
> PERL_SMOKE PERL_SKIP_LONG_TESTS
> Naive User0 0
> Contrary
Michael G Schwern wrote:
Disabling tests for subjective reasons (they take "too long", they don't
test critical functionality, etc...) is a slippery slope.
I've seen this approach used successfully in a commercial setting. The
key is to make sure that the long tests do get run by someone.
If u
N author how he
wants to treat the naive user (i.e. the user who installs his
module without explicitly setting any environment variable).
That is, the CPAN author can choose whether he wants to use
PERL_SMOKE or PERL_SKIP_LONG_TESTS (based on his good taste
and sound judgement, after all it is his m
On Wed, Nov 19, 2003 at 09:30:19AM +1100, Andrew Savige wrote:
> > Also, I would recommend something like PERL_SKIP_LONG_TESTS. By
> > default, all tests should be run to prevent the user accidentally
> > forget to run some tests.
>
> If some tests take hours to run, running them by default will
Ovid wrote:
> --- Kate L Pugh wrote:
> > This was discussed on this list back in June. I'm wanting to
> > implement it now and am wondering if Andrew's suggestion (below) has
> > been taken up by anyone. Is PERL_TEST_LONG what people here
> > generally
> > expect to be the right environment varia
--- Kate L Pugh <[EMAIL PROTECTED]> wrote:
> This was discussed on this list back in June. I'm wanting to
> implement it now and am wondering if Andrew's suggestion (below) has
> been taken up by anyone. Is PERL_TEST_LONG what people here
> generally
> expect to be the right environment variable
This was discussed on this list back in June. I'm wanting to
implement it now and am wondering if Andrew's suggestion (below) has
been taken up by anyone. Is PERL_TEST_LONG what people here generally
expect to be the right environment variable to set to enable
long-running tests?
(I know I could
I tried this one-line programme for example:
my %e = %ENV;
and got this (parrot-0.0.13/perl are built under mandrake linux):
Global '_HV_ENV' not found
Error: '/parrot-0.0.13/parrot -r env.imc ' failed with exit code 1
Stopped at /parrot-0.0.13/languages/perl6/perl6 line 339
main::mydie(256,'/p
[EMAIL PROTECTED] (Andrew Shitov) writes:
> Is it possible to get environment variables from perl6 programme? It
> failes when I try to use perl5 hash %ENV. Thanks.
Are you sure you're using the Perl 6 hash syntax? (%ENV{FOO} rather than Perl
5-style $ENV{FOO})
What version of Per
Is it possible to get environment variables from perl6 programme? It
failes when I try to use perl5 hash %ENV. Thanks.
Randal L. Schwartz wrote:
> All I'm asking for in my quest is to keep the "install health check"
> tests down to a minute or two. Remember that CPAN.pm insists that
> "make test" works before I can install.
I agree. Modules should commonly have long-running exhaustive tests
and/or stress tests. T
> "Adrian" == Adrian Howard <[EMAIL PROTECTED]> writes:
Adrian> I don't see it as a real problem. If I've written a test I want it
Adrian> run. Otherwise I wouldn't have written it. Not running tests is pretty
Adrian> much the ultimate sin as far as I am concerned - but I'm odd that way
Adrian
Randal L. Schwartz wrote:
> No, it doesn't need a standard name. The default should be the
> "install tests" without any special envar. The developer can select
> their own set of envars to control various *longer* tests.
While a standard name is not required, having one would allow
automated CP
> "Andrew" == Andrew Savige <[EMAIL PROTECTED]> writes:
Andrew> Randal L. Schwartz wrote:
>> All I'm asking for in my quest is to keep the "install health check"
>> tests down to a minute or two. Remember that CPAN.pm insists that
>> "make test" works before I can install.
Andrew> I agree. M
On Sunday, June 1, 2003, at 08:43 am, Andrew Savige wrote:
Merlyn's use perl journal of April 29, 2003:
http://use.perl.org/~merlyn/journal/
suggests using environment variables to spare the installer of
CPAN modules a long wait while running 'make test'. One reply
noted that D
Merlyn's use perl journal of April 29, 2003:
http://use.perl.org/~merlyn/journal/
suggests using environment variables to spare the installer of
CPAN modules a long wait while running 'make test'. One reply
noted that DBD, HTML::Mason and other modules already do this.
Is there a
35 matches
Mail list logo
