Re: Why does fpathconf give "bad file descriptor"?

Could it be returning zero? The proper usage is

defined( $sz = fpathconf($wd, _PC_PIPE_BUF) )
   or die "fpathconf(pipe): $!\n";
[download]

Update: Not quite. As ReturnOfThelonious points out, the function appears to expect a file number. The proper usage is actually

defined( $sz = fpathconf(fileno($wd), _PC_PIPE_BUF) )
   or die "fpathconf(pipe): $!\n";
[download]

Comment on Re: Why does fpathconf give "bad file descriptor"? Select or Download Code

Replies are listed 'Best First'.
Re^2: Why does fpathconf give "bad file descriptor"? by madscientist (Novice) on Mar 31, 2010 at 19:36 UTC
I did realize that it might be returning 0 and modified my code to check for defined values but that didn't make any difference... plus it's really not possible for a pipe to have a buffer size of 0 so that's just not a valid result. As stated, I need to use fileno(). So simple... in hindsight Thanks all!	[reply]
Re^3: Why does fpathconf give "bad file descriptor"? by ikegami (Patriarch) on Mar 31, 2010 at 19:49 UTC
it's really not possible for a pipe to have a buffer size of 0 fpathconf says it returns "the maximum number of bytes which will be written atomically to a pipe." I took that to mean it returns the available buffer size. The documentation isn't clear, but I'm favouring your interpretation. My local man page simply says "returns the size of the pipe buffer", confirming your interpretation.	[reply]
Re^4: Why does fpathconf give "bad file descriptor"? by madscientist (Novice) on Apr 01, 2010 at 04:25 UTC
The POSIX spec says: The fpathconf() and pathconf() functions shall determine the current value of a configurable limit or option (variable) that is associated with a file or directory. I'm quite confident this is intended to be the maximum available for that type of object, not the remaining space left for that particular instance of the object.	[reply]