Anonymous user
Talk:Parse command-line arguments: Difference between revisions
Talk:Parse command-line arguments (view source)
Revision as of 21:53, 15 December 2011
, 12 years ago→Task needs a task
(→Command line parameter conventions: Complex area, alas) |
|||
| (6 intermediate revisions by 3 users not shown) | |||
Line 1:
== Reasons ==
Reasons for this article:
Line 36 ⟶ 37:
The task description should probably specify what is to be accomplished here. --[[User:Rdm|Rdm]] 00:32, 9 August 2011 (UTC)
: It sure does... when will the below be added? — [[User:Crazyfirex|Crazyfirex]] 21:53, 15 December 2011 (UTC)
==Possible task==
Write a program:
# That if it sees an option called <math>b</math> will set an internal variable to Boolean true; otherwise the internal variable is false.
# Accepts an option called <math>s</math> followed by a string then sets an internal variable to the value of the string.
# Accepts an option called <math>n</math> followed by a number (integer or float) then sets an internal variable to the value of the string.
The order of the three options mentioned can vary and and option indicators such as any preceeding '-', '--', or ':' characters are allowed and should follow the conventions of an OS.
Comments please. --[[User:Paddy3118|Paddy3118]] 06:59, 13 September 2011 (UTC)
:Do you mean follow the conventions of an OS which might be different from the one where the command line is being used? Or do you mean that the program should detect what OS it is running under (and, for an interpreted language, that can change without any changes in the program). Meanwhile, the rules for quote handling under windows look [http://ss64.com/nt/cmd.html baroque]. Also the concept of "followed by a string" can be ambiguous (in the same option? in the next option? in the same option after an = character? ...) And then there's the handling of -- followed by whitespace that should probably be respected if we are using hyphen to delimit command line options? Meanwhile, another possibility here (one that seems to have been followed by some "implementations") is that of documenting the default parsing provided by the language. --[[User:Rdm|Rdm]] 10:36, 13 September 2011 (UTC)
::Hi.
::# Choose your OS (This may affect the normal option syntax)
::# What is the normal way of adding an option that is stand-alone; i.e. the presence/absence is used to set a boolean variable within your program, and has a name of 'b'.
::# What is the normal way of adding a string value associated with an option name of 's'
::# What is the normal way of adding a numeric value associated with an option name of 'n'
::Use extra syntax appropriate for the OS, but implement it in such a way that the order of the options is set by the option names b, s, and n and not hard-coded into the prog.
::Note: No mention of determining an OS. I have tried to leave enough scope to cater for different option syntaxes in different OS's, hoping that what I have nailed down should be workable under more than one OS, and recognising that even within one OS, there may be multiple schemes for specifying options (choose one, probably the one adopted by your languages compiler/interpreter). Please don't invent an options scheme for the task, adhere to some 'standard'. --[[User:Paddy3118|Paddy3118]] 12:44, 13 September 2011 (UTC)
::I guess I didn't want to force adherence to something like <code>progname -b -s 'Some string' -n 1.2345</code> as some might think it doesn't fit their OS or options scheme from some languages library. --[[User:Paddy3118|Paddy3118]] 12:52, 13 September 2011 (UTC)
:Me being me, I might want to add that the program should print a table of (sorted) option name vs option value for sdifferent runs with/without the b option and with options specified in different orders, Hmmm? --[[User:Paddy3118|Paddy3118]] 12:55, 13 September 2011 (UTC)
| |||