're'-redirecting STDOUT back to STDOUT after writing to a file

[Matthias Kraatz]

Hi,
   this might be a really stupid question. But, in a cgi-script I 
wanted to prevent an executable that I call from within the script from 
dumping output directly to the webpage.

This worked fine with 'open(STDOUT,">something-log.txt")'.
But now I want to write to the webpage again. 'open(STDOUT,">&STDOUT")' 
does not only look strange, well, it also doesn't work.

Thanks in advance,
Matthias
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: 're'-redirecting STDOUT back to STDOUT after writing to a file

[Matthias Kraatz]

Thanks, I have learned something. My conception was that STD* 
descriptors where sort of system constants. Now I see that you can 
query, rename and store them into other variables.

So storing old STDOUT and resetting when done with all the other stuff 
works perfect now.

Thanks again,
Matthias
Octavian Rasnita wrote:
Use select() function.
Read perldoc -f select
Teddy
- Original Message - 
From: "Matthias Kraatz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 27, 2004 12:20 AM
Subject: 're'-redirecting STDOUT back to STDOUT after writing to a file

Hi,
   this might be a really stupid question. But, in a cgi-script I 
wanted to prevent an executable that I call from within the script from 
dumping output directly to the webpage.

This worked fine with 'open(STDOUT,">something-log.txt")'.
But now I want to write to the webpage again. 'open(STDOUT,">&STDOUT")' 
does not only look strange, well, it also doesn't work.

Thanks in advance,
Matthias
 


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Problems installing CPAN perl modules

[Matthias Kraatz]

Hi,
first, on my home computer under cygwin installing the modules works 
just fine.

In contrast, the same task on a Sun (SunOS 5.9/sparc) gives me a 
headache. I don't have root access, so I define all the paths manually.

In detail, I do
  perl Makefile.PL `cat ~/.perl_dirs`
in the modules directory where .perl_dirs contains:
PREFIX=/home/kraatzm/persapps \
INSTALLPRIVLIB=/home/kraatzm/lib/perl5 \
INSTALLSCRIPT=/home/kraatzm/bin \
INSTALLSITELIB=/home/kraatzm/lib/perl5/site_perl \
INSTALLBIN=/home/kraatzm/bin \
INSTALLMAN1DIR=/home/kraatzm/lib/perl5/man  \
INSTALLMAN3DIR=/home/kraatzm/lib/perl5/man3
Then I try the standard make;make test; make; make install.
And here is the problem. The make reports all source files as missing. 
But they do exist! It can't be because of an errornous module package 
because the exact same one installs fine on my home computer. This is 
true for any kind of module I download from CPAN. Although the manuals 
install fine, the actual modules don't make it to their destination. As 
a workaround I found that copying them by myself works, but that is just 
too much work and error prone.

Does anybody have an  idea what might be wrong? Is it the installation 
of perl on the Sun? I will append the perl -V output at the end.

I have spend a a long time googling with no success, so any help is 
greatly appreciated,
Matthias

---
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
  osname=solaris, osvers=2.9, archname=sun4-solaris-64int
  uname='sunos localhost 5.9 sun4u sparc sunw,ultra-1'
  config_args=''
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef use5005threads=undef useithreads=undef 
usemultiplicity=unde
f
  useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
  use64bitint=define use64bitall=undef uselongdouble=undef
Compiler:
  cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-xO3 -xdepend',
  cppflags=''
  ccversion='Sun WorkShop', gccversion='', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=87654321
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long long', ivsize=8, nvtype='double', nvsize=8, 
Off_t='off_t', lsee
ksize=8
  alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
  ld='cc', ldflags =''
  libpth=/lib /usr/lib /usr/ccs/lib
  libs=-lsocket -lnsl -ldl -lm -lc
  perllibs=-lsocket -lnsl -ldl -lm -lc
  libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so
Dynamic Linking:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R 
/usr/perl5/5.6.
1/lib/sun4-solaris-64int/CORE'
  cccdlflags='-KPIC', lddlflags='-G'

