linux specific import

[nobody at nowhere.nonet]

anupam kapoor <anupam.kapoor at gmail.com> spewed this unto the Network: 
> hi all,
> 
> i am trying out a trivial daytime-client for getting my feet wet with
> sockets programming using D.

> all "unistd.h" stuff e.g. read/write/dup/dup2/... have been
> exported to D via the "std.c.linux.linux" module as defined in
> "std/c/linux/linux.d".

> i was just curious about the "std.c.linux.linux" module name. any reason
> for not using a simple "std.c.linux" or perhaps "std.c.linux.unistd" ?

> thanks
> anupam

This makes me think: What happens when D is implemented on other
Unix systems that have almost the exact same API? Will they still
use std.c.linux.linux, or will you need to use, for instance,
std.c.solaris.solaris to access fork(2) on Solaris, and
std.c.linux.linux to access fork(2) on Linux? Wouldn't it
be sort of silly to have to import a different module to get
the same function? 

Some posts in this newsgroup imply that there is already a D
compiler for Mac OS X, which implies that this issue has already
come up. Which of these modules must be imported to access fork(2)
on Mac OS X? :

	std.c.linux.linux
	std.c.macosx.macosx
	std.c.darwin.darwin
	std.c.freebsd.freebas
	std.c.mach.mach

BTW, if you're looking at unistd.h just for sockets, it would seem
that you are looking in the wrong place. I am looking at some D
source code right now that gets a class called TcpSocket from
std.socket. Therefore, D supports sockets in its standard library.

The D socket class seems to support both buffered and unbuffered
I/O. 

Here is a completely untested example program. Keep in mind that I have not
actually installed a D compiler on my system. This is based on my impression
of how it "seems to work:" 

import std.socket;
import std.socketstream;

int main() {
	SocketStream stream =
	   new SocketStream(new TcpSocket(new InternetAddress("something.com", 80)));

	stream.writeString("GET / HTTP/1.0\r\n\r\n");
	// Et cetera. 
}