Page 1 of 1

Resolving environment variables

PostPosted: October 4th, 2011, 3:06 pm
by Ajay Askoolum
Two small but useful enhancements to file functions (in V11 ?)

a. where environment variables are transparently resolved would be welcome:

- this would simplify code
- avoid the need for API calls

E.G.

'%TMP%\ajay%date%.txt' []xncreate tie

'c:\xyz\file_%computername%_%date%.sf' []fcreate tie

%date% would resolve to local short date format etc.

b. aupport for tie to be 0

- the tie number is automatically determined and explicitly returned.

Re: Resolving environment variables

PostPosted: October 4th, 2011, 5:18 pm
by Tech Support
This is already supported in the colossal ([]CF) component file system.

Ajay Askoolum wrote:b. aupport for tie to be 0

- the tie number is automatically determined and explicitly returned.

Re: Resolving environment variables

PostPosted: October 4th, 2011, 5:21 pm
by Tech Support
This looks interesting. However, the use of the percent sign wouldn't be good because it is a valid character for a file name; angle brackets, <> might be preferable instead.

Ajay Askoolum wrote:a. where environment variables are transparently resolved would be welcome:

- this would simplify code
- avoid the need for API calls

E.G.

'%TMP%\ajay%date%.txt' []xncreate tie

'c:\xyz\file_%computername%_%date%.sf' []fcreate tie

%date% would resolve to local short date format etc.

PostPosted: October 5th, 2011, 12:31 am
by Ajay Askoolum
Perhaps you can implement this:

- only pairs of % separated by an environment variable name are resolved.
- all other instances are left untouched.

Angle brackets will do, as you have suggested; however, this will introduce a deviation from other contexts such as the command line where the resolution is as described above.

PostPosted: October 16th, 2011, 3:22 pm
by Ajay Askoolum
I just discovered something & I need to clarify.

There are Environment Variable like USERNAME, TMP etc.

Such variables can be resolved with the GetEnvironmentVariable API e.g.

{take}{tale}[]wcall 'GetEnvironmentVariable' 'USERNAME' (256{shape}[]tcnul) 256

NOTE: No wrap round delimiters needed but variable name needs to be isolated before being submitted as the first argument.

And then there are Windows Variables like "%windir%'

GetEnvironmentVariable does no resolve these.

Need to be able to resolve both types.

PostPosted: October 16th, 2011, 3:28 pm
by Ajay Askoolum
Ajay Askoolum wrote:I just discovered something & I need to clarify.

There are Environment Variable like USERNAME, TMP etc.

Such variables can be resolved with the GetEnvironmentVariable API e.g.

{take}{tale}[]wcall 'GetEnvironmentVariable' 'USERNAME' (256{shape}[]tcnul) 256

NOTE: No wrap round delimiters needed but variable name needs to be isolated before being submitted as the first argument.

And then (this is the discovery!) there are Windows Variables like "%windir%'

GetEnvironmentVariable does not resolve these.

Need to be able to resolve both types.

PostPosted: October 17th, 2011, 9:48 am
by Tech Support
You can easily retrieve any environment variable using DOS command: echo %environment_variable%
[code]
Examples:

⎕vr 'GetEnv'
∇ GetEnv var
[1] 3 ⎕cmd 'echo %',var,'% > env-var.txt' â

PostPosted: October 17th, 2011, 4:25 pm
by Ajay Askoolum
I should have added this sooner!

Hard to believe perhaps but I have implemented exactly the same solution as you have illustrated and this even resolves multiple envitonment variables e.g,

%computername%\%username%%random%

etc.

Just as a matter of interest: Why is line 2 in your solution necessary?

The left hand argument of 3 ensures that the command completes before APL regains control.

PostPosted: October 17th, 2011, 4:34 pm
by Tech Support
The delay may not be necessary. It's there just to avoid any timing issues that could arise due to a slow disk write and/or buffering.

PostPosted: October 17th, 2011, 5:28 pm
by brent hildebrand
%random% ?? that one was new to me.

Code: Select all
      GetEnv ¨ 'random' 'random' 'random' 'random' 'random' 'random'
 1650  1650  1653  1653  1653  1653


hmmm.


With 3 ⎕cmd, delay should not be needed.

PostPosted: October 18th, 2011, 1:11 am
by Ajay Askoolum
%RANDOM% yields a number between 1 and 32768. Could have been useful for numbering files sequentially but it is 'random' i.e. could repeat and yield a lower integer in a subsequent call.

To number files sequentially, you need to create your own variable.

3 []cmd 'set fileseq=1'

Then use the technique provided by Technical Support to retrieve its value, use it and then increment it as follows:

3 []cmd 'set fileseq=2'

The command line does not do arithmetic; so an absolute number needs to be assigned.

PS: In order to retrieve all the variables available, use

3 []cmd 'set >allvars.txt'