Characteristics of this binary (from libperl):
Compile-time options: USE_64_BIT_INT USE_LARGE_FILES
Locally applied patches:
   9676 Port the OpenBSD glob() security patch
   9678 Addendum to #9676: some missing changes from OpenBSD glob.c
   9679 Up $File::Glob::VERSION, add OpenBSD glob version note
   9693 $VERSION and Version() on same line provokes CPAN.pm warning
   9706 #7210 broke .packlist generation
   9707 ExtUtils::Installed doesn't quote regex metacharacters in paths
   9775 Typo in utf8.h
   9950 Revert integration of #8254,#8255 in #8620 (causes coredump)
  10021 Insecure regexes
  10091 $ref1 == $ref2 behaves unpredictably if not NV_PRESERVES_UV
  10093 Incorrect line numbers in AutoSplit
  10100 [20010514.027] PL_last_in_gv may not be GV if stale filehandle
  10145 [20010515.004] Segfaults from premature GC
  10203 Don't think about UTF8
  10250 [20010422.005] perl -e '{s//${}/; //}' segfaults
  10394 Leakage of file scope lexicals into predeclared subroutines
  10404 eval.t was relying on pre-#10394 buggy behavior
  10412 Rationalize locale handling to fix bugs uncovered by #10394
  10422 Potential buffer overrun if the radix separator > 1 byte
  10448 Lexicals outside eval weren't resolved correctly pre-#10394
  10450 Optimize #10448 slightly
  10543 Add LC_MESSAGES constant to POSIX module
  10667 #10449 broke visibility of lexicals inside DB::DB()
  10739 C fails to compile correctly
  10939 Proposed fix for Pod::Man
  11169 Doc patch for Tie::Hash
  11374 Make h2ph grok ccsymbols fo the form 1234L, 1234ULL etc
  11427 t/harness wasn't picking up all the tests
  11428 run/runenv.t needs fflushNULL sanity
  11431 pod/*.t tests not picked up by t/TEST either
  11510 eval 'format foo=' would loop indefinitely
  11713 UTF8 wasn't printing for PVMGs
  11716 UTF8 flag should be meaningful only when POK
  11808 [20010831.002] Bug in Term::Cap on Solaris ansi terminal
  11847 Typo in perl_clone() code causes local(*foo) breakage
  12005 [20010912.007] substr reference core dump
  12024 Fix local() precedence bug in #8311
  12303 Fix 'local $!=0;undef*STDOUT;' segfault
  12304 Pod::Html makes a poor guess at author
  12350 Typo in IO::Seekable doc

Re: CGI

[Matthias Kraatz]

Hi Brent,
there are a few reasons that come to my mind why the code stopped 
working after transferring from another machine:

1) The shellbang line (e.g. "#!/usr/bin/perl") does not point to the 
actual perl binary on the local machine.
2) A newline problem, i.e. you binary copied from a unix to dos machine 
or vice versa.
3) A perl module called from your script is not found

Check the error log again. Usually just before the "Premature end of 
script... " message, there is a more descriptive warning that might help 
you to find out why it bailed out.

-Matthias

Brent Clark wrote:
Chris Devers wrote:
Please, just one copy of the email. Thanks.
On Mon, 6 Dec 2004, Brent Clark wrote:

In my apache log files, I keep getting this:

[Mon Dec  6 17:51:35 2004] [error] [client 192.168.111.214] Premature
end of script headers: /home/abc/cgi-bin/xyz/scripts/agent/logon.pl

 
If you got that far, then Apache is at least attempting to run the 
script, so you don't need to keep looking at the Apache config here.

You've provided none of your Perl code, so it's hard to say what 
exactly the problem might be, but "premature end of script headers" 
is often a hint that you didn't emit a Content-type header before 
your other output. The simple fix for this is to have a line like 
this before any other print statements in your code:

  print "Content-type: text/html\n\n";
But if you're using CGI.pm for content generation, it can do this for 
you, invisibly, before sending out any output. As it isn't clear how 
you're sending out your data, I won't get into specifics, but if 
nothing else try adding the print statement above and see if it helps.

If you're still stuck, please send a short script that demonstrates 
the problem.
 

Hi
thanks for your reply
The thing is that I dont get popup box whereby I have to enter the 
username and password (generated by my a.httaccess of apache).
In terms of the code, this same very code run on my hosted box in the 
uk and every thing runs fine.
All did was scp the files to my local box, installed apache with 
libapache-perl etc and it does not want to work. Basically tried  to 
simulate the box in the UK.

Thanks
Brent


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Perl on Cygwin

[Matthias Kraatz]

On my home computer I only run perl through cygwin. That way I can 
readily export scripts to Unix, without changing paths.
Works great.

Have fun,
  -Matthias
Mandar Rahurkar wrote:
Hello,
 Has anyone used perl on windows machine through cygwin ?  Is the
usability same as that on linux box ?
Mandar
 


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

How to detect present X-Server

[Matthias Kraatz]

Hi everybody -
is there a way to make a perl program find out whether a valid X-Server 
is running?
I.e. $ENV{DISPLAY} is not a dummy address, if set.

Thanks,
   Matthias

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: How to detect present X-Server

[Matthias Kraatz]

Jonathan -
thanks for the input. Actually I wanted to provide more details but I 
thought there would be a simple and standard solution for it (that I 
hadn't found.)

Anyway, I am working on a project for interfacing  a simulation 
software, creating input files, processing output, scripting variations 
of parameters for huge numbers of batch simulations and all that.
For certain subprocesses (imaging, text editing, etc.) it would be 
useful to know whether X functionality is there or not. Example: do I 
launch vi or xedit, should I even try to display an image, start OpenDX 
or not, and so on.
I thought about an option, works for me. But since a group of people is 
using the tool, I want to make it as simple as possible.
What I have noticed - when started without X support - X applications 
sometimes just sit there as idle processes, not quitting with an error 
'cannot open display etc...'. They accumulate and waste resources.

So maybe I should change my strategy - from highest-functionality to 
working-simple-but-by-default, the latter with explicit options to step up.

I thought that maybe a function/module would exist, returning true if X 
supported.

Thanks for your reply and ideas,
Matthias
Jonathan Paton wrote:
is there a way to make a perl program find out whether a
valid X-Server is running?
I.e. $ENV{DISPLAY} is not a dummy address, if set.
   

Not in a useful way.
I have a headless (no monitor) Linux server, and a Windows
desktop with a X win server.  If I forget to run the X server it
doesn't mean that DISPLAY contains a dummy address...
If a script made a guess at whether I wanted X functionality
(say for installation), then it could get it wrong.  That would
be most annoying.
If a script wants to know if it can use the X server (or if one
exists), then it should go ahead and try.  If the toolkit returns
an error then you know you don't have one.
In the situation you want to use X if available, terminal
otherwise, wouldn't it be better just to use an option?
More detail, better answers!
Jonathan Paton
 


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]