[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: parameters and the command line

On Sunday 06 February 2011 06:23:46 Boyd Stephen Smith Jr. wrote:
> In <201102060600.08478.lisi.reisz@gmail.com>, Lisi wrote:
> >Since I first used Linux I have been used (apparently erroneously) to the
> >idea of:
> >command options argument
> I think using that terminology will generally get your point across.
> >Now suddenly the word "parameters" jumps out at me in this context.
> This term is often avoided when discussing the shell, unless you are
> talking about shell functions.  The term includes what both options and
> arguments from above and can also mean the constructs used to access those
> values from within the function body.
> >Help!  What are parameters?
> If you want semi-formal defintions...
> From SUSv2:
> Parameters and Variables
>  A parameter can be denoted by a name, a number or one of the special
> characters listed in  Special Parameters . A variable is a parameter
> denoted by a name.
>  A parameter is set if it has an assigned value (null is a valid value).
> Once a variable is set, it can only be unset by using the unset special
> built-in command.
> My examples would be $1, $@, $USER, $LC_ALL, and $bar.
> Also from SUSv2:
> Utility Syntax Guidelines
>  The following guidelines are established for the naming of utilities and
> for the specification of options, option-arguments and operands. The
> getopt() function in the XSH specification assists utilities in handling
> options and operands that conform to these guidelines.
>  Operands and option-arguments can contain characters not specified in the
> portable character set.
> [...]
> Guideline  4:
> All options should be preceded by the "-" delimiter character.
> Guideline  5:
> Options without option-arguments should be accepted when grouped behind one
> "-" delimiter.
> Guideline  6:
> Each option and option-argument should be a separate argument, except as
> noted in  Utility Argument Syntax , item (2).
> Guideline  7:
> Option-arguments should not be optional.
> [...]
> Guideline  9:
> All options should precede operands on the command line.
> Guideline 10:
> The argument -- should be accepted as a delimiter indicating the end of
> options. Any following arguments should be treated as operands, even if
> they begin with the "-" character. The -- argument should not be used as an
> option or as an operand. Applications calling any utility with a first
> operand starting with - should usually specify --, as indicated by
> Guideline 10, to mark the end of the options. This is true even if the
> SYNOPSIS in the XCU specification does not specify any options;
> implementations may provide options as extensions to the XCU specification.
> The standard utilities that do not support Guideline 10 indicate that fact
> in the OPTIONS section of the utility description.
> So, if you work within the analogy of C function ~=~ shell command, then
> you get C formal parameter ~=~ shell Positional Parameter, C actual
> parameter `=~ shell argument, C variable ~=~ Shell non-Positional
> Parameter.  The shell terms "option", "option-argument", and "operand"
> don't directly correspond to C terms.  "options" include things like "-E"
> or "-q" to grep and "-l" to wc. "option-arguments" include things like what
> follows "-f" to tar or "-e" to sed or grep. "operands" are generally path
> names (files or directories), but they might be something else; they don't
> "belong" to a particular "option" but rather direct the global behavior of
> the command.

Thanks for taking so much trouble, Boyd.  I'm not sure that I understand 
massively better, but a bit, and hopefully it will eventually penetrate!  
I'll read it again when I am under less pressure.  I decided for now to 
pretend that my incomprehension doesn't matter!!


Reply to: