cprice
asked on
Sending a GIF via <IMG SRC="perl_script.cgi"> (using FLY or gd)
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
-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.
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
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
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?!!
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?!!
ASKER
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!!!!!
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!!!!!
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
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
ASKER