kernel/kernel_Notes
1
0
Fork 0
mirror of https://github.com/beyondx/Notes.git synced 2026-06-16 06:58:20 +08:00
Code Issues Packages Projects Releases Wiki Activity

Add New Notes

Browse Source
This commit is contained in:
geekard
2012-08-08 14:26:04 +08:00
commit 5ef7c20052
2374 changed files with 276187 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

610
Zim/Programme/APUE/FAQ/Single_UNIX_Specification_Frequently_Asked_Questions_(FAQ_Version_1.9).txt Normal file
View File

@@ -0,0 +1,610 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T12:33:20+08:00
====== Single UNIX Specification Frequently Asked Questions (FAQ Version 1.9) ======
Created 星期二 07 六月 2011
http://www.opengroup.org/austin/papers/single_unix_faq.html
Single UNIX Specification Frequently Asked Questions (FAQ Version 1.9)
Last Updated : Oct 28 2004: freq.ques,v 1.9
This is the Frequently Asked Questions file for the Single UNIX Specification. Its maintainer is Andrew Josey (ajosey at The Open Group ). Suggestions and contributions are always welcome.
This document can be found on the world wide web at http://www.opengroup.org/austin/papers/single_unix_faq.html.
UNIX® is a registered trademark of The Open Group in the USA and other countries.
The Open Group holds the definition of what a UNIX system is and its associated trademark in trust for the industry. The official web site for more information is http://www.unix.org.
This article includes answers to the following.
Q0. What is the Single UNIX Specification?
Q1. What is The Open Group Base Working Group ?
Q2. What is the Austin Group?
Q3. What is the latest version of the Single UNIX Specification?
Q4. Where can I read/download the Single UNIX Specification Version 3 from? Is there a book?
Q5. Where can I read/download earlier versions of the Single UNIX Specification from?
Q6. How do I become a participant in the Working Groups?
Q7. What is covered in the Base Definitions Technical Standard (XBD)?
Q8. What is covered in the System Interfaces Technical Standard (XSH)?
Q9. What is covered in the Shell and Utilities Technical Standard (XCU)?
Q10. What is covered in the Rationale Technical Standard (XRAT)
Q11. What is covered in the X/Open Curses Specification (XCURSES)?
Q12. How many APIs are there? Is there a list of APIs?
Q13. What Options are there in the Version 3 Specification?
Q14. What are the required directories and devices?
Q15. What regular expressions are supported?
Q16. How should I compile a conforming program?
Q17. What is the Relationship to the ISO C Standard?
Q18. What happened to the Networking Services Specification (XNS)?
Q19. What System Interfaces are included by Category?
Q20. What is the history of the development of the Single UNIX Specification?
Q21. How does the Single UNIX Specification compare to the Linux Standard Base?
Q22. What are the core technical changes in the latest version of the Single UNIX Specification?
Q23. Does removal of obsolescent utility syntax mean that implementations supporting usages of head -5 file, tail -5 file, tail -l file are no longer allowed?
Q24. Does an operating system have to be derived from AT&T/SCO code to meet the Single UNIX Specification?
Q25. What about UNIX Certification?
Q26. Where can I get a UNIX License Plate from?
Q27. How do I get permission to excerpt materials from the standard for reuse in my product?
Q28. How do I add a question to this FAQ?
Q0. What is the Single UNIX Specification?
The Single UNIX Specification is a set of open, consensus specifications that define the requirements for a conformant UNIX system. The standardized programming environment provides a broad-based functional set of interfaces to support the porting of existing UNIX applications and the development of new applications. The environment also supports a rich set of tools for application development.
The Single UNIX Specification came into being when in 1994 Novell (who had acquired the UNIX systems business of AT&T/USL) decided to get out of that business. Rather than sell the business as a single entity, Novell transferred the rights to the UNIX trademark and the specification (that subsequently became the Single UNIX Specification) to The Open Group (at the time X/Open Company). Subsequently, it sold the source code and the product implementation (UNIXWARE) to SCO. The Open Group also owns the trademark UNIXWARE, transferred to them from SCO more recently.
Q1. What is The Open Group Base Working Group ?
The Open Group's Base Working Group is the group that has and continues to develop the technical specifications that make up the Single UNIX Specification. More information can be found at http://www.opengroup.org/platform/ . The Base Working Group is one of the three parties involved in the Austin Group that maintain the Base Specifications of the Single UNIX Specification Version 3, which are also IEEE Std 1003.1 (POSIX) and ISO/IEC 9945.
Q2. What is the Austin Group?
The Austin Common Standards Revision Group (CSRG) is a joint technical working group established to develop and maintain the core volumes of the Single UNIX Specification, which are also the POSIX 1003.1 standard and ISO/IEC 9945. Anyone wishing to participate in the Austin Group can do so. There are no fees for participation or membership. You may participate as an observer or as a contributor. You do not have to attend face-to-face meetings to participate, electronic participation is most welcome.
See http://www.opengroup.org/austin/ for more information.
See http://www.opengroup.org/austin/faq.html for the Austin Group FAQ.
Q3. What is the latest version of the Single UNIX Specification?
The latest version is the Single UNIX Specification Version 3. The 2004 edition of the Single UNIX Specification was published on April 30th 2004, and updates the 2001 and 2003 editions of the specification to include Technical Corrigendum 1 (TC1) and Technical Corrigendum 2 (TC2). It consists of The Open Group Base Specifications Issue 6 and the X/Open Curses, Issue 4, Version 2 specification.
The Single UNIX Specification uses The Open Group Base Specifications, Issue 6 documentation as its core. The documentation is structured as follows:
Base Definitions, Issue 6 (XBD)
Shell and Utilities, Issue 6 (XCU)
System Interfaces, Issue 6 (XSH)
Rationale (Informative)
New for this version of the Single UNIX Specification is the incorporation of IEEE Std 1003.1 (POSIX) and ISO/IEC 9945 into the document set; The Open Group Base Specifications, Issue 6, ISO/IEC 9945 and IEEE Std 1003.1, 2004 Edition are technically identical. The base document for the joint revision of the documents was The Open Group's Base volumes of its Single UNIX Specification, Version 2. These were selected since they were a superset of the existing POSIX.1 and POSIX.2 specifications and had some organizational aspects that would benefit the audience for the new revision.
Detailed information on the Single UNIX Specification, including accessing the version 3 specification in html is available at http://www.unix.org/version3/
Q4. Where can I read/download the Single UNIX Specification Version 3 from? Is there a book?
The html version of the latest version (which incorporates technical corrigendum 1) is available to read and download from: URL:http://www.unix.org/version3/, you need to register for a copy.
A summary of the changes in Technical Corrigendum 1 is available from: URL:http://www.opengroup.org/austin/docs/austin_155.txt.
The pdf text of just the Technical Corrigendum 1 (changes to the 2001 edition) is available from: URL: http://www.opengroup.org/pubs/catalog/u057.htm .
The pdf text of just the Technical Corrigendum 2 (changes to both the 2001 and 2003 editions) is available from: URL: http://www.opengroup.org/pubs/catalog/u059.htm .
A summary of the changes in Technical Corrigendum 2 is available from: URL:http://www.opengroup.org/austin/docs/austin_206.txt.
The complete specification in pdf format is available to members of The Open Group from The Open Group publications catalog. If you wish to signup up your organization to become a member of The Open Group and are an active participant in the Austin Group you can sign up for no fee at http://www.opengroup.org/austin/ogmembers/ (note this is for companies and organizations only). If you want to join as an individual, or are working on standardization activities and need a copy to assist you in your work, please contact Andrew Josey directly, he can then add you as an individual affiliate member.
Ongoing draft specifications for future technical corrigenda are available online from the Austin Group web site at http://www.opengroup.org/austin/ . You need to be a member of the Austin Group. Information on how to join the group is on the web site.
URL:http://www.opengroup.org/austin/. (Austin Group Home Page)
Periodically The Open Group does hardcopy runs on the complete 4000 page request.Check the Open Group publications catalog for availability (http://www.opengroup.org/publications/). The Open Group also produces a number of Guide Books, including The Single UNIX Specification Version 3 on CDROM, The Authorized Guide (http://www.unix.org/version3/theguide.html), and the UNIX Internationalization Guide (this is the latest) (http://www.opengroup.org/publications/catalog/g032.htm).
Q5. Where can I read/download earlier version of the Single UNIX Specification from?
The specifications that make up the original Single UNIX Specification (1994) and the Single UNIX Specification Version 2 (1997), and other related specifications can be download in pdf, and html where available, from The Open Group publications catalog at http://www.opengroup.org/publications/catalog/un.htm.
Q6. How do I become a participant in the Working Groups?
To participate in the Austin Group just join the open mailing list. See http://www.opengroup.org/austin/lists.html for more information.
URL:http://www.opengroup.org/austin/lists.html. (How to Join the Austin Group)
If you want to join the Base Working Group please contact Andrew Josey for further information.
Q7. What is covered in the Base Definitions Technical Standard (XBD)?
The XBD document is part of the Base Specifications, Issue 6. XBD provides common definitions for the Base Specifications of the Single UNIX Specification; therefore readers should be familiar with it before using the other parts of the Single UNIX Specification. The presence of this document reduces duplication in the other related parts of the Single UNIX Specification and ensures consistent use of terminology.
This document is structured as follows:
Chapter 1 is an introduction which includes the scope of the Base Specifications, and the scope of the changes made in this revision. Normative references, terminology, and portability codes used throughout the Base Specifications are included in this chapter.
Chapter 2 defines the conformance requirements, both for implementation and application conformance. For implementation conformance, this includes documentation requirements, conformance definitions for the core POSIX subset, conformance definitions for systems conforming to the Single UNIX Specification (denoted as the XSI extension), and option groups (previously known as feature groups).
Chapter 3 contains the general terms and definitions that apply throughout the Base Specifications.
Chapter 4 describes general concepts that apply throughout the Base Specifications.
Chapter 5 describes the notation used to specify file input and output formats in XBD and XCU.
Chapter 6 describes the portable character set and the process of character set definition.
Chapter 7 describes the syntax for defining internationalization locales as well as the POSIX locale provided on all systems.
Chapter 8 describes the use of environment variables for internationalization and other purposes.
Chapter 9 describes the syntax of pattern matching using regular expressions employed by many utilities and matched by the regcomp() and regexec() functions. Both Basic Regular Expressions (BREs) and Extended Regular Expressions (EREs) are described in this chapter.
Chapter 10 describes files and devices found on all systems and their semantics. For example, the device /dev/null is an infinite data source and data sink.
Chapter 11 describes the asynchronous terminal interface for many of the functions in XSH and the stty utility in XCU.
Chapter 12 describes the policies for command line argument construction and parsing. It contains the utility argument syntax used throughout XCU, and also utility syntax guidelines for naming of utilities and the specification of their arguments and option-arguments and operands.
Chapter 13 defines the contents of headers which declare constants, macros, and data structures that are needed by programs using the services provided by the system interfaces defined in XSH. These are in the form of reference pages and are organized alphabetically.
Q8. What is covered in the System Interfaces Technical Standard (XSH)
The XSH document is part of the Base Specifications, Issue 6. XSH describes a set of system interfaces offered to application programs by systems conformant to this part of the Single UNIX Specification. Readers are expected to be experienced C language programmers, and to be familiar with the XBD document.
This document is structured as follows:
Chapter 1 explains the status of this document and its relationship to other formal standards. The scope, conformance, and definitions sections are pointers to the XBD document; the sections are here to meet ISO/IEC rules regarding required sections. The terminology and portability codes are identical to the section in XBD and repeated here for ease of reference.
Chapter 2 contains important concepts, terms, and caveats relating to the rest of this document. This includes information on the compilation environment, the name space, definitions of error numbers, signal concepts, standard I/O streams, STREAMS, XSI IPC, realtime, threads, sockets, tracing, and data types.
Chapter 3 defines the functional interfaces to systems conformant to this part of the Single UNIX Specification. These are in the form of reference pages and are organized alphabetically.
Q9. What is covered in the Shell and Utilities Technical Standard (XCU)?
The XCU1 document is part of the Base Specifications, Issue 6. XCU describes the shell and utilities that are available to application programs on systems conformant to this part of the Single UNIX Specification. Readers are expected to be familiar with the XBD document.
This document is structured as follows:
Chapter 1 explains the status of this document and its relationship to other formal standards, including the ISO C standard and also the XSH document. It also describes the utility limits, grammar conventions, defaults used by the utility descriptions, considerations for utilities in support of large files, and the list of required built-in utilities. The scope, conformance, and definitions sections are pointers to the XBD document; the sections are here to meet ISO/IEC rules regarding required sections. The terminology and portability codes are identical to the section in XBD and repeated here for ease of reference.
Chapter 2 describes the command language-that is, the shell command language interpreter-used in systems conformant to the Single UNIX Specification.
Chapter 3 describes a set of services and utilities that are implemented on systems supporting the Batch Environment option.
Chapter 4 consists of reference pages for all utilities available on systems conforming to the Single UNIX Specification. These are in the form of reference pages and are organized alphabetically.
Footnote
1.
The acronym ``XCU'' derives from the previous version of the specification which was called ``Commands and Utilities''.
Q10. What is covered in the Rationale Technical Standard (XRAT)
The XRAT document is part of the Base Specifications, Issue 6. The XRAT document has been published to assist in the process of review and understanding of the main text. It contains historical information concerning the contents of the Base Specifications, Issue 6 and why features were included or discarded by the standard developers. It also contains notes of interest to application programmers on recommended programming practices, emphasizing the consequences of some aspects that may not be immediately apparent.
This document is organized in parallel to the normative documents of the Base Specification, with a separate part (Parts A, B, and C) for each of the three normative documents. In addition, two additional parts are included: Part D, Portability Considerations and Part E Subprofiling Considerations. The Portability Considerations chapter includes a report on the perceived user requirements for the Base Specification and how the facilities provided satisfy those requirements, together with guidance to writers of profiles on how to use the configurable options, limits, and optional behavior. The Subprofiling Considerations chapter satisfies the requirement that the document address subprofiling. This contains an example set of subprofiling options.
Q11. What is covered in the X/Open Curses Specification (XCURSES)?
XCURSES is not part of the Base Specifications, Issue 6. XCURSES describes a set of interfaces providing a terminal-independent method of updating character screens that are available to application programs on systems conformant to this part of the Single UNIX Specification. This document should be read in conjunction with The Open Group Corrigendum U056.
This document is structured as follows:
Chapter 1 introduces Curses, gives an overview of enhancements that have been made to this version, and lists specific interfaces marked TO BE WITHDRAWN. This chapter also defines the requirements for conformance to this document and shows the generic format followed by interface definitions in Chapter 4.
Chapter 2 describes the relationship between Curses and the C language, the compilation environment, and the X/Open System Interface (XSI) operating system requirements. It also defines the effect of the interface on the name space for identifiers and introduces the major data types that the interfaces use.
Chapter 3 gives an overview of Curses. It discusses the use of some of the key data types and gives general rules for important common concepts such as characters, renditions, and window properties. It contains general rules for the common Curses operations and operating modes. This information is implicitly referenced by the interface definitions in Chapter 4. The chapter explains the system of naming the Curses functions and presents a table of function families. Finally, the chapter contains notes regarding use of macros and restrictions on block-mode terminals.
Chapter 4 defines the Curses functional interfaces.
Chapter 5 defines the contents of headers which declare constants, macros, and data structures that are needed by programs using the services provided by Chapter 4.
Chapter 6 discusses the terminfo database which Curses uses to describe terminals. The chapter specifies the source format of a terminfo entry using a formal grammar, an informal discussion, and an example. Boolean, numeric, and string capabilities are presented in tabular form.
Appendix A discusses the use of these capabilities by the writer of a terminfo entry to describe the characteristics of the terminal in use.
The chapters are followed by a glossary, which contains normative definitions of terms used in the document.
Q12. How many APIs are there? Is there a list of APIs?
There are 1742 APIs, broken down as follows: XSH 1123, XCU 160, XBD 84 and XCURSES 375.
A list of APIs is available at http://www.unix-systems.org/version3/apis.html.
Q13. What Options are there in the Version 3 Specification?
The Version 3 Specification includes a set of profiling options, allowing larger profiles of the options of the Base standard. In earlier versions of the Single UNIX Specification these were formerly known as Feature Groups. The Option Groups within the Single UNIX Specification are defined within XBD, Section 2.1.5.2, XSI Option Groups.
The Single UNIX Specification Version 3 contains the following Option Groups:
Encryption, covering the functions crypt(), encrypt( ), and setkey.()
Realtime, covering the functions from the IEEE Std 1003.1b-1993 Realtime extension.
Realtime Threads, covering the functions from the IEEE Std 1003.1c-1995 Threads extension that are related to realtime functionality.
Advanced Realtime, covering some of the non-threads-related functions from IEEE Std 1003.1d-1999 and IEEE Std 1003.1j-2000.
Advanced Realtime Threads, covering some of the threads-related functions from IEEE Std 1003.1d-1999 and IEEE Std 1003.1j-2000.
Tracing, covering the functionality from IEEE Std 1003.1q-2000.
XSI STREAMS, covering the functionality and interfaces related to STREAMS, a uniform mechanism for implementing networking services and other character-based I/O as described in XSH, Section 2.6, STREAMS. This was mandatory in previous versions of the Single UNIX Specification, but is now optional in this version.
Legacy, covering the functionality and interfaces which were mandatory in previous versions of the Single UNIX Specification, but are optional in this version.
Q14. What are the required directories and devices?
The Single UNIX Specification describes an applications portability environment, and as such defines a certain minimal set of directories and devices that applications regularly use.
The following directories are defined:
/ The root directory of the file system.
/dev Contains the devices /dev/console, /dev/null, and /dev/tty.
/tmp A directory where applications can create temporary files.
The directory structure does not cross into such system management issues as where user accounts are organized or software packages are installed. Refer to XBD, Section 10.1, Directory Structure and Files for more information. XBD, Chapter 10, Directory Structure and Devices also defines the mapping of control character sequences to real character values, and describes the actions an implementation must take when it cannot support certain terminal behavior.
Q15. What regular expressions are supported?
Both Basic Regular Expressions (BREs) and Extended Regular Expressions (EREs) are supported and are described in XBD, Chapter 9, Regular Expressions and all of the utilities and interfaces that use regular expressions refer back to this definition.
Basic regular expressions: csplit, ctags, ed, ex, expr, grep, more, nl, pax, pg, sed, vi
Extended regular expressions: awk, egrep, grep -E, lex
The functions regcomp() and regexec() in XSH, Chapter 3, System Interfaces implement regular expressions as defined in the Single UNIX Specification.
Q16. How should I compile a conforming program?
XCU defines c99 as the interface to the C compilation environment. The c99 interface is new to this version of the specification and an interface to the standard C compiler. The c89 and cc utilities are no longer defined in this version of the Single UNIX Specification although implementations may additionally support them for backwards-compatibility.
There are a number of tasks that must be done to effectively make the interface environment available to a program. A number of C-language macros, referred to as feature test macros, must be defined before any headers are included. These macros might more accurately be referred to as header configuration macros, as they control what symbols and prototypes will be exposed by the headers. The macro _XOPEN_SOURCE must be defined to a value of 600 to make available the functionality of the Single UNIX Specification, Version 3. With respect to POSIX functionality covered by the Single UNIX Specification, this is equivalent to defining the POSIX macro {_POSIX_C_SOURCE} to be 200112L.
Use of the {_XOPEN_SOURCE} macro should not be confused with the other feature test macros associated with Feature Groups and functionality, such as {_XOPEN_UNIX}. These feature test macros are the implementation's way of announcing functionality to the application.
Q17. What is the Relationship to the ISO C Standard?
The most recent revision to the ISO C standard occurred in 1999. The ISO C standard is itself independent of any operating system in so much as it may be implemented in many environments including hosted environments.
The Single UNIX Specification has a long history of building on the ISO C standard and deferring to it where applicable. Whereas revisions of POSIX.1 prior to the Austin Group specification built upon the ISO C standard by reference only, and also allowed support for traditional C as an alternative. The Single UNIX Specification in contrast, has always included manual pages for the ISO C interfaces.
The Version 3 Specification takes the latter approach. The standard developers believed it essential for a programmer to have a single complete reference place. They also recognized that deference to the formal standard had to be addressed for the duplicate interface definitions which occur in both the ISO C standard and their document.
It was agreed that where an interface has a version in the ISO C standard, the DESCRIPTION section should describe the relationship to the ISO C standard and markings added as appropriate within the manual page to show where the ISO C standard has been extended.
A block of text was added to the start of each affected reference page stating whether the page is aligned with the ISO C standard or extended. Each page was parsed for additions beyond the ISO C standard and these extensions are marked as CX extensions (for C Extensions).
Q18. What happened to the Networking Services Specification (XNS)?
Unlike previous versions of the Single UNIX Specification, for Version 3 the Networking Services have now been integrated into the Base Specifications. This includes sockets and IP address resolution interfaces. The X/Open Transport Interface (XTI) is no longer a requirement in Version 3 of the Single UNIX Specification. As with other functions in XSH, the application developer needs to define {_XOPEN_SOURCE} to be 600 prior to the inclusion of any Single UNIX Specification headers. The c99 compiler utilities recognize the additional -l operand for the xnet library.
Q19. What System Interfaces are included by Category?
The system interfaces in the Version 3 specification categorized by functional grouping are as follows:
Jump Interfaces
longjmp(), setjmp()
Maths Library Interfaces
acos(), acosf(), acosh(), acoshf(), acoshl(), acosl(), asin(), asinf(), asinh(), asinhf(), asinhl(), asinl(), atan(), atan2(), atan2f(), atan2l(), atanf(), atanh(), atanhf(), atanhl(), atanl(), cabs(), cabsf(), cabsl(), cacos(), cacosf(), cacosh(), cacoshf(), cacoshl(), cacosl(), carg(), cargf(), cargl(), casin(), casinf(), casinh(), casinhf(), casinhl(), casinl(), catan(), catanf(), catanh(), catanhf(), catanhl(), catanl(), cbrt(), cbrtf(), cbrtl(), ccos(), ccosf(), ccosh(), ccoshf(), ccoshl(), ccosl(), ceil(), ceilf(), ceill(), cexp(), cexpf(), cexpl(), cimag(), cimagf(), cimagl(), clog(), clogf(), clogl(), conj(), conjf(), conjl(), copysign(), copysignf(), copysignl(), cos(), cosf(), cosh(), coshf(), coshl(), cosl(), cpow(), cpowf(), cpowl(), cproj(), cprojf(), cprojl(), creal(), crealf(), creall(), csin(), csinf(), csinh(), csinhf(), csinhl(), csinl(), csqrt(), csqrtf(), csqrtl(), ctan(), ctanf(), ctanh(), ctanhf(), ctanhl(), ctanl(), erf(), erfc(), erfcf(), erfcl(), erff(), erfl(), exp(), exp2(), exp2f(), exp2l(), expf(), expl(), expm1(), expm1f(), expm1l(), fabs(), fabsf(), fabsl(), fdim(), fdimf(), fdiml(), floor(), floorf(), floorl(), fma(), fmaf(), fmal(), fmax(), fmaxf(), fmaxl(), fmin(), fminf(), fminl(), fmod(), fmodf(), fmodl(), fpclassify(), frexp(), frexpf(), frexpl(), hypot(), hypotf(), hypotl(), ilogb(), ilogbf(), ilogbl(), isfinite(), isgreater(), isgreaterequal(), isinf(), isless(), islessequal(), islessgreater(), isnan(), isnormal(), isunordered(), ldexp(), ldexpf(), ldexpl(), lgamma(), lgammaf(), lgammal(), llrint(), llrintf(), llrintl(), llround(), llroundf(), llroundl(), log(), log10(), log10f(), log10l(), log1p(), log1pf(), log1pl(), log2(), log2f(), log2l(), logb(), logbf(), logbl(), logf(), logl(), lrint(), lrintf(), lrintl(), lround(), lroundf(), lroundl(), modf(), modff(), modfl(), nan(), nanf(), nanl(), nearbyint(), nearbyintf(), nearbyintl(), nextafter(), nextafterf(), nextafterl(), nexttoward(), nexttowardf(), nexttowardl(), pow(), powf(), powl(), remainder(), remainderf(), remainderl(), remquo(), remquof(), remquol(), rint(), rintf(), rintl(), round(), roundf(), roundl(), scalbln(), scalblnf(), scalblnl(), scalbn(), scalbnf(), scalbnl(), signbit(), sin(), sinf(), sinh(), sinhf(), sinhl(), sinl(), sqrt(), sqrtf(), sqrtl(), tan(), tanf(), tanh(), tanhf(), tanhl(), tanl(), tgamma(), tgammaf(), tgammal(), trunc(), truncf(), truncl()
General ISO C Library Interfaces
abs(), asctime(), atof(), atoi(), atol(), atoll(), bsearch(), calloc(), ctime(), difftime(), div(), feclearexcept(), fegetenv(), fegetexceptflag(), fegetround(), feholdexcept(), feraiseexcept(), fesetenv(), fesetexceptflag(), fesetround(), fetestexcept(), feupdateenv(), free(), gmtime(), imaxabs(), imaxdiv(), isalnum(), isalpha(), isblank(), iscntrl(), isdigit(), isgraph(), islower(), isprint(), ispunct(), isspace(), isupper(), isxdigit(), labs(), ldiv(), llabs(), lldiv(), localeconv(), localtime(), malloc(), memchr(), memcmp(), memcpy(), memmove(), memset(), mktime(), qsort(), rand(), realloc(), setlocale(), snprintf(), sprintf(), srand(), sscanf(), strcat(), strchr(), strcmp(), strcoll(), strcpy(), strcspn(), strerror(), strftime(), strlen(), strncat(), strncmp(), strncpy(), strpbrk(), strrchr(), strspn(), strstr(), strtod(), strtof(), strtoimax(), strtok(), strtol(), strtold(), strtoll(), strtoul(), strtoull(), strtoumax(), strxfrm(), time(), tolower(), toupper(), tzname, tzset(), va_arg(), va_copy(), va_end(), va_start(), vsnprintf(), vsprintf(), vsscanf()
Thread-Safe General ISO C Library Interfaces
asctime_r(), ctime_r(), gmtime_r(), localtime_r(), rand_r(), strerror_r(), strtok_r()
Wide-Character ISO C Library Interfaces
btowc(), iswalnum(), iswalpha(), iswblank(), iswcntrl(), iswctype(), iswdigit(), iswgraph(), iswlower(), iswprint(), iswpunct(), iswspace(), iswupper(), iswxdigit(), mblen(), mbrlen(), mbrtowc(), mbsinit(), mbsrtowcs(), mbstowcs(), mbtowc(), swprintf(), swscanf(), towctrans(), towlower(), towupper(), vswprintf(), vswscanf(), wcrtomb(), wcscat(), wcschr(), wcscmp(), wcscoll(), wcscpy(), wcscspn(), wcsftime(), wcslen(), wcsncat(), wcsncmp(), wcsncpy(), wcspbrk(), wcsrchr(), wcsrtombs(), wcsspn(), wcsstr(), wcstod(), wcstof(), wcstoimax(), wcstok(), wcstol(), wcstold(), wcstoll(), wcstombs(), wcstoul(), wcstoull(), wcstoumax(), wcsxfrm(), wctob(), wctomb(), wctrans(), wctype(), wmemchr(), wmemcmp(), wmemcpy(), wmemmove(), wmemset()
General C Library Extension Interfaces
fnmatch(), getopt(), optarg, opterr, optind, optopt
Device Input and Output Interfaces
FD_CLR(), FD_ISSET(), FD_SET(), FD_ZERO(), clearerr(), close(), fclose(), fdopen(), feof(), ferror(), fflush(), fgetc(), fgets(), fileno(), fopen(), fprintf(), fputc(), fputs(), fread(), freopen(), fscanf(), fwrite(), getc(), getchar(), gets(), open(), perror(), printf(), pselect(), putc(), putchar(), puts(), read(), scanf(), select(), setbuf(), setvbuf(), stderr, stdin, stdout, ungetc(), vfprintf(), vfscanf(), vprintf(), vscanf(), write()
General Terminal Interfaces
cfgetispeed(), cfgetospeed(), cfsetispeed(), cfsetospeed(), ctermid(), isatty(), tcdrain(), tcflow(), tcflush(), tcgetattr(), tcsendbreak(), tcsetattr(), ttyname()
Thread-Safe General Terminal Interfaces
ttyname_r()
File Descriptor Management Interfaces
dup(), dup2(), fcntl(), fgetpos(), fseek(), fseeko(), fsetpos(), ftell(), ftello(), ftruncate(), lseek(), rewind()
FIFO Interfaces
mkfifo()
File Attributes Interfaces
chmod(), chown(), fchmod(), fchown(), umask()
Thread-Safe Stdio Locking Interfaces
flockfile(), ftrylockfile(), funlockfile(), getc_unlocked(), getchar_unlocked(), putc_unlocked(), putchar_unlocked()
File System Interfaces
access(), chdir(), closedir(), creat(), fpathconf(), fstat(), getcwd(), link(), mkdir(), opendir(), pathconf(), readdir(), remove(), rename(), rewinddir(), rmdir(), stat(), tmpfile(), tmpnam(), unlink(), utime()
File System Extensions Interfaces
glob(), globfree()
Thread-Safe File System Interfaces
readdir_r()
Job Control Interfaces
setpgid(), tcgetpgrp(), tcsetpgrp()
Multiple Processes Interfaces
_Exit(), _exit(), assert(), atexit(), clock(), execl(), execle(), execlp(), execv(), execve(), execvp(), exit(), fork(), getpgrp(), getpid(), getppid(), setsid(), sleep(), times(), wait(), waitpid()
Networking Interfaces
accept(), bind(), connect(), endhostent(), endnetent(), endprotoent(), endservent(), freeaddrinfo(), gai_strerror(), getaddrinfo(), gethostbyaddr(), gethostbyname(), gethostent(), gethostname(), getnameinfo(), getnetbyaddr(), getnetbyname(), getnetent(), getpeername(), getprotobyname(), getprotobynumber(), getprotoent(), getservbyname(), getservbyport(), getservent(), getsockname(), getsockopt(), h_errno, htonl(), htons(), if_freenameindex(), if_indextoname(), if_nameindex(), if_nametoindex(), inet_addr(), inet_ntoa(), inet_ntop(), inet_pton(), listen(), ntohl(), ntohs(), recv(), recvfrom(), recvmsg(), send(), sendmsg(), sendto(), sethostent(), setnetent(), setprotoent(), setservent(), setsockopt(), shutdown(), socket(), sockatmark(), socketpair()
Pipe Interfaces
pipe()
Regular Expressions Interfaces
regcomp(), regerror(), regexec(), regfree()
Shell and Utilities Interfaces
pclose(), popen(), system(), wordexp(), wordfree()
Signal Interfaces
abort(), alarm(), kill(), pause(), raise(), sigaction(), sigaddset(), sigdelset(), sigemptyset(), sigfillset(), sigismember(), signal(), sigpending(), sigprocmask(), sigsuspend(), sigwait()
Signal Jump Functions Interfaces
siglongjmp(), sigsetjmp()
Single Process Interfaces
confstr(), environ, errno, getenv(), setenv(), sysconf(), uname(), unsetenv()
Symbolic Links Interfaces
lstat(), readlink(), symlink()
System Database Interfaces
getgrgid(), getgrnam(), getpwnam(), getpwuid()
Thread-Safe System Database Interfaces
getgrgid_r(), getgrnam_r(), getpwnam_r(), getpwuid_r()
Threads Interfaces
pthread_addr_setstacksize(), pthread_atfork(), pthread_attr_destroy(), pthread_attr_getdetachstate(), pthread_attr_getstackaddr(), pthread_attr_getstacksize(), pthread_attr_init(), pthread_attr_setdetachstate(), pthread_attr_setschedparam(), pthread_attr_setstackaddr(), pthread_barrierattr_destroy(), pthread_barrierattr_getpshared(), pthread_barrierattr_init(), pthread_barrierattr_setpshared(), pthread_barrier_destroy(), pthread_barrier_init(), pthread_barrier_wait(), pthread_cancel(), pthread_cleanup_pop(), pthread_cleanup_push(), pthread_cond_broadcast(), pthread_cond_destroy(), pthread_cond_init(), pthread_cond_signal(), pthread_cond_timedwait(), pthread_cond_wait(), pthread_condattr_destroy(), pthread_condattr_getpshared(), pthread_condattr_init(), pthread_condattr_setpshared(), pthread_create(), pthread_detach(), pthread_equal(), pthread_exit(), pthread_getschedparam(), pthread_getspecific(), pthread_join(), pthread_key_create(), pthread_key_delete(), pthread_kill(), pthread_mutex_destroy(), pthread_mutex_init(), pthread_mutex_lock(), pthread_mutex_timedlock(), pthread_mutex_trylock(), pthread_mutex_unlock(), pthread_mutexattr_destroy(), pthread_mutexattr_getpshared(), pthread_mutexattr_init(), pthread_mutexattr_setpshared(), pthread_once(), pthread_rwlockattr_destroy(), pthread_rwlockattr_getpshared(), pthread_rwlockattr_init(), pthread_rwlockattr_setpshared(), pthread_rwlock_destroy(), pthread_rwlock_init(), pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock(), pthread_rwlock_timedwrlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock(), pthread_rwlock_unlock(), pthread_rwlock_wrlock(), pthread_self(), pthread_setcancelstate(), pthread_setcanceltype(), pthread_setspecific(), pthread_sigmask(), pthread_spin_destroy(), pthread_spin_init(), pthread_spin_lock(), pthread_spin_trylock(), pthread_spin_unlock(), pthread_testcancel()
Realtime Threads Interfaces
pthread_attr_getinheritsched(), pthread_attr_getschedpolicy(), pthread_attr_getscope(), pthread_attr_setinheritsched(), pthread_attr_setschedpolicy(), pthread_attr_setscope(), pthread_getschedparam(), pthread_mutex_getprioceiling(), pthread_mutex_setprioceiling(), pthread_mutexattr_getprioceiling(), pthread_mutexattr_getprotocol(), pthread_mutexattr_setprioceiling(), pthread_mutexattr_setprotocol(), pthread_setschedparam()
Realtime Interfaces
aio_cancel(), aio_error(), aio_fsync(), aio_read(), aio_return(), aio_suspend(), aio_write(), clock_getres(), clock_gettime(), clock_settime(), fdatasync(), lio_listio(), mlock(), mlockall(), mq_close(), mq_getattr(), mq_notify(), mq_open(), mq_receive(), mq_send(), mq_setattr(), mq_timedreceive(), mq_timedsend(), mq_unlink(), munlock(), munlockall(), nanosleep(), sched_get_priority_max(), sched_get_priority_min(), sched_getparam(), sched_getscheduler(), sched_rr_get_interval(), sched_setparam(), sched_setscheduler(), sched_yield(), sem_close(), sem_destroy(), sem_getvalue(), sem_init(), sem_open(), sem_post(), sem_timedwait(), sem_trywait(), sem_unlink(), sem_wait(), shm_open(), shm_unlink(), sigqueue(), sigtimedwait(), sigwaitinfo(), timer_create(), timer_delete(), timer_getoverrun(), timer_gettime(), timer_settime()
Tracing Interfaces
posix_trace_attr_destroy(), posix_trace_attr_getclockres(), posix_trace_attr_getcreatetime(), posix_trace_attr_getgenversion(), posix_trace_attr_getinherited(), posix_trace_attr_getlogfullpolicy(), posix_trace_attr_getlogsize(), posix_trace_attr_getmaxdatasize(), posix_trace_attr_getmaxsystemeventsize(), posix_trace_attr_getmaxusereventsize(), posix_trace_attr_getname(), posix_trace_attr_getstreamfullpolicy(), posix_trace_attr_getstreamsize(), posix_trace_attr_init(), posix_trace_attr_setinherited(), posix_trace_attr_setlogfullpolicy(), posix_trace_attr_setlogsize(), posix_trace_attr_setmaxdatasize(), posix_trace_attr_setname(), posix_trace_attr_setstreamfullpolicy(), posix_trace_attr_setstreamsize(), posix_trace_clear(), posix_trace_close(), posix_trace_create(), posix_trace_create_withlog(), posix_trace_event(), posix_trace_eventid_equal(), posix_trace_eventid_get_name(), posix_trace_eventid_open(), posix_trace_eventset_add(), posix_trace_eventset_del(), posix_trace_eventset_empty(), posix_trace_eventset_fill(), posix_trace_eventset_ismember(), posix_trace_eventtypelist_getnext_id(), posix_trace_eventtypelist_rewind(), posix_trace_flush(), posix_trace_get_attr(), posix_trace_get_filter(), posix_trace_getnext_event(), posix_trace_get_status(), posix_trace_open(), posix_trace_rewind(), posix_trace_set_filter(), posix_trace_shutdown(), posix_trace_start(), posix_trace_stop(), posix_trace_timedgetnext_event(), posix_trace_trid_eventid_open(), posix_trace_trygetnext_event()
Advisory Interfaces Interfaces
posix_fadvise(), posix_fallocate(), posix_madvise()
Typed Memory Interfaces Interfaces
posix_mem_offset(), posix_typed_mem_get_info(), posix_typed_mem_open()
User and Group Interfaces
getegid(), geteuid(), getgid(), getgroups(), getlogin(), getuid(), setegid(), seteuid(), setgid(), setuid()
Thread-Safe User and Group Interfaces
getlogin_r()
Wide Character Device Input and Output Interfaces
fgetwc(), fgetws(), fputwc(), fputws(), fwide(), fwprintf(), fwscanf(), getwc(), getwchar(), putwc(), putwchar(), ungetwc(), vfwprintf(), vfwscanf(), vwprintf(), vwscanf(), wprintf(), wscanf()
XSI General C Library Interfaces
_tolower(), _toupper(), a64l(), daylight(), drand48(), erand48(), ffs(), getcontext(), getdate(), getsubopt(), hcreate(), hdestroy(), hsearch(), iconv(), iconv_close(), iconv_open(), initstate(), insque(), isascii(), jrand48(), l64a(), lcong48(), lfind(), lrand48(), lsearch(), makecontext(), memccpy(), mrand48(), nrand48(), random(), remque(), seed48(), setcontext(), setstate(), signgam, srand48(), srandom(), strcasecmp(), strdup(), strfmon(), strncasecmp(), strptime(), swab(), swapcontext(), tdelete(), tfind(), timezone(), toascii(), tsearch(), twalk()
XSI Encryption Interfaces
crypt(), encrypt(), setkey()
XSI Database Management Interfaces
dbm_clearerr(), dbm_close(), dbm_delete(), dbm_error(), dbm_fetch(), dbm_firstkey(), dbm_nextkey(), dbm_open(), dbm_store()
XSI Device Input and Output Interfaces
fmtmsg(), poll(), pread(), pwrite(), readv(), writev()
XSI General Terminal Interfaces
grantpt(), posix_openpt(), ptsname(), unlockpt()
XSI Dynamic Linking Interfaces
dlclose(), dlerror(), dlopen(), dlsym()
XSI File Descriptor Management Interfaces
truncate()
XSI File System Interfaces
basename(), dirname(), fchdir(), fstatvfs(), ftw(), lchown(), lockf(), mknod(), mkstemp(), nftw(), realpath(), seekdir(), statvfs(), sync(), telldir(), tempnam()
XSI Internationalization Interfaces
catclose(), catgets(), catopen(), nl_langinfo()
XSI Interprocess Communication Interfaces
ftok(), msgctl(), msgget(), msgrcv(), msgsnd(), semctl(), semget(), semop(), shmat(), shmctl(), shmdt(), shmget()
XSI Job Control Interfaces
tcgetsid()
XSI Jump Functions Interfaces
_longjmp(), _setjmp()
XSI Maths Library Interfaces
j0(), j1(), jn(), scalb(), y0(), y1(), yn()
XSI Multiple Process Interfaces
getpgid(), getpriority(), getrlimit(), getrusage(), getsid(), nice(), setpgrp(), setpriority(), setrlimit(), ulimit(), usleep(), vfork(), waitid()
XSI Signal Interfaces
bsd_signal(), killpg(), sigaltstack(), sighold(), sigignore(), siginterrupt(), sigpause(), sigrelse(), sigset(), ualarm()
XSI Single Process Interfaces
gethostid(), gettimeofday(), putenv()
XSI System Database Interfaces
endpwent(), getpwent(), setpwent()
XSI System Logging Interfaces
closelog(), openlog(), setlogmask(), syslog()
XSI Thread Mutex Extensions Interfaces
pthread_mutexattr_gettype(), pthread_mutexattr_settype()
XSI Threads Extensions Interfaces
pthread_attr_getguardsize(), pthread_attr_setguardsize(), pthread_getconcurrency(), pthread_setconcurrency()
XSI Timers Interfaces
getitimer(), setitimer()
XSI User and Group Interfaces
endgrent(), endutxent(), getgrent(), getutxent(), getutxid(), getutxline(), pututxline(), setgrent(), setregid(), setreuid(), setutxent()
XSI Wide-Character Library Interfaces
wcswidth(), wcwidth()
XSI Legacy Interfaces
bcmp(), bcopy(), bzero(), ecvt(), fcvt(), ftime(), gcvt(), getwd(), index(), mktemp(), rindex(), utimes(), wcswcs()
Q20. What is the history of the development of the Single UNIX Specification?
The Open Group has been the custodian of the specification for the UNIX system and the trademark since 1994. This is a source level API specification which has traditionally built upon the formal IEEE POSIX standards. It is vendor neutral and not tied to any particular implementation.
The project that led to the creation of the Single UNIX Specification started when several vendors (Sun Microsystems, IBM, Hewlett-Packard, Novell/USL, and OSF) joined together to provide a single unified specification of the UNIX system services. By implementing a single common definition of the UNIX system services, third-party independent software vendors (ISVs) would be able to more easily deliver strategic applications on all of these vendors' platforms at once.
A two-pronged approach was used to develop the Single UNIX Specification. First, a set of formal industry specifications was chosen to form the overall base for the work. This would provide stability, vendor neutrality, and lay a well charted course for future application development, taking advantage of the careful work that has gone into developing these specifications. It would also preserve the portability of existing applications already developed to these core models.
The XPG4 Base (1992) was chosen as the stable functional base from which to start. XPG4 Base supports the POSIX.1 system interface and the ISO C standards at its core. It also provided a rich set of 174 commands and utilities.
To this base was added the traditional UNIX System V Interface Definition, (SVID) Edition 3, Level 1 calls, and the OSF Application Environment Specification Full Use interface definitions. This represented the stable central core of the latter two specifications.
The second part of the approach was to incorporate interfaces that were acknowledged common practice but had not yet been incorporated into any formal specification or standard. The intent was to ensure existing applications running on UNIX systems would port with relative ease to a platform supporting the Single UNIX Specification. A survey of real world applications was used to determine what additional interfaces would be required in the specification.
Fifty successful application packages were chosen to be analyzed using the following criteria:
- Ranked in International Data Corp's. 1992, 'Survey of Leading UNIX Applications',
- The application's domain of applicability was checked to ensure that no single application type (for example, databases) was overly represented,
- The application had to be available for analysis either as source code, or as a shared or dynamic linked library.
From the group of fifty, the top ten were selected carefully, ensuring that no more than two representative application packages in a particular problem space were chosen. The ten chosen applications were:
AutoCAD; Cadence; FrameMaker; Informix; Island Write/Paint; Lotus 1-2-3; SAS (4GL); Sybase; Teamwork; WordPerfect
APIs used by the applications that were not part of the base specifications were analyzed:
- If an API was used by any of the top ten applications, it was considered for inclusion.
- If an API was not used by one of the top ten, but was used by any three of the remaining 40 applications, it was considered for inclusion.
- While the investigation of these 50 applications was representative of large complex applications, it still was not considered as a broad enough survey, so an additional 3500 modules were scanned. If an API was used at least seven times in modules that came from at least two platforms (to screen out vendor specific libraries), then the interface was considered for inclusion.
When the survey was complete, there were 130 interfaces that did not already appear in the base specification. These interfaces were predominantly BSD interfaces that had never been covered in XPG4 Base, the SVID, or the AES, but did represent common practice in UNIX system applications developed originally on BSD-derived platforms. Such things as sockets and the 4.3BSD memory management calls were commonly used in many applications.
The goal was to ensure that APIs in common use were included, even if they were not in the formal specifications that made up the base. Making the Single UNIX Specification a superset of existing base specifications ensured any existing applications should work unmodified.
The Single UNIX Specification has evolved through several iterations; Version 2 in 1997 incorporated updates to the formal standards, as well as industry driven additions such as large file handling, dynamic linking, datasize neutrality and extended threads functionality. Version 3 in 2001 merges with the IEEE POSIX standard.
A list of the interfaces in Version 3 of the Single UNIX Specification together with comparative information on the presence of the interface in other specifications is available at http://www.unix.org/v3-apis.html
A wall poster with the history and timeline of the Single UNIX Specification is available at http://www.unix.org/Posters/
Q21. How does the Single UNIX Specification compare to the Linux Standard Base?
The Single UNIX Specification specifies application programming interfaces (APIs) at the source level, and is about application source code portability. Its neither a code implementation nor an operating system, but a stable definition of a programming interface that those systems supporting the specification guarantee to provide to the application programmer. Efforts such as the Linux Standard Base, and similarly the iBCS2 for x86 implementations of System V, are about binary portability and define a specific binary implementation of an interface to operating system services.
The LSB draws on the Single UNIX Specification for many of its interfaces although does not formally defer to it preferring to document any differences where they exist, such as where certain aspects of Linux cannot currently conform to the industry standards. Some interfaces are not included in the LSB, since they are outside the remit of a binary runtime environment, typically these are development interfaces or user level tools. Likewise there are some areas in the LSB that are outside the scope of the Single UNIX Specification (for example system administration interfaces).
Two white papers with further information on this topic are at: http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=6075, http://www.opengroup.org/platform/single_unix_specification/doc.tpl?gdid=5992.
Q22. What are the core technical changes in the latest version of the Single UNIX Specification?
The main changes are as follows: alignment with ISO/IEC 9899:1999 (ISO C), integration of the Networking Services volume (apart from XTI), support for IPv6, integration of recent POSIX realtime amendments ( 1003.1d, 1003.1j, 1003.1q), amendments to the core POSIX functionality from the 1003.2b and 1003.1a amendments, application of technical corrigendum from The Open Group and IEEE interpretations, revision of options , removal of obsolescent and legacy interfaces.
Q23. Does removal of obsolescent utility syntax mean that implementations supporting usages of head -5 file, tail -5 file, tail -l file are no longer allowed?
No, in general the intent of removing the obsolescent forms of the utility synopses was not to disallow them to be supported by implementations but to downgrade the status of their use in applications from conforming application using an obsolescent feature to non-conforming application. In general it is allowed for utilities to have extensions that violate the utility syntax guidelines so long as the forms defined in the standard that are required to follow the utility syntax guidelines do so. The cases cited fit the case. The Austin Group has more general cases under review at the present time.
Q24. Does an operating system have to be derived from AT&T/SCO code to meet the Single UNIX Specification?
No. As the owner of the UNIX trademark, The Open Group has separated the UNIX trademark from any actual code stream itself, thus allowing multiple implementations. Since the introduction of the Single UNIX Specification, there has been a single, open, consensus specification that defines the requirements for a conformant UNIX system.
Q25. What about UNIX Certification?
There is a mark, or brand, that is used to identify those products that have been certified as conforming to the Single UNIX Specification, initially UNIX 93, followed subsequently by UNIX 95, UNIX 98 and now UNIX 03. Information on the UNIX certification program which operates under The Open Group's Open Brand, can be found at http://www.opengroup.org/certification/idx/unix.html
The UNIX 03 Certification Guide is available at http://www.opengroup.org/openbrand/docs/UNIX03_Certification_Guide.html.
The Practical Guide to the Open Brand is available at http://www.opengroup.org/openbrand/Certification_Guide/
The register of Certified Products is available at http://www.opengroup.org/openbrand/register/
Q26. Where can I get a UNIX License Plate from?
The classic "Live Free or Die" license plates can be ordered from The Open Group's publications catalog at: http://www.opengroup.org/publications/catalog/n900.htm.
A wall poster with the story of the history of the license plate can be downloaded from http://www.unix.org/Posters/
Q27. How do I get permission to excerpt materials from the standard for reuse in my product?
All queries regarding permission to reproduce sections of the standard should be sent to austin-group-permissions at Open Group . Permission needs to be granted by both copyright holders, The IEEE and The Open Group.
Q28. How do I add a question to this FAQ?
Send the question (preferably with a proposed answer) to Andrew Josey.

105
Zim/Programme/APUE/FAQ/TCP-IP_FAQ.txt Normal file
View File

@@ -0,0 +1,105 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T13:34:37+08:00
====== TCP-IP FAQ ======
Created 星期二 07 六月 2011
http://www.itprc.com/tcpipfaq/default.htm
Archive-name: internet/tcp-ip/tcp-ip-faq/contents
Version: 5.15
Posting-Frequency: monthly (first Friday)
Maintainer: tcp-ip-faq@eng.sun.com (Mike Oliver)
URL: http://www.itprc.com/tcpipfaq/default.htm
TCP/IP Frequently Asked Questions
Table of Contents
This is the Table of Contents for the Frequently Asked Questions (FAQ) list for the comp.protocols.tcp-ip Usenet newsgroup. The FAQ provides answers to a selection of common questions on the various protocols (IP, TCP, UDP, ICMP and others) that make up the TCP/IP protocol suite. It is posted to the news.answers, comp.answers and comp.protocols.tcp-ip newsgroups on or about the first Friday of every month.
The FAQ is posted in two parts. Part 1 contains answers to general questions and questions that concern the fundamental components of the suite. Part 2 contains answers to questions concerning common applications that depend on the TCP/IP suite for their network connectivity.
Comments on this document can be emailed to the FAQ maintainer at <tcp-ip-faq@eng.sun.com>.
FAQ Part 1: Introduction and Fundamental Protocols
Administrivia
Where can I find an up-to-date copy of this FAQ?
Who wrote this FAQ?
About TCP/IP
What is TCP/IP?
How is TCP/IP defined?
Where can I find RFC's?
How do I find the right RFC?
About IP
What is IP?
How is IP carried on a network?
Does IP Protect Data on the Network?
What is ARP?
What is IPv6?
What happened to IPv5?
What is the 6bone?
What is the MBONE?
What is IPsec?
About TCP
What is TCP?
How does TCP try to avoid network meltdown?
How do applications coexist over TCP and UDP?
Where do I find assigned port numbers?
About UDP
What is UDP?
About ICMP
What is ICMP?
TCP/IP Network Operations
How can I measure the performance of an IP link?
What IP addresses should I assign to machines on a private internet?
Can I set up a gateway to the Internet that translates IP addresses, so that I don't have to change all our internal addresses to an official network?
Can I use a single bit subnet?
TCP/IP Protocol Implementations
Where can I find TCP/IP source code?
Where can I find TCP/IP application source code?
Where can I find IPv6 source code?
Further Sources of Information
What newsgroups deal with TCP/IP?
Are there any good books on TCP/IP?
FAQ Part 2 -- Applications and Application Programming
What Are The Common TCP/IP Application Protocols?
DHCP
DNS
FTP
HTTP
IMAP
NFS
NNTP
NTP
POP
Rlogin
Rsh
SMTP
SNMP
Ssh
Telnet
X Window System
TCP/IP Programming
What are sockets?
How can I detect that the other end of a TCP connection has crashed?
Can TCP keepalive timeouts be configured?
Are there object-oriented network programming tools?

990
Zim/Programme/APUE/FAQ/TCP-IP_FAQ/Frequently_Asked_Questions_(1999-09)_Part_1_of_2.txt Normal file
View File

@@ -0,0 +1,990 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T13:35:35+08:00
====== Frequently Asked Questions (1999-09) Part 1 of 2 ======
Created 星期二 07 六月 2011
From: tcp-ip-faq@eng.sun.com (TCP/IP FAQ Maintainer)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP/IP FAQ; Frequently Asked Questions (1999-09) Part 1 of 2
Date: 7 Sep 1999 03:36:53 GMT
Message-ID: <tcp-ip-faq-1.1999-09@eng.sun.com>
Summary: Part 1 of a 2-part informational posting that contains
responses to common questions on basic TCP/IP network
protocols and applications.
X-Disclaimer: Approval for postings in *.answers is based on form, not content.
Archive-name: internet/tcp-ip/tcp-ip-faq/part1
Version: 5.15
Last-modified: 1999-09-06 20:11:43
Posting-Frequency: monthly (first Friday)
Maintainer: tcp-ip-faq@eng.sun.com (Mike Oliver)
URL: http://www.itprc.com/tcpipfaq/default.htm
TCP/IP Frequently Asked Questions
Part 1: Introduction and Fundamental Protocols
This is Part 1 of the Frequently Asked Questions (FAQ) list for the
comp.protocols.tcp-ip Usenet newsgroup. The FAQ provides answers to a
selection of common questions on the various protocols (IP, TCP, UDP,
ICMP and others) that make up the TCP/IP protocol suite. It is posted
to the news.answers, comp.answers and comp.protocols.tcp-ip newsgroups
on or about the first Friday of every month.
The FAQ is posted in two parts. Part 1 contains answers to general
questions and questions that concern the fundamental components of the
suite. Part 2 contains answers to questions concerning common
applications that depend on the TCP/IP suite for their network
connectivity.
Comments on this document can be emailed to the FAQ maintainer at
<tcp-ip-faq@eng.sun.com>.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table of Contents
FAQ Part 1: Introduction and Fundamental Protocols
Administrivia
1. Where can I find an up-to-date copy of this FAQ?
2. Who wrote this FAQ?
About TCP/IP
1. What is TCP/IP?
2. How is TCP/IP defined?
3. Where can I find RFC's?
4. How do I find the right RFC?
About IP
1. What is IP?
2. How is IP carried on a network?
3. Does IP Protect Data on the Network?
4. What is ARP?
5. What is IPv6?
6. What happened to IPv5?
7. What is the 6bone?
8. What is the MBONE?
9. What is IPsec?
About TCP
1. What is TCP?
2. How does TCP try to avoid network meltdown?
3. How do applications coexist over TCP and UDP?
4. Where do I find assigned port numbers?
About UDP
1. What is UDP?
About ICMP
1. What is ICMP?
TCP/IP Network Operations
1. How can I measure the performance of an IP link?
2. What IP addresses should I assign to machines on a private
internet?
3. Can I set up a gateway to the Internet that translates IP
addresses, so that I don't have to change all our internal
addresses to an official network?
4. Can I use a single bit subnet?
TCP/IP Protocol Implementations
1. Where can I find TCP/IP source code?
2. Where can I find TCP/IP application source code?
3. Where can I find IPv6 source code?
Further Sources of Information
1. What newsgroups deal with TCP/IP?
2. Are there any good books on TCP/IP?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Administrivia
1. Where can I find an up-to-date copy of this FAQ?
You can browse a hyperlinked version of this FAQ on the World Wide
Web at <http://www.itprc.com/tcpipfaq/default.htm> in the US
(thanks to Irwin Lazar) and at
<http://t2.technion.ac.il/~s2845543/tcpip-faq/default.htm> in
Israel (thanks to Uri Raz). Links to RFC's from Irwin's site refer
to the ISI RFC repository in the US, while links to RFC's from
Uri's site refer to the RFC repository at Imperial College in the
UK. Use whichever gives you better response time.
The current version of this FAQ is posted on a monthly basis to
the news.answers, comp.answers and comp.protocols.tcp-ip
newsgroups.
A plaintext copy of the most recently posted version of the FAQ is
available by anonymous FTP from
<ftp://rtfm.mit.edu/pub/faqs/internet/tcp-ip/tcp-ip-faq/>.
2. Who wrote this FAQ?
This FAQ was compiled from Usenet postings and email contributions
made by many people, including: Rui Duarte Tavares Bastos, Mark
Bergman, Stephane Bortzmeyer, Rodney Brown, Dr. Charles E.
Campbell Jr., James Carlson, Phill Conrad, Alan Cox, Michael
Hunter, Jay Kreibrich, William Manning, Barry Margolin, Vic
Metcalfe, Jim Muchow, George V. Neville-Neil, Dang Thanh Ngan,
Subu Rama, Uri Raz, and W. Richard Stevens.
The FAQ is currently maintained by Mike Oliver. Comments,
criticisms and contributions should be mailed to
<tcp-ip-faq@eng.sun.com>. Please do not send TCP/IP questions to
this address; it is intended only for FAQ issues. If you have a
question that is not already answered by the material in this FAQ
you will get a much faster (and probably more accurate) response
by posting the question to the comp.protocols.tcp-ip newsgroup
than you will by sending it to the FAQ maintainer.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
About TCP/IP
1. What is TCP/IP?
TCP/IP is a name given to the collection (or suite) of networking
protocols that have been used to construct the global Internet.
The protocols are also referred to as the DoD (dee-oh-dee) or
Arpanet protocol suite because their early development was funded
by the Advanced Research Projects Agency (ARPA) of the US
Department of Defense (DoD).
The TCP/IP name is taken from two of the fundamental protocols in
the collection, IP and TCP. Other core protocols in the suite are
UDP and ICMP. These protocols work together to provide a basic
networking framework that is used by many different application
protocols, each tuned to achieving a particular goal.
TCP/IP protocols are not used only on the Internet. They are also
widely used to build private networks, called internets (spelled
with a small 'i'), that may or may not be connected to the global
Internet (spelled with a capital 'I'). An internet that is used
exclusively by one organization is sometimes called an intranet.
2. How is TCP/IP defined?
All of the protocols in the TCP/IP suite are defined by documents
called Requests For Comments (RFC's). An important difference
between TCP/IP RFC's and other (say, IEEE or ITU) networking
standards is that RFC's are freely available online.
RFC's can be composed and submitted for approval by anyone.
Standards RFC's are often the product of many weeks or months of
discussion between interested parties designated as working
groups, during which time drafts of the proposed RFC are
continually updated and made available for comment. These
discussions typically take place on open mailing lists which
welcome input from all quarters. The RFC approval process is
managed by the Internet Engineering Steering Group (IESG) based on
recommendations from the Internet Engineering Task Force (IETF)
which is a prime mover in the formation of working groups focused
on strategic TCP/IP issues. You can find out more about IESG and
IETF activities from the IETF home page at
<http://www.ietf.org/>.
Not all RFC's specify TCP/IP standards. Some RFC's contain
background information, some provide hints for managing an
internet, some document protocol weaknesses in the hope that they
might be addressed by future standards, and some are entirely
humorous.
3. Where can I find RFC's?
The Definitive RFC Repository
The official and definitive RFC repository is the anonymous FTP
archive maintained by the Information Sciences Institute of the
University of Southern California at <ftp://ftp.isi.edu/in-notes>.
It is reachable via the Web at <http://www.rfc-editor.org/>.
RFC Repository Mirror Sites
The RFC repository is mirrored at many sites on the Internet, and
you may get a faster response from a local archive than you would
from the often-overworked ISI site. Primary mirrors are updated at
the same time as the ISI site. Secondary mirrors may lag by a few
hours or days. The current primary mirror sites are:
In the USA ...
Missouri:
<ftp://wuarchive.wustl.edu/doc/rfc>
New Jersey:
<ftp://nisc.jvnc.net/>
North Carolina:
<ftp://ftp.ncren.net/rfc>
Texas:
<ftp://ftp.sesqui.net/pub/>
In Europe ...
France:
<ftp://ftp.imag.fr/pub/archive/IETF/rfc>
Italy:
<ftp://ftp.nic.it/rfc>
UK:
<ftp://src.doc.ic.ac.uk/rfc>
Secondary mirror sites are listed in a document named
rfc-retrieval.txt which can be found alongside the RFC's
themselves at any of the above sites.
RFC's by Email
If you don't have direct access to the Internet but are able to
send and receive email then you can still get RFC's through
various email-to-ftp gateways. For instructions on how to do this,
send email containing the text:
help: ways_to_get_rfcs
to <rfc-info@isi.edu>.
4. How do I find the right RFC?
There are over 2500 RFC's. Each RFC is known by a number. For
instance, RFC 1180 presents a tutorial on TCP/IP, RFC 1920 lists
the current standards RFC's and explains the RFC standards
process, and RFC 1941 is a FAQ list on the topic of Internet
deployment in educational establishments. RFC numbers are assigned
in ascending order as each RFC is approved.
The RFC files in the archive are named rfcNNNN.txt where NNNN is
the number of the RFC. For instance, the text of RFC 822 is
contained in the file named rfc822.txt. A small number of RFC's
are also available in PostScript format, in which case a file
named rfcNNNN.ps will exist in addition to the .txt file.
Basic information (number, title, author, publication date and so
on) on all of the RFC's is contained in the RFC index document
named rfc-index.txt which you can find alongside the RFC's at any
of the RFC archive sites. If you don't know which RFC's you need,
the index is a good place to start. The index also indicates the
current status of each RFC. The content of an RFC does not change
once the RFC has been published, but since TCP/IP is in a constant
state of evolution the information in one RFC is often revised,
extended, clarified and in some cases completely superseded by
later RFC's. Annotations in the index indicate when this is the
case.
If you find yourself using the index a lot then you might find it
convenient to create your own HTML version of the index. Wayne
Mesard has published a Perl script that takes the plaintext index
file as input and produces an HTML version with hyperlinks to your
chosen RFC FTP repository or to your own local RFC archive. The
script is available at
<ftp://ftp.ibnets.com/pub/wmesard/>.
If you don't want to wade through the index, some sites provide
the ability to search the RFC catalogue by keyword:
Keyword Searches on the Web
<http://www.faqs.org/rfcs/> lets you search on RFC content.
<http://web.nexor.co.uk/public/rfc/index/rfc.html> and
<http://www.csl.sony.co.jp/rfc/> let you search on words in the
RFC title.
Keyword Searches via gopher
<gopher://r2d2.jvnc.net/11/Internet%20Resources/RFC> or
<gopher://muspin.gsfc.nasa.gov:4320/1g2go4%20ds.internic.net%2070%201%201/.ds/.internetdocs>
RFC Keyword Searches via WAIS
<wais://wais.cnam.fr/RFC>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
About IP
1. What is IP?
Internet Protocol (IP) is the central, unifying protocol in the
TCP/IP suite. It provides the basic delivery mechanism for packets
of data sent between all systems on an internet, regardless of
whether the systems are in the same room or on opposite sides of
the world. All other protocols in the TCP/IP suite depend on IP to
carry out the fundamental function of moving packets across the
internet.
In terms of the OSI networking model, IP provides a Connectionless
Unacknowledged Network Service, which means that its attitude to
data packets can be characterised as "send and forget". IP does
not guarantee to actually deliver the data to the destination, nor
does it guarantee that the data will be delivered undamaged, nor
does it guarantee that data packets will be delivered to the
destination in the order in which they were sent by the source,
nor does it guarantee that only one copy of the data will be
delivered to the destination.
Because it makes so few guarantees, IP is a very simple protocol.
This means that it can be implemented fairly easily and can run on
systems that have modest processing power and small amounts of
memory. It also means that IP demands only minimal functionality
from the underlying medium (the physical network that carries
packets on behalf of IP) and can be deployed on a wide variety of
networking technologies.
The no-promises type of service offered by IP is not directly
useful to many applications. Applications usually depend on TCP or
UDP to provide assurances of of data integrity and (in TCP's case)
ordered and complete data delivery.
The fundamentals of IP are defined in RFC 791. RFC 1122 summarises
the requirements that must be met by an IP implementation in an
Internet host, and RFC 1812 summarises the IP requirements for an
Internet router.
2. How Is IP Carried On A Network?
IP really isn't very fussy about how its packets are transported.
The details of how an IP packet is carried over a particular kind
of network are usually chosen to be convenient for the network
itself. As long as the transmitter and receiver observe some
convention that allows IP packets to be differentiated from any
other data that might be seen by the receiver, then IP can be used
to carry data between those stations.
On a LAN, IP is carried in the data portion of the LAN frame and
the frame header contains additional information that identifies
the frame an an IP frame. Different LAN's have different
conventions for carrying that additional information. On an
Ethernet the Ethertype field is used; a value of 0x0800 identifies
a frame that contains IP data. FDDI and Token Ring use frames that
conform to IEEE 802 Logical Link Control, and on those LAN's IP is
carried in Unnumbered Information frames with Source and
Destination LSAP's of 0xAA and a SNAP header of 00-00-00-08-00.
The only thing that IP cares strongly about is the maximum size of
a frame that can be carried on the medium. This controls whether,
and to what extent, IP must break down large data packets into a
train of smaller packets before arranging for them to be
transmitted on the medium. This activity is called "fragmentation"
and the resulting smaller and incomplete packets are called
"fragments". The final destination is responsible for rebuilding
the original IP packet from its fragments, an activity called
"fragment reassembly".
3. Does IP Protect Data On The Network?
IP itself does not guarantee to deliver data correctly. It leaves
all issues of data protection to the transport protocol. Both TCP
and UDP have mechanisms that guarantee that the data they deliver
to an application is correct.
IP does try to protect the packet's IP header, the relatively
small part of each packet that controls how the packet is moved
through the network. It does this by calculating a checksum on the
header fields and including that checksum in the transmitted
packet. The receiver verifies the IP header checksum before
processing the packet. Packets whose checksums no longer match
have been damaged in some way and are simply discarded.
The IP checksum is discussed in detail in RFC 1071, which also
includes sample code for calculating the checksum. RFC 1141 and
RFC 1624 describe incremental modification of an existing
checksum, which can be useful in machines such as routers which
modify fields in the IP header while forwarding a packet and
therefore need to compute a new header checksum.
The same checksum algorithm is used by TCP and UDP, although they
include the data portion of the packet (not just the header) in
their calculations.
4. What is ARP?
Address Resolution Protocol (ARP) is a mechanism that can be used
by IP to find the link-layer station address that corresponds to a
particular IP address. It defines a method that is used to ask,
and answer, the question "what MAC address corresponds to a given
IP address?". ARP sends broadcast frames to obtain this
information dynamically, so it can only be used on media that
support broadcast frames. Most LAN's (including Ethernet, FDDI,
and Token Ring) have a broadcast capability and ARP is used when
IP is running on those media. ARP is defined in RFC 826. That
definition assumes an Ethernet LAN. Additional details for ARP on
networks that use IEEE 802.2 frame formats (IEEE 802.3 CSMA/CD,
IEEE 802.4, IEEE 802.5 Token Ring) are in RFC 1042. ARP on FDDI is
described in RFC 1390.
When IP is runnning over non-broadcast media (say, X.25 or ATM)
some other mechanism is used to match IP addresses to media
addresses. IP really doesn't care how the media address is
obtained.
RFC 903 defines Reverse ARP (RARP) which lets a station ask the
question "which IP address corresponds to a given MAC address?".
RARP is typically used to let a piece of diskless equipment
discover its own IP address as part of its boot procedure. RARP is
rarely used by modern equipment; it has been supplanted by the
Boot Protocol (BOOTP) defined in RFC 1542. BOOTP in turn is being
supplanted by the Dynamic Host Configuration Protocol (DHCP).
5. What is IPv6?
IP Version 6 (IPv6) is the newest version of IP, sometimes called
IPng for "IP, Next Generation". IPv6 is fairly well defined but is
not yet widely deployed. The main differences between IPv6 and the
current widely-deployed version of IP (which is IPv4) are:
o IPv6 uses larger addresses (128 bits instead of 32 bits in
IPv4) and so can support many more devices on the network,
and
o IPv6 includes features like authentication and multicasting
that had been bolted on to IPv4 in a piecemeal fashion over
the years.
Information on IPv6 can be found on the IPv6 home page at
<http://playground.sun.com/pub/ipng/html/ipng-main.html>
6. What happened to IPv5?
Or, ""Why are we skipping from IPv4 to IPv6?"
IPv5 never existed. The version number "5" in the IP header was
assigned to identify packets carrying an experimental non-IP
real-time stream protocol called ST. ST was never widely used, but
since the version number 5 had already been allocated the new
version of IP was given its own unique identifying number, 6. ST
is described in RFC 1819.
7. What is the 6bone?
The 6bone is the experimental IPv6 backbone being developed using
IPv6-in-IPv4 tunnels. This is intended for early experimentation
with IPv6 and is not a production service.
8. What is the MBONE?
The Multicast backBONE (MBONE) is a multicast-capable portion of
the Internet backbone. Multicast support over IP is provided by a
protocol called IGMP (Internet Group Management Protocol) which is
defined in RFC 1112. The MBONE is still a research prototype, but
it extends through most of the core of the Internet (including
North America, Europe, and Australia). It is typically used to
relay multimedia (audio and low bandwidth video) presentations
from a single source to multiple receiving sites dispersed over
the Internet.
A slightly dated MBONE FAQ is available by anonymous FTP from
<ftp://ftp.isi.edu/mbone/faq.txt>.
9. What is IPsec?
IPsec stands for "IP Security". The IPsec working group of the
IETF is developing standards for cryptographic authentication and
for encryption within IP. The base specifications are defined in
RFC's 1825, 1826 and 1827. Products that implement these are
beginning to appear.
A freely distributable implementation of IPsec for IPv4 and IPsec
for IPv6 is included in the NRL IPv6/IPsec distribution for
4.4-Lite BSD. The NRL software is available from
<http://web.mit.edu/network/isakmp/> (for distribution within the
US only), from
<http://www.cisco.com/public/library/isakmp/ipsec.html> (for
distribution within the US and Canada), and from
<ftp://ftp.ripe.net/ipv6/nrl/> (for unrestricted distribution).
(Some countries consider encryption software to have military
significance and so restrict the export and import of such
software, which is why there are geographical restrictions on the
areas served by the above sites.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
About TCP
1. What is TCP?
Transmission Control Protocol (TCP) provides a reliable
byte-stream transfer service between two endpoints on an internet.
TCP depends on IP to move packets around the network on its
behalf. IP is inherently unreliable, so TCP protects against data
loss, data corruption, packet reordering and data duplication by
adding checksums and sequence numbers to transmitted data and, on
the receiving side, sending back packets that acknowledge the
receipt of data.
Before sending data across the network, TCP establishes a
connection with the destination via an exchange of management
packets. The connection is destroyed, again via an exchange of
management packets, when the application that was using TCP
indicates that no more data will be transferred. In OSI terms, TCP
is a Connection-Oriented Acknowledged Transport protocol.
TCP has a multi-stage flow-control mechanism which continuously
adjusts the sender's data rate in an attempt to achieve maximum
data throughput while avoiding congestion and subsequent packet
losses in the network. It also attempts to make the best use of
network resources by packing as much data as possible into a
single IP packet, although this behaviour can be overridden by
applications that demand immediate data transfer and don't care
about the inefficiencies of small network packets.
The fundamentals of TCP are defined in RFC 793, and later RFC's
refine the protocol. RFC 1122 catalogues these refinements as of
October 1989 and summarises the requirements that a TCP
implementation must meet.
TCP is still being developed. For instance, RFC 1323 introduces a
TCP option that can be useful when traffic is being carried over
high-capacity links. It is important that such developments are
backwards-compatible. That is, a TCP implementation that supports
a new feature must continue to work with older TCP implementations
that do not support that feature.
2. How does TCP try to avoid network meltdown?
TCP includes several mechanisms that attempt to sustain good data
transfer rates while avoiding placing excessive load on the
network. TCP's "Slow Start", "Congestion Avoidance", "Fast
Retransmit" and "Fast Recovery" algorithms are summarised in RFC
2001. TCP also mandates an algorithm that avoids "Silly Window
Syndrome" (SWS), an undesirable condition that results in very
small chunks of data being transferred between sender and
receiver. SWS Avoidance is discussed in RFC 813. The "Nagle
Algorithm", which prevents the sending side of TCP from flooding
the network with a train of small frames, is described in RFC
896.
Van Jacobson has done significant work on this aspect of TCP's
behaviour. The FAQ used to contain a couple of pieces of
historically interesting pieces of Van's email concerning an early
implementation of congestion avoidance, but in the interests of
saving space they've been removed and can instead be obtained by
anonymous FTP from the end-to-end mailing list archive at
<ftp://ftp.isi.edu/end2end/end2end-1990.mail>. PostScript slides
of a presentation on this implementation of congestion avoidance
can be obtained by anonymous FTP from
<ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z>.
That directory contains several other interesting TCP-related
papers, including one
(<ftp://ftp.ee.lbl.gov/papers/fastretrans.ps>) by Sally Floyd that
discusses a algorithm that attempts to give TCP the ability to
recover quickly from packet loss in a network.
3. How do applications coexist over TCP and UDP?
Each application running over TCP or UDP distinguishes itself from
other applications using the service by reserving and using a
16-bit port number. Destination and source port numbers are placed
in the UDP and TCP headers by the originator of the packet before
it is given to IP, and the destination port number allows the
packet to be delivered to the intended recipient at the
destination system.
So, a system may have a Telnet server listening for packets on TCP
port 23 while an FTP server listens for packets on TCP port 21 and
a DNS server listens for packets on port 53. TCP examines the port
number in each received frame and uses it to figure out which
server gets the data. UDP has its own similar set of port
numbers.
Many servers, like the ones in this example, always listen on the
same well-known port number. The actual port number is arbitrary,
but is fixed by tradition and by an official allocation or
"assignment" of the number by the Internet Assigned Numbers
Authority (IANA).
4. Where do I find assigned port numbers?
The IANA allocates and keeps track of all kinds of arbitrary
numbers used by TCP/IP, including well-known port numbers. The
entire collection is published periodically in an RFC called the
Assigned Numbers RFC, each of which supersedes the previous one in
the series. The current Assigned Numbers RFC is RFC 1700.
The Assigned Numbers document can also be obtained directly by FTP
from the IANA at <ftp://ftp.isi.edu/in-notes/iana/assignments>.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
About UDP
1. What is UDP?
User Datagram Protocol (UDP) provides an unreliable packetized
data transfer service between endpoints on an internet. UDP
depends on IP to move packets around the network on its behalf.
UDP does not guarantee to actually deliver the data to the
destination, nor does it guarantee that data packets will be
delivered to the destination in the order in which they were sent
by the source, nor does it guarantee that only one copy of the
data will be delivered to the destination. UDP does guarantee data
integrity, and it does this by adding a checksum to the data
before transmission. (Some machines run with UDP checksum
generation disabled, in which case data corruption or truncation
can go undetected. Very few people think this is a good idea.)
The fundamentals of UDP are defined in RFC 768. RFC 1122
summarises the requirements that a UDP implementation must meet.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
About ICMP
1. What is ICMP?
Internet Control Message Protocol (ICMP) defines a small number of
messages used for diagnostic and management purposes. ICMP depends
on IP to move packets around the network on its behalf.
The fundamentals of ICMP are defined in RFC 792. RFC 1122
summarises the requirements that must be met by an ICMP
implementation in an Internet host, and RFC 1812 summarises the
ICMP requirements for an Internet router.
ICMP is basically IP's internal network management protocol and is
not intended for use by applications. Two well known exceptions
are the ping and traceroute diagnostic utilities:
o ping sends and receives ICMP "ECHO" packets, where the
response packet can be taken as evidence that the target host
is at least minimally active on the network, and
o traceroute sends UDP packets and infers the route taken to
the target from ICMP "TIME-TO-LIVE EXCEEDED" or "PORT
UNREACHABLE" packets returned by the network. (Microsoft's
TRACERT sends ICMP "ECHO" packets rather than UDP packets,
and so receives ICMP "TIME-TO-LIVE EXCEEDED" or "ECHO
RESPONSE" packets in return.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TCP/IP Network Operations
1. How can I measure the performance of an IP link?
You can get a quick approximation by timing how long it takes to
FTP or RCP a large file over the link, but bear in mind that that
measurement will be skewed by the time spent in dealing with the
local and remote filesystems, not simply with the network itself.
And remember to measure the time it takes to receive a file, not
the time it takes to send it; the sender can report completion
even though large amounts of data are still buffered locally by
TCP and have not yet been delivered to the destination.
Two well-known open-source programs that measure and report
throughput over an IP link without involving the filesystem are:
o TTCP, available for anonymous ftp from the Silicon Graphics
FTP archive at <ftp://ftp.sgi.com/sgi/src/ttcp/>.
o Rick Jones' NETPERF, available on the Web at
<http://www.cup.hp.com/netperf/NetperfPage.html>.
If neither of those tools does what you want then you might find
something that meets your needs in CAIDA's measurement tools list
at <http://www.caida.org/Tools/meastools.html>.
2. What IP addresses should I assign to machines on a private
internet?
You shouldn't use IP addresses that have been assigned to some
other organisation, because if knowledge of your network ever gets
leaked onto the Internet they may disrupt that innocent
organisation's activity. RFC 1918 provides a solution for this
problem by allocating several IP address ranges specifically for
use on private networks. These addresses will never be assigned
to any organisation and are never supposed to appear on the
Internet. The ranges are:
Class A: 10.0.0.0 through 10.255.255.255
Class B: 172.16.0.0 through 172.31.255.255
Class C: 192.168.0.0 through 192.168.255.255
3. Can I set up a gateway to the Internet that translates IP
addresses, so that I don't have to change all our internal
addresses to an official network?
This is called Network Address Translation, or NAT. In general it
is a difficult thing to do properly because many applications
embed IP addresses in the application-level data (FTP's "PORT"
command is a notable example) so NAT isn't simply a matter of
translating addresses in the IP header and recalculating header
checksums. Also, if the network number(s) you're using match those
assigned to another organisation, your gateway may not be able to
communicate with that organisation. As noted above, RFC 1918
proposes network numbers that are reserved for private use, to
avoid such conflicts, but if you're already using a different
network number this won't help you.
However, there are several products that do attempt to provide
this kind of on-the-fly NAT. Linux provides NAT through its "IP
Masquerading" feature, and many firewall and router vendors offer
NAT capabilities in their products -- look for "Network Address
Translation" in your favourite Web search engine to get a list of
vendors. Proxy servers developed for firewalls can also sometimes
be used as a substitute for an address-translating gateway for
particular application protocols. This is discussed in more detail
in the FAQ for the comp.security.firewalls newsgroup. That FAQ can
be viewed on the Web at <http://www.clark.net/pub/mjr/pubs/fwfaq/>.
4. Can I use a single bit subnet?
The answer used to be a straightforward "no", because a 1-bit
subnet can only have a subnet part of all-ones or all-zeroes, both
of which were assigned special meanings when the subnetting
concept was originally defined. (All-ones meant "broadcast, all
subnets of this net" and all-zeroes meant "this subnet, regardless
of its actual subnet number".)
However, the old definition of subnetting has been superseded by
the concept of Classless Inter-Domain Routing (CIDR, pronounced
'cider'). Under CIDR the subnet doesn't really have an existence
of its own and the subnet mask simply provides the mechanism for
isolating an arbitrarily-sized network portion of an IP address
from the remaining host part. As CIDR-aware equipment is deployed
it becomes increasingly like that you will be able to use a 1-bit
subnet with at least some particular combinations of networking
equipment. However, it's still not safe to assume that a 1-bit
subnet will work properly with all kinds of equipment.
As Steinar Haug explains:
From RFC 1122:
> 3.3.6 Broadcasts
>
> Section 3.2.1.3 defined the four standard IP broadcast address
> forms:
> Limited Broadcast: {-1, -1}
> Directed Broadcast: {<Network-number>, -1}
> Subnet Directed Broadcast: {<Network-number>, <Subnet-number>, -1}
> All-Subnets Directed Broadcast: {<Network-number>, -1, -1}
All-Subnets Directed broadcasts are being deprecated in favor of IP
multicast, but were very much defined at the time RFC1122 was written.
Thus a Subnet Directed Broadcast to a subnet of all ones is not
distinguishable from an All-Subnets Directed Broadcast.
For those old systems that used all zeros for broadcast in IP
addresses, a similar argument can be made against the subnet of all
zeros.
Also, for old routing protocols like RIP, a route to subnet zero is not
distinguishable from the route to the entire network number (except
possibly by context).
Most of today's systems don't support variable length subnet masks
(VLSM), and for such systems the above is true. However, all the major
router vendors and *some* Unix systems (BSD 4.4 based ones) support
VLSMs, and in that case the situation is more complicated :-)
With VLSMs (necessary to support CIDR, see RFC 1519), you can utilize
the address space more efficiently. Routing lookups are based on
*longest* match, and this means that you can for instance subnet the
class C net with a mask of 255.255.255.224 (27 bits) in addition to the
subnet mask of 255.255.255.192 (26 bits) given above. You will then be
able to use the addresses x.x.x.33 through x.x.x.62 (first three bits
001) and the addresses x.x.x.193 through x.x.x.222 (first three bits
110) with this new subnet mask. And you can continue with a subnet mask
of 28 bits, etc. (Note also, by the way, that non-contiguous subnet
masks are deprecated.)
This is all very nicely covered in the paper by Havard Eidnes:
Practical Considerations for Network Address using a
CIDR Block Allocation
Proceedings of INET '93
This paper is available with anonymous FTP from
aun.uninett.no:pub/misc/eidnes-cidr.ps.
The same paper, with minor revisions, is one of the articles in the
special Internetworking issue of Communications of the ACM (last month,
I believe).
Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TCP/IP Protocol Implementations
1. Where can I find TCP/IP source code?
Code used in the venerable Net-2 version of Berkeley Unix is
available by anonymous FTP from
<ftp://ftp.uu.net/systems/unix/bsd-sources/sys/netinet> (at UUNet
in Virginia, US) and
<ftp://gatekeeper.dec.com/pub/BSD/net2/sys/> (at Compaq in
California, US).
Source code for the TCP/IP implementations in the current dialects
of BSD Unix is available. Instructions on how to access the
sources through FTP and other methods is detailed on their
respective websites: FreeBSD at <http://www.freebsd.org/>; NetBSD
at <http://www.netbsd.org/>; and OpenBSD at
<http://www.openbsd.org/>.
Source for the Unix-like Linux operating system is at
<http://www.kernel.org/pub/linux/>.
Source for the TCP/IP implementation of the Xinu operating system
discussed in Comer & D. L. Stevens' "Internetworking with TCP/IP
Volume II" is at <ftp://ftp.cs.purdue.edu/pub/Xinu/>.
WATTCP is a DOS TCP/IP stack derived from the NCSA Telnet program
and much enhanced. It is available from many DOS software archive
sites as WATTCP.ZIP. This file includes some example programs and
complete source code. The interface isn't BSD sockets but is well
suited to PC type work.
KA9Q is Phil Karn's network operating system for PC's. It includes
a TCP/IP implementation originally developed for use over packet
radio. Source is available from Phil's website at
<http://people.qualcomm.com/karn/code/ka9qos/>.
2. Where can I find TCP/IP application source code?
Source code for the various TCP/IP applications delivered with the
current BSD Unix flavours is available through the FreeBSD, NetBSD
and OpenBSD websites noted in the previous section.
Linux application source is at <http://www.kernel.org/pub/linux/>.
Much of the application source used by Linux was originally
developed by the GNU Project whose website is at
<http://www.gnu.org/>.
Code from Comer & D. L. Stevens' "Internetworking with TCP/IP
Volume III" is available by anonymous FTP from
<ftp://ftp.cs.purdue.edu/pub/dls/>.
Code from W. R. Stevens' "TCP/IP Illustrated, Volume 1" is
available from
<ftp://ftp.uu.net/published/books/stevens.tcpipiv1.tar.Z>.
Source code for some well-known cross-system TCP/IP applications
(BIND, sendmail, Apache and so on) is available from the various
organisations that sponsor the applications. See Part 2 of the FAQ
for details.
3. Where can I find IPv6 source code?
There are several freely distributable implementations of IPv6,
particularly for BSD and Linux. You can find detailed information at
<http://playground.sun.com/pub/ipng/html/ipng-implementations.html>,
part of the IPv6 home site mentioned above.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Further Sources of Information
1. TCP/IP-related newsgroups and FAQ lists
Collections of newsgroup FAQ documents are archived at many
locations including <http://www.faqs.org/> and
<ftp://rtfm.mit.edu/pub/faqs/>. The following newsgroups are
particularly relevant to TCP/IP:
comp.protocols.tcp-ip covers all of the TCP/IP suite.
comp.protocols.dns.bind covers the BIND suite, which contains
server and client implementations of DNS.
comp.protocols.tcp-ip.domains discusses DNS global
administration and politics.
comp.protocols.nfs covers NFS protocol, implementation, and
administration.
comp.protocols.snmp covers SNMP definition, implementation,
and administration.
comp.protocols.time.ntp covers NTP definition,
implementation, and administration.
comp.protocols.tcp-ip.ibmpc discusses TCP/IP for IBM(-like)
personal computers. The group's FAQ is available at
<ftp://ftp.netcom.com/pub/ma/mailcom/IBMTCP/>.
comp.os.ms-windows.networking.tcp-ip discusses TCP/IP on
Microsoft Windows machines.
comp.os.ms-windows.programmer.tools.winsock covers the
Winsock sockets API on Microsoft Windows machines. The
group's FAQ is available at
<http://www.cyberport.com/~tangent/programming/winsock/>.
comp.os.os2.networking.tcp-ip discusses TCP/IP on OS/2.
comp.dcom.lans.ethernet covers Ethernet and IEEE 802.3 LAN's.
The group's FAQ is available at
<ftp://dorm.rutgers.edu/pub/novell/info_and_docs/Ethernet.FAQ>.
comp.dcom.lans.fddi covers FDDI LAN's.
comp.dcom.lans.token-ring covers IBM Token Ring and IEEE
802.5 LAN's.
comp.dcom.lans.misc covers all other types of LAN.
comp.protocols.ppp covers PPP and SLIP. The group's FAQ is
available at <http://cs.uni-bonn.de/ppp/part1.html>.
comp.dcom.sys.cisco discusses cisco products.
comp.dcom.sys.wellfleet discusses Wellfleet (now Bay
Networks) products.
2. Are there any good books on TCP/IP?
Yes, lots of them, far too many to list here. Uri Raz maintains a
TCP/IP bibliography (the "TCP/IP Resources List") that is posted
to the comp.protocols.tcp-ip newsgroup on a monthly basis. It is
available on the Web at
<http://www.qnx.com/%7Emphunter/tcpip_resources.html> and
<http://www.faqs.org/faqs/internet/tcp-ip/resource-list/index.html>
or can be retrieved by anonymous FTP from
<ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/protocols/tcp-ip/>.
However, a couple of books that always head the list of
recommended reading are:
"Internetworking with TCP/IP Volume I (Principles, Protocols,
and Architecture)" by Douglas E. Comer, published by Prentice
Hall, 1991 (ISBN 0-13-468505-9). This is an introductory book
which covers all of the fundamental protocols, including IP,
UDP, TCP, and the gateway protocols. It also discusses some
higher level protocols such as FTP, Telnet, and NFS.
"TCP/IP Illustrated, Volume 1: The Protocols" by W. Richard
Stevens, published by Addison-Wesley, 1994 (ISBN
0-201-63346-9). This book explains the TCP/IP protocols and
several application protocols in exquisite detail. It
contains many real-life traces of the protocols in action,
which is especially valuable for people who need to
understand the protocols in depth.
If you're writing programs that use TCP/IP then the classic text
is "Unix Network Programming" by W. Richard Stevens, published by
Prentice Hall, 1990 (ISBN 0-13-949876-1). It's now being rewritten
as a three volume set. The first volume "Unix Network Programming:
Networking APIs: Sockets and Xti" published by Prentice Hall, 1997
(ISBN 013490012X), contains just about everything you need to know
about using TCP/IP and includes material on topics (eg IPv6,
multicasting, threads) that are not covered in the original UNP.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This compilation contains the opinions of the FAQ maintainer and the
various FAQ contributors. Any resemblance to the opinions of the FAQ
maintainer's employer is entirely coincidental.
Copyright (C) Mike Oliver 1997-1999. All Rights Reserved.

