Solved

Sending a GIF via <IMG SRC="perl_script.cgi"> (using FLY or gd)

Posted on 1997-06-17
7
274 Views
Last Modified: 2013-12-25
there are a few utilities out there that support "on-the-fly" gif manipulation.  One such util is FLY: http://www.unimelb.edu.au/fly/fly.html, which is based on Boutell's GD graphics library.

I am trying to call FLY (or any other similar util) from a PERL script to generate a gif and send it back to the web browser.  In other words, I will have some file called "index.html", and somewhere in that file will be a tag that says: '<img src="makegif.cgi">'.  The CGI script then calls FLY with the right commands to generate the desired GIF, and fly spits out the gif.  Now, fly can supposedly write the gif to an output file or to STDOUT.  The only files that it can write to are files that already exist with permissions of 777, so I can't write to a file at all.  If I did, I would be limiting my web page to one user at a time, since FLY would try to write the gif to the same file every time.  Instead, I want to send FLY's output to STDOUT.   My PERL script sends "Content-type: image/gif\n\n" and then I should just be able to send the gif in binary format--I have seen other sites take advantage of this before.

However, I can't seem to pipe the binary gif data to STDOUT properly.  When I run my perl script from a unix command line, it returns what I expect, which is a content-type header followed by a blank line followed by a bunch of binary garbage that I assume is the gif.  

However, when I call the same perl script via the web, it pops up a netscape window that says "document contains no data".  I've played with syntax and file permissions to the point that I can't hardly bear to look at it anymore.... i KNOW that other people have gotten this to work before.

One other problem--I do NOT have root permission on my web server, so anything I call is being called from my home directory--but when writing to STDOUT I wouldn't think that would matter.  It obviously does.

Here's the fragment of my code that is in question:

open(FOO,"fly -q -i $infile |");
while (<FOO>) {print;}
close(FOO);

If any of you experts are not familiar with fly and need to know the syntax, I can give it to you.

My best guess so far is that and programs my scripts call, via piping or whatever, are not allowed to write, period.  Even to STDOUT.  If that sounds like a reasonable explanation, then how would i go about solving that problem?

Thanks in advance for any help.
0
Comment
Question by:cprice
  • 4
  • 3
7 Comments
 

Author Comment

by:cprice
ID: 1828276
Adjusted points to 175
0
 
LVL 5

Accepted Solution

by:
julio011597 earned 170 total points
ID: 1828277
First, shouldn't be: while(<FOO>) {print(<FOO>);} ??

Anyway, you not being root shouldn't matter when talking about STDOUT; BTW, think that the web server usually runs as user nobody, which means that your CGI is invoked from the web as user nobody, so is fly.

I can just think of a path problem, i.e., when _you_ run the Perl script from command line, it succesfully finds and runs fly; maybe the web server cannot.
You should try giving a full path name to the fly command (e.g., /usr/local/bin/fly or whatever fits), make sure fly mode is 777 so that anybody may run it, and - this could help too - set up some error handling to your open(FOO, "").

To handle the error, you could put a gif whichever in the same directory as the Perl CGI script, give it mode - say - 644, and send that gif instead, in case of failure.
Or just send a bunch of nonsense in case of failure, so that you'll get a broken image instead of the 'document contains no data' warning. At least you'll be sure that it's the open() call which is failing. In that case you would investigate further... but let's try with the full path first.

Rgds, julio
0
 

Author Comment

by:cprice
ID: 1828278
re: "shouldn't be: while(<FOO>) {print(<FOO>);} ??"
-No difference.  If you do while(<FOO>) {print;} then PERL reads one line at a time from FOO into $_ and prints $_ to STDOUT.

re: "Anyway, you not being root shouldn't matter when talking about STDOUT"
-THat's what I thought, but I have since determined that my PERL scripts CANNOT create a file.  Period.  They can overwrite an existing file iff it already exists with 777 perm's.  That's IT.
That's not normal, is it?

re: "BTW, think that the web server usually runs as user nobody, which means that your CGI is invoked from the web as user nobody,
-on my server, it runs as user WWW, whose permissions I have no idea about.

