In your first system call, "fasta32.exe" is supposed to write its output to "out.fasta", but before running that system call, you open that file name for input with the file handle "FASTA". You should run the system call first -- and check the return value (the exit status from the sub-process) -- then open the file to read it in perl. Since you assign the return value to $return, you would check for bad exit status like this:
The other problem is this embedding of while loops:if ( $return >> 8 ) { warn "fasta32.exe ended with non-zero exit status\n"; }
The problem there is that once the inner while loop is reached, it will eat up everything in the file that hasn't been read yet. Once the inner while loop finishes, you will have reached the end of the file, and there will be nothing left for the outer loop to read.while (<FASTA>) { ... if ( /(\d+\.\d+)% identity/ ) { ... if ( $per > $cut ) { ... while (<FASTA>) { ... } ...
And then there's some really strange stuff in that inner while loop: you seem to be trying to seek backwards on the FASTA file handle, but how can you be sure that seeking backwards by 100 bytes is the right thing to do? Also, after you run "fasta32.exe" again, sending it's output to a file called "compare.fasta", you open that file, but you never read from it.
And then, there may also be some trouble with some of your regexes. Have you tested them against various lines of your data files to make sure they match when you want them to (and do not match when you do not want them to)?
For example, />>(.{4,6})(.*)/ seems a little odd: if only 4, 5 or 6 characters (including spaces and CRLF) follow the double-angle-bracket, this match will succeed, and $2 will be empty. If there are more than 6 characters, everything from the 7th on (including spaces and CRLF) is assigned to $2. Is this your intention?
You should start by laying out a description of your task and algorithm in clear, specific terms (e.g. always refer to particular file names, not "a file" or "another file"), and identify a sequence of distinct steps. Try doing the steps manually first, to make sure you have them specified correctly and in the proper order. Create the script in pieces and work with each piece until it does its job the right way for a given step (or some tightly bound subset of steps).
If you build the pieces correctly, you'll have more flexibility in assembling them into "higher-order" tools -- not just the one you're working on now. Also, if a particular piece gives you a lot of trouble, it will be easier to post the smaller chunk of code, together with a small sample of the data that is problematic.
update: forgot to mention: if you're going to be reading things like file names and numeric values from STDIN -- and for that matter, if you're going to be manipulating lines of data that you read from a text file -- you need to start using "chomp", to remove the CRLF from the end of each string.
In reply to Re: OUTPUT FILE
by graff
in thread OUTPUT FILE
by FarTech
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |