Resolving environment variables

General discussions on potential enhancements to the APL+Win system.

Resolving environment variables

Postby Ajay Askoolum » October 4th, 2011, 3:06 pm

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.
Ajay Askoolum
 
Posts: 636
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: Resolving environment variables

Postby Tech Support » October 4th, 2011, 5:18 pm

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.
Tech Support
 
Posts: 1133
Joined: February 10th, 2007, 7:33 am
Location: Rockville, MD

Re: Resolving environment variables

Postby Tech Support » October 4th, 2011, 5:21 pm

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.
Tech Support
 
Posts: 1133
Joined: February 10th, 2007, 7:33 am
Location: Rockville, MD

Postby Ajay Askoolum » October 5th, 2011, 12:31 am

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.
Ajay Askoolum
 
Posts: 636
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Postby Ajay Askoolum » October 16th, 2011, 3:22 pm

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.
Ajay Askoolum
 
Posts: 636
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Postby Ajay Askoolum » October 16th, 2011, 3:28 pm

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.
Ajay Askoolum
 
Posts: 636
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Postby Tech Support » October 17th, 2011, 9:48 am

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' â
Last edited by Tech Support on October 17th, 2011, 9:15 pm, edited 1 time in total.
Tech Support
 
Posts: 1133
Joined: February 10th, 2007, 7:33 am
Location: Rockville, MD

Postby Ajay Askoolum » October 17th, 2011, 4:25 pm

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.
Ajay Askoolum
 
Posts: 636
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Postby Tech Support » October 17th, 2011, 4:34 pm

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.
Tech Support
 
Posts: 1133
Joined: February 10th, 2007, 7:33 am
Location: Rockville, MD

Postby brent hildebrand » October 17th, 2011, 5:28 pm

%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.
brent hildebrand
 
Posts: 479
Joined: February 12th, 2007, 5:53 pm
Location: Loma Linda, CA

Postby Ajay Askoolum » October 18th, 2011, 1:11 am

%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'
Ajay Askoolum
 
Posts: 636
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom


Return to APL+Win Wish-List

Who is online

Users browsing this forum: No registered users and 1 guest

cron