socket family is used to communicate between processes on the same machine
efficiently.
Traditionally, UNIX domain sockets can be either unnamed,
-or bound to a file system pathname (marked as being of type socket).
+or bound to a filesystem pathname (marked as being of type socket).
Linux also supports an abstract namespace which is independent of the
-file system.
+filesystem.
Valid types are:
.BR SOCK_STREAM ,
and
.BR accept (2),
its length is
-.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1" ,
+
+ offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1
+
and
.I sun_path
contains the null-terminated pathname.
.IR sun_path
that are covered by the specified length of the address structure.
(Null bytes in the name have no special significance.)
-The name has no connection with file system pathnames.
+The name has no connection with filesystem pathnames.
When the address of an abstract socket is returned by
.BR getsockname (2),
.BR getpeername (2),
.SH ERRORS
.TP
.B EADDRINUSE
-The specified local address is already in use or the file system socket
+The specified local address is already in use or the filesystem socket
object already exists.
.TP
.B ECONNREFUSED
Unknown socket type.
.PP
Other errors can be generated by the generic socket layer or
-by the file system while generating a file system socket object.
+by the filesystem while generating a filesystem socket object.
See the appropriate manual pages for more information.
.SH VERSIONS
.B SCM_CREDENTIALS
but the implementation details differ.)
.SH NOTES
In the Linux implementation, sockets which are visible in the
-file system honor the permissions of the directory they are in.
+filesystem honor the permissions of the directory they are in.
Their owner, group and their permissions can be changed.
Creation of a new socket will fail if the process does not have write and
search (execute) permission on the directory the socket is created in.
this feature for security.
Binding to a socket with a filename creates a socket
-in the file system that must be deleted by the caller when it is no
+in the filesystem that must be deleted by the caller when it is no
longer needed (using
.BR unlink (2)).
The usual UNIX close-behind semantics apply; the socket can be unlinked
-at any time and will be finally removed from the file system when the last
+at any time and will be finally removed from the filesystem when the last
reference to it is closed.
To pass file descriptors or credentials over a