Had a very strange thing happen today. I am working on packaging software into pkg (Sun), rpm (SuSE) and installp (AIX) formats. Part of the post install features of the package is that it runs a perl script to configure the software that's been laid onto disk. The post install procedure for installp on AIX is basically to run a shell script, and in that shell script I have it do:

su - softwareUser -c /path/to/my/script.pl

The package, as with every package installation across all the platforms I've dealt with, runs as root. So in order to have the script run with the correct authority the 'su' is needed. So that's all the background.

What I had was a simple block of code:

my $confgiFile = '/path/to/configFile';

open ( CONFIG, ">$configFile" ) or die "FATAL :: failure configuring -
+ $!\n\n";

print CONFIG $config; # $config is populated much earlier

close(CONFIG);
[download]

That was dandy on Sun and Linux. On AIX, I kept getting errors saying "The file permissions do not allow the specified action".

The strange part was that I had another piece of code that worked fine just above it:

open ( OTHERCONFIG, ">/path/to/otherconfigFile" ) or die "FATAL :: fai
+lure configuring - $!\n\n";

print OTHERCONFIG $otherConfig;

close(OTHERCONFIG);
[download]

The 'OTHERCONFIG' worked fine. Permissions on the files were identical. Permissions that were identical on the other platforms worked fine. It was running as the same user. The same operation worked on AIX 5.2 with the same perl version. very, very, very odd...

So I changed the first one to use a real path instead of a variable (a bit of a pain b/c the path is different on each platform so I have to make sure that is changed down in the bowels of the script instead of manipulating a variable at the top). Now it works, too.

I've been poking around doc and google, but no luck finding a cause for this. Anyone else have ideas? We worked around it in a way I'm mostly happy with, but I'm very curious why it happened...