Re: Difference between File Handles and File Descriptors in function parameters.

One downside I can think of here is, if you accept a passed-in filehandle, and use it directly, then your method will be altering the file position of the caller's handle. Your method will also be subject to the current position and any settings on the caller's filehandle, so "printRestOfFile()" might be a more accurate name than "printfile()" for your sub as shown.

By accepting a descriptor, you would then make your own handle, with whatever settings that are appropriate for your method, only affecting your method, not the caller. This becomes much more of a concern when you're abstracting something, rather than just creating a worker sub for a structured script. Do no harm to your caller and all that.

--Dave

Comment on Re: Difference between File Handles and File Descriptors in function parameters.

Replies are listed 'Best First'.
Re^2: Difference between File Handles and File Descriptors in function parameters. by tchrist (Pilgrim) on Aug 14, 2011 at 19:36 UTC
One downside I can think of here is, if you accept a passed-in filehandle, and use it directly, then your method will be altering the file position of the caller's handle. That’s not a bug, it’s a feature! It has to work this way, because otherwise you will get mangled I/O. It is critical that the seek points be the same or else you get overwrites and duplicate reads on seekable devices. You will also incur behavioral differences between running on nonseekable devices like sockets, pipes, and ttys then when running on seekable devices like disk files. Completely misery and chaos would ensue. Never assume that you alone have the sole copy of a particular kernel file descriptor. If you are relying on that, you are almost certainly broken in some way. Passed in descriptors are quite possibly duplicated in another process; with the std streams, this is virtually guaranteed. In fact, even if you open a file yourself, you cannot know you have the only copy because you cannot guarantee that you are not yourself a clone, since any function that you call after the open is welcome to fork itself an identical process. You cannot know you are who you think you are — or least, not easily. Welcome to Unix, and have a nice day. --tom	[reply]

Replies are listed 'Best First'.

Re^2: Difference between File Handles and File Descriptors in function parameters.
by tchrist (Pilgrim) on Aug 14, 2011 at 19:36 UTC

One downside I can think of here is, if you accept a passed-in filehandle, and use it directly, then your method will be altering the file position of the caller's handle.

That’s not a bug, it’s a feature!

It has to work this way, because otherwise you will get mangled I/O. It is critical that the seek points be the same or else you get overwrites and duplicate reads on seekable devices. You will also incur behavioral differences between running on nonseekable devices like sockets, pipes, and ttys then when running on seekable devices like disk files. Completely misery and chaos would ensue.

Never assume that you alone have the sole copy of a particular kernel file descriptor. If you are relying on that, you are almost certainly broken in some way. Passed in descriptors are quite possibly duplicated in another process; with the std streams, this is virtually guaranteed.

In fact, even if you open a file yourself, you cannot know you have the only copy because you cannot guarantee that you are not yourself a clone, since any function that you call after the open is welcome to fork itself an identical process. You cannot know you are who you think you are — or least, not easily.

Welcome to Unix, and have a nice day.

--tom

[reply]