[Coco] a new problem with decode

Wayne Campbell asa.rand at gmail.com
Wed Apr 16 18:55:45 EDT 2014


Thanks for that info, Bob. I understand that this is true. Back when I was
coding DCom, and I first got shell+, one of the things the documentation
said (as I recall, anyway) was that Basic09 programs could now be run and
passed parameters without having to use the () and commas to separate
items. DCom used 2 strings as parameters, the filespec (80 chars) and the
option (2 chars). I couldn't reverse it because it was always passed wrong
(and I know why) if the option was left out. By putting the option after
the filespec, I was able to avoid the problem. However, that does not take
away from the fact that because I can't pass numbers or booleans from the
shell, I have to use a different method. In decode, in order to put option
first, I take the whole as a single string by using a character delimiter
(any character, as long as it can be included through the command line)
between the option and the filespec. I use a comma, but it can be any
character. The parser accounts for this position in the string, but does
not care what it is. So, if you type:

decode -o,<filespec>

you're good to go. But if you type:

decode -o<filespec>

you will lose the first character of the filespec and generate a 216 error.
This only happens with the -o option. The -h/-? option has no other data
besides the -h or -?. Anything else added is ignored.

This works, and is cleaner, in my opinion, than dealing with 2 parameter
strings.

Wayne



On Wed, Apr 16, 2014 at 3:26 PM, Bob Devries <devries.bob at gmail.com> wrote:

> Hi Wayne,
>
> I would think that there is no way for Shell to know that what you're
> using as a parameter is string, integer, float or boolean.
>
> In fact, on page 1-6 of the Microware C manual it says:
>
> QOUTE:
> The startup routine for C programs ensures that the parameter string
> passed to it by the parent process is converted to nul-terminated STRINGS
> as expected by the program. In adition, it will run together as a single
> argument any strings enclosed between single or double quotes ("'"or '"').
> /QUOTE
>
> Regards, Bob Devries
> Dalby, QLD, Australia
>
>
> On 17/04/2014 7:28 AM, Wayne Campbell wrote:
>
>> The fix is done. It turned out to be a boolean not set properly. To
>> elaborate, I use booleans to determine which files are open and which are
>> closed. When a file gets opened, the corresponding boolean is set TRUE.
>> When the file is closed, the boolean gets set to FALSE. In this case, I
>> set
>> the boolean FALSE, but in the wrongf place, so as far as the error trap
>> was
>> concerned, that file should have been open and it was repeatedly erroring
>> when trying to close the file.
>>
>> In addition, I was able to solve the 67 error that ErrorCodes has been
>> returning from within decode. I had neglected to change the parameters to
>> strings when calling ErrorCodes from the shell. I learned some time ago
>> that, when the shell passes parameters to Basic09, it makes them all
>> strings. When you would think that:
>>
>> OS9:errorcodes 216 1
>>
>> (216 and 1 being INTEGERS) would work, but the shell turns them into "216"
>> "1". BOOLEANs also are affected. You would think TRUE or FALSE could be
>> passed and B09 would resolve which token to use, but no. The shell turns
>> them into "TRUE" and "FALSE". If you want to pass numbers or booleans, you
>> *MUST* use the syntax:
>>
>> OS9:procedure("string",integer,TRUE)
>>
>> and it should work. This defeats the purpose of the shell being able to
>> pass parameters using the form:
>>
>> OS9:procedure string integer TRUE
>>
>> I started using only string parameters when calling from the shell, and
>> errorcodes and decode are no exception. However, this means that if I want
>> to pass those types, I have to do so using some other delimiter between
>> types and accepting it as one big string, then parse the string for its
>> contents.
>>
>> Wayne
>>
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>



-- 
The Structure of I-Code
http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code

decode
http://cococoding.com/wayne/



More information about the Coco mailing list