491
Zim/Programme/APUE/FAQ/TCP-IP_FAQ/Frequently_Asked_Questions_(1999-09)_Part_2_of_2.txt Normal file
View File

@@ -0,0 +1,491 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T13:36:12+08:00
====== Frequently Asked Questions (1999-09) Part 2 of 2 ======
Created 星期二 07 六月 2011
From: tcp-ip-faq@eng.sun.com (TCP/IP FAQ Maintainer)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP/IP FAQ; Frequently Asked Questions (1999-09) Part 2 of 2
Date: 7 Sep 1999 03:38:45 GMT
Message-ID: <tcp-ip-faq-2.1999-09@eng.sun.com>
Summary: Part 2 of a 2-part informational posting that contains
responses to common questions on basic TCP/IP network
protocols and applications.
X-Disclaimer: Approval for postings in *.answers is based on form, not content.
Archive-name: internet/tcp-ip/tcp-ip-faq/part2
Version: 5.15
Last-modified: 1999-09-06 20:11:43
Posting-Frequency: monthly (first Friday)
Maintainer: tcp-ip-faq@eng.sun.com (Mike Oliver)
URL: http://www.itprc.com/tcpipfaq/default.htm
TCP/IP Frequently Asked Questions
Part 2: Applications and Application Programming
This is Part 2 of the Frequently Asked Questions (FAQ) list for the
comp.protocols.tcp-ip Usenet newsgroup. The FAQ provides answers to a
selection of common questions on the various protocols (IP, TCP, UDP,
ICMP and others) that make up the TCP/IP protocol suite. It is posted
to the news.answers, comp.answers and comp.protocols.tcp-ip newsgroups
on or about the first Friday of every month.
The FAQ is posted in two parts. Part 1 contains answers to general
questions and questions that concern the fundamental components of the
suite. Part 2 contains answers to questions concerning common
applications that depend on the TCP/IP suite for their network
connectivity.
Comments on this document can be emailed to the FAQ maintainer at
<tcp-ip-faq@eng.sun.com>.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table of Contents
FAQ Part 2 -- Applications and Application Programming
What Are The Common TCP/IP Application Protocols?
1. DHCP
2. DNS
3. FTP
4. HTTP
5. IMAP
6. NFS
7. NNTP
8. NTP
9. POP
10. Rlogin
11. Rsh
12. SMTP
13. SNMP
14. Ssh
15. Telnet
16. X Window System
TCP/IP Programming
1. What are sockets?
2. How can I detect that the other end of a TCP connection has
crashed?
3. Can TCP keepalive timeouts be configured?
4. Are there object-oriented network programming tools?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
What Are The Common TCP/IP Application Protocols?
1. DHCP
Dynamic Host Configuration Protocol (DHCP) allows IP addresses to
be allocated to hosts on an as-needed basis. The conventional
scheme of allocating a permanent fixed IP address to every host is
wasteful of addresses in situations where only a relatively small
number of hosts are active at any given time. DHCP lets a host
'borrow' an IP address from a pool of IP addresses; when the
address is no longer needed it is recycled and made available for
use by some other host. DHCP also allows a host to retrieve a
variety of configuration information at the same time as it
acquires an IP address.
DCHP depends on UDP to carry packets between the client and server
tasks.
DHCP is defined by RFC's 2131 and 2132. A widely-used
implementation of DHCP can be downloaded from
<http://www.isc.org/dhcp.html>.
2. DNS
The Domain Name System (DNS) provides dynamic on-demand
translation between human-readable names (like www.pizzahut.com)
and the numeric addresses actually used by IP (like
192.112.170.243). The basics of DNS operation are defined in RFC's
1034, 1101, 1876, 1982 and 2065.
DNS uses both UDP and TCP. It used UDP to carry simple queries and
responses but depends on TCP to guarantee the correct and orderly
delivery of large amounts of bulk data (eg transfers of entire
zone configurations) across the network.
DNS standards are discussed in the comp.protocols.dns.std
newsgroup. A very widely-used implementation of DNS called BIND
(Berkeley Internet Name Domain) is discussed in the
comp.protocols.dns.bind newsgroup, and the BIND software itself
can be downloaded from <http://www.isc.org/bind.html>. The
operation and politics of DNS are discussed in the
comp.protocols.tcp-ip.domains newsgroup.
3. FTP
File Transfer Protocol (FTP) provides a mechanism for moving data
files between systems. In addition to the fundamental PUT and GET
operations, FTP provides a small number of file management and
user authentication facilities. The protocol is defined in RFC
959.
FTP depends on TCP to guarantee the correct and orderly delivery
of data across the network.
4. HTTP
Hyper Text Transfer Protocol (HTTP) is the protocol used to move
Web pages across an internet. Version 1.0 of HTTP is defined by
RFC 1945. Version 1.1 makes more efficient use of TCP and is
defined by RFC 2068.
HTTP depends on TCP to guarantee the correct and orderly delivery
of data across the network.
5. IMAP
Interactive Mail Access Protocol (IMAP) allows clients to
manipulate email messages and mailboxes that reside on some server
machine. The current version of IMAP is Version 4, usually
referred to as IMAP4. IMAP4 is described by RFC 2060. IMAP
provides no way of sending email; client programs that use IMAP to
read mail usually use SMTP to send messages. IMAP is more powerful
and more complex than the other widely-used mail-reading protocol
POP.
IMAP depends on TCP to guarantee the correct and orderly delivery
of data across the network.
IMAP is discussed in the comp.mail.imap newsgroup.
6. NFS
Network File System (NFS) allows files stored on one machine (the
"server") to be accessed by other machines (the "clients") as
though the files were actually present on the client systems. NFS
is defined in terms of a Remote Procedure Call (RPC) abstraction
which in turn formats its packets according to a
processor-independent eXternal Data Representation (XDR).
Version 2 of NFS is defined in RFC 1094 and Version 3 is defined
in RFC 1813. The RPC mechanism most often used with NFS, ONC/RPC,
is defined by RFC 1831. The XDR conventions used by ONC/RPC are
defined by RFC 1832. The ONC/RPC binding mechanism (a minimal
directory service which allows RPC clients to rendezvous with RPC
servers) is defined by RFC 1833.
NFS can run over any kind of transport, but is most often used
over UDP. UDP does not guarantee packet delivery or ordering, so
when NFS runs over UDP the RPC implementation must provide its own
guarantees of correctness. When NFS runs over TCP, the RPC layer
can depend on TCP to provide this kind of correctness.
NFS is discussed in the comp.protocols.nfs newsgroup.
7. NNTP
Network News Transfer Protocol (NNTP) is used to propagate netnews
postings (including Usenet postings) between systems. It is
defined in RFC 977. (The format of netnews messages is defined in
RFC 1036.)
NNTP depends on TCP to guarantee the correct and orderly delivery
of data across the network.
NNTP is discussed in the news.software.nntp newsgroup. A very
widely-used implementation of NNTP called INN (InterNet News) can
be downloaded from <http://www.isc.org/inn.html>.
8. NTP
Network Time Protocol (NTP) is used to synchronise time-of-day
clocks between various computer systems. The current version of
NTP is Version 3, defined in RFC 1305. Earlier versions (2 and 1
respectively) of the protocol are defined in RFC's 1119 and 1059.
David Mills maintains a publically-available implementation of NTP
server and clients along with a comprehensive collection of NTP
documentation on the web at <http://www.eecis.udel.edu/%7Entp/>.
NTP depends on UDP to carry packets between server and client
tasks.
NTP is discussed in the comp.protocols.time.ntp newsgroup.
9. POP
Post Office Protocol (POP) allows clients to read and remove email
from a mailbox that resides on some server machine. The current
version of POP is Version 3, usually referred to as POP3. It is
described by RFC 1939. POP provides no way of sending email;
client programs that use POP to read mail usually use SMTP to send
messages. POP is simpler and less powerful than the other
widely-used mail-reading protocol IMAP.
POP depends on TCP to guarantee the correct and orderly delivery
of data across the network.
POP doesn't have its own dedicated newsgroup. It is sometimes
discussed in client-specific newsgroups in the comp.mail.*
hierarchy.
10. Rlogin
Remote Login (rlogin) provides a network terminal or "remote
login" capability. Rlogin is similar to Telnet but it adds a
couple of features that make it a little more convenient than
Telnet.
Rlogin is one of the so-called Berkeley r-commands, (where the "r"
stands for "remote") a family of commands created at UC Berkeley
during the development of BSD Unix to provide access to remote
systems in ways that are more convenient than the original TCP/IP
commands.
The most obvious convenience is that rlogin, like other
r-commands, examines a .rhosts (pronounced "dot ar hosts") file on
the server side to authenticate logins based on the client host
address. The .rhosts file can be constructed to allow remote
access without requiring you to enter a password. If used
improperly this feature can be a security threat, but if used
correctly it can actually enhance security by not requiring a
password to be sent over the network where it might be read by a
packet sniffer.
The r-commands depend on TCP to guarantee the correct and orderly
delivery of data across the network.
11. Rsh
Remote Shell (rsh) is an r-command that provides for remote
execution of arbitrary commands. It allows you to run a command on
a server without having to actually log in on the server. More
importantly it allows you to feed data to the remote command and
retrieve the command's output without having to stage the data
through temporary files on the server.
Like other Berkeley r-commands, rsh uses the .rhosts file on the
server side to authenticate access based on the client's host
address.
On some non-BSD systems the Remote Shell command is named remsh
because by the time the command was delivered on those systems the
usual rsh name had been used for a "restricted shell" application,
a command line interpreter intended to boost security by
preventing its users from performing certain activities.
On Unix systems most of the work of rsh is handled by the rcmd(3)
library function, so if you're writing a program that needs
rsh-like functionality then you might be able to use that
function. However, since the rsh protocol requires the client to
use a privileged port you'll only be able to use rcmd(3) if your
program executes with superuser privileges. That's why the rsh
executable is setuid-root on Unix machines.
If your program will not run as root then you might be able to use
the rexec(3) function instead. rexec(3) does not use the
server-side .rhosts file. Instead it requires the client to supply
an account password which is then transmitted unencrypted over the
network.
12. SMTP
Simple Mail Transfer Protocol (SMTP) is used to deliver email from
one system to another. The basic SMTP is defined in RFC 821 and
the format of Internet mail messages is described in RFC 822.
SMTP depends on TCP to guarantee the correct and orderly delivery
of data across the network.
A very widely-used implementation of SMTP called sendmail can be
downloaded from <http://www.sendmail.org/>. Other open-source SMTP
implementations include qmail (available at
<http://www.qmail.org/>) postfix (available at
<http://www.postfix.org/>), smail (available at
<ftp://ftp.planix.com/pub/Smail/>), exim (available at
<http://www.exim.org/>) and smtpd (available at
<http://www.obtuse.com/smtpd.html>).
13. SNMP
Simple Network Management Protocol (SNMP) provides a means of
monitoring and managing systems over a network. SNMP defines a
method of sending queries (the GET and GET-NEXT primitives) and
commands (the SET primitive) from a management station client to
an agent server running on the target system, and collecting
responses and unsolicited event notifications (the TRAP
primitive).
Version 1 of SNMP is defined by RFC's 1098 and 1157. SNMP Version
2 is defined by RFC's 1441, 1445, 1446, 1447 and 1901 through
1909. The various things that can be monitored and managed by
SNMP, collectively called the Management Information Base (MIB)
are defined in dozens of additional RFC's.
SNMP sends traffic through UDP because of its relative simplicity
and low overhead.
SNMP is discussed in the comp.protocols.snmp newsgroup.
14. Ssh
Secure Shell (ssh) provides remote login and execution features
similar to those of the rsh and rlogin r-commands, but ssh
encrypts the data that is exchanged over the network. Encryption
can protect sensitive information, and it is not uncommon for
security-conscious administrators to disable plain rsh and telnet
services in favour of ssh.
The SSH protocol used by the ssh command has also been used to
build a secure file transfer application which can be used as an
alternative to FTP for sensitive data.
Complete information on ssh and its SSH protocol can be found at
<http://www.ssh.fi/>.
15. Telnet
Telnet provides a network terminal or "remote login" capability.
The Telnet server accepts data from the telnet client and forwards
them to the operating system in such a way that the received
characters are treated as though they had been typed at a terminal
keyboard. Responses generated by the server operating system are
passed back to the Telnet client for display.
The Telnet protocol provides the ability to negotiate many kinds
of terminal-related behaviour (local vs. remote echoing, line mode
vs. character mode and others) between the client and server. The
basic Telnet protocol is defined in RFC's 818 and 854 and the
option negotiation mechanism is described in RFC 855.
Specific Telnet options, implementation issues and protocol quirks
are discussed in several dozen RFC's dating back to 1971. (That's
RFC's 97, 137, 139, 206, 215, 216, 318, 328, 340, 393, 435, 466,
495, 513, 559, 560, 562, 563, 581, 587, 595, 596, 652, 653, 654,
655, 656, 657, 658, 698, 726, 727, 728, 732, 735, 736, 748, 749,
779, 856, 857, 858, 859, 860, 861, 885, 927, 933, 946, 1041, 1043,
1053, 1073, 1079, 1091, 1096, 1097, 1143, 1184, 1205, 1372, 1408,
1411, 1412, 1416, 1571, 1572 and 2066, and that's not counting
obsolete ones. A couple of these are not entirely serious.) As you
might infer from this pedigree, Telnet is a widely-deployed and
well-used protocol.
Telnet depends on TCP to guarantee the correct and orderly
delivery of data between the client and server.
16. X Window System
The X Window System (X11R6 is the most recent incarnation) allows
client programs running on one machine to control the graphic
display, keyboard and mouse of some other machine or of a
dedicated X display terminal.
X depends on TCP to guarantee the correct and orderly delivery of
data across the network.
The X Window System is discussed in the comp.windows.x newsgroup.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TCP/IP Programming
1. What are sockets?
A socket is an abstraction that represents an endpoint of
communication. Most applications that consciously use TCP and UDP
do so by creating a socket of the appropriate type and then
performing a series of operations on that socket. The operations
that can be performed on a socket include control operations (such
as associating a port number with the socket, initiating or
accepting a connection on the socket, or destroying the socket)
data transfer operations (such as writing data through the socket
to some other application, or reading data from some other
application through the socket) and status operations (such as
finding the IP address associated with the socket).
The complete set of operations that can be performed on a socket
constitutes the Sockets API (Application Programming Interface).
If you are interested in writing programs that use TCP/IP then
you'll probably need to use and understand the sockets API. Your
system manuals may have a description of the API (try `man socket'
if you're using a Unix system) and many books devote chapters to
it. A FAQ list for sockets programming is available on the Web
from its Canadian home at <http://www.ibrado.com/sock-faq/>, from
a UK mirror at <http://kipper.york.ac.uk/%7Evic/sock-faq/> or by
anonymous FTP from
<ftp://rtfm.mit.edu/pub/usenet/news.answers/unix-faq/>.
The TLI (Transport Layer Interface) API provides an alternative
programming interface to TCP/IP on some systems, notably those
based on AT&T's System V Unix. The Open Group, a Unix standards
body, defines a variation of TLI called XTI (X/Open Transport
Interface). Note that both sockets and TLI (and XTI) are
general-purpose facilities and are defined to be completely
independent of TCP/IP. TCP/IP is just one of the protocol families
that can be accessed through these API's.
2. How can I detect that the other end of a TCP connection has
crashed? Can I use "keepalives" for this?
Detecting crashed systems over TCP/IP is difficult. TCP doesn't
require any transmission over a connection if the application
isn't sending anything, and many of the media over which TCP/IP is
used (e.g. Ethernet) don't provide a reliable way to determine
whether a particular host is up. If a server doesn't hear from a
client, it could be because it has nothing to say, some network
between the server and client may be down, the server or client's
network interface may be disconnected, or the client may have
crashed. Network failures are often temporary (a thin Ethernet
will appear down while someone is adding a link to the daisy
chain, and it often takes a few minutes for new routes to
stabilize when a router goes down) and TCP connections shouldn't
be dropped as a result.
Keepalives are a feature of the sockets API that requests that an
empty packet be sent periodically over an idle connection; this
should evoke an acknowledgement from the remote system if it is
still up, a reset if it has rebooted, and a timeout if it is down.
These are not normally sent until the connection has been idle for
a few hours. The purpose isn't to detect a crash immediately, but
to keep unnecessary resources from being allocated forever.
If more rapid detection of remote failures is required, this
should be implemented in the application protocol. There is no
standard mechanism for this, but an example is requiring clients
to send a "no-op" message every minute or two. An example protocol
that uses this is X Display Manager Control Protocol (XDMCP), part
of the X Window System, Version 11; the XDM server managing a
session periodically sends a Sync command to the display server,
which should evoke an application-level response, and resets the
session if it doesn't get a response (this is actually an example
of a poor implementation, as a timeout can occur if another client
"grabs" the server for too long).
3. Can the TCP keepalive timeouts be configured?
This varies by operating system. There is a program that works on
many Unices (though not Linux or Solaris), called netconfig, that
allows one to do this and documents many of the variables. It is
available by anonymous FTP from
<ftp://cs.ucsd.edu:/pub/csl/Netconfig/>.
In addition, Richard Stevens' TCP/IP Illustrated, Volume 1
includes a good discussion of setting the most useful variables on
many platforms.
4. Are there object-oriented network programming tools?
Yes. One such system is the ADAPTIVE Communication Environment
(ACE). The README file for ACE is available on the Web at
<http://www.cs.wustl.edu/%7Eschmidt/ACE.html>. All software and
documentation is available via both anonymous ftp and the Web.
ACE is available for anonymous ftp from
<ftp://ics.uci.edu/gnu/>. That's a compressed
tar archive approximately 500KB in size. This release contains
contains the source code, documentation, and example test drivers
for C++ wrapper libraries.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This compilation contains the opinions of the FAQ maintainer and the
various FAQ contributors. Any resemblance to the opinions of the FAQ
maintainer's employer is entirely coincidental.

1260
Zim/Programme/APUE/FAQ/The_Well-Tempered_Unix_Application.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1385
Zim/Programme/APUE/FAQ/Unix-socket-faq_for_network_programming.txt Normal file
View File

File diff suppressed because it is too large Load Diff

185
Zim/Programme/APUE/FAQ/Unix_-_Frequently_Asked_Questions_(Contents).txt Normal file
View File

@@ -0,0 +1,185 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T13:06:27+08:00
====== Unix - Frequently Asked Questions (Contents) ======
Created 星期二 07 六月 2011
http://www.faqs.org/faqs/unix-faq/faq/contents/
Message-ID: <unix-faq/faq/contents_1084272547@rtfm.mit.edu>
X-Last-Updated: 1996/06/11
From: tmatimar@isgtec.com (Ted Timar)
Newsgroups: comp.unix.questions, comp.unix.shell
Subject: Unix - Frequently Asked Questions (Contents) [Frequent posting]
Date: 11 May 2004 10:49:59 GMT
Archive-name: unix-faq/faq/contents
Version: $Id: contents,v 2.9 1996/06/11 13:08:13 tmatimar Exp $
The following seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting. Thank you.
This collection of documents is Copyright (c) 1994, Ted Timar, except
Part 6, which is Copyright (c) 1994, Pierre Lewis and Ted Timar.
All rights reserved. Permission to distribute the collection is
hereby granted providing that distribution is electronic, no money
is involved, reasonable attempts are made to use the latest version
and all credits and this copyright notice are maintained.
Other requests for distribution will be considered. All reasonable
requests will be granted.
All information here has been contributed with good intentions, but
none of it is guaranteed either by the contributors or myself to be
accurate. The users of this information take all responsibility for
any damage that may occur.
Many FAQs, including this one, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.
The name under which a FAQ is archived appears in the "Archive-Name:"
line at the top of the article. This FAQ is archived as
"unix-faq/faq/part[1-7]".
These articles are divided approximately as follows:
1.*) General questions.
2.*) Relatively basic questions, likely to be asked by beginners.
3.*) Intermediate questions.
4.*) Advanced questions, likely to be asked by people who thought
they already knew all of the answers.
5.*) Questions pertaining to the various shells, and the differences.
6.*) An overview of Unix variants.
7.*) An comparison of configuration management systems (RCS, SCCS).
The following questions are answered:
1.1) Who helped you put this list together?
1.2) When someone refers to 'rn(1)' or 'ctime(3)', what does
the number in parentheses mean?
1.3) What does {some strange unix command name} stand for?
1.4) How does the gateway between "comp.unix.questions" and the
"info-unix" mailing list work?
1.5) What are some useful Unix or C books?
1.6) What happened to the pronunciation list that used to be
part of this document?
2.1) How do I remove a file whose name begins with a "-" ?
2.2) How do I remove a file with funny characters in the filename ?
2.3) How do I get a recursive directory listing?
2.4) How do I get the current directory into my prompt?
2.5) How do I read characters from the terminal in a shell script?
2.6) How do I rename "*.foo" to "*.bar", or change file names
to lowercase?
2.7) Why do I get [some strange error message] when I
"rsh host command" ?
2.8) How do I {set an environment variable, change directory} inside a
program or shell script and have that change affect my
current shell?
2.9) How do I redirect stdout and stderr separately in csh?
2.10) How do I tell inside .cshrc if I'm a login shell?
2.11) How do I construct a shell glob-pattern that matches all files
except "." and ".." ?
2.12) How do I find the last argument in a Bourne shell script?
2.13) What's wrong with having '.' in your $PATH ?
2.14) How do I ring the terminal bell during a shell script?
2.15) Why can't I use "talk" to talk with my friend on machine X?
2.16) Why does calendar produce the wrong output?
3.1) How do I find the creation time of a file?
3.2) How do I use "rsh" without having the rsh hang around
until the remote command has completed?
3.3) How do I truncate a file?
3.4) Why doesn't find's "{}" symbol do what I want?
3.5) How do I set the permissions on a symbolic link?
3.6) How do I "undelete" a file?
3.7) How can a process detect if it's running in the background?
3.8) Why doesn't redirecting a loop work as intended? (Bourne shell)
3.9) How do I run 'passwd', 'ftp', 'telnet', 'tip' and other interactive
programs from a shell script or in the background?
3.10) How do I find the process ID of a program with a particular
name from inside a shell script or C program?
3.11) How do I check the exit status of a remote command
executed via "rsh" ?
3.12) Is it possible to pass shell variable settings into an awk program?
3.13) How do I get rid of zombie processes that persevere?
3.14) How do I get lines from a pipe as they are written instead of
only in larger blocks?
3.15) How do I get the date into a filename?
3.16) Why do some scripts start with #! ... ?
4.1) How do I read characters from a terminal without requiring the user
to hit RETURN?
4.2) How do I check to see if there are characters to be read without
actually reading?
4.3) How do I find the name of an open file?
4.4) How can an executing program determine its own pathname?
4.5) How do I use popen() to open a process for reading AND writing?
4.6) How do I sleep() in a C program for less than one second?
4.7) How can I get setuid shell scripts to work?
4.8) How can I find out which user or process has a file open or is using
a particular file system (so that I can unmount it?)
4.9) How do I keep track of people who are fingering me?
4.10) Is it possible to reconnect a process to a terminal after it has
been disconnected, e.g. after starting a program in the background
and logging out?
4.11) Is it possible to "spy" on a terminal, displaying the output
that's appearing on it on another terminal?
5.1) Can shells be classified into categories?
5.2) How do I "include" one shell script from within another
shell script?
5.3) Do all shells have aliases? Is there something else that
can be used?
5.4) How are shell variables assigned?
5.5) How can I tell if I am running an interactive shell?
5.6) What "dot" files do the various shells use?
5.7) I would like to know more about the differences between the
various shells. Is this information available some place?
6.1) Disclaimer and introduction.
6.2) A very brief look at Unix history.
6.3) Main Unix flavors.
6.4) Main Players and Unix Standards.
6.5) Identifying your Unix flavor.
6.6) Brief notes on some well-known (commercial/PD) Unices.
6.7) Real-time Unices.
6.8) Unix glossary.
6.9) Acknowledgements.
7.1) RCS vs SCCS: Introduction
7.2) RCS vs SCCS: How do the interfaces compare?
7.3) RCS vs SCCS: What's in a Revision File?
7.4) RCS vs SCCS: What are the keywords?
7.5) What's an RCS symbolic name?
7.6) RCS vs SCCS: How do they compare for performance?
7.7) RCS vs SCCS: Version Identification.
7.8) RCS vs SCCS: How do they handle with problems?
7.9) RCS vs SCCS: How do they interact with make(1)?
7.10) RCS vs SCCS: Conversion.
7.11) RCS vs SCCS: Support
7.12) RCS vs SCCS: Command Comparison
7.13) RCS vs SCCS: Acknowledgements
7.14) Can I get more information on configuration management systems?
If you're looking for the answer to, say, question 2.5, look in
part 2 and search for the regular expression "^2.5)".
While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up. You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.
With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere. Read your local manual pages
before trying anything suggested here. If you have suggestions or
corrections for any of these answers, please send them to to
tmatimar@isgtec.com.
--
Ted Timar - tmatimar@isgtec.com
ISG Technologies Inc., 6509 Airport Road, Mississauga, Ontario, Canada L4V 1S7

427
Zim/Programme/APUE/FAQ/Unix_-_Frequently_Asked_Questions_(Contents)/Unix_-_Frequently_Asked_Questions_(1-7).txt Normal file
View File

@@ -0,0 +1,427 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T13:07:15+08:00
====== Unix - Frequently Asked Questions (1-7) ======
Created 星期二 07 六月 2011
http://www.faqs.org/faqs/unix-faq/faq/part1/
Message-ID: <unix-faq/faq/part1_1084272547@rtfm.mit.edu>
X-Last-Updated: 1996/06/11
From: tmatimar@isgtec.com (Ted Timar)
Newsgroups: comp.unix.questions, comp.unix.shell
Subject: Unix - Frequently Asked Questions (1/7) [Frequent posting]
Date: 11 May 2004 10:49:59 GMT
Archive-name: unix-faq/faq/part1
Version: $Id: part1,v 2.9 1996/06/11 13:07:56 tmatimar Exp $
These seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting. Thank you.
This collection of documents is Copyright (c) 1994, Ted Timar, except
Part 6, which is Copyright (c) 1994, Pierre Lewis and Ted Timar.
All rights reserved. Permission to distribute the collection is
hereby granted providing that distribution is electronic, no money
is involved, reasonable attempts are made to use the latest version
and all credits and this copyright notice are maintained.
Other requests for distribution will be considered. All reasonable
requests will be granted.
All information here has been contributed with good intentions, but
none of it is guaranteed either by the contributors or myself to be
accurate. The users of this information take all responsibility for
any damage that may occur.
Many FAQs, including this one, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.
The name under which a FAQ is archived appears in the "Archive-Name:"
line at the top of the article. This FAQ is archived as
"unix-faq/faq/part[1-7]".
These articles are divided approximately as follows:
1.*) General questions.
2.*) Relatively basic questions, likely to be asked by beginners.
3.*) Intermediate questions.
4.*) Advanced questions, likely to be asked by people who thought
they already knew all of the answers.
5.*) Questions pertaining to the various shells, and the differences.
6.*) An overview of Unix variants.
7.*) An comparison of configuration management systems (RCS, SCCS).
This article includes answers to:
1.1) Who helped you put this list together?
1.2) When someone refers to 'rn(1)' or 'ctime(3)', what does
the number in parentheses mean?
1.3) What does {some strange unix command name} stand for?
1.4) How does the gateway between "comp.unix.questions" and the
"info-unix" mailing list work?
1.5) What are some useful Unix or C books?
1.6) What happened to the pronunciation list that used to be
part of this document?
If you're looking for the answer to, say, question 1.5, and want to skip
everything else, you can search ahead for the regular expression "^1.5)".
While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up. You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.
With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere. Read your local manual pages
before trying anything suggested here. If you have suggestions or
corrections for any of these answers, please send them to to
tmatimar@isgtec.com.
Subject: Who helped you put this list together?
Date: Thu Mar 18 17:16:55 EST 1993
1.1) Who helped you put this list together?
This document was one of the first collections of Frequently Asked
Questions. It was originally compiled in July 1989.
I took over the maintenance of this list. Almost all of the work
(and the credit) for generating this compilation was done by
Steve Hayman.
We also owe a great deal of thanks to dozens of Usenet readers who
submitted questions, answers, corrections and suggestions for this
list. Special thanks go to Maarten Litmaath, Guy Harris and
Jonathan Kamens, who have all made many especially valuable
contributions.
Part 5 of this document (shells) was written almost entirely by
Matthew Wicks <wicks@dcdmjw.fnal.gov>.
Part 6 of this document (Unix flavours) was written almost entirely by
Pierre (P.) Lewis <lew@bnr.ca>.
Where possible the author of each question and the date it was last
updated is given at the top. Unfortunately, I only started this
practice recently, and much of the information is lost. I was also
negligent in keeping track of who provided updates to questions.
Sorry to those who have made valuable contributions, but did not
receive the credit and recognition that they legitimately deserve.
I make this document available in *roff format (ms and mm macro
packages). Andrew Cromarty has also converted it into Texinfo format.
Marty Leisner <leisner@sdsp.mc.xerox.com> cleaned up the Texinfo
version.
Major contributors to this document who may or may not be
recognized elsewhere are:
Steve Hayman <shayman@Objectario.com>
Pierre Lewis <lew@bnr.ca>
Jonathan Kamens <jik@mit.edu>
Tom Christiansen <tchrist@mox.perl.com>
Maarten Litmaath <maart@nat.vu.nl>
Guy Harris <guy@auspex.com>
The formatted versions are available for anonymous ftp from
ftp.wg.omron.co.jp under pub/unix-faq/docs .
Subject: When someone refers to 'rn(1)' ... the number in parentheses mean?
Date: Tue, 13 Dec 1994 16:37:26 -0500
1.2) When someone refers to 'rn(1)' or 'ctime(3)', what does
the number in parentheses mean?
It looks like some sort of function call, but it isn't. These
numbers refer to the section of the "Unix manual" where the
appropriate documentation can be found. You could type
"man 3 ctime" to look up the manual page for "ctime" in section 3
of the manual.
The traditional manual sections are:
1 User-level commands
2 System calls
3 Library functions
4 Devices and device drivers
5 File formats
6 Games
7 Various miscellaneous stuff - macro packages etc.
8 System maintenance and operation commands
Some Unix versions use non-numeric section names. For instance,
Xenix uses "C" for commands and "S" for functions. Some newer
versions of Unix require "man -s# title" instead of "man # title".
Each section has an introduction, which you can read with "man #
intro" where # is the section number.
Sometimes the number is necessary to differentiate between a
command and a library routine or system call of the same name.
For instance, your system may have "time(1)", a manual page about
the 'time' command for timing programs, and also "time(3)", a
manual page about the 'time' subroutine for determining the
current time. You can use "man 1 time" or "man 3 time" to
specify which "time" man page you're interested in.
You'll often find other sections for local programs or even
subsections of the sections above - Ultrix has sections 3m, 3n,
3x and 3yp among others.
Subject: What does {some strange unix command name} stand for?
Date: Thu Mar 18 17:16:55 EST 1993
1.3) What does {some strange unix command name} stand for?
awk = "Aho Weinberger and Kernighan"
This language was named by its authors, Al Aho, Peter
Weinberger and Brian Kernighan.
grep = "Global Regular Expression Print"
grep comes from the ed command to print all lines matching a
certain pattern
g/re/p
where "re" is a "regular expression".
fgrep = "Fixed GREP".
fgrep searches for fixed strings only. The "f" does not stand
for "fast" - in fact, "fgrep foobar *.c" is usually slower than
"egrep foobar *.c" (Yes, this is kind of surprising. Try it.)
Fgrep still has its uses though, and may be useful when searching
a file for a larger number of strings than egrep can handle.
egrep = "Extended GREP"
egrep uses fancier regular expressions than grep. Many people
use egrep all the time, since it has some more sophisticated
internal algorithms than grep or fgrep, and is usually the
fastest of the three programs.
cat = "CATenate"
catenate is an obscure word meaning "to connect in a series",
which is what the "cat" command does to one or more files. Not
to be confused with C/A/T, the Computer Aided Typesetter.
gecos = "General Electric Comprehensive Operating Supervisor"
When GE's large systems division was sold to Honeywell,
Honeywell dropped the "E" from "GECOS".
Unix's password file has a "pw_gecos" field. The name is a
real holdover from the early days. Dennis Ritchie has reported:
"Sometimes we sent printer output or batch jobs
to the GCOS machine. The gcos field in the password file
was a place to stash the information for the $IDENT card.
Not elegant."
nroff = "New ROFF"
troff = "Typesetter new ROFF"
These are descendants of "roff", which was a re-implementation
of the Multics "runoff" program (a program that you'd use to
"run off" a good copy of a document).
tee = T
From plumbing terminology for a T-shaped pipe splitter.
bss = "Block Started by Symbol"
Dennis Ritchie says:
Actually the acronym (in the sense we took it up; it may
have other credible etymologies) is "Block Started by
Symbol." It was a pseudo-op in FAP (Fortran Assembly [-er?]
Program), an assembler for the IBM 704-709-7090-7094
machines. It defined its label and set aside space for a
given number of words. There was another pseudo-op, BES,
"Block Ended by Symbol" that did the same except that the
label was defined by the last assigned word + 1. (On these
machines Fortran arrays were stored backwards in storage
and were 1-origin.)
The usage is reasonably appropriate, because just as with
standard Unix loaders, the space assigned didn't have to be
punched literally into the object deck but was represented
by a count somewhere.
biff = "BIFF"
This command, which turns on asynchronous mail notification,
was actually named after a dog at Berkeley.
I can confirm the origin of biff, if you're interested.
Biff was Heidi Stettner's dog, back when Heidi (and I, and
Bill Joy) were all grad students at U.C. Berkeley and the
early versions of BSD were being developed. Biff was
popular among the residents of Evans Hall, and was known
for barking at the mailman, hence the name of the command.
Confirmation courtesy of Eric Cooper, Carnegie Mellon University
rc (as in ".cshrc" or "/etc/rc") = "RunCom"
"rc" derives from "runcom", from the MIT CTSS system, ca. 1965.
'There was a facility that would execute a bunch of
commands stored in a file; it was called "runcom" for "run
commands", and the file began to be called "a runcom."
"rc" in Unix is a fossil from that usage.'
Brian Kernighan & Dennis Ritchie, as told to Vicki Brown
"rc" is also the name of the shell from the new Plan 9
operating system.
Perl = "Practical Extraction and Report Language"
Perl = "Pathologically Eclectic Rubbish Lister"
The Perl language is Larry Wall's highly popular
freely-available completely portable text, process, and file
manipulation tool that bridges the gap between shell and C
programming (or between doing it on the command line and
pulling your hair out). For further information, see the
Usenet newsgroup comp.lang.perl.misc.
Don Libes' book "Life with Unix" contains lots more of these
tidbits.
Subject: How does the gateway between "comp.unix.questions" ... work ?
Date: Thu Mar 18 17:16:55 EST 1993
1.4) How does the gateway between "comp.unix.questions" and the
"info-unix" mailing list work?
"info-unix" and "unix-wizards" are mailing list versions of
comp.unix.questions and comp.unix.wizards respectively.
There should be no difference in content between the
mailing list and the newsgroup.
To get on or off either of these lists, send mail to
info-unix-request@brl.mil or unix-wizards-request@brl.mil.
Be sure to use the '-Request'. Don't expect an immediate response.
Here are the gory details, courtesy of the list's maintainer,
Bob Reschly.
==== postings to info-UNIX and UNIX-wizards lists ====
Anything submitted to the list is posted; I do not moderate
incoming traffic -- BRL functions as a reflector. Postings
submitted by Internet subscribers should be addressed to the list
address (info-UNIX or UNIX- wizards); the '-request' addresses
are for correspondence with the list maintainer [me]. Postings
submitted by USENET readers should be addressed to the
appropriate news group (comp.unix.questions or
comp.unix.wizards).
For Internet subscribers, received traffic will be of two types;
individual messages, and digests. Traffic which comes to BRL
from the Internet and BITNET (via the BITNET-Internet gateway) is
immediately resent to all addressees on the mailing list.
Traffic originating on USENET is gathered up into digests which
are sent to all list members daily.
BITNET traffic is much like Internet traffic. The main
difference is that I maintain only one address for traffic
destined to all BITNET subscribers. That address points to a list
exploder which then sends copies to individual BITNET
subscribers. This way only one copy of a given message has to
cross the BITNET-Internet gateway in either direction.
USENET subscribers see only individual messages. All messages
originating on the Internet side are forwarded to our USENET
machine. They are then posted to the appropriate newsgroup.
Unfortunately, for gatewayed messages, the sender becomes
"news@brl-adm". This is currently an unavoidable side-effect of
the software which performs the gateway function.
As for readership, USENET has an extremely large readership - I
would guess several thousand hosts and tens of thousands of
readers. The master list maintained here at BRL runs about two
hundred fifty entries with roughly ten percent of those being
local redistribution lists. I don't have a good feel for the
size of the BITNET redistribution, but I would guess it is
roughly the same size and composition as the master list.
Traffic runs 150K to 400K bytes per list per week on average.
Subject: What are some useful Unix or C books?
Date: Thu Mar 18 17:16:55 EST 1993
1.5) What are some useful Unix or C books?
Mitch Wright (mitch@cirrus.com) maintains a useful list of Unix
and C books, with descriptions and some mini-reviews. There are
currently 167 titles on his list.
You can obtain a copy of this list by anonymous ftp from
ftp.rahul.net (192.160.13.1), where it's "pub/mitch/YABL/yabl".
Send additions or suggestions to mitch@cirrus.com.
Samuel Ko (kko@sfu.ca) maintains another list of Unix books.
This list contains only recommended books, and is therefore
somewhat shorter. This list is also a classified list, with
books grouped into categories, which may be better if you are
looking for a specific type of book.
You can obtain a copy of this list by anonymous ftp from
rtfm.mit.edu, where it's "pub/usenet/news.answers/books/unix".
Send additions or suggestions to kko@sfu.ca.
If you can't use anonymous ftp, email the line "help" to
"ftpmail@decwrl.dec.com" for instructions on retrieving
things via email.
Subject: What happened to the pronunciation list ... ?
Date: Thu Mar 18 17:16:55 EST 1993
1.6) What happened to the pronunciation list that used to be part of this
document?
From its inception in 1989, this FAQ document included a
comprehensive pronunciation list maintained by Maarten Litmaath
(thanks, Maarten!). It was originally created by Carl Paukstis
<carlp@frigg.isc-br.com>.
It has been retired, since it is not really relevant to the topic
of "Unix questions". You can still find it as part of the
widely-distributed "Jargon" file (maintained by Eric S. Raymond,
eric@snark.thyrsus.com) which seems like a much more appropriate
forum for the topic of "How do you pronounce /* ?"
If you'd like a copy, you can ftp one from ftp.wg.omron.co.jp
(133.210.4.4), it's "pub/unix-faq/docs/Pronunciation-Guide".
------------------------------
End of unix/faq Digest part 1 of 7
**********************************
--
Ted Timar - tmatimar@isgtec.com
ISG Technologies Inc., 6509 Airport Road, Mississauga, Ontario, Canada L4V 1S7

1021
Zim/Programme/APUE/FAQ/Unix_-_Frequently_Asked_Questions_(Contents)/Unix_-_Frequently_Asked_Questions_(2-7).txt Normal file
View File

File diff suppressed because it is too large Load Diff

1104
Zim/Programme/APUE/FAQ/Unix_-_Frequently_Asked_Questions_(Contents)/Unix_-_Frequently_Asked_Questions_(3-7).txt Normal file
View File

File diff suppressed because it is too large Load Diff

677
Zim/Programme/APUE/FAQ/Unix_-_Frequently_Asked_Questions_(Contents)/Unix_-_Frequently_Asked_Questions_(4-7).txt Normal file
View File

@@ -0,0 +1,677 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T13:10:03+08:00
====== Unix - Frequently Asked Questions (4-7) ======
Created 星期二 07 六月 2011
Message-ID: <unix-faq/faq/part4_1084272547@rtfm.mit.edu>
X-Last-Updated: 1996/06/11
From: tmatimar@isgtec.com (Ted Timar)
Newsgroups: comp.unix.questions, comp.unix.shell
Subject: Unix - Frequently Asked Questions (4/7) [Frequent posting]
Date: 11 May 2004 10:50:00 GMT
Archive-name: unix-faq/faq/part4
Version: $Id: part4,v 2.9 1996/06/11 13:07:56 tmatimar Exp $
These seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting. Thank you.
This collection of documents is Copyright (c) 1994, Ted Timar, except
Part 6, which is Copyright (c) 1994, Pierre Lewis and Ted Timar.
All rights reserved. Permission to distribute the collection is
hereby granted providing that distribution is electronic, no money
is involved, reasonable attempts are made to use the latest version
and all credits and this copyright notice are maintained.
Other requests for distribution will be considered. All reasonable
requests will be granted.
All information here has been contributed with good intentions, but
none of it is guaranteed either by the contributors or myself to be
accurate. The users of this information take all responsibility for
any damage that may occur.
Many FAQs, including this one, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.
The name under which a FAQ is archived appears in the "Archive-Name:"
line at the top of the article. This FAQ is archived as
"unix-faq/faq/part[1-7]".
These articles are divided approximately as follows:
1.*) General questions.
2.*) Relatively basic questions, likely to be asked by beginners.
3.*) Intermediate questions.
4.*) Advanced questions, likely to be asked by people who thought
they already knew all of the answers.
5.*) Questions pertaining to the various shells, and the differences.
6.*) An overview of Unix variants.
7.*) An comparison of configuration management systems (RCS, SCCS).
This article includes answers to:
4.1) How do I read characters from a terminal without requiring the user
to hit RETURN?
4.2) How do I check to see if there are characters to be read without
actually reading?
4.3) How do I find the name of an open file?
4.4) How can an executing program determine its own pathname?
4.5) How do I use popen() to open a process for reading AND writing?
4.6) How do I sleep() in a C program for less than one second?
4.7) How can I get setuid shell scripts to work?
4.8) How can I find out which user or process has a file open or is using
a particular file system (so that I can unmount it?)
4.9) How do I keep track of people who are fingering me?
4.10) Is it possible to reconnect a process to a terminal after it has
been disconnected, e.g. after starting a program in the background
and logging out?
4.11) Is it possible to "spy" on a terminal, displaying the output
that's appearing on it on another terminal?
If you're looking for the answer to, say, question 4.5, and want to skip
everything else, you can search ahead for the regular expression "^4.5)".
While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up. You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.
With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere. Read your local manual pages
before trying anything suggested here. If you have suggestions or
corrections for any of these answers, please send them to to
tmatimar@isgtec.com.
Subject: How do I read characters ... without requiring the user to hit RETURN?
Date: Thu Mar 18 17:16:55 EST 1993
4.1) How do I read characters from a terminal without requiring the user
to hit RETURN?
Check out cbreak mode in BSD, ~ICANON mode in SysV.
If you don't want to tackle setting the terminal parameters
yourself (using the "ioctl(2)" system call) you can let the stty
program do the work - but this is slow and inefficient, and you
should change the code to do it right some time:
#include <stdio.h>
main()
{
int c;
printf("Hit any character to continue\n");
/*
* ioctl() would be better here; only lazy
* programmers do it this way:
*/
system("/bin/stty cbreak"); /* or "stty raw" */
c = getchar();
system("/bin/stty -cbreak");
printf("Thank you for typing %c.\n", c);
exit(0);
}
Several people have sent me various more correct solutions to
this problem. I'm sorry that I'm not including any of them here,
because they really are beyond the scope of this list.
You might like to check out the documentation for the "curses"
library of portable screen functions. Often if you're interested
in single-character I/O like this, you're also interested in
doing some sort of screen display control, and the curses library
provides various portable routines for both functions.
Subject: How do I check to see if there are characters to be read ... ?
Date: Thu Mar 18 17:16:55 EST 1993
4.2) How do I check to see if there are characters to be read without
actually reading?
Certain versions of UNIX provide ways to check whether characters
are currently available to be read from a file descriptor. In
BSD, you can use select(2). You can also use the FIONREAD ioctl,
which returns the number of characters waiting to be read, but
only works on terminals, pipes and sockets. In System V Release
3, you can use poll(2), but that only works on streams. In Xenix
- and therefore Unix SysV r3.2 and later - the rdchk() system call
reports whether a read() call on a given file descriptor will block.
There is no way to check whether characters are available to be
read from a FILE pointer. (You could poke around inside stdio
data structures to see if the input buffer is nonempty, but that
wouldn't work since you'd have no way of knowing what will happen
the next time you try to fill the buffer.)
Sometimes people ask this question with the intention of writing
if (characters available from fd)
read(fd, buf, sizeof buf);
in order to get the effect of a nonblocking read. This is not
the best way to do this, because it is possible that characters
will be available when you test for availability, but will no
longer be available when you call read. Instead, set the
O_NDELAY flag (which is also called FNDELAY under BSD) using the
F_SETFL option of fcntl(2). Older systems (Version 7, 4.1 BSD)
don't have O_NDELAY; on these systems the closest you can get to
a nonblocking read is to use alarm(2) to time out the read.
Subject: How do I find the name of an open file?
Date: Thu Mar 18 17:16:55 EST 1993
4.3) How do I find the name of an open file?
In general, this is too difficult. The file descriptor may
be attached to a pipe or pty, in which case it has no name.
It may be attached to a file that has been removed. It may
have multiple names, due to either hard or symbolic links.
If you really need to do this, and be sure you think long
and hard about it and have decided that you have no choice,
you can use find with the -inum and possibly -xdev option,
or you can use ncheck, or you can recreate the functionality
of one of these within your program. Just realize that
searching a 600 megabyte filesystem for a file that may not
even exist is going to take some time.
Subject: How can an executing program determine its own pathname?
Date: Thu Mar 18 17:16:55 EST 1993
4.4) How can an executing program determine its own pathname?
Your program can look at argv[0]; if it begins with a "/", it is
probably the absolute pathname to your program, otherwise your
program can look at every directory named in the environment
variable PATH and try to find the first one that contains an
executable file whose name matches your program's argv[0] (which
by convention is the name of the file being executed). By
concatenating that directory and the value of argv[0] you'd
probably have the right name.
You can't really be sure though, since it is quite legal for one
program to exec() another with any value of argv[0] it desires.
It is merely a convention that new programs are exec'd with the
executable file name in argv[0].
For instance, purely a hypothetical example:
#include <stdio.h>
main()
{
execl("/usr/games/rogue", "vi Thesis", (char *)NULL);
}
The executed program thinks its name (its argv[0] value) is
"vi Thesis". (Certain other programs might also think that
the name of the program you're currently running is "vi Thesis",
but of course this is just a hypothetical example, don't
try it yourself :-)
Subject: How do I use popen() to open a process for reading AND writing?
Date: Thu Mar 18 17:16:55 EST 1993
4.5) How do I use popen() to open a process for reading AND writing?
The problem with trying to pipe both input and output to an
arbitrary slave process is that deadlock can occur, if both
processes are waiting for not-yet-generated input at the same
time. Deadlock can be avoided only by having BOTH sides follow a
strict deadlock-free protocol, but since that requires
cooperation from the processes it is inappropriate for a
popen()-like library function.
The 'expect' distribution includes a library of functions that a
C programmer can call directly. One of the functions does the
equivalent of a popen for both reading and writing. It uses ptys
rather than pipes, and has no deadlock problem. It's portable to
both BSD and SV. See question 3.9 for more about 'expect'.
Subject: How do I sleep() in a C program for less than one second?
Date: Thu Mar 18 17:16:55 EST 1993
4.6) How do I sleep() in a C program for less than one second?
The first thing you need to be aware of is that all you can
specify is a MINIMUM amount of delay; the actual delay will
depend on scheduling issues such as system load, and could be
arbitrarily large if you're unlucky.
There is no standard library function that you can count on in
all environments for "napping" (the usual name for short
sleeps). Some environments supply a "usleep(n)" function which
suspends execution for n microseconds. If your environment
doesn't support usleep(), here are a couple of implementations
for BSD and System V environments.
The following code is adapted from Doug Gwyn's System V emulation
support for 4BSD and exploits the 4BSD select() system call.
Doug originally called it 'nap()'; you probably want to call it
"usleep()";
/*
usleep -- support routine for 4.2BSD system call emulations
last edit: 29-Oct-1984 D A Gwyn
*/
extern int select();
int
usleep( usec ) /* returns 0 if ok, else -1 */
long usec; /* delay in microseconds */
{
static struct /* `timeval' */
{
long tv_sec; /* seconds */
long tv_usec; /* microsecs */
} delay; /* _select() timeout */
delay.tv_sec = usec / 1000000L;
delay.tv_usec = usec % 1000000L;
return select( 0, (long *)0, (long *)0, (long *)0, &delay );
}
On System V you might do it this way:
/*
subseconds sleeps for System V - or anything that has poll()
Don Libes, 4/1/1991
The BSD analog to this function is defined in terms of
microseconds while poll() is defined in terms of milliseconds.
For compatibility, this function provides accuracy "over the long
run" by truncating actual requests to milliseconds and
accumulating microseconds across calls with the idea that you are
probably calling it in a tight loop, and that over the long run,
the error will even out.
If you aren't calling it in a tight loop, then you almost
certainly aren't making microsecond-resolution requests anyway,
in which case you don't care about microseconds. And if you did,
you wouldn't be using UNIX anyway because random system
indigestion (i.e., scheduling) can make mincemeat out of any
timing code.
Returns 0 if successful timeout, -1 if unsuccessful.
*/
#include <poll.h>
int
usleep(usec)
unsigned int usec; /* microseconds */
{
static subtotal = 0; /* microseconds */
int msec; /* milliseconds */
/* 'foo' is only here because some versions of 5.3 have
* a bug where the first argument to poll() is checked
* for a valid memory address even if the second argument is 0.
*/
struct pollfd foo;
subtotal += usec;
/* if less then 1 msec request, do nothing but remember it */
if (subtotal < 1000) return(0);
msec = subtotal/1000;
subtotal = subtotal%1000;
return poll(&foo,(unsigned long)0,msec);
}
Another possibility for nap()ing on System V, and probably other
non-BSD Unices is Jon Zeeff's s5nap package, posted to
comp.sources.misc, volume 4. It does require a installing a
device driver, but works flawlessly once installed. (Its
resolution is limited to the kernel HZ value, since it uses the
kernel delay() routine.)
Many newer versions of Unix have a nanosleep function.
Subject: How can I get setuid shell scripts to work?
Date: Thu Mar 18 17:16:55 EST 1993
4.7) How can I get setuid shell scripts to work?
[ This is a long answer, but it's a complicated and frequently-asked
question. Thanks to Maarten Litmaath for this answer, and
for the "indir" program mentioned below. ]
Let us first assume you are on a UNIX variant (e.g. 4.3BSD or
SunOS) that knows about so-called `executable shell scripts'.
Such a script must start with a line like:
#!/bin/sh
The script is called `executable' because just like a real (binary)
executable it starts with a so-called `magic number' indicating
the type of the executable. In our case this number is `#!' and
the OS takes the rest of the first line as the interpreter for
the script, possibly followed by 1 initial option like:
#!/bin/sed -f
Suppose this script is called `foo' and is found in /bin,
then if you type:
foo arg1 arg2 arg3
the OS will rearrange things as though you had typed:
/bin/sed -f /bin/foo arg1 arg2 arg3
There is one difference though: if the setuid permission bit for
`foo' is set, it will be honored in the first form of the
command; if you really type the second form, the OS will honor
the permission bits of /bin/sed, which is not setuid, of course.
----------
OK, but what if my shell script does NOT start with such a `#!'
line or my OS does not know about it?
Well, if the shell (or anybody else) tries to execute it, the OS
will return an error indication, as the file does not start with
a valid magic number. Upon receiving this indication the shell
ASSUMES the file to be a shell script and gives it another try:
/bin/sh shell_script arguments
But we have already seen that a setuid bit on `shell_script' will
NOT be honored in this case!
----------
Right, but what about the security risks of setuid shell scripts?
Well, suppose the script is called `/etc/setuid_script', starting
with:
#!/bin/sh
Now let us see what happens if we issue the following commands:
$ cd /tmp
$ ln /etc/setuid_script -i
$ PATH=.
$ -i
We know the last command will be rearranged to:
/bin/sh -i
But this command will give us an interactive shell, setuid to the
owner of the script!
Fortunately this security hole can easily be closed by making the
first line:
#!/bin/sh -
The `-' signals the end of the option list: the next argument `-i'
will be taken as the name of the file to read commands from, just
like it should!
---------
There are more serious problems though:
$ cd /tmp
$ ln /etc/setuid_script temp
$ nice -20 temp &
$ mv my_script temp
The third command will be rearranged to:
nice -20 /bin/sh - temp
As this command runs so slowly, the fourth command might be able
to replace the original `temp' with `my_script' BEFORE `temp' is
opened by the shell! There are 4 ways to fix this security hole:
1) let the OS start setuid scripts in a different, secure way
- System V R4 and 4.4BSD use the /dev/fd driver to pass the
interpreter a file descriptor for the script
2) let the script be interpreted indirectly, through a frontend
that makes sure everything is all right before starting the
real interpreter - if you use the `indir' program from
comp.sources.unix the setuid script will look like this:
#!/bin/indir -u
#?/bin/sh /etc/setuid_script
3) make a `binary wrapper': a real executable that is setuid and
whose only task is to execute the interpreter with the name of
the script as an argument
4) make a general `setuid script server' that tries to locate the
requested `service' in a database of valid scripts and upon
success will start the right interpreter with the right
arguments.
---------
Now that we have made sure the right file gets interpreted, are
there any risks left?
Certainly! For shell scripts you must not forget to set the PATH
variable to a safe path explicitly. Can you figure out why?
Also there is the IFS variable that might cause trouble if not
set properly. Other environment variables might turn out to
compromise security as well, e.g. SHELL... Furthermore you must
make sure the commands in the script do not allow interactive
shell escapes! Then there is the umask which may have been set
to something strange...
Etcetera. You should realise that a setuid script `inherits' all
the bugs and security risks of the commands that it calls!
All in all we get the impression setuid shell scripts are quite a
risky business! You may be better off writing a C program instead!
Subject: How can I find out which user or process has a file open ... ?
Date: Thu Mar 18 17:16:55 EST 1993
4.8) How can I find out which user or process has a file open or is using
a particular file system (so that I can unmount it?)
Use fuser (system V), fstat (BSD), ofiles (public domain) or
pff (public domain). These programs will tell you various things
about processes using particular files.
A port of the 4.3 BSD fstat to Dynix, SunOS and Ultrix
can be found in archives of comp.sources.unix, volume 18.
pff is part of the kstuff package, and works on quite a few systems.
Instructions for obtaining kstuff are provided in question 3.10.
I've been informed that there is also a program called lsof. I
don't know where it can be obtained.
Michael Fink <Michael.Fink@uibk.ac.at> adds:
If you are unable to unmount a file system for which above tools
do not report any open files make sure that the file system that
you are trying to unmount does not contain any active mount
points (df(1)).
Subject: How do I keep track of people who are fingering me?
>From: Jonathan I. Kamens
>From: malenovi@plains.NoDak.edu (Nikola Malenovic)
Date: Thu, 29 Sep 1994 07:28:37 -0400
4.9) How do I keep track of people who are fingering me?
Generally, you can't find out the userid of someone who is
fingering you from a remote machine. You may be able to
find out which machine the remote request is coming from.
One possibility, if your system supports it and assuming
the finger daemon doesn't object, is to make your .plan file a
"named pipe" instead of a plain file. (Use 'mknod' to do this.)
You can then start up a program that will open your .plan file
for writing; the open will block until some other process (namely
fingerd) opens the .plan for reading. Now you can feed whatever you
want through this pipe, which lets you show different .plan
information every time someone fingers you. One program for
doing this is the "planner" package in volume 41 of the
comp.sources.misc archives.
Of course, this may not work at all if your system doesn't
support named pipes or if your local fingerd insists
on having plain .plan files.
Your program can also take the opportunity to look at the output
of "netstat" and spot where an incoming finger connection is
coming from, but this won't get you the remote user.
Getting the remote userid would require that the remote site be
running an identity service such as RFC 931. There are now three
RFC 931 implementations for popular BSD machines, and several
applications (such as the wuarchive ftpd) supporting the server.
For more information join the rfc931-users mailing list,
>rfc931-users-request@kramden.acf.nyu.edu.
There are three caveats relating to this answer. The first is
that many NFS systems won't recognize the named pipe correctly.
This means that trying to read the pipe on another machine will
either block until it times out, or see it as a zero-length file,
and never print it.
The second problem is that on many systems, fingerd checks that
the .plan file contains data (and is readable) before trying to
read it. This will cause remote fingers to miss your .plan file
entirely.
The third problem is that a system that supports named pipes
usually has a fixed number of named pipes available on the
system at any given time - check the kernel config file and
FIFOCNT option. If the number of pipes on the system exceeds the
FIFOCNT value, the system blocks new pipes until somebody frees
the resources. The reason for this is that buffers are allocated
in a non-paged memory.
Subject: Is it possible to reconnect a process to a terminal ... ?
Date: Thu Mar 18 17:16:55 EST 1993
4.10) Is it possible to reconnect a process to a terminal after it has
been disconnected, e.g. after starting a program in the background
and logging out?
Most variants of Unix do not support "detaching" and "attaching"
processes, as operating systems such as VMS and Multics support.
However, there are three freely redistributable packages which can
be used to start processes in such a way that they can be later
reattached to a terminal.
The first is "screen," which is described in the
comp.sources.unix archives as "Screen, multiple windows on a CRT"
(see the "screen-3.2" package in comp.sources.misc, volume 28.)
This package will run on at least BSD, System V r3.2 and SCO UNIX.
The second is "pty," which is described in the comp.sources.unix
archives as a package to "Run a program under a pty session" (see
"pty" in volume 23). pty is designed for use under BSD-like
system only.
The third is "dislocate," which is a script that comes with the
expect distribution. Unlike the previous two, this should run on
all UNIX versions. Details on getting expect can be found in
question 3.9 .
None of these packages is retroactive, i.e. you must have
started a process under screen or pty in order to be able to
detach and reattach it.
Subject: Is it possible to "spy" on a terminal ... ?
Date: Wed, 28 Dec 1994 18:35:00 -0500
4.11) Is it possible to "spy" on a terminal, displaying the output
that's appearing on it on another terminal?
There are a few different ways you can do this, although none
of them is perfect:
* kibitz allows two (or more) people to interact with a shell
(or any arbitary program). Uses include:
- watching or aiding another person's terminal session;
- recording a conversation while retaining the ability to
scroll backwards, save the conversation, or even edit it
while in progress;
- teaming up on games, document editing, or other cooperative
tasks where each person has strengths and weakness that
complement one another.
kibitz comes as part of the expect distribution. See question 3.9.
kibitz requires permission from the person to be spyed upon. To
spy without permission requires less pleasant approaches:
* You can write a program that rummages through Kernel structures
and watches the output buffer for the terminal in question,
displaying characters as they are output. This, obviously, is
not something that should be attempted by anyone who does not
have experience working with the Unix kernel. Furthermore,
whatever method you come up with will probably be quite
non-portable.
* If you want to do this to a particular hard-wired terminal all
the time (e.g. if you want operators to be able to check the
console terminal of a machine from other machines), you can
actually splice a monitor into the cable for the terminal. For
example, plug the monitor output into another machine's serial
port, and run a program on that port that stores its input
somewhere and then transmits it out *another* port, this one
really going to the physical terminal. If you do this, you have
to make sure that any output from the terminal is transmitted
back over the wire, although if you splice only into the
computer->terminal wires, this isn't much of a problem. This is
not something that should be attempted by anyone who is not very
familiar with terminal wiring and such.
* The latest version of screen includes a multi-user mode.
Some details about screen can be found in question 4.10.
* If the system being used has streams (SunOS, SVR4), the advise
program that was posted in volume 28 of comp.sources.misc can
be used. AND it doesn't requirethat it be run first (you do
have to configure your system in advance to automatically push
the advise module on the stream whenever a tty or pty is opened).
------------------------------
End of unix/faq Digest part 4 of 7
**********************************
--
Ted Timar - tmatimar@isgtec.com
ISG Technologies Inc., 6509 Airport Road, Mississauga, Ontario, Canada L4V 1S7

292
Zim/Programme/APUE/FAQ/Unix_-_Frequently_Asked_Questions_(Contents)/Unix_-_Frequently_Asked_Questions_(5-7).txt Normal file
View File

@@ -0,0 +1,292 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T13:10:14+08:00
====== Unix - Frequently Asked Questions (5-7) ======
Created 星期二 07 六月 2011
Message-ID: <unix-faq/faq/part5_1084272547@rtfm.mit.edu>
X-Last-Updated: 1996/06/11
From: tmatimar@isgtec.com (Ted Timar)
Newsgroups: comp.unix.questions, comp.unix.shell
Subject: Unix - Frequently Asked Questions (5/7) [Frequent posting]
Date: 11 May 2004 10:50:00 GMT
Archive-name: unix-faq/faq/part5
Version: $Id: part5,v 2.9 1996/06/11 13:07:56 tmatimar Exp $
These seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting. Thank you.
This collection of documents is Copyright (c) 1994, Ted Timar, except
Part 6, which is Copyright (c) 1994, Pierre Lewis and Ted Timar.
All rights reserved. Permission to distribute the collection is
hereby granted providing that distribution is electronic, no money
is involved, reasonable attempts are made to use the latest version
and all credits and this copyright notice are maintained.
Other requests for distribution will be considered. All reasonable
requests will be granted.
All information here has been contributed with good intentions, but
none of it is guaranteed either by the contributors or myself to be
accurate. The users of this information take all responsibility for
any damage that may occur.
Many FAQs, including this one, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.
The name under which a FAQ is archived appears in the "Archive-Name:"
line at the top of the article. This FAQ is archived as
"unix-faq/faq/part[1-7]".
These articles are divided approximately as follows:
1.*) General questions.
2.*) Relatively basic questions, likely to be asked by beginners.
3.*) Intermediate questions.
4.*) Advanced questions, likely to be asked by people who thought
they already knew all of the answers.
5.*) Questions pertaining to the various shells, and the differences.
6.*) An overview of Unix variants.
7.*) An comparison of configuration management systems (RCS, SCCS).
This article includes answers to:
5.1) Can shells be classified into categories?
5.2) How do I "include" one shell script from within another
shell script?
5.3) Do all shells have aliases? Is there something else that
can be used?
5.4) How are shell variables assigned?
5.5) How can I tell if I am running an interactive shell?
5.6) What "dot" files do the various shells use?
5.7) I would like to know more about the differences between the
various shells. Is this information available some place?
If you're looking for the answer to, say, question 5.5, and want to skip
everything else, you can search ahead for the regular expression "^5.5)".
While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up. You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.
With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere. Read your local manual pages
before trying anything suggested here. If you have suggestions or
corrections for any of these answers, please send them to to
tmatimar@isgtec.com.
Subject: Can shells be classified into categories?
>From: wicks@dcdmjw.fnal.gov (Matthew Wicks)
Date: Wed, 7 Oct 92 14:28:18 -0500
5.1) Can shells be classified into categories?
In general there are two main class of shells. The first class
are those shells derived from the Bourne shell which includes sh,
ksh, bash, and zsh. The second class are those shells derived
from C shell and include csh and tcsh. In addition there is rc
which most people consider to be in a "class by itself" although
some people might argue that rc belongs in the Bourne shell class.
With the classification above, using care, it is possible to
write scripts that will work for all the shells from the Bourne
shell category, and write other scripts that will work for all of
the shells from the C shell category.
Subject: How do I "include" one shell script from within another shell script?
>From: wicks@dcdmjw.fnal.gov (Matthew Wicks)
Date: Wed, 7 Oct 92 14:28:18 -0500
5.2) How do I "include" one shell script from within another shell script?
All of the shells from the Bourne shell category (including rc)
use the "." command. All of the shells from the C shell category
use "source".
Subject: Do all shells have aliases? Is there something else that can be used?
>From: wicks@dcdmjw.fnal.gov (Matthew Wicks)
Date: Wed, 7 Oct 92 14:28:18 -0500
5.3) Do all shells have aliases? Is there something else that can be used?
All of the major shells other than sh have aliases, but they
don't all work the same way. For example, some don't accept
arguments.
Although not strictly equivalent, shell functions (which exist in
most shells from the Bourne shell category) have almost the same
functionality of aliases. Shell functions can do things that
aliases can't do. Shell functions did not exist in bourne shells
derived from Version 7 Unix, which includes System III and BSD 4.2.
BSD 4.3 and System V shells do support shell functions.
Use unalias to remove aliases and unset to remove functions.
Subject: How are shell variables assigned?
>From: wicks@dcdmjw.fnal.gov (Matthew Wicks)
Date: Wed, 7 Oct 92 14:28:18 -0500
5.4) How are shell variables assigned?
The shells from the C shell category use "set variable=value" for
variables local to the shell and "setenv variable value" for
environment variables. To get rid of variables in these shells
use unset and unsetenv. The shells from the Bourne shell
category use "variable=value" and may require an "export
VARIABLE_NAME" to place the variable into the environment. To
get rid of the variables use unset.
Subject: How can I tell if I am running an interactive shell?
>From: wicks@dcdmjw.fnal.gov (Matthew Wicks)
>From: dws@ssec.wisc.edu (DaviD W. Sanderson)
Date: Fri, 23 Oct 92 11:59:19 -0600
5.5) How can I tell if I am running an interactive shell?
In the C shell category, look for the variable $prompt.
In the Bourne shell category, you can look for the variable $PS1,
however, it is better to check the variable $-. If $- contains
an 'i', the shell is interactive. Test like so:
case $- in
*i*) # do things for interactive shell
;;
*) # do things for non-interactive shell
;;
esac
Subject: What "dot" files do the various shells use?
>From: wicks@dcdmjw.fnal.gov (Matthew Wicks)
>From: tmb@idiap.ch (Thomas M. Breuel)
Date: Wed, 28 Oct 92 03:30:36 +0100
5.6) What "dot" files do the various shells use?
Although this may not be a complete listing, this provides the
majority of information.
csh
Some versions have system-wide .cshrc and .login files. Every
version puts them in different places.
Start-up (in this order):
.cshrc - always; unless the -f option is used.
.login - login shells.
Upon termination:
.logout - login shells.
Others:
.history - saves the history (based on $savehist).
tcsh
Start-up (in this order):
/etc/csh.cshrc - always.
/etc/csh.login - login shells.
.tcshrc - always.
.cshrc - if no .tcshrc was present.
.login - login shells
Upon termination:
.logout - login shells.
Others:
.history - saves the history (based on $savehist).
.cshdirs - saves the directory stack.
sh
Start-up (in this order):
/etc/profile - login shells.
.profile - login shells.
Upon termination:
any command (or script) specified using the command:
trap "command" 0
ksh
Start-up (in this order):
/etc/profile - login shells.
.profile - login shells; unless the -p option is used.
$ENV - always, if it is set; unless the -p option is used.
/etc/suid_profile - when the -p option is used.
Upon termination:
any command (or script) specified using the command:
trap "command" 0
bash
Start-up (in this order):
/etc/profile - login shells.
.bash_profile - login shells.
.profile - login if no .bash_profile is present.
.bashrc - interactive non-login shells.
$ENV - always, if it is set.
Upon termination:
.bash_logout - login shells.
Others:
.inputrc - Readline initialization.
zsh
Start-up (in this order):
.zshenv - always, unless -f is specified.
.zprofile - login shells.
.zshrc - interactive shells, unless -f is specified.
.zlogin - login shells.
Upon termination:
.zlogout - login shells.
rc
Start-up:
.rcrc - login shells
Subject: I would like to know more about the differences ... ?
>From: wicks@dcdmjw.fnal.gov (Matthew Wicks)
Date: Wed, 7 Oct 92 14:28:18 -0500
5.7) I would like to know more about the differences between the
various shells. Is this information available some place?
A very detailed comparison of sh, csh, tcsh, ksh, bash, zsh, and
rc is available via anon. ftp in several places:
ftp.uwp.edu (204.95.162.190):pub/vi/docs/shell-100.BetaA.Z
utsun.s.u-tokyo.ac.jp:misc/vi-archive/docs/shell-100.BetaA.Z
This file compares the flags, the programming syntax,
input/output redirection, and parameters/shell environment
variables. It doesn't discuss what dot files are used and the
inheritance for environment variables and functions.
------------------------------
End of unix/faq Digest part 5 of 7
**********************************
--
Ted Timar - tmatimar@isgtec.com
ISG Technologies Inc., 6509 Airport Road, Mississauga, Ontario, Canada L4V 1S7

1025
Zim/Programme/APUE/FAQ/Unix_-_Frequently_Asked_Questions_(Contents)/Unix_-_Frequently_Asked_Questions_(6-7).txt Normal file
View File

File diff suppressed because it is too large Load Diff

368
Zim/Programme/APUE/FAQ/Unix_-_Frequently_Asked_Questions_(Contents)/Unix_-_Frequently_Asked_Questions_(7-7).txt Normal file
View File

@@ -0,0 +1,368 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-06-07T13:10:33+08:00
====== Unix - Frequently Asked Questions (7-7) ======
Created 星期二 07 六月 2011
Message-ID: <unix-faq/faq/part7_1084272547@rtfm.mit.edu>
X-Last-Updated: 1996/06/11
From: tmatimar@isgtec.com (Ted Timar)
Newsgroups: comp.unix.questions, comp.unix.shell
Subject: Unix - Frequently Asked Questions (7/7) [Frequent posting]
Date: 11 May 2004 10:50:01 GMT
Archive-name: unix-faq/faq/part7
Version: $Id: part7,v 2.9 1996/06/11 13:07:56 tmatimar Exp $
These seven articles contain the answers to some Frequently Asked
Questions often seen in comp.unix.questions and comp.unix.shell.
Please don't ask these questions again, they've been answered plenty
of times already - and please don't flame someone just because they may
not have read this particular posting. Thank you.
This collection of documents is Copyright (c) 1994, Ted Timar, except
Part 6, which is Copyright (c) 1994, Pierre Lewis and Ted Timar.
All rights reserved. Permission to distribute the collection is
hereby granted providing that distribution is electronic, no money
is involved, reasonable attempts are made to use the latest version
and all credits and this copyright notice are maintained.
Other requests for distribution will be considered. All reasonable
requests will be granted.
All information here has been contributed with good intentions, but
none of it is guaranteed either by the contributors or myself to be
accurate. The users of this information take all responsibility for
any damage that may occur.
Many FAQs, including this one, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.
The name under which a FAQ is archived appears in the "Archive-Name:"
line at the top of the article. This FAQ is archived as
"unix-faq/faq/part[1-7]".
These articles are divided approximately as follows:
1.*) General questions.
2.*) Relatively basic questions, likely to be asked by beginners.
3.*) Intermediate questions.
4.*) Advanced questions, likely to be asked by people who thought
they already knew all of the answers.
5.*) Questions pertaining to the various shells, and the differences.
6.*) An overview of Unix variants.
7.*) An comparison of configuration management systems (RCS, SCCS).
This article includes answers to:
7.1) RCS vs SCCS: Introduction
7.2) RCS vs SCCS: How do the interfaces compare?
7.3) RCS vs SCCS: What's in a Revision File?
7.4) RCS vs SCCS: What are the keywords?
7.5) What's an RCS symbolic name?
7.6) RCS vs SCCS: How do they compare for performance?
7.7) RCS vs SCCS: Version Identification.
7.8) RCS vs SCCS: How do they handle problems?
7.9) RCS vs SCCS: How do they interact with make(1)?
7.10) RCS vs SCCS: Conversion
7.11) RCS vs SCCS: Support
7.12) RCS vs SCCS: Command Comparison
7.13) RCS vs SCCS: Acknowledgements
7.14) Can I get more information on configuration management systems?
If you're looking for the answer to, say, question 7.5, and want to skip
everything else, you can search ahead for the regular expression "^7.5)".
While these are all legitimate questions, they seem to crop up in
comp.unix.questions or comp.unix.shell on an annual basis, usually
followed by plenty of replies (only some of which are correct) and then
a period of griping about how the same questions keep coming up. You
may also like to read the monthly article "Answers to Frequently Asked
Questions" in the newsgroup "news.announce.newusers", which will tell
you what "UNIX" stands for.
With the variety of Unix systems in the world, it's hard to guarantee
that these answers will work everywhere. Read your local manual pages
before trying anything suggested here. If you have suggestions or
corrections for any of these answers, please send them to to
tmatimar@isgtec.com.
Subject: RCS vs SCCS: Introduction
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.1) RCS vs SCCS: Introduction
The majority of the replies (in a recent poll) were in favor of
RCS, a few for SCCS, and a few suggested alternatives such as CVS.
Functionally RCS and SCCS are practically equal, with RCS having
a bit more features since it continues to be updated.
Note that RCS learned from the mistakes of SCCS...
Subject: RCS vs SCCS: How do the interfaces compare?
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.2) RCS vs SCCS: How do the interfaces compare?
RCS has an easier interface for first time users. There are less
commands, it is more intuitive and consistent, and it provides
more useful arguments.
Branches have to be specifically created in SCCS. In RCS, they
are checked in as any other version.
Subject: RCS vs SCCS: What's in a Revision File?
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.3) RCS vs SCCS: What's in a Revision File?
RCS keeps history in files with a ",v" suffix. SCCS keeps
history in files with a "s." prefix.
RCS looks for RCS files automatically in the current directory or
in a RCS subdirectory, or you can specify an alternate RCS file.
The sccs front end to SCCS always uses the SCCS directory. If
you don't use the sccs front end, you must specify the full SCCS
filename.
RCS stores its revisions by holding a copy of the latest version
and storing backward deltas. SCCS uses a "merged delta"
concept.
All RCS activity takes place within a single RCS file. SCCS
maintains several files. This can be messy and confusing.
Editing either RCS or SCCS files is a bad idea because mistakes
are so easy to make and so fatal to the history of the file.
Revision information is easy to edit in both types, whereas one
would not want to edit the actual text of a version in RCS. If
you edit an SCCS file, you will have to recalculate the checksum
using the admin program.
Subject: RCS vs SCCS: What are the keywords?
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.4) RCS vs SCCS: What are the keywords?
RCS and SCCS use different keywords that are expanded in the
text. For SCCS the keyword "%I%" is replaced with the revision
number if the file is checked out for reading.
The RCS keywords are easier to remember, but keyword expansion is
more easily customized in SCCS.
In SCCS, keywords are expanded on a read-only get. If a version
with expanded keywords is copied into a file that will be
deltaed, the keywords will be lost and the version information in
the file will not be updated. On the other hand, RCS retains the
keywords when they are expanded so this is avoided.
Subject: What's an RCS symbolic name?
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.5) What's an RCS symbolic name?
RCS allows you treat a set of files as a family of files while
SCCS is meant primarily for keeping the revision history of
files.
RCS accomplishes that with symbolic names: you can mark all the
source files associated with an application version with `rcs
-n', and then easily retrieve them later as a cohesive unit. In
SCCS you would have to do this by writing a script to write or
read all file names and versions to or from a file.
Subject: RCS vs SCCS: How do they compare for performance?
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.6) RCS vs SCCS: How do they compare for performance?
Since RCS stores the latest version in full, it is much faster in
retrieving the latest version. After RCS version 5.6, it is also
faster than SCCS in retrieving older versions.
Subject: RCS vs SCCS: Version Identification.
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.7) RCS vs SCCS: Version Identification.
SCCS is able to determine when a specific line of code was added
to a system.
Subject: RCS vs SCCS: How do they handle problems?
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.8) RCS vs SCCS: How do they handle problems?
If you are missing the sccs or rcs tools, or the RCS or SCCS file
is corrupt and the tools don't work on it, you can still retrieve
the latest version in RCS. Not true with SCCS.
Subject: RCS vs SCCS: How do they interact with make(1)?
Date: Wed, 30 Dec 1992 10:41:51 -0700
>From: Blair P. Houghton <bhoughto@sedona.intel.com>
7.9) RCS vs SCCS: How do they interact with make(1)?
The fact that SCCS uses prefixes (s.file.c) means that make(1)
can't treat them in an ordinary manner, and special rules
(involving '~' characters) must be used in order for make(1) to
work with SCCS; even so, make(1) on some UNIX platforms will not
apply default rules to files that are being managed with SCCS.
The suffix notation (file.c,v) for RCS means that ordinary
suffix-rules can be used in all implementations of make(1), even
if the implementation isn't designed to handle RCS files
specially.
Subject: RCS vs SCCS: Conversion.
Date: Tue, 10 Jan 1995 21:01:41 -0500
>From: Ed Ravin <elr@wp.prodigy.com>
7.10) RCS vs SCCS: Conversion.
An unsupported C-Shell script is available to convert from SCCS
to RCS. You can find it in
ftp://ftp.std.com/src/gnu/cvs-1.3/contrib/
One would have to write their own script or program to convert
from RCS to SCCS.
Subject: RCS vs SCCS: Support
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.11) RCS vs SCCS: Support
SCCS is supported by AT&T. RCS is supported by the Free Software
Foundation. Therefore RCS runs on many more platforms, including
PCs.
Most make programs recognize SCCS's "s." prefix while GNU make
is one of the few that handles RCS's ",v" suffix.
Some tar programs have a -F option that ignores either RCS
directories, or SCCS directories or both.
Subject: RCS vs SCCS: Command Comparison
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.12) RCS vs SCCS: Command Comparison
SCCS RCS Explanation
==== === ===========
sccs admin -i -nfile file ci file Checks in the file
for the first time,
creating the revision
history file.
sccs get file co file Check out a file for
reading.
sccs edit file co -l file Check out a file for
modification.
sccs delta file ci file Check in a file
previously locked.
what file ident file Print keyword
information.
sccs prs file rlog file Print a history of
the file.
sccs sccsdiff -rx -ry file rcsdiff -rx -ry file Compare two
revisions.
sccs diffs file rcsdiff file Compare current with
last revision.
sccs edit -ix-y file rcsmerge -rx-y file Merge changes between
two versions into
file.
??? rcs -l file Lock the latest
revision.
??? rcs -u file Unlock the latest
revision. Possible
to break another's
lock, but mail is
sent to the other
user explaining why.
Subject: RCS vs SCCS: Acknowledgements
Date: Sat, 10 Oct 92 19:34:39 +0200
>From: Bill Wohler <wohler@newt.com>
7.13) RCS vs SCCS: Acknowledgements
I would like to thank the following persons for contributing to
these articles. I'd like to add your name to the list--please
send comments or more references to Bill Wohler <wohler@newt.com>.
Karl Vogel <vogel@c-17igp.wpafb.af.mil>
Mark Runyan <runyan@hpcuhc.cup.hp.com>
Paul Eggert <eggert@twinsun.com>
Greg Henderson <henders@infonode.ingr.com>
Dave Goldberg <dsg@mbunix.mitre.org>
Rob Kurver <rob@pact.nl>
Raymond Chen <rjc@math.princeton.edu>
Dwight <dwight@s1.gov>
Subject: Can I get more information on configuration management systems?
Date: Thu Oct 15 10:27:47 EDT 1992
>From: Ted Timar <tmatimar@isgtec.com>
7.14) Can I get more information on configuration management systems?
Bill Wohler, who compiled all of the information in this part of
the FAQ, has compiled much more information. This information is
available for ftp from ftp.wg.omron.co.jp (133.210.4.4) under
"pub/unix-faq/docs/rev-ctl-sys".
------------------------------
End of unix/faq Digest part 7 of 7
**********************************
--
Ted Timar - tmatimar@isgtec.com
ISG Technologies Inc., 6509 Airport Road, Mississauga, Ontario, Canada L4V 1S7

3715
Zim/Programme/APUE/FAQ/Unix_Programming_FAQ_(v1.37).txt Normal file
View File

File diff suppressed because it is too large Load Diff