It seems very strange to me that these other programs (can you give an example?) require uppercase %ENV only. Do these programs require the keys or the values or both of %ENV to be in uppercase?

*nix right? If so, then changing %ENV only affects the running program and any children. If that's what you need to do, then that's what you need to do. The only real question is do you need the lowercase (or mixed case) entry to still be around. If not, then something like this works fine:

foreach my $key ( keys %ENV ) {
  my $val = $ENV{$key};
  delete $ENV{$key};
  $ENV{ uc $key } = $val;
}
[download]

foreach my $key ( keys %ENV ) {
  $ENV{ uc $key } = $ENV{$key};
}
[download]

Yes, target is linux.

But there will be _some_ENV_manipulations_, and I am not clear what it will be.

example

use my_future_runtime;
my $x = get_command_line_param(); # $x may be mixed case
my $y = read_some_file(); # $y may be mixed case
sub_which_add_new_key($x, 'value_for_cobol');
sub_which_delete_key($y);
launch_cobol_prog();
[download]

imho, tie the "most right" way in such situation.

If you're on Unix, the easiest/safest way might be to:

1. Fork (so you can mess with your child process's copy of the environment without affecting your own copy)
2. Loop over each key - delete the key from %ENV, uppercase both key and val, stash them back into %ENV
3. exec your child program (your modified environment should be preserved).

1) tie %ENV, 'my_uppercase_env';

2) just simple access methods Eget, Eset, Edel, Eexs

3) Define some intermediate %ENV_, tie it, and in its methods do with real %ENV

is a trade-off between the effort to implement the solution and the effort to adapt the (existing?) code that expects case-insensitive access to %ENV.

1) is the hardest one to implement, as you have noted. %ENV is magical, and tie-ing a magical variable is bound to be tricky. On the other hand, it requires no change at all to the code that uses it. You'd need that method if you can't change that code at all. If you can, choose one of the others.

2) is the simplest one to implement, but it would presumably require hand-editing the code that uses it, replacing every access to %ENV with the appropriate access method.

3) is in effect a wrapper around 2). It needs extra effort to embed the access methods in a tied hash. The advantage would be that you could mechanically change the using code, applying something like s/([%@$])ENV/${1}ENV_/g.

In this view, the choice would depend on how hard it is to adapt the code that needs a caseless %ENV.

Anno

This problem is strange, but it's my formal task. I am not main project designer. I have limited "free-hand". Project's aim is to make some runtime library with own internal data and additional ENV manipulation functionality. I know that some future functions in this library will launch some cobol programs that require uppercase ENV, that's all. Now I'm at the beginning and want to deside how to make this better for the future tasks.

I thought about this like Anno wrote. Thanks him for advise not tie magical vars, I didnt knew it. I may change code. So only two or even "one and a half" ways remain.

C:\>perl -le"$ENV{lowerlowerlower}=1;print for keys %ENV"
USERPROFILE
HOMEDRIVE
CLIENTNAME
COMMONPROGRAMFILES
APPDATA
PROGRAMFILES
OS
PATHEXT
PROMPT
NUMBER_OF_PROCESSORS
HOMEPATH
PATH
USERDOMAIN
PROCESSOR_ARCHITECTURE
TEMP
SYSTEMDRIVE
COMSPEC
WINDIR
PROCESSOR_LEVEL
USERNAME
LOWERLOWERLOWER
PROCESSOR_IDENTIFIER
ALLUSERSPROFILE
COMPUTERNAME

C:\>
[download]

Don't count on a specific environment variable existing in %ENV. Don't count on %ENV entries being case-sensitive, or even case-preserving. Don't try to clear %ENV by saying "%ENV = ();", or, if you really have to, make it conditional on "$^O ne 'VMS'" since in VMS the %ENV table is much more than a per-process key-value string table.

Maybe on windows but not a UNIX.

bruce:0:~/tmp $ export fred=1
bruce:0:~/tmp $ env | grep fred
fred=1
bruce:0:~/tmp $ perl -e 'print $ENV{fred},"\n"'
1
bruce:0:~/tmp $ perl -e 'print $ENV{FRED},"\n"'

bruce:0:~/tmp $
[download]