Here's one:

unshift @ARGV, $rfile;
while( <> ) {
  # ....
}
[download]

Or how about this:

use Tie::File;
tie my @array, 'Tie::File', $rfile or die;
[download]

Here's another variation on the @ARGV theme...

#!/usr/bin/perl -p
BEGIN{ 
    $rfile = 'myfile.txt';
    unshift @ARGV, $rfile;
}
[download]

Update:
By the way, I won't attempt to justify any of these abominations other than to state the obvious; they're just for fun.

I'm pretty fond of the diamond operator and just feeding a filename to the script when it's called.

#!/usr/bin/perl

while (<>) {
    # do stuff
}
[download]

and . . .

$ script.pl filename

I guess it's the KISS principle applied to getting data from a file.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

The sysopen call is sometimes useful for its full range of open modes, and the ability to set file permissions when the file is created.

sysopen FILEHANDLE,FILENAME,MODE,PERMS
[download]

If you fool around with that, use Fcntl;. That lets you take your program to another machine without worrying about differing numeric values for the system constants.

I use sysopen when I want my scripts to play nicely with each other, and observe locking. eg:

use Fcntl qw(:DEFAULT :flock);

sysopen(OUT, $file, O_WRONLY | O_CREAT)
   or die "Cannot open $file for writing:$!\n";
flock(OUT, LOCK_EX)
   or die "Cannot get a lock on $file:$!\n";
[download]

(That example is pretty much straight out of the book)

Cheers,
Darren :)

system( "$^X -pl -e 's/foo/bar/g' $rfile $afile" );
[download]

exec "$0 $rfile $afile" unless @ARGV;
while (<>) {
    # Do whatever you want here.
}
[download]

Object-oriented (adapted from IO::File synopsis):

use IO::File;

$fh = IO::File->new("< file");
$fh = IO::File->new("file", "r");
$fh = IO::File->new("file", O_WRONLY|O_APPEND);
[download]

oooo....i like that...that's pretty...and clean.

my question is...what kind of modules are there for operating systems that don't support file locking?

I know there's quite a few methods for checking and adapting for such, but has anyone put together a module encompassing these routines?

meh.

According to perlport, flock is available on WinNT (and later). You should be able to check Config for d_flock.

> perl -MConfig -le "print $Config{d_flock}"
define
[download]

No guarantees on how good that is for protecting against anything other than other Perl programs using flock. You might have to use Win32API::File for more direct control.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Windows supports both advisory and mandatory file locking, and can perform a non-blocking lock check.

It even uses mandatory exclusive locks by default. You can relax the lock and allow others to do any combination of the following: delete the file (FILE_SHARE_DELETE), read from the file (FILE_SHARE_READ) and write to the file (FILE_SHARE_WRITE).

Finally, Perl's flock works perfectly fine in Windows, including LOCK_NB.

open(FILE, "cat $file |") or die "Cannot read '$file': $!";
[download]

I helped a number of people with this trick back in the day, but its time has is long past now. Today you can compile Perl to understand how to handle large files (which you couldn't easily do with, say, Perl 5.004), and this setting is on by default.

The disadvantages are numerous. You require an extra process, you have to worry about escaping special characters in the filename, error handling is more complex, etc, etc, etc. The only remaining advantage that I can think of for this method is that the additional parallelism might allow you to reduce the effect of disk latency if you were doing simple processing of a large file off of a slow disk. But that should only make a big difference if I/O time was close to processing time, and I'd need to see a benchmark before I'd believe it really was helping.

To start things off, here is the trivial, fairly obvious case:

open my $fh, $rfile, 'r';
[download]

open my $fh, 'r', $rfile ;
[download]

open my $fh, 'r', $rfile ;

Should read

open my $fh, '<', $rfile;
[download]

And shame on those who upvoted the parent node... :-)

How come you don't mention the most obvious solution, `cat $filename`?

use Win32::OLE;

my $fso = Win32::OLE->new('Scripting.FileSystemObject');
my $ts = $fso->OpenTextFile($rFile);

while (!$ts->AtEndOfStream) {
  print $ts->ReadLine,"\n";
};
[download]

Disadvantage: Only works with Win32.

What? No one's mentioned the swiss army chainsaw of of IO operations, IO::All ?

From the docs:

use IO::All;
my ($io, $contents);
$io = io 'file.txt';
$contents < $io;
[download]

# manipulate $contents to write it back out:
$contents > $io;
$some_extra_bit >> $io;
[download]

  my $filename = 'thefile.txt';
  my $pid = open(FH, "-|");
  if (not defined $pid) {
    die "cannot fork: $!; bailing out";
  }
  if (! $pid) {
    exec('/bin/cat', $filename);
  }
  while (<FH>) { ... }
[download]

@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
[download]

TIMTOWTDI, true. Most of them may not be *wrong*, necessarily, but many of them aren't great. They may be clumsy, difficult to use, so obscure that they're nearly impossible to maintain (even the author might not remember quite what he/she intended, a few months down the pike), security holes, inefficient, and so on.

I suspect that while TIMTOWTDI, there is usually a very limited number of optimum ways to do it - often that number being one.

Well, I agree that though there are many ways to do things, there are occasionally only a few (or a single) good way(s) to do it. And on the face of things, it would seem obvious that when you want to open a file, you just open it.

I wouldn't want to advocate difficult to read code, and as I mentioned in my own earlier post in this thread, this really is just for fun. But the mental exercise is valuable, I believe. There is nothing wrong with exploring the corners of the language, as long as you take the time to learn why, and why not. A great orator may command a mastery of spoken language that would make doctors and attorneys blush. And certanly he may go to great lengths to personally explore the corners of his language of communication. But in composing a speech, he is going to select words and constructs from his tool chest of expression that meet the needs of his audience, in level of education, field of specialty, as well as degree of entertainment, appropriate level of formality, and efficiency of communication of important ideas.

In coding, there are many such factors to keep in mind. Maintainability (usually but not always an issue), corporate culture for coding style (sometimes, sometimes not an issue), conciseness, efficiency, and so on. The truth is, there may even be an appropriate time to unshift a filename into @ARGV and tap into the diamond operator's power. That's not usually the clearest way to open and read a file. But nobody should go so far as to say it's never appropriate.

...just some food for thought. Now back to the fun at hand.......




Dave