On Sunday 06 February 2011 06:23:46 Boyd Stephen Smith Jr. wrote: > In <201102060600.08478.lisi.re...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102061016.43301.lisi.re...@gmail.com
