awohld has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to read an Excel file and I'm getting an error:
Software error: Could not open Excel spreadsheet file 'test.xls': Bad file descriptor +at /usr/lib/perl5/site_perl/5.8.6/Spreadsheet/BasicRead.pm line 306. For help, please send mail to the webmaster (user@localhost.localdomai +n), giving this error message and the time and date of the error.
I can open the Excel file in windows and it's okay.

Here's my read code straight out of the example in CPAN:
#!/usr/bin/perl use CGI::Carp qw(fatalsToBrowser); use CGI; use Spreadsheet::BasicRead; my $cgi = CGI->new(); print $cgi->header; my $xlsFileName = 'test.xls'; my $ss = new Spreadsheet::BasicRead($xlsFileName) || die "Could not open '$xlsFileName': $!"; my $row = 0; while (my $data = $ss->getNextRow()) { $row++; print join(',', $row, @$data), "\n"; }
And here's my XLS file test.xls

Is it a problem with Spreadsheet::BasicRead or with my XLS file? Is there a workaround for this?

Replies are listed 'Best First'.
Re: Spreadsheet::BasicRead - Open XLS Error???
by davidrw (Prior) on Sep 23, 2005 at 03:51 UTC
    File permissions? is the test.xls in the same directory as the cgi file? Does whatever use the cgi run as (IIS user?) have permissions to read the xls file? What happens if you run the scrpit from the command-line?

    If that doesn't identify the problem, can you open it directly with Spreadsheet::ParseExcel (which is what Spreadsheet::BasicRead wraps).

    Related good node with lots of reference material: Index of Spreadsheet FAQs
      It's not permissions or anything and it's in the same directory as the CGI script. I can save a excel file straight out of WIN2K and use it exactly in the same manner as the text.xls that is posted above and it works fine.

      The test.xls is output from another computer program which can be opened fine by excel, so there's some kind of nuance with test.xls and test.xls appears to be compliant with MS-EXCEL. So I'm wondering if there's something with "Spreadsheet" that makes it bug out when looking at test.xls.

      What's a "Bad File Descriptor"?

      When I use Spreadsheet::ParseExcel I also get errors, here's my code:
      #!/usr/bin/perl -w use strict; use Spreadsheet::ParseExcel; my $oExcel = new Spreadsheet::ParseExcel; die "You must provide a filename to $0 to be parsed as an Excel file" +unless @ARGV; my $oBook = $oExcel->Parse($ARGV[0]); my($iR, $iC, $oWkS, $oWkC); print "FILE :", $oBook->{File} , "\n"; print "COUNT :", $oBook->{SheetCount} , "\n"; print "AUTHOR:", $oBook->{Author} , "\n" if defined $oBook->{Author}; for(my $iSheet=0; $iSheet < $oBook->{SheetCount} ; $iSheet++) { $oWkS = $oBook->{Worksheet}[$iSheet]; print "--------- SHEET:", $oWkS->{Name}, "\n"; for(my $iR = $oWkS->{MinRow} ; defined $oWkS->{MaxRow} && $iR <= $oWkS->{MaxRow} ; $iR++) { for(my $iC = $oWkS->{MinCol} ; defined $oWkS->{MaxCol} && $iC <= $oWkS->{MaxCol} ; $iC++) { $oWkC = $oWkS->{Cells}[$iR][$iC]; print "( $iR , $iC ) =>", $oWkC->Value, "\n" if($oWkC); } } }
Re: Spreadsheet::BasicRead - Open XLS Error???
by Corion (Patriarch) on Sep 23, 2005 at 06:21 UTC

    You are using a relative path to open the Excel file. That is wrong. Your CGI program may have a different current directory when it is run.

      With a direct path I get the same error. Also I have my CGI script in the same directory as my Excel file.
        While your CGI script may be in the same directory as the Excel file, the script may be running with a different directory as its current working directory. You can check this by adding:
        use Cwd; print cwd(), $/;
        to your CGI script.

        Additionally, your CGI script may be run as a user with less permissions on the system than you have. This is actually extremely common, especially to the directories which contain CGI scripts. This is a security measure against unauthorized people on the internet reading the code for your CGI scripts.

        I would recommend running the script from the Windows commandline and seeing if you still get the same error. If you don't, then it's a problem with how the webserver is running your script. If you get the same error, then it's something we can help investigate.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?