[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000915: 20000915: running gempak from CGI:part 2



>From: address@hidden (Chris Hennon)


Chis,

The problem could be the "uname" command in the Gemenviron script, which
may not be found using the bare bones environment of the CGI.

Typically, uname is in /usr/ucb on solaris.
You probably want to set a little PATH in your script before
the source command. That way, any commands you use will be found.

Let me know if this is indeed the problem. If uname is the
problem, then that would prevent the $GEMEXE directory from being
properly defined.

Steve Chiswell
Unidata User SUpport



>Organization: UCAR/Unidata
>Keywords: 200009160321.e8G3Ldb25820

>Steve -
>
>I confirmed that my script is indeed being invoked.  Now it seems to be
>choking when I try to source the Gemenviron file:
>
>#!/bin/csh -f
>source /usr/local/gempak/NAWIPS-5.4/Gemenviron
>setenv DISPLAY twister:1.0
>
># Create a temporary work directory
>set WORK=/tmp/.viewer.$$
>mkdir $WORK
>cd $WORK
>
>exit(0)
>
>That script does not create the directory .viewer.3453.  But if I
>comment out the source statement, the directory is created successfully
>(but my gempak programs don't appear to run).  Any thoughts?  I verified
>that the Gemenviron script is r-x for all.
>
>Thanks.
>
>Chris
>
>================================================
>| Chris Hennon        Ohio State University   |
>| Tropical Meteorology      address@hidden   |
>|                                              |
>| Dept of Geography   Office: 1155 Derby Hall  |
>| 1036 Derby Hall     Phone : (614) 292-2704   |
>| Columbus, OH 43210  Fax   : (614) 292-6213   |
>================================================
>
>On Fri, 15 Sep 2000, Unidata Support wrote:
>
>> 
>> Chris,
>> 
>> First, your 2 system() calls will not have the desired effect, since
>> the cd command will not be inherited by the program.
>> This would probably be something that the script itself would have to
>> perform internally to set up its own working directory.
>> 
>> The second thing to be aware of is that asking the user "nobody" to
>> connect to your Xserver on twister:0.0 will require that you have
>> allowed "xhost + twister" , so that this users will be allowed to connect.
>> 
>> But those things above aside, if your program cannot execute you script,
>> then that is a different problem.
>> 
>> I have an example at:
>> http://www.unidata.ucar.edu/staff/chiz/trajectory/inter_traj.html
>> 
>> This html calls a CGI which accepts a lat/lon pair, and uses them to
>> call my csh script which draws the trajectory using GEMPAK.
>> 
>> The cgi invokes the csh script through /bin/csh, since it is passing
>> command line arguments to the shell:
>> 
>> sprintf(line,"/bin/csh /www/staff/chiz/trajectory/make_traj.csh %s \0",
>>            entries[x].val);
>> system(line);
>> printf("<A HREF=\"http://www.unidata.ucar.edu/staff/chiz/trajectory/forw_int
> er.gif\">\n");
>> printf("<IMG ALT=\"Interactive trajectory [image]\" 
>>    SRC=\"http://www.unidata.ucar.edu/staff/chiz/trajectory/forw_icon.gif\"; >
> \n");
>> printf("</A>\n");
>> 
>> 
>> I actually use the postscript driver to draw from the script (To avoid X ser
> vers,
>> but Xvfb would work too!), and then convert the postscript to gif at the end
> .
>> 
>> To test whether your system command is actually invoking your csh script,
>> I'd suggest a simple script like:
>> 
>> #!/bin/csh -f
>> date > /tmp/testcgi.$$
>> exit(0)
>> 
>> If that fails, then you have to make sure that "nobody" is allowed to get to
>> the csh location (which means that the "other" permissions have to be allowe
> d
>> on your read and execute bits on the directory and script. The server
>> log would also help in tracking this problem down.
>> 
>> One thing you cannot do from system is your command:
>> /home/chennon/output/sst_000830_all.csh > /home/chennon/logs/viewer.log
>> since the ">" is a csh directive, and your C program system() command knows 
> nothing
>> about being in a csh. If you need to send output to a log, then set
>> that up inside the script. You also need to watch out for "noclobber" being
>> set, since that will not allow you to overwrite the existing log. And, if yo
> u
>> have done testing as yourself. then you need to make sure you remove any log
> s
>> that the user "nobody" would have to overwrite.
>> 
>> You show below:
>> system("/home/chennon/output/sst_000830_all.csh");
>> which should be ok....not the previous use of redirection, but
>> as I mentioned, your directory and shemm script must have other mode r-x.
>> If not, then you need "chmod 755".
>> 
>> 
>> If you have any more info/questions, let me know.
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> 
>> 
>> >From: address@hidden (Chris Hennon)
>> >Organization: UCAR/Unidata
>> >Keywords: 200009151434.e8FEYib01065
>> 
>> >Steve -
>> >
>> >I've done some more testing and it appears that my CGI program can't even
>> >invoke a simple csh script like:
>> >
>> >#!/bin/csh
>> >
>> >echo Hi
>> >
>> >exit
>> >
>> >So maybe this isn't a gempak issue - do you have any insight as to whether
>> >this could be a server issue or something else?  Thanks
>> >
>> >Chris
>> >
>> >
>> >---------- Forwarded message ----------
>> >Date: Thu, 14 Sep 2000 18:25:20 -0400 (EDT)
>> >From: Chris Hennon <address@hidden>
>> >To: address@hidden
>> >Subject: running gempak from CGI
>> >
>> >Steve -
>> >
>> >I have a CGI program which uses a system call to run a csh program that
>> >produces a gempak map.  The call from the CGI program is:
>> >
>> >/home/chennon/output/sst_000830_all.csh > /home/chennon/logs/viewer.log
>> >
>> >The script, which uses gdedit and gdcntr, works fine from the command
>> >line when the inputs are manually specified by myself.  It is meant to
>> >produce a gif image using input that the user gives it through the HTML
>> >form.  But when I test it by using the HTML form and submitting the
>> >request, the gif is not produced and the log file has nothing in it.  The
>> >script itself looks like:
>> >
>> >#!/bin/csh
>> >#---------------------------------------------------
>> >#
>> >#   This script dynamically created by viewer.cgi
>> >#
>> >#---------------------------------------------------
>> >source /usr/local/gempak/NAWIPS-5.4/Gemenviron
>> >setenv DISPLAY twister:0.0
>> >
>> >gdedit << EOF
>> > GDEFIL  = /home/chennon/data/sst/sst_000830.gem
>> > GDFILE  = /home/chennon/grids/sst.grd
>> > GPACK   =
>> >r
>> >
>> >e
>> >EOF
>> >
>> >gdcntr << EOF
>> > GDATTIM  = 000830/0000
>> >
>> >etc....
>> >
>> >r
>> >
>> >e
>> >EOF
>> >gpend
>> >
>> >As you can infer the script is created on the fly according to user inputs
>> >from the HTML form.  I was looking through the user support archives and
>> >noticed that this problem seems similar to the 19990324:MOS data
>> >correspondence, where you suggested that gempak needed a place to write
>> >last.nts and gemglb.nts.  I tried creating a temp directory and making the
>> >owner "nobody", which is the default user that is making the image from
>> >the HTML page. I then put in a command in my CGI script before the system
>> >call, i.e.
>> >
>> >system("cd /home/chennon/temp/");
>> >system("/home/chennon/output/sst_000830_all.csh");
>> >
>> >but I still have the same problem (no image created).  Do you have any
>> >ideas?  Thanks.
>> >
>> >Chris  
>> >   
>> >
>> >================================================
>> >| Chris Hennon             Ohio State University   |
>> >| Tropical Meteorology      address@hidden   |
>> >|                                              |
>> >| Dept of Geography   Office: 1155 Derby Hall  |
>> >| 1036 Derby Hall     Phone : (614) 292-2704   |
>> >| Columbus, OH 43210  Fax   : (614) 292-6213   |
>> >================================================
>> >
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>