Environment variables in dialogs.

[MVV]

We may change dir to %TEMP%, %$PERSONAL% or similar. When we type %TEMP%\ or %$PERSONAL%\ in command window or target path windows (in copy/move dialogs, command/param toolbar fields and so on), TC shows a hint with folder contents allowing to choose subfolder. But if we try to copy file/directory to %$PERSONAL%, we get another result...

Is it possible to expand environment variables for all cases?

Dear Ghisler, can you tell me, it is a bug or missing feature?

[ghisler(Author)]

Is it possible to expand environment variables for all cases?

Sorry, it's not possible because the % sign is a perfectly legal sign in a directory or file name. When changing dirs with Enter it's clear, the variables must not be resolved. But when such a dir like c:\%temp% is in the target panel and you press F5, it will be shown as target name, so TC must not replace the variable.

I will therefore remove the resolving of environment variables in auto-complete in functions like F5 (but keep them in the command line, current dir field etc).

[MVV]

Maybe you can do something to allow using of environment variables? I suggest to enclose %TEMP% or %$PERSONAL% in brackets if user wants to expand %TEMP% as a variable in all dialogs and so on (I think, this feature will be used mainly in button bar parameters).

So, TC will treat %TEMP%\1.txt as a file 1.txt in folder %TEMP% in current directory.
And TC will treat <%TEMP%>\1.txt as a file 1.txt in folder contained in TEMP environment variable.

I have another idea to make situation clear. If user wants to pass temp directory path as param or path (I mean button bar config), he should write %TEMP%. But if he wants to pass just string %TEMP%, he should write %%TEMP%%.

BTW, I don't know any people who names directories like %TEMP% or %$PERSONAL%.

[Boofo]

You can use %temp% as %%temp%% or %$PERSONAL% as %%$PERSONAL%% in the parameters and it works.

[MVV]

%%$PERSONAL%% don't work because $PERSONAL (like other $-vars: %$APPDATA%, %$DESKTOP%, %$PROGRAMS%, %$STARTMENU%, %$FONTS%, %$STARTUP%) is an internal TC variable - Windows doesn't know it, so can't expand.
BTW, %%TEMP%% also don't working. I try to use button with program 'explorer.exe' and this variable as path.

[Boofo]

I only use them with TC so they are working for me.

[karlchen]

Hello, Christian.

Up to the latest version, T.C. 7.50a (24-Sept-2009), exhibits an unexpected and pretty annoying behaviour if you use valid environment variables like %TEMP% or %$PERSONAL% inside e.g. the copy dialogue (F5)

• Left panel, drive D:, root folder, file D:\pass.rpt selected
• Right panel, drive C:, root folder
• <F5> pressed for copy
• Suggested target filename C:\pass.rpt. - So far, so good.
• Target filename modified to be %TEMP%\pass.rpt
  Expected: pass.rpt will be copied to the folder where %TEMP% points to.
  Unexpected result: Folder named %TEMP% created on D:\, file pass.rpt copied to folder D:\%TEMP%
• Target filename modified to be "%TEMP%\pass.rpt" - note the double quotes.
  Expected: pass.rpt will be copied to the folder where %TEMP% points to.
  Unexpected result: Error message telling me that the target path D:\"%TEMP% is invalid

This behaviour is really unexpected, annoying and illogical.

In case a valid enironment variable is used inside the target path, it should definitely be expanded and used.
In case something looking like an environment variable is used inside the target path, but there is no such environment variable, in this case take it as a normal string.
This is what e.g. cmd.exe will do as well.
In no case, enclosing the target name in double quotes should lead to incorrect error messages about incorrect pathnames although this is not true.

So I do support MVV's request.

Kind regards,
Karl

[ghisler(Author)]

What does your post have to do with this thread?

[Balderstrom]

Likely that ENVIRONMENT syntax/variables should be expanded whereever TC might encounter them

• CommandLine
• ButtonBar Command|Parameters
• Copy/Move dialog,
• Directory Menu
• MultiRename Tool even could support ENVironment variables in the "Rename Mask" field.

With the other thread's previous recommendation of anytime you want to use an actual "%" use 2: %%.

There might be a small issue with WEB named files, FOO%20BAR
But if there is no enclosing %, and/or if %SomeString% is not an Environment variable, then just pass it as is.

[karlchen]

Hello, Christian.

What does your post have to do with this thread?

Of course, I was sure I were giving an example illustrating what MVV told in his initial post.
Maybe I was wrong and misunderstood MVV's post completely.

As this thread has been moved to the " TC7.5 bugs which should be fixed now" section, I start wondering which entry inside the "history.txt" this thread corresponds to.

It can hardly be

17.09.09 Fixed: Auto-complete: Handle special case: %envvar%\..\

because this was reported in a different thread, wasn't it?

Kind regards,
Karl

[ghisler(Author)]

Maybe I misunderstood his post, but it was about incorrect handling of env vars in auto-complete/auto-append. This seems to work fine for me now. Can you give an example where auto-complete doesn't work correctly?

[Balderstrom]

But if we try to copy file/directory to %$PERSONAL%, we get another result...
Is it possible to expand environment variables for all cases?

I will therefore remove the resolving of environment variables in auto-complete in functions like F5 (but keep them in the command line, current dir field etc).

Then HolgerK notes environment variables are not expanded in Copy/Move dialog. Because you purposely broke it...

In Explorer:
Type in AddressBar: %Temp%
Type in Open/Save Dialog: %Temp%

Type in command prompt: CD %Temp%
Type in RUN Dialog: explorer %TEMP%

Open a command prompt, type: SET FOO=FOOBAR
type: notepad.exe
CTRL+S, type: %foo%
File saved... FOOBAR.txt

The only time Explorer/Windows will actually Let you use an Environment variable without expanding it, is during inline file renaming or folder creation. In the above example, I can't find any syntax that will allow notepad to save a file as %FOO%.txt - when the %FOO% ENV variable exists.

Here is another syntax that CMD prompt finds acceptable:
CD %FOO% --> CD FOOBAR
CD %"FOO% --> CD %FOO%
CD %"FOO"% --> CD %FOO%
Along with it's escape character ^, but that was disliked in another thread.

[karlchen]

Hello, Christian.

Maybe I misunderstood his post, but it was about incorrect handling of env vars in auto-complete/auto-append.

All right, I see. If this thread is about auto-complete/auto-append, then it is me who got the idea wrong.
In this case I can confirm that the issue affecting auto-complete/auto-append in combination with %ENVVAR% (environment variables) has been fixed - as I had confirmed in the beta forum before and also here.

Kind regards,
Karl

[ghisler(Author)]

It seems that two problems are somehow mixed up here - the expansion of environment variables in command/param toolbar fields, and the expansion of them in F5 copy. The first should be fixed now, the second one was removed because it's not clear whether the user wants to create a directory named %something%, or whether he wants to copy to an env. var. with this name. We still need to find a solution for the second problem.

[MVV]

BTW, I found a bug in TC.
I'd created a file named %PROCESSOR_IDENTIFIER%.rtf. Then, I paste its name into command line and press Enter. TC said that it couldn't find a file.

BTW2, Windows somehow determines when expand or not envvars. When I press Enter or use right click+open with, Wordpad i.e. opens my file. But when I use Save as and press OK, program saves file with another name...

BTW3, from CMD I may open my file via command %"PROCESSOR_IDENTIFIER"%.rtf and can't open it via command %PROCESSOR_IDENTIFIER%.rtf (Balderstrom wrote about it).

Maybe we should do something similar in TC but vice versa? I mean %TEMP% we should treat as %TEMP% and %"TEMP"% as environment variable?