Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

perl 5.6.1 on AIX 5.1 doesn't open() a $var, only real path

by jptxs (Curate)
on May 19, 2005 at 19:01 UTC ( #458737=perlquestion: print w/ replies, xml ) Need Help??
jptxs has asked for the wisdom of the Perl Monks concerning the following question:

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);

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);

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...

We speak the way we breathe. --Fugazi

Comment on perl 5.6.1 on AIX 5.1 doesn't open() a $var, only real path
Select or Download Code
Re: perl 5.6.1 on AIX 5.1 doesn't open() a $var, only real path
by chas (Priest) on May 19, 2005 at 19:20 UTC
    Well, if your code is really as it appears here, the problem would seem to be that $config hasn't been defined as a file path.
    chas
    (Update: Or perhaps there is not enough code shown for me to understand just what is being done...what is the relation between $config and $confgiFile?)
Re: perl 5.6.1 on AIX 5.1 doesn't open() a $var, only real path
by Fletch (Chancellor) on May 19, 2005 at 20:26 UTC

    Just to toss out an idea: I want to say AIX has support for Access Control Lists (ACLs) in addition to the traditional ugo permissions. Perhaps those are set different?

      I did check that. No ACLs were set.

      We speak the way we breathe. --Fugazi
Re: perl 5.6.1 on AIX 5.1 doesn't open() a $var, only real path
by bluto (Curate) on May 19, 2005 at 20:47 UTC
    su - softwareUser -c /path/to/my/script.pl

    This should work, but you may also be able to use: fork, POSIX::setuid, exec(). I've used this on with perl 5.8.5 on AIX.

    Opening to a file with a variable should work fine. You have this...

    my $confgiFile = '/path/to/configFile'; open ( CONFIG, ">$config" ) or die "FATAL :: failure configuring - $!\ +n\n"; print CONFIG $config; # $config is populated much earlier close(CONFIG);

    So you are setting $confgiFile to a path, but you are opening $config. Are these two the same here (e.g. is this a typo)? One thing I'd suggest is to put the file name that you pass to 'open' in the 'die' as well so you can sanity check what it is trying to do. The only other thing I can suggest is to check your umask just before the open, though I suspect it's probably ok.

      Yes, that was a typo. I did set a bunch of debug in the script and everything looked fine with the path being passed.

      what could the umask do? If I create a file I own, I can't see how a umask would prevent then editing that file myself. Maybe I'm missing something... I will check it, though; and see what's happening there.

      We speak the way we breathe. --Fugazi
        what could the umask do? If I create a file I own, I can't see how a umask would prevent then editing that file myself.

        On AIX I've seen problems with giving garbage mode bits (e.g 0) to the equivalent of a sysopen call cause problems later accessing the file, even for the owner. I thought that there was a slight chance that perhaps a bad umask could cause the same problem (though very unlikely). But even why I try that I can't reproduce it (i.e. this works fine for me on perl 5.8.5...)

        % umask 777 % perl -le 'open my $fh, ">foo" or die "open:$!"; print $fh "hello" or + die "print:$!"; close $fh or die "close:$!"'

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://458737]
Approved by rev_1318
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (14)
As of 2014-07-25 18:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (174 votes), past polls