At work (on windows) I was trying to install File::Flat via cpan, and ran into an issue in the make test where it was expecting certain operations to fail if the installing user wasn't root (or perhaps the other way around, that exact point isn't important at the moment), and was of course making that determination (root v. non-root UID) based on the value of $>. I knew I had administrative rights on the machine, which ought to translate into root-like privileges from the world of unix. My first attempt to update the failing test was something like this: (previously)

$root = $> == 0 ? 1 : 0;
[download]

$> = eval "use Win32" || ! $@ ? Win32::IsAdminUser() ? 1 : 0 : $>;
# or something like that
$root = $> == 0 ? 1 : 0;
[download]

Which I could never get to work.

On a unix (or unix-like OS such as my Mac), I guess I can understand and accept why I can't change "$>"...

$ perl -e '$> = 0; print "$!\n"; print "$>\n"'
Operation not permitted
501
$
[download]

But should these same constraints apply to Windows/cygwin? Especially in the following case?

$ perl -e 'use Win32;print Win32::IsAdminUser(),"\n";$>=0; print $!,"\
+n"; print $>,"\n"'
1
Invalid Argument
4638
$
[download]

Does $> have a little extra magic that even applies across the great Win32 divide?

I've since thought that perhaps this might work (not trying to set $> at all), and looks like it ought to work:

$root = eval "use Win32" || ! $@ ? Win32::IsAdminUser() ? 1 : 0 : $> =
+= 0 ? 1 : 0;
[download]

At any rate, what's going on with $>? :)

$,=42;for(34,0,-3,9,-11,11,-17,7,-5){$*.=pack'c'=>$,+=$_}for(reverse s
+plit//=>$*
){$%++?$ %%2?push@C,$_,$":push@c,$_,$":(push@C,$_,$")&&push@c,$"}$C[$#
+C]=$/;($#C
>$#c)?($ c=\@C)&&($ C=\@c):($ c=\@c)&&($C=\@C);$%=$|;for(@$c){print$_^
+$$C[$%++]}
[download]