Shell command for tooltype manipulation ViewT

ViewT.lha
http://nl.aminet.net/util/cli/ViewT.lha
I am trying to port the ViewT(ooltypes) Cli command above, by Phil Dietz, to OS4.
This command allows you to print an icon's tooltypes, add one or delete one.
This surely is interesting in scripts.

It works now, but
i have some questions
- one about 'residentiable' programs which this program seems to be.
This seems to be the rationale to not use Printf() but the function PRintf() below.
Does this mean that Printf() is not reentrant?
Searching the web i noted this
"AmigaOS was also entirely reentrant," http://en.wikipedia.org/wiki/Talk%3AAmigaOS
Searching the SDK for 'reentrant' i got 91 hits, the RKRM gave me 4.
I did not find yet a good startin point.
Does anybody knows of a good tutorial?

- To make the command work i had to use Printf() instead of the defined function PRintf() below
Neither the original definition (commented out) nor the one i modified did show the tooltypes, only the count number.
What should it be?


My modified source is at http://users.online.be/AD/ViewTOS4p.c
Extract:

I am trying to port the ViewT(ooltypes)
??? I'd think it would be easier to do it in Python. Read/write a icon ".info " file with new tooltypes, yes? Or, is there something else? Why say it 'C'; it's a maintenance thing.

I see it as getting back in C as an exercice, getting my hands back on the Gui4CLi source in fall; Better have something usefull. Reentrant code is something i would learn more of too. Finally with Gui4CLI i can read all the tooltypestogether,easily. I can not however change or delete them, so i want to update it's source so as to just acheave this.

I did look at Amiga python and did not find an 'icon module' or did i miss it?

I wrote a program with similar functionality, it is on OS4depot. modicon

I think the archive is missing the source code, but I will see if I can fix that some time next week.

Whether a program is reentrant or not depends on the way it is written. Although most AOS programs are inherently reentrant (meaning you can have two or more independent copies running at once), there are some limitations.

For instance, if the program locks a global resource (like the WB screen) while it is running, the other instances of it have to wait. Poor example, I know, but it only needs one Lock to screw things up. Some programs were not written with reentrancy in mind, some were deliberately written to hold onto system resources while they do their work.

It is an exaggeration to say that AmigaOS was completely reentrant. There are always some system tools that will take control of a resource while they do their work. Likewise, some calls to Exec, DOS or Intuition will lock out all others until the resource is freed again. It's necessary to make sure that system structures can not be changed by someone else while you are reading or changing them yourself.

There is no dependency on reentrancy for which version of printf() you use. You can use the C runtime library printf(), you can use DOS' Printf(), Exec's DebugPrintF() or Utility's RawDoFmt(). Normally your program will have Exec and DOS open, so you could use any of them. The C library "printf()" and DOS' "Printf()" will automatically open a console window for you if you are running from a WB icon. DebugPrintF() will usually write to the debug (serial) port, while RawDoFmt() just makes a printable string for you, like fprintf().

I can't see the point of the "PRintf()" definition in your example. You may as well use DOS' "Printf()" or the C library's "printf()".

@tonyw, thanks for your clarifications. Good to see a knowledgeable confirmation of my intuition about PRintf() not really needed to have a reentrant command.

@tesla ModIcon is the command,i thought would be available, but it is still more. I did not think of position of the icon, icontype and other changes, only of tooltype.
Looking forward for your code.

What i would like to achieve is to have all tooltypes as variables (In Gui4CLI after using the "ttget myfile" you have all the tootype names initialised as variables containing their value. I would like to add the opposite command : ttput myfile MYTOOLTYPE mynewttvalue

In a shell command i would use environmental variables for this.
Did not find/look yet how you can write environmental variables in C.
OK : stdlib.h

Quote:

IDOS->Getvar()

IDOS->SetVar()

IDOS->DeleteVar()

@tonyw
Quote:
No. Reentrancy has little to do with how many copies can be run at once. Reentrant means that a single copy of a program can be run by multiple other programs simultaneously. A reentrant command can be added to the system "resident list" with the AmigaDOS "resident" command and the command can be called by multiple programs without reloading it from disk each time. That means that the command cannot have global variables etc.
A reentrant program can't have any internal or external global variables. A program that can be run mulitple times from disk simultaneously can have internal global variables but not external global variables (such as altering an environmental variable with a fixed name).
Some C library functions in older standard C libraries were not reentrant so it was deemed necessary to use AmigaDOS library functions instead of C library functions. I don't know if the more modern newlib.library is completely reentrant so someone else may need to comment on that.

@JosDuchit
Unless you are planning to add your program to the AmigaDOS "resident list" I don't think you need to be worried about it being internally reentrant. However, there might be some concern about using environmental variables. Local environmental variables are "local" to a shell or subshells, not just to the program that sets them. If your program is called twice by the same AmigaDOS script the variables set by the the first copy will be overwritten by the second copy if you use the same variable names in each copy.

Thanks for your hints warnings and explanation.

I did not spot the IDOS functons in the autodocs drawer, because i used "environmental variables" as a seachstring. The autodoc speaks of 'environment variables'
I am not sure but is not the first the more common (and more correct) form?

char*  getenv (const char *name)
int  setenv (const char *name, const char *value, int overwrite)
int  putenv (const char *string)
void  unsetenv (const char *name)

are the stdlib functions that i found.

Quote:

'Environment Variable' is the correct term, and 'environmental variable' is something more like 'rain fall', 'sunlight' etc

The stdlib functions will also work, although they a re limited to global vars IIRC. If your prgram is Amiga Sepecific I would use the DOS functions, use the stdlib only if you need some degree of portabilty.