Open tumagonx opened 5 years ago
I can confirm this: attempt to open a file with valid %env% vars syntax fails due to those vars' expansion.
Apparently the original intention of Notepad2 is to not rely on Windows shell expanding those vars. I guess we'll need to disable this by default and add a command-line flag like /expand
which will perform substitutions on the command-line arguments.
Added command line option /expandenv
(default value is 0).
Provide /expandenv=1
to enable legacy behavior.
It doesn't work for me.
However, the fix is incorrect anyway because it's made inside ExpandEnvironmentStringsEx which is used in many places, e.g. for locating INI file. Making /expandenv a global option affecting all these places is wrong - it should only affect paths read from the command line, not elsewhere.
The correct place for this correction would be around line 6330 but I don't see ExpandEnvironmentStringsEx (PathFixBackslashes call) there so it must be somewhere later in the initialization logic. Still, it should only be applied to command line pathnames.
However, the fix is incorrect anyway because it's made inside ExpandEnvironmentStringsEx which is used in many places, e.g. for locating INI file. Making /expandenv a global option affecting all these places is wrong - it should only affect paths read from the command line, not elsewhere.
Here are some points:
MRU_AddFile()
-method uses PathRelativeToApp
which heavily uses transform path logic. This affects File> Recent (History)
-feature (when RelativeFileMRU is set to 1) and caused preserving of incorrect path. This also breaks Recall Previous
feature. I assume there can be some other features which would be unusable without additional fixes.PathRelativeToApp
and ExpandEnvironmentStringsEx
which are called in multiple places. These changes were tested in different scenarios.Notepad2e.exe /f %APPDATA%
.
FindIniFile()
(utilizes ExpandEnvironmentStringsEx()
) is called once from WinMain.
Affected code depends on CheckIniFile()
-result which internally uses standard ExpandEnvironmentStrings
function to expand environmental variables when checking provided path. I've made different tests using /f switch to provide INI path and different /expandenv modes and found no difference: in all cases loading of INI file works correctly.It doesn't work for me.
Here are the test cases to check the fix:
C:\data%appdata%\1.txt
%
character and note result, e.g:
notepad2e.exe C:\data^%appdata^%\1.txt
1.txt
file into running instance of Notepad2e, note the result.1.txt
, note the result.Still, it should only be applied to command line pathnames.
Please confirm if you insist on the rollback.
Looks like indeed a quirk one, more complicated than I thought which make me wonder whats the original real world use-cases of that quirk?
Another weird behavior of notepad2 for a long time
Case : create the following file and path in explorer D:\data\%appdata%\foo\bar.txt try open bar.txt using notepad2 e.g. via imageexecution hack or direct drag and drop onto notepad2e.exe it return error unable to find "D:\data\C:\Users\root\Application Data\bar.txt"
notepad or wordpad or any "normal" programs don't do that. note: the usecase is by Thinapp/Thinstall which create such directory structure, but is still a valid case of how to open file properly.