Hello any one. :-)
I'm interested in wrting a file parser using AmigaDOS routines. In particular ReadArgs() and any related functions. The file could be read into memory or read in line by line.
The file read in would be similar to an AmigaDOS template and in some places exactly alike. I'd like to be able to pick out key words and act out on them. That is the key words themselves would each represent a different template. Like different commands.
I'd also like to deal with comments and mask them out. The end result would be like a basic shell script. Where it loads in a line and interprets it. Mine would be similar. But I would use it to load in settings so it would be somewhat like a settings file. I can see an example will be needed to demonstrate.
Has anyone used ReadArgs() for this purpose? As you can see my example would be suitable for this purpose. I looked online but found no examples, just brief talk of doing it.
VERSION 1.0 LABEL "Label" KEY Example="String" OPTION ACTIVATE SELECT=1 EXTRA OPTIONS ON
This would correlate to the following keyword templates:
VERSION/K
LABEL/K
KEY NAME/K/A
OPTION ACTIVATE/S SELECTK/N OTHER/K
EXTRA OPTIONS/T
I see two possible ways:
1. read one line at a time, extract the first word manually and from it decide which template to apply to the rest of the line.
2. read the whole file into a buffer, eliminate all comments and newline characters and then parse it using just one template which contains all keywords.
IMHO the first one matches better to what you seem to imagine.
The second one is what the Mount command probably does. But in this case you cannot have options without values, like KEY, OPTION and EXTRA in your example.
You could hide them with /S, but you wouldn't be able to ensure that EXAMPLE is only used in a line starting with KEY or that ACTIVATE is only used in a line starting with OPTION.
Thanks Thomas for the advice.
I thought it may be more efficient to read the entire file in memory. Then supply it as a buffer. I suppose it could just as easily be an input file.
The doc says each string needs a newline. Which shouldn't be a problem in a text file. But doesn't say if it needs termination. Since a file would lack termination a whole string buffer should be fine in that case.
Mount is a good example as I want to do something similar. Including how it handles commments. Just slightly more complicated. One problem is comments, since an argument line doesn't have any. So I would need to detect those or filter them out.
I think either way I will need to manually find the first word on every line. Since this determines the template used I don't think using a "#/F" is a safe option for comments. :-)
I'm thinking a template with switches for all my keywords could work. But then I'd have an array I need to clear and check every entry of after to detect one keyword. Though it would make sense to process each entry in turn.
I should probably look into ReadItem() or ReadLineItem() but those look more complicated and the former is buggy. FindArg() looks interesting but I can't get my head around it. It's unclear what it means by template. In the normal understanding it would look for a keyword in a template, but why would you look for it in the template? Huh? Are they confuisng terms here? Clearly, like a lof of AmigaOS things, this needs an example.
ReadArgs() will allow you to parse a file, so will ReadLineItem().
Take a look at include/dos/rdargs.h in there you will find the RDArgs and CSource structures.
Initialise the CSource structure with your filehandle and friends, and you're done.
As for FindArgs(), I have written a new autodoc with examples, there is also extensive
information for the ReadLineItem() function as well as example code in the Autodoc.
If you wanted to parse the arguments yourself and put them into a custom output format,
you would use ReadLineItem() to get the 'words' and then FindArgs() to identify them,
just like the ReadArgs() function does internally. It also handles comments.
Make sure you have the latest SDK. (53.33)
Thank you cwenzel. Yes those examples are helpful. That looks like a plan. An issue I can see would be with having a string copied to a buffer as I would prefer it to read it directly but I'm just picky about slight overhead that way. :-)