Intro man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]

INTRO(1)							      INTRO(1)

       Intro, intro - introduction to commands and application programs

       This  section describes, in alphabetical order, commands available with
       this operating system.

       Pages of special interest are categorized as follows:

	     Commands found only in the SunOS/BSD Compatibility Package.

	     Commands for communicating with other systems.

	     Commands associated  with	Form  and  Menu	 Language  Interpreter

	     Commands specific to SunOS.

       See  the	 following  sections  of  the  SunOS Reference Manual for more

	   o	  Section 1M for system maintenance commands.

	   o	  Section 4 for information on file formats.

	   o	  Section 5 for descriptions of publicly available  files  and
		  miscellaneous information pages.

       For  tutorial  information  about  these	 commands  and procedures, see
       Solaris Advanced User's Guide.

   Manual Page Command Syntax
       Unless otherwise noted, commands described in the SYNOPSIS section of a
       manual page accept options and other arguments according to the follow‐
       ing syntax and should be interpreted as explained below.

       name [-option...] [cmdarg...] where:

       [ ]
		      Surround an option or cmdarg that is not required.

		      Indicates multiple occurrences of the option or cmdarg.

		      The name of an executable file.

       { }
		      The options and/or arguments enclosed within braces  are
		      interdependent,  such  that  everything enclosed must be
		      treated as a unit.

		      (Always preceded by a "−".) noargletter... or, argletter

		      A	 single	 letter	 representing  an  option  without  an
		      option-argument. Notice that more than  one  noargletter
		      option  can  be  grouped	after  one  "−"	 (Guideline 5,

		      A single letter  representing  an	 option	 requiring  an

		      An  option-argument (character string) satisfying a pre‐
		      ceding argletter.	 Notice that groups of optargs follow‐
		      ing  an  argletter must be separated by commas, or sepa‐
		      rated by a tab or space character and quoted  (Guideline
		      8, below).

		      Path name (or other command argument) not beginning with
		      "−", or "−" by itself indicating the standard input.

       Unless otherwise specified, whenever an operand or option-argument  is,
       or contains, a numeric value:

	   o	  The number is interpreted as a decimal integer.

	   o	  Numerals in the range 0 to 2147483647 are syntactically rec‐
		  ognized as numeric values.

	   o	  When the utility description states that it accepts negative
		  numbers  as  operands	 or  option-arguments, numerals in the
		  range -2147483647 to 2147483647 are syntactically recognized
		  as numeric values.

	   o	  Ranges greater than those listed here are allowed.

   Command Syntax Standard: Guidelines
       These  command  syntax  guidelines are not followed by all current com‐
       mands, but new commands are likely to obey them. getopts(1)  should  be
       used  by	 all  shell  procedures	 to parse positional parameters and to
       check for legal	options.   It  supports	 Guidelines  3-10  below.  The
       enforcement of the other guidelines must be done by the command itself.

	   1.	  Command  names  (name	 above) should be between two and nine
		  characters long.

	   2.	  Command names should include	only  lower-case  letters  and

	   3.	  Option names (option above) must be one character long.

	   4.	  All options must be preceded by "−".

	   5.	  Options with no arguments can be grouped after a single "−".

	   6.	  The first option-argument (optarg above) following an option
		  must be preceded by a tab or space character.

	   7.	  Option-arguments cannot be optional.

	   8.	  Groups of option-arguments following an option  must	either
		  be  separated by commas or separated by tab or space charac‐
		  ter and quoted (-o xxx,z,yy or -o"xxx z yy").

	   9.	  All options must precede operands (cmdarg above) on the com‐
		  mand line.

	   10.	  "−−" can be used to indicate the end of the options.

	   11.	  The  order of the options relative to one another should not

	   12.	  The relative order of the operands (cmdarg above) can affect
		  their	 significance  in  ways determined by the command with
		  which they appear.

	   13.	  "−" preceded and followed by a white space character	should
		  only be used to mean standard input.

       An  expanded  set  of  guidelines  referred to as CLIP for Command Line
       Interface Paradigm has been developed for Solaris and other  Sun	 prod‐
       ucts.  Its  intent  is  to  provide  a command line syntax more closely
       aligned with the GNU command line syntax popular on Linux systems.There
       is  no  intent  to retrofit existing utilities or even to apply this to
       all new utilities. It is only intended to be applied to sets of	utili‐
       ties being developed when appropriate.

       CLIP  is	 a  full  superset of the guidelines discussed above which are
       closely aligned with IEEE Std. 1003.1-2001 (SUSv3). It does not include
       all  the	 GNU syntax. The GNU syntax allows constructs that either con‐
       flict with the IEEE rules or are ambiguous. These  constructs  are  not

       The expanded CLIP command line syntax is:

	 utility_name -a --longopt1 -c option_argument \
	    -f option_argument --longopt2=option_argument \
	    --longopt3 option_argument operand

       The  utility  in	 the  example is named utility_name. It is followed by
       options, option-arguments, and operands, collectively  referred	to  as
       arguments.   The	 arguments  that consist of a hyphen followed a single
       letter or digit, such as -a, are known as short-options . The arguments
       that consist of two hyphens followed by a series of letters, digits and
       hyphens, such as --longopt1, are known as long-options .	 Collectively,
       short-options  and long-options are referred to as options (or histori‐
       cally, flags ). Certain options are followed by an option-argument,  as
       shown  with  -c	option_argument	 .  The	 arguments  following the last
       options and option-arguments are named operands. Once the first operand
       is  encountered,	 all  subsequent arguments are interpreted to be oper‐

       Option-arguments are sometimes shown separated from their short-options
       by  BLANKSs,  sometimes	directly adjacent. This reflects the situation
       that in some cases an option-argument is included within the same argu‐
       ment  string as the option; in most cases it is the next argument. This
       specification requires that the option be a separate argument from  its
       option-argument,	 but  there  are  some	exceptions to ensure continued
       operation of historical applications:

	   o	  If the SYNOPSIS of a utility shows a SPACE between a	short-
		  option  and  option-argument	(as with -c option_argument in
		  the example), the application uses  separate	arguments  for
		  that option and its option-argument.

	   o	  If  a	 SPACE is not shown (as with -f option_argument in the
		  example), the application expects an option and its  option-
		  argument  directly  adjacent	in  the	 same argument string,
		  without intervening BLANKs.

	   o	  Notwithstanding the preceding requirements,  an  application
		  should accept short-options and option-arguments as a single
		  argument or as separate arguments whether or not a SPACE  is
		  shown on the synopsis line.

	   o	  Long-options	with option-arguments are always documented as
		  using an equals sign as the  separator  between  the	option
		  name	and  the  option-argument. If the OPTIONS section of a
		  utility shows an equals sign (=) between a  long-option  and
		  its  option-argument (as with --longopt2= option_argument in
		  the example), a application shall also  permit  the  use  of
		  separate  arguments  for that option and its option-argument
		  (as with --longopt1 option_argument in the example).

       CLIP expands the guidelines discussed  with  the	 following  additional

	      The  form command subcommand [options] [operands] is appropriate
	      for grouping similar operations. Subcommand names should	follow
	      the same conventions as command names as specified in guidelines
	      1 and 2.

	      Long-options should be preceded by -- and	 should	 include  only
	      alphanumeric  characters and hyphens from the portable character
	      set. Option names are typically one to three  words  long,  with
	      hyphens to separate words.

	      --name=argument should be used to specify an option-argument for
	      a long-option. The form --name argument is also accepted.

	      All utilities should support two standard	 long-options:	--ver‐
	      sion  (with  the	short-option synonym -V ) and --help (with the
	      short-option synonym -? ). The short option synonyms for	--ver‐
	      sion  can vary if the preferred synonym is already in use (but a
	      synonym shall be provided).  Both of these options stop  further
	      argument	processing  when  encountered and after displaying the
	      appropriate output, the utility successfully exits.

	      Every short-option should have exactly one  corresponding	 long-
	      option and every long-option should have exactly one correspond‐
	      ing short-option. Synonymous  options  can  be  allowed  in  the
	      interest	of compatibility with historical practice or community
	      versions of equivalent utilities.

	      The short-option name should get its name from  the  long-option
	      name according to these rules:

		  1.	 Use  the first letter of the long-option name for the
			 short-option name.

		  2.	 If the first letter conflicts with other short-option
			 names, choose a prominent consonant.

		  3.	 If  the first letter and the prominent consonant con‐
			 flict with other shortoption names, choose  a	promi‐
			 nent vowel.

		  4.	 If  none  of  the letters of the long-option name are
			 usable, select an arbitrary character.

	      If a long-option name consists of a single  character,  it  must
	      use  the same character as the short-option name. Single charac‐
	      ter long-options should be avoided. They are  only  allowed  for
	      the  exceptionally rare case that a single character is the most
	      descriptive name.

	      The subcommand in the form described in guideline 1 of the addi‐
	      tional  CLIP guidelines is generally required. In the case where
	      it is omitted, the command  shall	 take  no  operands  and  only
	      options  which  are  defined to stop further argument processing
	      when encountered are allowed. Invoking a command	of  this  form
	      without  a  subcommand and no arguments is an error. This guide‐
	      line is provided to allow the common forms command --help,  com‐
	      mand -?, command --version, and command -V to be accepted in the
	      command-subcommand construct.

       Several of these guidelines are only of	interest  to  the  authors  of
       utilities.   They  are  provided	 here for the use of anyone wanting to
       author utilities following this syntax.

       See attributes(5) for a discussion of the  attributes  listed  in  this

       Sun  Microsystems, Inc. gratefully acknowledges The Open Group for per‐
       mission to reproduce portions of its copyrighted documentation.	Origi‐
       nal  documentation  from	 The  Open  Group  can	be  obtained online at

       The Institute of Electrical and	Electronics  Engineers	and  The  Open
       Group, have given us permission to reprint portions of their documenta‐

       In the following statement, the phrase ``this text'' refers to portions
       of the system documentation.

       Portions	 of  this text are reprinted and reproduced in electronic form
       in the SunOS Reference Manual, from  IEEE  Std  1003.1,	2004  Edition,
       Standard for Information Technology -- Portable Operating System Inter‐
       face (POSIX), The Open Group Base Specifications Issue 6, Copyright (C)
       2001-2004 by the Institute of Electrical and Electronics Engineers, Inc
       and The Open Group.  In the event of any discrepancy between these ver‐
       sions  and  the original IEEE and The Open Group Standard, the original
       IEEE and The Open Group Standard is the referee document.  The original
       Standard	    can	    be	  obtained    online	at‐

       This notice shall appear on any product containing this material.

       getopts(1), wait(1), exit(2), getopt(3C), wait(3UCB), attributes(5)

       Upon termination, each command returns two bytes of  status,  one  sup‐
       plied  by  the system and giving the cause for termination, and (in the
       case  of	 "normal"  termination)	 one  supplied	by  the	 program  [see
       wait(3UCB)  and	exit(2)]. The former byte is 0 for normal termination.
       The latter byte is customarily 0 for successful execution and  non-zero
       to indicate troubles such as erroneous parameters, or bad or inaccessi‐
       ble data. It is called variously "exit code", "exit status", or "return
       code", and is described only where special conventions are involved.

       Some commands produce unexpected results when processing files contain‐
       ing null characters. These commands often treat	text  input  lines  as
       strings	and therefore become confused upon encountering a null charac‐
       ter (the string terminator) within a line.

				 Nov 18, 2008			      INTRO(1)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net