Environmental variables - Library?

I don't find much about the internals of environmental variables in th SDK
Did i overlook it?

Q: are they kept in some list?
If yes how can you access the list & say prin them out all?

@JosDuchIt
The Global environmental variables are in ENV: and you can see them typing something like "list ENV: ALL FILES QUICK". The Local environmental variables for a shell might require you to use IDOS->ScanVars() in a program.

Do *not* use file i/o on environment variables!

In a Shell you can use Set or SetEnv without arguments to print all variables.

In a program you use

GetVar
SetVar
DeleteVar
FindVar
ScanVars

of dos.library

@thomas
Quote:
Why not? Most of the system prefs programs save their prefs files with file i/o. Check the prefs system files in SYS:Prefs/env-archive and you will see that most of them are IFF files (FORM). The system prefs programs are obvioulsy using iffparse.library to load and save their prefs with file i/o. In addition, if you search your system partition for the words ENV: and ENVARC: and you will find dozens of programs containing those words. Why would a program need to know about ENV: and ENVARC: if it's using the environmental variable functions like GetVar() or SetVar() to set prefs?

It is recommended that we use designated functions to access environmental variable instead of using file i/o, but if the system programs do it then it won't do any harm for us to do the same. The old saying "What's good for the goose is good for the gander" comes to mind.

We've also been misled by the claim that the ENV: device only acceses saved variables when they are requested with GetEnv. If you doubt that try this:
Save an environmental variable with SetEnv SAVE myvar "variable test".
Perform a warm system reboot.
Enter "GetEnv myvar" from a shell while watching your hard-disk LED.
You won't detect any disk activity but you will get the value of "myvar".

If you talk about OS3 which will never again change, then ok, do what you want.

But if you develop for OS4 and want to be future-proof, then RTFM! And please don't argue against what the docs say.

I know that up to now env vars are stored in files and can be used like files. But anyway the env system should be considered a black box which can change. Don't give bad advice only because you know about the inner workings. They might change in the future.

(And harddisk activity while reading or writing data proves nothing. Of course permanent settings have to be saved to disk, otherwise they wouldn't be permanent.)

@thomas

My initial question was about some library function to get hold of the list of env variables.
Till now the only answer is: go get them listing the content of env
Is this indeed the only way? This seems to go against the advice to use only system functions to access them.

As for the discussion about the dual acces of the env: variables as files or as variables:
I would considere it a big loss of functionality if at some point you wouldn't be able to access them as files, or if any other limitation on what such a variable could contain (only xml, only IFF ??) was introduced.

It would be of rather major importance to me to clarify what the functional advantages would be. I don't see a single one and i even can't think of one. I can be wrong, but then the question is: can't other solutions to acheave the advantage(s) be found that are more acceptable?

In first instance dropping the double access possibility, would stop even a lot of programs reworked to OS4 standards from working. It can be doubted if all authors would still be eager to adapt them once more.

env varibles can be used not only to save settings but they offer also easy ways of interaction between applciations.

Gui4Cli uses the double possibility quite extensively, giving each simultaneous running script the possibility to define env variables (all starting with a ".") directly or by saving some file in env; and permitting its access (in both cases) s a file (eg loading them in a listview)
by other scripts.



Advantages of dropping the file access that are known or come to mind?

@JosDuchIt

He did say:

"
GetVar
SetVar
DeleteVar
FindVar
ScanVars

of dos.library
"

Stick to that and you'll be fine.

@orgin
Indeed, thanks for pointing out. i did read his initial answer too rapidly &
ScanVars() is the function i missed.
My latest reaction was a bit of a panic reaction.

It should be read solely as a question for information, about the dual access possibility of an env variable. It is a feature of the Gui4CLi language to make use of both , and in the structured sets of G4scriptis wrote, i make extensive use of this duality.

I'll have to check if and how reading in the content of an environmental variable as a file in a listview (LVChange env:.MyEnvVar ) which i want to maintain in Gui4Cli can be internally replaced by the available dos calls.

@thomas
Quote:
Changing the environmental variable system is a dream that can never materialize as long as we need backward compatability in OS4. Besides, why turn a completely functional environmental variable system into a mysterious "black box" that can only be accessed by the system? It seems like a very MS concept to me

I will however, refrain from advising filesystem access to ENV: in the future.

@thomas
Quote:
Set without args only prints "local" variables. SetEnv without args only prints the top level "global" variables, not the variables in directories (like ENV:sys). The only way to see all the Global variables from a shell is to use the filesystem method you chastised me for advising.

If it were true that ENV: only loads variables from ENVARC: when they are requested by a program then ScanVars() will cause all variables to be loaded and make the whole concept of a non-filesystem ENV: device somewhat useless. Please don't take my skepticism personally. I'm not criticising you.