CLIL source code from book "Firmware demystified"

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello, All!

Recently this book has fallen into my hands and I was reviewing the chapter
dedicated to development of  Command Line Interface for generic embedded
system.

I was confused, the author offers unusual method: there is main function
getting command line from user and parsing it, than calls appropriate
function (for example, which shows env. variables: show_env()) and pass
'argc' and 'argv[]' to that function (assuming that in CLI prompt you enter
some arguments, like 'show env current').

How is it possible to work?

With best regards, Roman Mashak.  E-mail: snipped-for-privacy@tusur.ru



Re: CLIL source code from book "Firmware demystified"


Quoted text here. Click to load it

What exactly do you not understand?
- main function getting command line from user?
- parsing it?
- calls appropriate function?
- pass 'argc' and 'argv[]'?

Quoted text here. Click to load it


Re: CLIL source code from book "Firmware demystified"
Hello, Lanarcam!
You wrote  on 29 Jun 2005 02:02:52 -0700:

 ??>> parsing it, than calls appropriate function (for example, which shows
 ??>> env. variables: show_env()) and pass 'argc' and 'argv[]' to that
 ??>> function (assuming that in CLI prompt you enter some arguments, like
 ??>> 'show env current'). How is it possible to work?

 L> What exactly do you not understand?
 L> - main function getting command line from user?
 L> - parsing it?
 L> - calls appropriate function?
 L> - pass 'argc' and 'argv[]'?
Main function gets command line (comman and its arguments) from user and
than pass it to appropriate function handling all functionality. I don't
understand why is 'argc' and 'argv[]' is passed, because I used to think
'argc' and 'argv[]' are valid only with a program running, not function.

With best regards, Roman Mashak.  E-mail: snipped-for-privacy@tusur.ru



Re: CLIL source code from book "Firmware demystified"


Quoted text here. Click to load it

If from a script shell you invoke a command such as

prompt> prog arg1 arg2

then a process is started, prog, whose main function receives
as arguments argc, the number of arguments and argv[], the
list of arguments, here arg1 and arg2.

The process is started by the shell. The process then parses
the arguments and calls the appropriate function.

When the process has finished its task it terminates and
the prompt is displayed again.

Or the process could be launched as a background process
and the prompt is displayed immediately.

Quoted text here. Click to load it


Re: CLIL source code from book "Firmware demystified"
Quoted text here. Click to load it

You certainly can pass argc and argv to another function.
One of my standard programming techniques is to have a
function such as:

int valid_options(int argc, char *argv[], )

which processes the CLI arguments and places the results
in a location where the rest of the program can use them.
No muss, no fuss.

Re: CLIL source code from book "Firmware demystified"
Hello, Everett!
You wrote  on Wed, 29 Jun 2005 10:16:16 PST:

 ??>> Main function gets command line (comman and its arguments) from user
 ??>> and than pass it to appropriate function handling all functionality. I
 ??>> don't understand why is 'argc' and 'argv[]' is passed, because I used
 ??>> to think 'argc' and 'argv[]' are valid only with a program running,
 ??>> not function.

 EMG> You certainly can pass argc and argv to another function.
 EMG> One of my standard programming techniques is to have a
 EMG> function such as:

 EMG> int valid_options(int argc, char *argv[], )
I don't quite understand WHY I can pass 'argc' and 'argv' to another
function? The reason I ask this is every command I type in command line is
not a seperate process, it's run in the whoel scope (according to the book I
mentioned before). And originally 'argc' and 'argv' are valid for
single-running processes, not as a part of any code.

Still confused...

With best regards, Roman Mashak.  E-mail: snipped-for-privacy@tusur.ru



Re: CLIL source code from book "Firmware demystified"

Quoted text here. Click to load it

Because they're nowhere near as special as you assume them to be.
They have *no* special meaning to the language, the standard library,
or anything.  Using 'argc' and 'argv' as the names of the arguments of
main() in a hosted environment is pure convention.

Any C function can have arguments called 'argc' and 'argv', of
whatever type you like.  You could use them with reversed roles, just
for the perverse fun of it, i.e. let 'argv' be the count of arguments,
and 'argc' the array of strings.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CLIL source code from book "Firmware demystified"


Quoted text here. Click to load it

I

I don't understand your non-understanding. argc and argv have lifetime
throughout the execution of the process in question. The first is
an integer, and the second is a pointer to a (effectively constant)
array of strings. If you need to be able to use these anywhere in your
code (for a single process) you can. What is it that you expect not
to be able to do ?

In particular, what do you mean by "single-running processes, not as
a part of any code" ?

Richard [in PE12]



Re: CLIL source code from book "Firmware demystified"

Quoted text here. Click to load it

I haven't read the book, but I think I know what your question is
about.  I think all of your other replies come from their confusion
(and yours, as well.)

When DOS attempts to parse a command line, the Microsoft designers
included an INT 2Fh, Function AEh undocumented feature to permit the
replacement of both internal DOS commands as well as to allow special
processing of the command line before COMMAND.COM did its default
processing for it.  In fact, the command APPEND uses this feature.

Two sets of calls are provided: one to determine if a command is
supported by any of the functions that are hooked into this interface
and the other to, obviously, then execute or implement it.  In the
first case, DOS calls with AL00%h.  DOS expects to see a response of
FFh in AL if the command is supported by one of the installable
command functions hooked in.  If one does send back the ALFF%h, then
DOS calls it back with AL01%h so that the command gets executed by the
installed code and NOT by DOS's COMMAND.COM program.  The command line
text is passed in DS:SI, in both cases.

I suspect that this is what you are on about.

Jon

Re: CLIL source code from book "Firmware demystified"
Hello,

thank to everyone for replies. I was overthinking the meaning of 'argc' and
'argv' parameters :-) Now it's clear.

With best regards, Roman Mashak.  E-mail: snipped-for-privacy@tusur.ru



Site Timeline