Environment variables in dialogs.

[Balderstrom]

If going with the %"quote"% option, I don't see why you would want to reverse it. Consistency

Maybe my generalization is off, but, I doubt anyone would be naming any files after the handful of variables that exist as default ENV vars.
Almost everyone trying to use %somevar%\foo\bar in TC's Move/Rename/Command/Param/Command-Line(etc) fields are expecting variable expansion.

So if you make the rule consistent.
1) %String% is always expanded, if it exists as a variable.
2) %"String"% is literal, quotes break attempts to expand.
3) %% Sends 1 literal percent sign.
4) "%" Sends 1 literal percent sign.
Quotes are an illegal character for Files/Folders.

Thus you have this:
* Attempt expansion of any percent-enclosed strings that don't contain quotes.
* If variable doesn't exist, the percent-enclosed string is literal.

People are used to needing to quote paths/files that have spaces in them (in various places).
Except for #3 - The rules are consistent with command-line.
Explaining this in the help should be fairly straight forward:
If you wish to use percent-enclosed strings, enclose the string in quotes to prevent variable expansion.
Show %"TEMP"%, %"TMP"%, %TEMP% as examples.

If the %"quote"% option is a workable solution. Put it up for a vote on which people would prefer? Consistent with CMD Prompt or the inverse as MVV said?

Personally I believe with the quote options, #3 is not needed and is even possibly confusing. But it seemed like at least a few ppl thought it was a good solution.

[MVV]

So if you make the rule consistent.
1) %String% is always expanded, if it exists as a variable.
2) %"String"% is literal, quotes break attempts to expand.
3) %% Sends 1 literal percent sign.

Support. One generic function for expanding paths may do this.

But I think that %%-rule may be used as default because % sign isn't used frequently. Also it is easier to put %% than "%".
BTW, envvar name may contain spaces.

If the %"quote"% option is a workable solution. Put it up for a vote on which people would prefer? Consistent with CMD Prompt or the inverse as MVV said?

I suggested to invert just because it will be a new thing that may confuse some users. But if %"quote"% is a kind of standard, of course better solution is to support it as is.

[Balderstrom]

What I meant with not even needing the %% rule, is the places it was mentioned you were trying to send a literal %word% -- and %"word"% would send a literal...
As well things like %%S in the Param button field (not sure why you would want to), would be literal percent then expanded normal %S.

The only time you would see a double percent - where you don't actually mean double percent is if it was in front of a TC param or an ENV variable... and the second percent is for the TC param|ENV variable. Thus the rule for double percent isn't needed.

1) %String% is always expanded: if it exists as a variable AND creates a valid path.
2) %"String"% is literal, quotes break attempts to expand.

Note the added logic of: creates a valid path

Thus we have something like:
C:\MyFolder\%Temp% --> C:\MyFolder\%Temp%
Since after expanding %Temp% the path is no longer valid (it would be C:\MyFolder\C:\...), thus the user must mean literal %Temp%
As opposed to:
%Temp%\My Folder\ --> C:\Users\MyUser\Local Settings\Temp\My Folder\

[MVV]

I will remember the main topic of this topic.
This topic originally told that we could use %TEMP%\ to see folder contents in auto-complete/auto-append combo but we couldn't use such path as copy/move target - %TEMP% folder was created in current folder instead. So main idea was to add some way to use envvars in destination path field of copy/move dialogs.

Later, in TC 7.50a auto-complete/auto-append feature was disabled for paths like %temp%\123. But not for paths like %temp%\..\123.

But currently in TC 7.55pb2 when I type as copy target path like %bla-bla-bla%\..\, auto-complete combo shows wrong items - items may be from source or target folder or something else.

E.g.:

Code: Select all

I type: %bla-bla-bla%\..\
I see: files and folders from target folder (opened in another panel)

Code: Select all

I type: %bla-bla-bla%\bla-bla-bla..\
I see: files from current folder's upfolder

Regardless of defined envvar or not. This is valid for TC 7.50a and TC 7.55pb2. Both cases show wrong folder contents.