re: "path problem"
--nope, I just cut the path from the question I posted because it was a long path.  But it was there in the real script.  No dice.

re: "error-checking; At least you'll be sure that it's the open() call which is failing.
--thanks, good advice, and I did add some error checking.  It is indeed the open call that is failing.  Even if I put the script in a directory that is world read/writable, and I call 'open(FILEHANDLE, ">scratch.txt") || print "Error!"' it will run fine from the command line.  But if I run it from the web and scratch.txt doesn't already exist, then I see "Error!".  If scratch.txt does exist and has world-write perms, then the script works ok.  Even over the web.  
0
Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

 
LVL 5

Expert Comment

by:julio011597
ID: 1828279
Hi back,

i must admit i've never heard of such a thing! i mean, not being able to create a file may be reasonable, and it's just a matter of setting up right directory permissions (755 would be enough to prevent creating a new file by the generic user, as WWW probably is); this sounds like if your sysadmin has done something _very_ tricky to system settings and/or web server settings: preventing a pipe to work.

I'm talking about pipes because the only thing that comes to mind is that your cgi is not allowed to spawn subprocesses.

Just a suggestion: go with 'open(...) || print "Error: $!"' in your script; this should tell you what went wrong.

If you cannot solve the bundle, try also talking to your sysadmin; maybe (s)he can tell you something you didn't were aware of.

-julio
0
 
LVL 5

Expert Comment

by:julio011597
ID: 1828280
Hi back,

i must admit i've never heard of such a thing! i mean, not being able to create a file may be reasonable, and it's just a matter of setting up right directory permissions (755 would be enough to prevent creating a new file by the generic user, as WWW probably is); this sounds like if your sysadmin has done something _very_ tricky to system settings and/or web server settings: preventing a pipe to work.

I'm talking about pipes because the only thing that comes to mind is that your cgi is not allowed to spawn subprocesses.

Just a suggestion: go with 'open(...) || print "Error: $!"' in your script; this should tell you what went wrong.

If you cannot solve the bundle, try also talking to your sysadmin; maybe (s)he can tell you something you didn't were aware of.

-julio

P.S. if you make it work, would you mind telling how?!!
0
 

Author Comment

by:cprice
ID: 1828281
If you would like to e-mail me your e-mail address, mine is cgprice@austin.ibm.com.

Something very strange is definitely going on.  I have send numerous e-mails to my webmaster but they have thus far (>1week) gone unanswered.

Just so you know, this wasn't restricted to pipes.  I could issue the simple command 'open(FOO, ">scratch.txt")', and, unless scratch.txt existed already AND was 777, I would get an error.  I followed your suggestion about using $! in my error message, and the error message that I keep getting is "Quota exceeded."  However, I am allotted 10 MB of disk space, and my server has a 'diskused' command to report how much space I'm using and I'm only using 3.5 megs.

OOOOOHHHHHH I think I just figured it out!!! I betcha user WWW has reached his disk quota!!!!!


0
 
LVL 5

Expert Comment

by:julio011597
ID: 1828282
Sure, the script is running as user WWW.

Exceeding disk quotas may prevent a user to have access to any resources that need disk space or i-nodes. Wheter this could be the case with a pipe too, depends on the OS and on which file systems the admin has turned quota on (anyway, they must not be so skilled).

Anyway, now it's your ISP turn... you could menace them with a mass mail bombing! ;-)

Good luck, julio

julio@webzone.it
0

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Introduction This tutorial will give you a fast look what you can do with WhizBase. I expect you already know how to work with HTML at least, and that you understand the basics of the internet and how the internet works. WhizBase is a server-s…
This article is meant to give a basic understanding of how to use R Sweave as a way to merge LaTeX and R code seamlessly into one presentable document.
The viewer will learn how to create and use a small PHP class to apply a watermark to an image. This video shows the viewer the setup for the PHP watermark as well as important coding language. Continue to Part 2 to learn the core code used in creat…
In this fourth video of the Xpdf series, we discuss and demonstrate the PDFinfo utility, which retrieves the contents of a PDF's Info Dictionary, as well as some other information, including the page count. We show how to isolate the page count in a…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now