Redirect STDERR to file with flock

[Rene Scheibe]

Normal redirection of for example STDERR to a file is clear.
open(STDERR, $filename) || die;
select STDERR;
$| = 1;
# some stuff...
close STDERR || die;

But how about flock()ing this file?
Can I do:
flock(STDERR, LOCK_EX);

I am not use about the effects on such 'special filehandles'.

Thanks
Rene

 

[Tassilo v. Parseval]

Also sprach Purl Gurl:

Rene Scheibe wrote:

(snipped)





If you are a talented programmer, you know of your machine's
file locking numbers. If not, you may use the Fcntl module
designed for the less talented. Neither method is a guarantee
of file locking but both are relatively reliable.

Neither method? I only see one method here, namely through flock().

And, well, I don't understand this part about reliability either. If the
call to flock(2) was successful, it's pretty safe to assume that the
file is now locked. However, depending on the platform a lock may be
advisory in which case any process may just as easily ignore it. But any
process that itself tries to acquire a flock on a locked file will be
blocked until the initial flock is released.

And, eventually, there are those platforms that don't even have a
flock() system-call, such as Win95/98/ME.

You should not experience any problems for typical usages. Fcntl will
provide better portability.

Indeed. And yet, it's only a fraction of what should be done. Locking of
files can become a real nuisance when different platforms are taken into
account. Often you end up implementing various mechanisms (flock()
versus dot-file locking via sysopen()) to satisfy most machines.

Tassilo

 

[Tassilo v. Parseval]

Also sprach Purl Gurl:

I count two. Perhaps between your two hands, you only have one finger
and no thumbs. Typing must be a very busy activity for you.

You are right insofar as I don't have fingers between my hands. I have
my fingers attached to them.

I still can't see them. Please exhibit those two different methods so
that even I get it. You are actually aware that

flock FILE, 2;

and

flock FILE, LOCK_EX;

are the identical methods and compile to the very same optree on those
machines where LOCK_EX == 2?

Why are you parroting what I wrote about "relatively reliable?"

I am not. Instead I am pointing out that the term 'reliable' is wrong
here. It has nothing to do with reliable. It's perfectly reliable (or as
reliable as any software can get) and predictable when knowing the
mechanisms behind locking.

My previous article provides a reference for Win32 file locking.

I was talking about flock(2). Does your article provide an example of
how you use flock(2) on Windows (the versions I mentioned above, not
necessarily NT/2000/XP)? Will this compile on your machine?

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/file.h>
#include <fcntl.h>
#include <stdio.h>

int main (void) {
int fd = open("file", O_RDONLY);
if ((flock(fd, LOCK_SH)) == 0)
return 0;
else {
perror("flock");
return 1;
}
}

You should pay less attention to your single finger and pay more
attention to your reading comprehension skills.

Probably.

Tassilo

 

[James Willmore]

Normal redirection of for example STDERR to a file is clear.
open(STDERR, $filename) || die;
select STDERR;
$| = 1;
# some stuff...
close STDERR || die;

But how about flock()ing this file?
Can I do:
flock(STDERR, LOCK_EX);

I am not use about the effects on such 'special filehandles'.

Are you trying to prevent blocking writes? Maintain an error log file
for a script that runs multiple times?

Just a suggestion - if you want to log errors from your script in a
central place, why not use the system log file? If you're on a *NIX
system, you could use the PID as the unique quantifier for the
messages. If you're on a WIN32 system, I'm thinking there's a similar
mechanism in place.

Again, just a suggestion. I realize it doesn't 'fit the bill' for the
OP ... maybe I'm reading into it.

HTH

Jim