Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Writes to frile not being committed 1

Status
Not open for further replies.

blues77

Programmer
Jun 11, 2002
230
0
0
CA
Hello,

I'm trying to write to some text files but it doesn't appear to be writing to the files UNLESS I use the >> operator (append operator) when opening the file. Can anyone tell me what is going on? Below is my code which writes fine when I use the >> operator. If I remove it though nothing gets written to the file.

All help is appreciated!

Code:
use strict;

open(SOURCE, $ARGV[0]);

if( -e "labels.txt")
{	
	if (-w "labels.txt")
	{
		open(LABELS, ">>labels.txt");
	}
	else
	{
		print "File labels.txt is not wrtitable\n";
		exit();
	}
}
else
{
	print "File labels.txt does not exist.  Please create this file first and then run this script\n";
	exit();
}


if( -e "tables.txt")
{	
	if (-w "tables.txt")
	{
		open(TABLES, ">>tables.txt");
	}
	else
	{
		print "File tables.txt is not wrtitable\n";
		exit();
	}
}
else
{
	print "File tables.txt does not exist.  Please create this file first and then run this script\n";
	exit();
}


if( -e "columns.txt")
{	
	if (-w "columns.txt")
	{
		open(COLUMNS, ">>columns.txt");
	}
	else
	{
		print "File columns.txt is not wrtitable\n";
		exit();
	}
}
else
{
	print "File columns.txt does not exist.  Please create this file first and then run this script\n";
	exit();
}


while (<SOURCE>)
{
	chomp;	
	$_ =~ s/ //g;
	if($_ =~ m/:\s*(.+)\s*\(.+\."(\w+)""(\w+)/)
	{
		print "Extracting information for $_\n";
		
		print LABELS "$1\n";
		print TABLES "$2\n";
		print COLUMNS "$3\n";
	}		
}

#need to close the file in order to 'commit the write operations
close SOURCE;
close LABELS;
close TABLES;
close COLUMNS;
 
Are you sure?
When I executed the script it worked.
Try to change the appended file a bit and after exec version with > u will see that changes are gone.
If you haven't the files of course nothing will happen because u check for that.

Corwin
 
Yeah it's not writing to the file. I added the text "This is a test" to the labels.txt file and ran the script, which should have overwritten the contents of the file but the text I entered is still there.
 
No idea dude.
I tried it again and still works fine. :)

Corwin
 
are you sure u have the .txt file in the same directory as your script
 
also you should also open your files like so..

open(LABELS, ">>labels.txt") or die "cannot open labels.txt $!";
 
I figured it out. I needed to put a > before the filename when opening it.
 
Opening with neither > nor >> opens a file in read mode.

I've had a hack at your code
Code:
use strict;

open(SOURCE,    $ARGV[0]    ) or die "$ARGV[0]: $!";
open(LABELS,  ">labels.txt" ) or die "labels.txt: $!";
open(TABLES,  ">tables.txt" ) or die "tables.txt: $!";
open(COLUMNS, ">columns.txt") or die "columns.txt: $!";

while (<SOURCE>)
{
    chomp;    
    s/ //g; [red]# ?[/red]
    if( /:\s*(.+)\s*\(.+\."(\w+)""(\w+)/ ) [red]# ?[/red]
    {
        print "Extracting information for $_\n";
        print LABELS "$1\n";
        print TABLES "$2\n";
        print COLUMNS "$3\n";
    }        
}

The die will print to STDERR rather than STDOUT but including $! will differentiate between non-existance or lack of permission so you don't need to do that explicitly.

I've lost the explicit references to $_ - it's only there so that you can use it implicitly and any perl coder will be more comfortable with the idiom.

I've also lost the explicit closes. Perl will happily flush and close all open filehandles on exit.

I have several worries with your regex. On the preceding code line you have removed a single space (the first on the input line), but any such space is already incorporated into the longer regex. If the first space occurs before the colon then it's irrelevant - the regex will ignore it. If it occurs after the colon, then it will get swallowed by one of the \s* tokens in your regex as * matches zero or more characters.

On the subject of the second regex, they way that it is coded is very inefficient. The engine will look for and match the first colon. It will then look for and match any spaces. The next token is .+ which matches all the
rest of the line.

This is followed by \s*, so the engine will backtrack through the line until it finds some spaces that it could use to match. It will almost certainly find the wrong ones (it's starting from the wrong end!) so it will have to backtrack again later to get this right.

The next token is another .+ so, again, perl will match the rest of the line and again have to backtrack before it can match the following token. At this point, it has to backtrack the first one again, and will get it wrong again...

I'm sure you get the picture. Using repeated .+ or .* tokens in a regex condemns you to needlessly appalling performance.

Without seeing some sample input, I can't do more than guess at a better solution so here's my guess: Your first .+ should probably be a \S+ (one or more not-spaces)and your second one should probably be [^.]+ (one or more not-periods). Am I right?

Yours,

fish

[&quot;]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.[&quot;]
--Maur
 
Yeah you are right. Thanks for the suggestions and you're help!

 
you are welcome.

f

[&quot;]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.[&quot;]
--Maur
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top