[ghisler(Author)]

If %bla-bla-bla% doesn't resolve to a path, then %bla-bla-bla%\..\ will be replaced by NOTHING. It then depends on what is the current directory in Windows where the names are taken from. I don't think that it's TC's job to handle such a strange situation.

[MVV]

But why auto-complete shows target panel's contents for such strange situation? If I copy files from left panel, I assume that current folder is left panel's folder.

Also, in my logic %bla-bla-bla%\..\ should be expanded to \..\ if variable is not defined, so it should be root folder, but not current's folder upfolder.

And, %bla-bla-bla%\bla-bla-bla..\ should be expanded to \bla-bla-bla..\ - to wrong path, so TC should not show auto-complete at all for such strange paths. I don't understand why TC shows such strange paths.

I checked, if I type something like "\blabla..\" (or just "blabla..\"), TC suggests items from current folder's upfolder! But path I entered doesn't exist at all!

I think TC should block displaying auto-complete if path doesn't exist, and relative paths should be taken relative to active panel's path.

[Balderstrom]

CMD.exe functions like this:
CD %foobar%

If the folder "%foobar%" exists, directory is changed to.
If the folder "%foobar%" doesn't exist, then error: The system cannot find the path specified.

If the variable is set to a valid (existing) path, i.e. "_", then the directory is changed to.

If the variable is set to an INvalid path, then error: The system cannot find the path specified.

The interesting part comes in, when either:

• The variable is unset, and the directory doesn't exist
• The variable IS set to an invalid path.
• The path exists
• or The variable is set to a valid path.

In all of these cases: CD %foobar%\.. , Will result in the directory not changing.


Though we'll need more info on the directory structure you have MVV, as in my case when I try an unset variable or %bla-bla-bla%\.. the copy/move dialog shows the current folder (source panel), like cmd.exe does above.

[ghisler(Author)]

Correct - TC cannot constantly change the current directory just to get the auto-complete files, that could affect other parts of the program. Therefore TC tries to parse the passed directory name and handle situations of relative paths correctly. Incorrect paths aren't currently handled, though.

[MVV]

Correct - TC cannot constantly change the current directory just to get the auto-complete files, that could affect other parts of the program. Therefore TC tries to parse the passed directory name and handle situations of relative paths correctly. Incorrect paths aren't currently handled, though.

Sorry but I don't understand why TC needs to change path, it should just call FindFirstFile/FindNextFile/FindClose to retrieve folder contents. If FindFirstFile returns error (this will have place for buggy paths like "\blabla.." in my examples), there is no auto-complete available. This way will work for any current path and for any path entered by user.

[ghisler(Author)]

It's because you entered a relative path: Either TC needs to call SetCurrentDirectory with the active panel path before calling FindFirstFile, or construct a full path somehow. I chose the second way, but that fails with invalid env var...

[MVV]

Well, I understand that it is not ideal way to call SetCurrentDirectory every time user changes panel. But it I have "C:\1" folder active in panel and type "\blabla..\", TC should construct path like "C:\1\blabla.." which is invalid anyway (and FindFirstFile will return 0 for such paths)! I don't understand why TC shows auto-complete for wrong user input - this is a bug that is easy-to-fix (in my mind).

[Hacker]

Christian,

I understand that it is not ideal way to call SetCurrentDirectory every time user changes panel

Actually, I disagree and strongly support setting the current directory whenever the active path in TC changes. I have missed this behavior several times already, when running external programs.

Roman

[Balderstrom]

Christian,

I understand that it is not ideal way to call SetCurrentDirectory every time user changes panel

Actually, I disagree and strongly support setting the current directory whenever the active path in TC changes. I have missed this behavior several times already, when running external programs.

@ Hacker, I agree with that much at least.
One of the reasons I stopped using NotePad2 was it's poor CurrentDirectory handling when opening New/Empty instances. If MetaPad had actual Unicode support I'd probably still be with that for my quickedit Notepad replacement: I never found any fault with that app.