I am using the standalone version of BLAT for one of my school projects. The standalone version is run through a python CGI file in a web server hosted by our class server. When the client-side HTML form sends a query sequence to the python CGI on the server-side, the CGI file writes the query sequence to a file in the working directory. The CGI then runs the BLAT standalone version using os.system() with the following command:
blat_standalone/blat/blat -stepSize=5 -repMatch=2253 -minScore=20 -minIdentity=0 GRCh38_chrom1.fna query.fa output.psl
The blat_standalone version is saved in the working directory. I have also made sure that the working directory (the directory in which the python cgi is saved) is world accessible (i.e. permission of the directory is 777)
However, after running the web application, I got an "output.psl" file in the directory that was empty and also write-protected. When I removed the output.psl file and ran BLAT on command line (i.e. not through python CGI) using the above noted command, I had no problem running the program and a new output.psl file was created with correct results. When I changed the permission of this output.psl file (the one created through command line and has correct results) to 774 and reran the web application, the output.psl file was overwritten and becomes empty again.
I also recorded the exit code of the command when it was ran in python CGI and it is 65280.
The permission of the output.psl file created through python cgi is as follows:
-rw-r--r-- 1 daemon apache 0 May 10 01:05 output.psl
What did I do wrong?
Depends on your web server, but look at your server's error logs. This can be a fast way to troubleshoot cgi-bin problems. Permissions can be painful to deal with, especially if a process is executed by the user account associated with the server, e.g., Apache or Nginx. Things that work for your account may not work for others, depending on where you are writing results to, or reading input from.
thanks. Unfortunately, I have no access to the server's error log
I suspect that you'll find it much easier to troubleshoot server-side problems by accessing the error logs. It will very likely help you zero in on what is wrong.