[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Subroutine arguments not right yet
- From: "Jeff Wise" <jwise@...>
- Date: Thu, 6 Sep 2007 12:21:59 -0500
>> The "dummy2" is a "hello, world" program which also prints
>> the two arguments that were passed to it.
>The arg table is created for scripts called from the command
>line, so the arg table you're seeing is the one created for
>the calling program's command-line arguments. Try making
>dummy2.lua look like this:
> print("dummy2.lua's arguments:", ...)
>> print("Call # 2 --------------------------------")
>> assert(loadfile("C:\\lua\\source\\dummy2.lua"))
>loadfile just creates a function; the above never calls it.
>(Calls 1 and 3 are fine.)
--
>Aaron
>http://arundelo.com/
Thank you for your reply. Unfortunately, I have no clue what you are
telling me. My background is probably very different than most on this
forum, as it is mostly IBM mainframe assembler. Perhaps this is the source
of my difficulty. I apologize for my lack of comprehension.
An examination of "loadfil4" reveals that the last 3 groups of statements
are testing multiple ways to invoke "dummy2". It totally escapes me why
there is no output from dummy2 on call #2. This is confusing to me.
The real problem is that I wish to "construct" the "parameters" that I send
to the second program ("dummy2" in this case). This program ("dummy2") is
written to display these two passed parameters, and as calls 1 and 3
illustrate, nothing seems to pass these arguments. I am aware that if I
provide "loadfil4" with command line arguments (invoked by "lua
c:\lua\source\loadfil4.lua 'Apple' 'Banana'" I will in fact get apple and
banana passed to dummy2. This does NOT allow "loadfil4" to construct these
passed arguments. In other words, "loadfil4" will "discover" these
arguments in the data it processes, and send that to "dummy2".
Again, there is a real program which has this problem, but with many lines
of code I wrote these simplified programs just to illustrate the question.
Said a third way, the first program will analyze data, build the "loadfile"
request from this data including the passed arguments, and allow the second
program to perform its function. This is my attempt at modularized
function, and I am emulating a common mainframe assembler technique.
It may be that the "arg[1]" construct is ONLY valid from "command line
arguments". If that is the case, I'm sure lua provides some other mechanism
for chaining program execution. The old mainframe makes no distinction in
its linkage conventions.
I apologize for the long reply. I am very interested in how to solve this
problem.
TIA
CONFIDENTIALITY NOTICE: This E-mail message and all attachments, which
originated from Sealy Management Company Inc, are intended solely for the
use of the intended recipient or entity and may contain legally privileged
and confidential information. If the reader of this message is not the
intended recipient, you are hereby notified that any reading, disclosure,
dissemination, distribution, copying or other use of this message is
strictly prohibited. If you have received this message in error, please
notify the sender of the message immediately and delete this message and all
attachments, including all copies or backups thereof, from your system. You
may also reach us by phone at 205-391-6000. Thank you.
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.6/991 - Release Date: 9/5/2007
2:55 PM
CONFIDENTIALITY NOTICE: This E-mail message and all attachments, which originated from Sealy Management Company Inc, are intended solely for the use of the intended recipient or entity and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any reading, disclosure, dissemination, distribution, copying or other use of this message is strictly prohibited. If you have received this message in error, please notify the sender of the message immediately and delete this message and all attachments, including all copies or backups thereof, from your system. You may also reach us by phone at 205-391-6000. Thank you.