in reply to Win32::TieRegistry and Delimiter

No, Win32::TieRegistry handles your chosen delimiter being in a key name for only one very restricted situation. Quoting the documentation:

If you have already called the Perl C<keys> function on the tied hash [or have already called C<MemberNames> on the object] and the hash key string exactly matches one of the strings returned, then no further parsing is done. In other words, if the key string exactly matches the name of a direct subkey with a delimiter appended, then a reference to a hash tied to that subkey is returned [but only if keys or MemberNames has already been called for that tied hash].

This is only important if you have selected a delimiter other than the system default delimiter and one of the subkey names contains the delimiter you have chosen. This rule allows you to deal with subkeys which contain your chosen delimiter in their name as long as you only traverse subkeys one level at a time and always enumerate the list of members before doing so.

The main advantage of this is that Perl code which recursively traverses a hash will work on hashes tied to Registry keys even if a non-default delimiter has been selected.

That is, you could get away with:

use Win32::TieRegistry( Delimiter=>"/" ); unless( $remoteKey= $Registry->{"//$pserver/LMachine/SYSTEM/" . "CurrentControlSet/Control/Print/Monitors/"} and $remoteKey->SubKeyNames() and $remoteKey= $remoteKey->{"HP Standard TCP/IP Port/"} and $remoteKey= $remoteKey->{"Ports/$portname/"} ) { die "Can't read the port key on $pserver: $^E\n"; }
But you'd probably be better off just using:
use Win32::TieRegistry( Delimiter=>"/" ); $remoteKey = $Registry->Open( "##$pserver#LMachine#SYSTEM#" . "CurrentControlSet#Control#Print#Monitors#" . "HP Standard TCP/IP Port#Ports#$portname#", { Delimiter=>"#" } ) or die "Can't read the port key on $pserver: $^E\n";

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re: Win32::TieRegistry and Delimiter
by mumbles (Friar) on Apr 15, 2002 at 17:13 UTC
    Excellent.

    Couldn't see it until it was pointed out.

    Thank you.