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.
>
> HTH
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!!
Lisi
Reply to: