Note that it is perfectly valid to omit the penultimate zero value octets. You can play around with this in the following one-liner:

% perl -MSocket -e 'print inet_aton shift' 65.0.0.65|hexdump
0000000 0041 4100
0000004
% perl -MSocket -e 'print inet_aton shift' 65.65|hexdump
0000000 0041 4100
0000004
[download]

That is, there exists a shorthand for x.0.0.y and x.y.0.z (but not x.0.y.z). To complete the picture, you can also do this for 0.0.0.x, but that's hardly ever useful.

Which is another reason why inet_aton is such a good idea.

<update> Re your 01.1.1.010 problem, there is an issue you should be aware of. A leading 0 in a string, signals octal (assuming you're trying to interpret the string as a number). Consider the following:

% perl -MSocket -le 'print inet_ntoa inet_aton shift' 01.1.1.10
1.1.1.10
% perl -MSocket -le 'print inet_ntoa inet_aton shift' 01.1.1.010
1.1.1.8
[download]

Note that I don't see the behaviour you describe, although I'd be loathe to consider this the work of an interfering shell. If this is really a problem, I'd be inclined to do a simple cleanup prior to calling inet_aton with something like (untested):

my $_IP = inet_aton( join '.',
    map { s/^0([1-9]\d*)$/$1/; $_ } # strip leading zeroes
    split( /\./, $original_ip)      # of each octet
);
[download]

</update>
print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'