«

Maybe a poor title, but this has been driving me nuts for about an hour
now.....

Consider:

my $log_file = 'active.log';

print "log_file is $log_file\n";

# prints 'active_log'

open( LOG, '+>>', $log_file )
or die "Can't open logfile: $log_file $!\n";

# prints "Can't open logfile: "

Obviously there is more going on in this logging script, but if I print
out the value of $log_file immediately before the open, the value is
correct, then it seems to go away when reference in the open statement...

It's probably something stupid, but sheesh....

Perl 5.008 (I know, but it's not my server)

perl -V (just in case it's Perl itself)
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.6.9-67.0.7.elsmp, archname=i386-linux-thread-multi
uname='linux hs20-bc2-4.build.redhat.com 2.6.9-67.0.7.elsmp #1 smp wed
feb 27 04:47:23 est 2008 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686
-Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red
Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
-Dvendorprefix=/usr -Dsiteprefix=/usr
-Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads
-Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db
-Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
-Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less
-isr -Dinc_version_list=5.8.0'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -march=i386 -mcpu=i686',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.3 20030502 (Red Hat Linux 3.2.3-59)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
MAINT18379
Built under linux
Compiled at Jun 5 2008 09:47:16
@INC:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
..

If anyone can slap me upside the head and give me a clue on what is
going on I'd sure appreciate it....

TIA,

Steve M

Steve May <stevem_@nogood.com> writes:
> Consider:
>
> my $log_file = 'active.log';
>
> print "log_file is $log_file\n";
>
> # prints 'active_log'
>
> open( LOG, '+>>', $log_file )
> or die "Can't open logfile: $log_file $!\n";
>
> # prints "Can't open logfile: "
>
> Obviously there is more going on in this logging script, but if I
> print out the value of $log_file immediately before the open, the
> value is correct, then it seems to go away when reference in the open
> statement...

As it stands, this is rather unintelligible. What are the exact
symptoms of your problem? Could your perhaps post something
sufficiently completed that it can be run through perl with 'the
problem' actually occuring?

On 11/07/2011 12:54 PM, Steve May wrote:
> Maybe a poor title, but this has been driving me nuts for about an hour
> now.....
>
> Consider:
>
> my $log_file = 'active.log';
>
> print "log_file is $log_file\n";
>
> # prints 'active_log'
>
> open( LOG, '+>>', $log_file )
> or die "Can't open logfile: $log_file $!\n";
>
> # prints "Can't open logfile: "
>
> Obviously there is more going on in this logging script, but if I print
> out the value of $log_file immediately before the open, the value is
> correct, then it seems to go away when reference in the open statement...
>
> It's probably something stupid, but sheesh....



Ah well... thanks guys, I'm considering this one closed.

This is a cgi program and the problem turned out to be a permissions
issue (not used to non-SUEXEC servers), though why die would not pass
along the value of $log_file still has me scratching my head.

I didn't post more code as it is property of the customer and as silly
as non-disclosures are... well.

\s

Steve May <stevem_@nogood.com> writes:
> On 11/07/2011 12:54 PM, Steve May wrote:
>> Maybe a poor title, but this has been driving me nuts for about an hour
>> now.....
>>
>> Consider:
>>
>> my $log_file = 'active.log';
>>
>> print "log_file is $log_file\n";
>>
>> # prints 'active_log'
>>
>> open( LOG, '+>>', $log_file )
>> or die "Can't open logfile: $log_file $!\n";
>>
>> # prints "Can't open logfile: "
>>
>> Obviously there is more going on in this logging script, but if I print
>> out the value of $log_file immediately before the open, the value is
>> correct, then it seems to go away when reference in the open statement...

[...]

> This is a cgi program and the problem turned out to be a permissions
> issue (not used to non-SUEXEC servers), though why die would not pass
> along the value of $log_file still has me scratching my head.
>
> I didn't post more code as it is property of the customer and as silly
> as non-disclosures are... well.

It is silly to complain about a problem without saying what the
problem actually is and even more silly to post random mock-up code
that doesn't demonstrate the problem alongside of the content-free
complaint.

On 11/08/2011 05:28 AM, Rainer Weikusat wrote:
> Steve May<stevem_@nogood.com> writes:
>> On 11/07/2011 12:54 PM, Steve May wrote:
>>> Maybe a poor title, but this has been driving me nuts for about an hour
>>> now.....

<snip>
>
> It is silly to complain about a problem without saying what the
> problem actually is and even more silly to post random mock-up code
> that doesn't demonstrate the problem alongside of the content-free
> complaint.
>

Thank you for your insightful comments.

\s

On 11/08/2011 09:48 AM, Henry Law wrote:
> On 08/11/11 16:13, Steve May wrote:
>> On 11/08/2011 05:28 AM, Rainer Weikusat wrote:
>
>>> that doesn't demonstrate the problem alongside of the content-free
>>> complaint.
>>
>> Thank you for your insightful comments.
>
> I sense your irritation;

Irritation?

Ah... well, I guess the smiley face didn't get my amusement across. I
realize that the 'seriousness' here is high, but I thought I'd danced
around that.

Guess not.

Sorry about that. It seems my communication skills have suffered along
with everything else this last year or so.


> The only way to get really high-quality help (and
> people of the highest quality hang out here, not excluding the author of
> the language himself) is to do what Rainer says, and what it says in the
> posting guidelines: *post something that can be run by anyone and that
> fails in the way you're describing*
>

Agreed.

> This doesn't mean the original code, proprietary or otherwise. It means
> a cut-down version, anonymised if necessary and with as many external
> things stubbed out as possible. And the very cutting-down will often
> help you to find the problem. As you're cutting down your real code
> suddenly something happens which gives you an insight into your own
> problem.
>

Of course, this problem turned out to be (mostly) a non-Perl problem.

paths/permissions were NOT what I expected and... well, it was a mess.

I mostly posted the original in a fit of frustration, and I doubted I
should at the time. But once you hit that send button....

Hell to get old and stupid(er) to begin with and then add in multiple
heart attacks, mini-strokes, drugs to prevent more of the same, etc. and
a person gets *really* loony.

I'll just go back to lurking now, thanks.

\s