|
Home > Archive > Unix Programming > August 2007 > is a file descriptor a socket?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
is a file descriptor a socket?
|
|
| Frank Cusack 2007-08-23, 1:21 am |
| how can i tell if a given descriptor is a socket? i am just doing
getsockopt() but is there a better way?
-frank
| |
| fjblurt@yahoo.com 2007-08-23, 1:21 am |
| On Aug 22, 5:54 pm, Frank Cusack <fcus...@fcusack.com> wrote:
> how can i tell if a given descriptor is a socket? i am just doing
> getsockopt() but is there a better way?
man 2 fstat. Check the S_IFSOCK in st_mode.
| |
| David Schwartz 2007-08-23, 1:21 am |
| On Aug 22, 5:54 pm, Frank Cusack <fcus...@fcusack.com> wrote:
> how can i tell if a given descriptor is a socket? i am just doing
> getsockopt() but is there a better way?
> -frank
Better in what way? What's wrong with 'getsockopt'?
DS
| |
| Måns Rullgård 2007-08-23, 7:21 am |
| David Schwartz <davids@webmaster.com> writes:
> On Aug 22, 5:54 pm, Frank Cusack <fcus...@fcusack.com> wrote:
>
> Better in what way? What's wrong with 'getsockopt'?
Why care in the first place?
--
Måns Rullgård
mans@mansr.com
| |
| Frank Cusack 2007-08-23, 7:21 pm |
| On Wed, 22 Aug 2007 23:12:41 -0700 David Schwartz <davids@webmaster.com> wrote:
> On Aug 22, 5:54 pm, Frank Cusack <fcus...@fcusack.com> wrote:
>
> Better in what way? What's wrong with 'getsockopt'?
Well, just more to the point. I like fjblurt's pointer to fstat().
Also, on Solaris, this also avoids having to link against libsocket.
Which really isn't a big deal but fewer dependencies are always
better.
-frank
| |
| Frank Cusack 2007-08-23, 7:21 pm |
| On Thu, 23 Aug 2007 08:39:11 +0100 Måns Rullgård <mans@mansr.com> wrote:
> David Schwartz <davids@webmaster.com> writes:
>
>
> Why care in the first place?
Well obviously I want to do something different if the file is a socket. 
This is for a cgi application and for command line debug I want
different output. I know, there's no guarantee that when used with a
webserver the output will be a socket (e.g. webserver might intercept
output to count bytes xmitted), but in my special-purpose case testing
for a socket does what I need.
hmm, could a webserver dup() the socket, fire off the cgi (and not
intercept the output), then when the cgi child dies do an ftell() to
see how many bytes were sent?
-frank
| |
| David Schwartz 2007-08-23, 7:21 pm |
| On Aug 23, 4:07 pm, Frank Cusack <fcus...@fcusack.com> wrote:
> Well obviously I want to do something different if the file is a socket.
Really?
> This is for a cgi application and for command line debug I want
> different output. I know, there's no guarantee that when used with a
> webserver the output will be a socket (e.g. webserver might intercept
> output to count bytes xmitted), but in my special-purpose case testing
> for a socket does what I need.
Why not test if the application is running as a CGI then? For example,
"if (getenv("QUERY_STRING")!=NULL)" or similar.
> hmm, could a webserver dup() the socket, fire off the cgi (and not
> intercept the output), then when the cgi child dies do an ftell() to
> see how many bytes were sent?
Not likely.
DS
| |
| Frank Cusack 2007-08-24, 1:23 am |
| On Thu, 23 Aug 2007 17:07:58 -0700 David Schwartz <davids@webmaster.com> wrote:
> On Aug 23, 4:07 pm, Frank Cusack <fcus...@fcusack.com> wrote:
>
> Why not test if the application is running as a CGI then? For example,
> "if (getenv("QUERY_STRING")!=NULL)" or similar.
well QUERY_STRING wouldn't work because i invoke it the same way the
webserver would as far as arg passing goes. but that's a good idea in
general; i could test for SERVER_NAME or some other var.
-frank
| |
| Barry Margolin 2007-08-24, 1:23 am |
| In article <m2ejhtvoig.fsf@sucksless.local>,
Frank Cusack <fcusack@fcusack.com> wrote:
> On Thu, 23 Aug 2007 08:39:11 +0100 Måns Rullgård <mans@mansr.com> wrote:
>
> Well obviously I want to do something different if the file is a socket.
>
> This is for a cgi application and for command line debug I want
> different output. I know, there's no guarantee that when used with a
> webserver the output will be a socket (e.g. webserver might intercept
> output to count bytes xmitted), but in my special-purpose case testing
> for a socket does what I need.
How about doing it the other way around? Use isatty() to see if you're
writing to a terminal.
Or how about setting an HTTP_DEBUG environment variable when you're
debugging? The interesting thing about this is that you can then use it
even when you actually DO go through the webserver, by sending a
"Debug:" request header.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Frank Cusack 2007-08-24, 7:24 am |
| On Thu, 23 Aug 2007 23:02:36 -0400 Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <m2ejhtvoig.fsf@sucksless.local>,
> Frank Cusack <fcusack@fcusack.com> wrote:
>
....[vbcol=seagreen]
> How about doing it the other way around? Use isatty() to see if you're
> writing to a terminal.
Doesn't work if i pipe or redirect the output somewhere.
> Or how about setting an HTTP_DEBUG environment variable when you're
> debugging? The interesting thing about this is that you can then use it
> even when you actually DO go through the webserver, by sending a
> "Debug:" request header.
good idea.
-frank
|
|
|
|
|