Re: [perl #130776] Environment variables are case insensitive on Windows
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 variables: > For the uppercasing operation, you can use CharUpper, CharUpperBuff, or > LCMapString > with the LCMAP_UPPERCASE flag (and *without* the LCMAP_LINGUISTIC_CASING > flag!). > (emphasis in the original) To test whether the same applied to names of environment variables as well, I set the user locale to Turkish, and verified that iş was mapped to IŞ and not İŞ on a computer where the OS code page was not Turkish. The most straightforward function to use is thus CharUpperBuffW[2]. [1]: http://archives.miloush.net/michkap/archive/2005/10/17/481600.html [2]: https://msdn.microsoft.com/en-us/library/windows/desktop/ms647475(v=vs.85).aspx
Re: [perl #130776] Environment variables are case insensitive on Windows
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 something to reference.
The simple solution seems to work, but I do believe case needs to be preserved.
Anyway, this is a low priority issue and I am not even certain any
part of the Perl 6 machinery needs to be involved. Maybe it's
sufficient for client programs to case fold when looking for keys.
-- Sinan
[perl #130776] Environment variables are case insensitive on Windows
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 Rakudo version 2017.01 built on MoarVM version 2017.01
> implementing Perl 6.c.
>
> Both %*ENV and %*ENV (as well as, e.g., %*ENV
> etc) should return 'C:\WINDOWS'.
>
> -- Sinan
What would be a good approach? Store them in whatever case they come in, but
apply fc() when looking up keys?
If I dump all the vars with `set` I see all-uppercase, mixed-case, and
all-lowercase vars. Perl 5 seems to uppercase them all (when I dump %ENV with
Data::Dumper). And that naturally leads to what to do with stuff like 'ß',
which Perl 5 dumps out to me as `'▀' => '42',`
---
I'm thinking of just sticking a subclass of Hash to %*ENV on Windows, something
along the lines of
$ perl6 -e 'my %h := class :: is Hash { method AT-KEY ($k) { nextwith $k.fc
}; method ASSIGN-KEY ($k, $v) { nextwith $k.fc, $v } }.new; %h = 42; dd
%h; dd %h'
{:foo(42)}
Int = 42
[perl #130776] Environment variables are case insensitive on Windows
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 Rakudo version 2017.01 built on MoarVM version 2017.01
> implementing Perl 6.c.
>
> Both %*ENV and %*ENV (as well as, e.g., %*ENV
> etc) should return 'C:\WINDOWS'.
>
> -- Sinan
What would be a good approach? Store them in whatever case they come in, but
apply fc() when looking up keys?
If I dump all the vars with `set` I see all-uppercase, mixed-case, and
all-lowercase vars. Perl 5 seems to uppercase them all (when I dump %ENV with
Data::Dumper). And that naturally leads to what to do with stuff like 'ß',
which Perl 5 dumps out to me as `'▀' => '42',`
---
I'm thinking of just sticking a subclass of Hash to %*ENV on Windows, something
along the lines of
$ perl6 -e 'my %h := class :: is Hash { method AT-KEY ($k) { nextwith $k.fc
}; method ASSIGN-KEY ($k, $v) { nextwith $k.fc, $v } }.new; %h = 42; dd
%h; dd %h'
{:foo(42)}
Int = 42
[perl #130776] Environment variables are case insensitive on Windows
# 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 -e "say %*ENV" (Any) $ c:\opt\perl6-mingw\bin\perl6 -e "say %*ENV" C:\WINDOWS $ c:\opt\perl6-mingw\bin\perl6 -v This is Rakudo version 2017.01 built on MoarVM version 2017.01 implementing Perl 6.c. Both %*ENV and %*ENV (as well as, e.g., %*ENV etc) should return 'C:\WINDOWS'. -- Sinan
[perl #43235] [PATCH][Win32] Fix Environment Variables Handling
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #43235]
# in the subject line of all future correspondence about this issue.
# URL: 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
$ runtests -v t\pmc\env.t
t\pmc\env..
1..12
ok 1 - all Envs are ident
ok 2 - getenv
ok 3 - setenv/getenv
ok 4 - envs are all the same
ok 5 - gone/delete
ok 6 - iterate
ok 7 - exists/delete
ok 8 - check whether interface is done
ok 9 - get_integer()
ok 10 - get_number()
ok 11 - getenv - null key
ok 12 - setenv/getenv - PMC key
ok
All tests successful.
Files=1, Tests=12, 1 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Windows XP - MinGW (GCC)
$ runtests -v t\pmc\env.t
t\pmc\env..
1..12
ok 1 - all Envs are ident
ok 2 - getenv
ok 3 - setenv/getenv
ok 4 - envs are all the same
ok 5 - gone/delete
ok 6 - iterate
ok 7 - exists/delete
ok 8 - check whether interface is done
ok 9 - get_integer()
ok 10 - get_number()
ok 11 - getenv - null key
ok 12 - setenv/getenv - PMC key
ok
All tests successful.
Files=1, Tests=12, 2 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Ron
Index: t/pmc/env.t
===
--- t/pmc/env.t (revision 19066)
+++ t/pmc/env.t (working copy)
@@ -92,11 +92,7 @@
ok 2
OUT
-SKIP:
-{
-skip 'iterator not available on win32' = 1
-if 'MSWin32' eq $^O;
-pasm_output_is( 'CODE', OUT, iterate );
+pasm_output_is( 'CODE', OUT, iterate );
new P0, .Env
set P0[PARROT_1], hello
set P0[PARROT_2], polly
@@ -121,10 +117,8 @@
CODE
ok
OUT
-}
SKIP: {
-
# This will not work on our unsetenv implementation
skip( no native unsetenv, 1 ) unless $PConfig{unsetenv};
pasm_output_is( 'CODE', OUT, exists/delete );
@@ -173,10 +167,7 @@
0
OUTPUT
-SKIP: {
-skip 'not changing environment on windows', 2 if $^O eq 'MSWin32';
-
-pir_output_is( 'CODE', 'OUTPUT', get_integer() );
+pir_output_is( 'CODE', 'OUTPUT', get_integer() );
.sub main
.local pmc env
.local int num_before, num_after, num_diff
@@ -197,7 +188,7 @@
3
OUTPUT
-pir_output_is( 'CODE', 'OUTPUT', get_number() );
+pir_output_is( 'CODE', 'OUTPUT', get_number() );
.sub main
.local pmc env
.local num num_before, num_after, num_diff
@@ -217,7 +208,6 @@
CODE
3.00
OUTPUT
-}
pasm_output_is( 'CODE', OUT, getenv - null key );
new P0, .Env
Index: config/gen/platform/win32/env.c
===
--- config/gen/platform/win32/env.c (revision 19066)
+++ config/gen/platform/win32/env.c (working copy)
@@ -1,14 +1,59 @@
/*
+ On Windows there are two ways to access the environment. Either through the
+ Windows environment block, using GetEnvironmentVariable,
+ SetEnvironmentVariable and GetEnvironmentStrings, or the C runtime using
+ _getenv, _putenv and _environ.
+
+ Changes through the C runtime are reflected in the environment block, but
+ changes in the environment block are NOT reflected in the C runtime!
+
+ To keep both in sync we always update environment variables through the C
+ runtime. Getting an environment variable can be done either way,
+ whichever is more convenient.
+*/
+
+/*
** Parrot_setenv()
*/
void
Parrot_setenv(const char *name, const char *value)
{
-SetEnvironmentVariable(name, value);
+assert(name != NULL);
+assert(value != NULL);
+
+{
+const int name_len = strlen(name );
+const int value_len = strlen(value);
+
+{
+char * const envstring = malloc(
+name_len /* name */
++ 1 /* '=' */
++ value_len /* value */
++ 1 /* string terminator */
+);
+if (envstring == NULL) {
+/* TODO: Shouldn't we tell anyone that we failed? */
+return;
+}
+
+/* Save a bit of time, by using the fact we already have the
+lengths, avoiding strcat */
+strcpy(envstring,name );
+strcpy(envstring + name_len, = );
+strcpy(envstring + name_len + 1, value);
+
+if (_putenv(envstring) == 0) {
+/* success */
+} else {
+/* TODO: Shouldn't we tell anyone that we failed? */
+}
+free(envstring);
+}
+}
}
-
char *
Parrot_getenv(const char *name, int *free_it)
{
@@ -25,10 +70,15 @@
return buffer;
}
+
void
Parrot_unsetenv(const char *name)
{
-SetEnvironmentVariable(name, NULL);
+/* You can remove a variable from the environment by specifying an empty
+ string -- in other words, by specifying only varname=.
+ -- _putenv, _wputenv (CRT) documentation
+*/
+Parrot_setenv(name, );
}
/*
Re: [perl #43235] [PATCH][Win32] Fix Environment Variables Handling
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
S02 - s/environmental variables/environment variables/g please
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 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: S02 - s/environmental variables/environment variables/g please
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 environment variable is something in %*ENV. An environmental variable is a variable which was declared with env $foo, and which can be seen by callers. I rather dislike this naming scheme, but can't think of a better one. -=- James Mastros
Re: S02 - s/environmental variables/environment variables/g please
james == james [EMAIL PROTECTED] writes: james I think they are different things. An environment variable is james something in %*ENV. An environmental variable is a variable which james was declared with env $foo, and 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 $foo be called environmental variables, you're cruisin' for a world of hurt, and I say this as someone who will have to document this and teach this to a group of newbies for every week of my upcoming life. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Makefile environment variables for testing
As I was thinking about how to turn on test file logging, I thought it
might be nice to set a flag in Makefile.PL that would, perhaps, set an
environment variable while tests are run. Then the default value of
$Test::log_file could be %ENV{'TEST_LOG_FILE'} instead of ''. That 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
Environment variables
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;
Re: Environment variables
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 by populating the %*ENV hash, when the script is first run. To add it, hack Main.hs line 102 to add a new SGlobal symbol of a VHash. If you already have a list of pairs x, it is as simple as: VHash $ MkHash (listToFM x) Now, to obtain the list of ENV, hack Posix.hs to add an import of System.Posix.Env, and you'll have a that list of pairs via the getEnvironment call: x - getEnvironment Find me on #perl6 if you're unsure how to approach this. :) Thanks, /Autrijus/ pgpgF80FtbGOg.pgp Description: PGP signature
Re: Environment variables
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 Right way to do it in Perl 6. Any hints ? In Perl6 I think you do it by populating the %*ENV hash, when the script is first run. 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 environment for any scripts invoked from Perl 6. (This also eliminates the runtime overhead of populating %*ENV when it's not going to be used by a particular script.) Pm
Re: Environment variables
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 environment for any scripts invoked from Perl 6. Right, I was just saying that to rgs on #perl6. :) (This also eliminates the runtime overhead of populating %*ENV when it's not going to be used by a particular script.) Yup. This may very well be our first example of an IType. Thanks, /Autrijus/ pgpbGJluDZhUO.pgp Description: PGP signature
Re: Environment variables
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 ?
In Perl6 I think you do it by populating the %*ENV hash, when the
script is first run. To add it, hack Main.hs line 102 to add a new
SGlobal symbol of a VHash. If you already have a list of pairs x,
it is as simple as:
VHash $ MkHash (listToFM x)
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 suspect that the type of the internal thingy in %*ENV might not
be right, so you may want to turn it in a VHash instead (I haven't found
any difference).
Comes with tests. Note that this %*ENV is not magical. It should be
sufficient to write simple http-GET CGI scripts, though.
Index: t/op/magic.t
===
--- t/op/magic.t(revision 0)
+++ t/op/magic.t(revision 0)
@@ -0,0 +1,13 @@
+# Tests for magic variables
+
+use v6;
+
+say 1..2;
+
+# Tests for %*ENV
+
+# it must not be empty at startup
+if (0 + %*ENV.keys 0) { say ok 1; } else { say not ok 1; }
+
+# PATH is usually defined. But this test is not portable
+if %*ENV{PATH} ne { say ok 2; } else { say not ok 2; }
Index: MANIFEST
===
--- MANIFEST(revision 170)
+++ MANIFEST(working copy)
@@ -71,6 +71,7 @@
t/op/hash.t
t/op/inc.t
t/op/join.t
+t/op/magic.t
t/op/pair.t
t/op/pop.t
t/op/push.t
Index: src/Main.hs
===
--- src/Main.hs (revision 170)
+++ src/Main.hs (working copy)
@@ -22,6 +22,7 @@
import Parser
import Help
import Pretty
+import Posix
main :: IO ()
main = do
@@ -92,14 +93,20 @@
runFile file = do
withArgs [file] main
+flattenPairs :: [(x,x)] - [x]
+flattenPairs [] = []
+flattenPairs ((a,b):q) = [a,b] ++ flattenPairs q
+
runProgramWith :: (Env - Env) - (Val - IO ()) - VStr - [VStr] - String
- IO ()
runProgramWith fenv f name args prog = do
+environ - getEnvironment
env - emptyEnv
[ Symbol SGlobal @*ARGS (Val $ VList $ map VStr args)
, Symbol SGlobal @*INC (Val $ VList [])
, Symbol SGlobal $*PROGNAME (Val $ VStr name)
--, Symbol SGlobal $*STDIN (Val $ VStr str)
, Symbol SGlobal $*END (Val VUndef)
+, Symbol SGlobal %*ENV (Val $ VList $ map VStr $ flattenPairs
environ)
]
--str - return -- getContents
let env' = runRule (fenv env) id ruleProgram prog
Index: src/Posix.hs
===
--- src/Posix.hs(revision 170)
+++ src/Posix.hs(working copy)
@@ -21,9 +21,11 @@
rename,
removeLink,
sleep,
+getEnvironment,
) where
#ifdef PUGS_HAVE_POSIX
+import System.Posix.Env
import System.Posix.Files
import System.Posix.Process
import System.Posix.Unistd
@@ -47,4 +49,7 @@
sleep :: Int - IO ()
sleep _ = fail 'sleep' not implemented on this platform.
+getEnvironment :: IO [(String, String)]
+getEnvironment = []
+
#endif
Re: Environment variables
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 suspect that the type of the internal thingy in %*ENV might not be right, so you may want to turn it in a VHash instead (I haven't found any difference). Thanks, indeed a list of pairs may be casted, in Pugs internal, as a hash at any time. To cast into VHash, use listToFM: VHash . MkHash . listToFM $ [ (VStr k, VStr v) | (k, v) - environ ] But otherwise, the patch is clean. Applied, thanks! /Autrijus/ pgpKLovpKs18u.pgp Description: PGP signature
Re: Using environment variables to control long running tests (again)
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 User 1 1 Impatient User0 1 Robot 1 0 Naive: Gets default behaviour desired by CPAN author Contrary: Gets opposite of default behaviour desired by CPAN author Impatient: Never runs long tests Robot: Always runs long tests Since we've got a very natural 3 valued logic here, you can achieve the same with PERL_SKIP_LONG_TESTS undef = do what the author wants 1 = skip 0 = don't skip Which makes sense - do what the user says if they actually said something otherwise do what the author says, F
Re: Using environment variables to control long running tests (again)
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 check to ensure that my environment is close enough to your devel environment to safely install a tool, versus tests that are check all functionality to ensure that during your coding, you don't hose up some existing action. I want to be able to run tip of the iceberg tests while installing. And that's all. 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 long as it's consistent, and I can set it easily in CPAN.pm without having to write a wrapper (via make_arg). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Using environment variables to control long running tests (again)
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 long as it's consistent, and I can set it easily in CPAN.pm without having to write a wrapper (via make_arg). Consistency? I think you've chosen the wrong programming language, sir! -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ The plot seems complicated at first but with a little study it becomes hopelessly confused. - Peter Schickele, Hansel and Gretel and Ted and Alice
Using environment variables to control long running tests (again)
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 just pick something and document it, but I'm working on Least Surprise here.) Kake On Fri 06 Jun 2003, Andrew Savige [EMAIL PROTECTED] wrote: Since no experienced perl-qa'er has leapt in, and against my better judgement, I suggest an environment variable name of: PERL_TEST_LONG Paranoid/masochistic folks and automated test harnesses can set this variable to ensure all tests are run, even the long running ones.
Re: Using environment variables to control long running tests (again)
--- 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 to set to enable long-running tests? I don't know if something like that's been implemented or not, but I think it's something that should be implemented by the user and probably not be pushed into the core testing suite. 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 any tests are skipped, it should be by the explicit instruction by the person running the test lest nasty surprises crop up. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: Using environment variables to control long running tests (again)
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 variable to set to enable long-running tests? I followed merlyn's suggestion and used PERL_SMOKE. That is, the long- running tests are skipped by default; they are run only if the user sets the PERL_SMOKE environment variable. Since the name is arbitrary, it makes little sense for each developer to invent her own different name for the same purpose, hence my initial query. I don't know if something like that's been implemented or not, but I think it's something that should be implemented by the user and probably not be pushed into the core testing suite. Having an agreed name requires no changes to any test harnesses, the user controls simply by setting the PERL_SMOKE environment variable. 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 annoy interactive users, in particular those running the CPAN shell. /-\ http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time.
Re: Using environment variables to control long running tests (again)
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 annoy interactive users, in particular those running the CPAN shell. Disabling tests for subjective reasons (they take too long, they don't test critical functionality, etc...) is a slippery slope. For that reason I'd agree with Curtis and say that everything is always run by default and users can then elect what to turn off. PERL_SKIP_LONG_TESTS seems like a clear name. If users find tests annoying then can turn them off, or ignore them or not run them at all. Because the user impulse is more often to weaken the tests than the strengthen them, the default should always be the strongest testing position. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Congratulations, you're a thieving bastard... Now give me back my pants. That's MISTER Pants! -- Ian's Adventures In Morrowind http://www.machall.com/morrowind/page3.html
Re: Using environment variables to control long running tests (again)
Michael G Schwern wrote: Disabling tests for subjective reasons (they take too long, they don't test critical functionality, etc...) is a slippery slope. For that reason I'd agree with Curtis and say that everything is always run by default and users can then elect what to turn off. PERL_SKIP_LONG_TESTS seems like a clear name. If users find tests annoying then can turn them off, or ignore them or not run them at all. Because the user impulse is more often to weaken the tests than the strengthen them, the default should always be the strongest testing position. I think PERL_SKIP_LONG_TESTS is a fine name. Given the sometimes heated discussion in this thread: http://www.perlmonks.org/index.pl?node_id=254011 I doubt the two camps will ever agree on this issue. My view is that it is up to the individual CPAN 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 module). 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 User 1 1 Impatient User0 1 Robot 1 0 Naive: Gets default behaviour desired by CPAN author Contrary: Gets opposite of default behaviour desired by CPAN author Impatient: Never runs long tests Robot: Always runs long tests /-\ http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time.
Re: Using environment variables to control long running tests (again)
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 users find tests annoying then can turn them off, or ignore them or not run them at all. Because the user impulse is more often to weaken the tests than the strengthen them, the default should always be the strongest testing position. Note that this might put pressure on test writers to not write a more complex test, if they feel guilty about the extra exection time it would require. -- Danny R. Faught Tejas Software Consulting http://tejasconsulting.com/
How to get environment variables?
Is it possible to get environment variables from perl6 programme? It failes when I try to use perl5 hash %ENV. Thanks.
Re: How to get environment variables?
[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 Perl 6 are you using?
--
The C Programming Language -- A language which combines the power of
assembly language with the flexibility of assembly language.
Re: How to get environment variables?
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,'/parrot-0.0.13/parrot -r env.imc ') called at
/parrot-0.0.13/languages/perl6/perl6 line 819
main::pass4('env.imc','env.warn') called at
/parrot-0.0.13/languages/perl6/perl6 line 741
main::pass2('env.imc','env.warn') called at
/parrot-0.0.13/languages/perl6/perl6 line 435
main::output_tree('P6C::prog=ARRAY(0x8ef6e5c)','env.p6','env.warn')
called at /parrot-0.0.13/languages/perl6/perl6 line 500
main::pass1('Parse::RecDescent=HASH(0x8f2ed70)','env.p6','env.warn','undef') called at /parrot-0.0.13/languages/perl6/perl6 line 562
main::run() called at /parrot-0.0.13/languages/perl6/perl6 line 219
Are you sure you're using the Perl 6 hash syntax? (%ENV{FOO} rather than Perl
5-style $ENV{FOO})
What version of Perl 6 are you using?
Re: Using environment variables to control long running tests
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. Modules should commonly have long-running exhaustive tests Andrew and/or stress tests. These tests are primarily for the benefit of Andrew module maintainers; it's unreasonable to expect users to wait hours Andrew for them to run. I think this is a common enough scenario to warrant Andrew defining a standard way to do it -- which may be as simple as Andrew agreeing on a standard name of a single environment variable Andrew (I don't have enough experience to suggest a good name, however). 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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Using environment variables to control long running tests
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 CPAN test harnesses to run the longer tests. /-\ http://mobile.yahoo.com.au - Yahoo! Mobile - Check compose your email via SMS on your Telstra or Vodafone mobile.
Using environment variables to control long running tests
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 standard name/s for such environment variables? If not, is it desirable to standardise on at least one environment variable name to control whether long tests are run? Is anyone using alternative mechanisms to solve this problem? /-\ http://mobile.yahoo.com.au - Yahoo! Mobile - Check compose your email via SMS on your Telstra or Vodafone mobile.
Re: Using environment variables to control long running tests
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 DBD, HTML::Mason and other modules already do this. Actually DBD HTML::Mason don't do what Merlyn is asking for. They use environment variables to skip tests when the necessary features are not available (no database, no mod_perl, etc.) Merlyn is talkin about skipping tests because they take too long (more than a minute or two). Is there a standard name/s for such environment variables? If not, is it desirable to standardise on at least one environment variable name to control whether long tests are run? Is anyone using alternative mechanisms to solve this problem? I don't see it as a real problem. If I've written a test I want it run. Otherwise I wouldn't have written it. Not running tests is pretty much the ultimate sin as far as I am concerned - but I'm odd that way :-) There's some related discussion on http://www.perlmonks.org/index.pl?node_id=254011 that you might find of interest. Cheers, Adrian
