Separate location for log files ? (and exclusions?)

[mdnava]

I just found out about this extension by mere chance.. I've been using KuShellExtension for a few years now, which has been very useful and works very well, but hasn't been updated in over 10 years. This extension looks like the perfect replacement, but it would take me while to convert from KuShellExt to ShellAnything (my KSE config file is about 900 lines).

I'd like to ask a couple questions if that's ok..

1. Is there a way to change the location for the logs folder, or the location for the config files without the logs?.. I ask this because I share the Windows context menus among several computers by putting the KuShellExt config file in a cloud folder. I could implement a junction with the ShellAnything config folder, but it contains log files with file locking that will interfere with proper cloud synchronization and will prompt sync errors.

2. Is there a way to add a context menu to all folders but exclude the Desktop?

[end2endzone]

Hi. Thank you for showing interest in ShellAnything.

1. This is a feature I never though about and it is not how I use the extension myself. I mostly copy & paste my configurations across all my computers "once" and don't change them much. When I do, I resynchronize them from a "master" computer (copy them from \\mastercomputer\c$\Users\%USERNAME%\ShellAnything to each local computers).
   1. Right now, there is no way to change the Configuration or Log directories. If you can find a good way to implement and document this, I would be willing to integrate it to the application. Maybe by adding an "override" in the registry would be a good start. I am open to suggestions. Unfortunately, the "plugin system" (issue 50) right now is using all my free time and I would not be able to implement this myself in a near future. If you want to submit a pull request, I will
   2. I have also never tested ShellAnything with network paths (paths that starts with \\computername\sharename). It might work or not. On a worst case, you might have to "map a network drive" but this is probably too much hassle for your simple use case. If mapping a network drive is not an option, you could also override the Configuration and Log directories to your DropBox-like local directory. This would be transparent for ShellAnything.
   3. Have you tried to use a Junction to "share" the same Configuration and Log directories ? It might work. You should not have conflicts about file names because the log files are prefixed with the File Explorer's process id. For example, shellext-d.dll.WARNING.20220417-170528.8616.log where 8616 is my process id. Running multiple ShellAnything instance that share the same log directory might work. However, the files would be identified as "in use" (log files are closed when the extension is unloaded or when all instances of File Explorer are closed). I assume that a cloud synchronization software should identify files that are "in use" (and maybe warn the user about it) but not fail the synchronization process. Downloading log files (when running the synchronization) from other sources should not conflict with existing files. Keep my updated if you try this.
2. Yes. I think you can validate your use case with something like this:
   <visibility class="directory" pattern="${env.USERPROFILE}\Desktop" inserve="pattern" />.
   I have not tested this myself but you get the idea. The attribute class="directory" forces the menu to be visible only when a directory is selected. You could also force how many directory can be selected with maxfiles="0" maxfolders="99999". The pattern attribute matches only your Desktop directory (it will make the menu visible only when your right click on your Desktop directory). However, ShellAnything supports the inverse attribute which inverses the logic of an attribute. Inversing your pattern will match all directories except when the selected path is exactly your Desktop directory. Basically, it converts the pattern to "everything but your Desktop directory". You can look at other attributes for validation in the User Manual.
3. On a side note, you are not the first one that contacts me about migrating from KuShellExtension. I would like to add a section in the User Manual for helping with the migration. Maybe something like "how to map feature X of KuShellExtension to ShellAnything" or provide a "generic" KuShellExtension xml file and its equivalent in ShellAnything format. If you are willing to provide feedback or instructions (preferably in markdown format), I would gladly add them to the User Manual.

Waiting for your feedback.

[end2endzone]

Also, if you like ShellAnything, please consider leaving a star to the project. I think this is the best way to increase the visibility of the project.

[mdnava]

@end2endzone Thank you for answering..

1. Right now, there is no way to change the Configuration or Log directories. If you can find a good way to implement and document this, I would be willing to integrate it to the application. Maybe by adding an "override" in the registry would be a good start. I am open to suggestions. Unfortunately, the "plugin system" (issue 50) right now is using all my free time and I would not be able to implement this myself in a near future. If you want to submit a pull request, I will

I think the easier way to go would be to move the "Logs/" directory to %LOCALAPPDATA%\ShellAnything\Logs and leave the config files on %USERPROFILE%\ShellAnything (or put them in the roaming directory: "%APPDATA%\ShellAnything").

3. Have you tried to use a Junction to "share" the same Configuration and Log directories ? It might work. You should not have conflicts about file names because the log files are prefixed with the File Explorer's process id. For example, shellext-d.dll.WARNING.20220417-170528.8616.log where 8616 is my process id. Running multiple ShellAnything instance that share the same log directory might work. However, the files would be identified as "in use" (log files are closed when the extension is unloaded or when all instances of File Explorer are closed). I assume that a cloud synchronization software should identify files that are "in use" (and maybe warn the user about it) but not fail the synchronization process. Downloading log files (when running the synchronization) from other sources should not conflict with existing files. Keep my updated if you try this.

Yes, I did try a junction from "%OneDrive%\CloudAppData\ShellAnything" and the Logs folder prompted sync errors in OneDrive. It happened exactly what you described: it identified files as "in use" and made some warnings. This is usually harmless, but I've had some experience with this. First, the warnings are there, always and forever. Then it could happen that, if there are enough sync issues in queue the sync process can actually fail altogether, it freezes completely. They pile up.

2. Yes. I think you can validate your use case with something like this:
   <visibility class="directory" pattern="${env.USERPROFILE}\Desktop" inserve="pattern" />.
   I have not tested this myself but you get the idea. The attribute class="directory" forces the menu to be visible only when a directory is selected. You could also force how many directory can be selected with maxfiles="0" maxfolders="99999". The pattern attribute matches only your Desktop directory (it will make the menu visible only when your right click on your Desktop directory). However, ShellAnything supports the inverse attribute which inverses the logic of an attribute. Inversing your pattern will match all directories except when the selected path is exactly your Desktop directory. Basically, it converts the pattern to "everything but your Desktop directory". You can look at other attributes for validation in the User Manual.

Thank you. I will try this and get back to you with a comment (next week possibly, sth personal just came up that I have to deal with). It will certainly be very useful. Is one thing I could not make work with KuShellExt. If there's an inverse or negated parameter I could not find it documented. Whatever I put in "folders" shows up also on the Desktop.

In this image you can see some options that I intend to use only on folders (like "IDE from here", "Shell from here", "Manage Folder", "Manage Images"), but not from the Desktop where they occupy screen real state and add up to the apparent limit for contextual objects. I can use these programs on any computer because they're all in a OneDrive folder, so I don't have to update every one of them, every time a new version comes up. It helps with consistency. Then the Start menu is left for programs that require installation like Office or Adobe Software.

3. On a side note, you are not the first one that contacts me about migrating from KuShellExtension. I would like to add a section in the User Manual for helping with the migration. Maybe something like "how to map feature X of KuShellExtension to ShellAnything" or provide a "generic" KuShellExtension xml file and its equivalent in ShellAnything format. If you are willing to provide feedback or instructions (preferably in markdown format), I would gladly add them to the User Manual.

I might be able to write up something once I'm more familiar with ShellAnything.
This is a shortened example for KuShellExt (config.xml):

<config version="1">
	<var name="archive">.001 .7z .ace .arj .bzip2 .cab .gz .gzip .lha .lzh .mzp .rar .rmskin .tar .wzp .xz .z .zip</var>
	<var name="audio">.aac .ac3 .aiff .ape .flac .m4a .m4b .m4r .mp+ .mp2 .mp3 .mpc .wma .ra .mka .ape .ogg .flac .tta .tak .wav .wv</var>
	<var name="code">.ahk .asm .asp .aspx .au3 .awk .bat .bsh .c .cjs .cmd .cpp .cs .csh .dart .erl .ex .exs .fish .go .groovy .gvy .gy .java .jl .js .jsx .ksh .kts .lua .mjs .p6 .p .pas .php .phtml .pl6 .pl .pp .ps1 .psd1 .psm1 .py .pyw .rb .rbw .rs .scala .sh .tcl .vb .vbs .wlua .wsf .xaml .yaml .yml .zsh</var>
	<var name="docs">.chm .doc .docm .docx .dot .dotm .dotx .epub .gnm .gnumeric .mobi .odt .pdf .potx .potm .ppam .ppsm .ppsx .pps .ppt .pptm .pptx .rtf .sldm .sldx .thmx .vsd .wpd .wps .wri .xlam .xls .xlsb .xlsm .xlsx .xltm .xltx</var>
	<var name="image">.avif .bmp .heic .heif .jpg .jpe .jpeg .jfif .jif .png .tga .tif .tiff .webp</var>
	<var name="imageapng">.png .apng</var>
	<var name="imageraw">.arw .dng .cr2 crw .nef .nrw .raw .sr2 .srf</var>
	<var name="text">.cfg .conf .csv .inf .ini .json .log .lrc .mn .mnx .txt .text .xml</var>
	<var name="video">.avi .divx .f4v .flv .m2t .m2ts .m4v .mkv .mov .mp4 .mp4v .mpg .mpeg .mts .wmv .rm .rmvb .vob .webm .wmp .wmv</var>

	<!-- Folder Context (will appear also on the Desktop) -->
	<!-- The use for workdir="." sets the working directory to the program location, 
	otherwise it'll be where the context menu is called -->
	<menu name="Manage folder" class="folder" icon="D:\USER\OneDrive\Depot\Icons\{Context}\folder_managemore.ico">
		<menuitem name="XYplorer [LR]" workdir="." icon="D:\USER\OneDrive\Programs\XYplorer\XYplorer\XYplorer.exe,0">D:\USER\OneDrive\Programs\XYplorer\XYplorerRun.vbs %*</menuitem>
		<menuitem name="----" />
		<menuitem name="grepWin" workdir="." icon="D:\USER\OneDrive\Programs\_Utilities\Stefans-grepWin\grepWin.exe,0">wscript.exe D:\USER\OneDrive\Programs\_Utilities\Stefans-grepWin\grepWinRun.vbs %*</menuitem>
		<menuitem name="TextCrawler" workdir="." icon="D:\USER\OneDrive\Programs\_Utilities\TextCrawler\TextCrawler.exe,0">wscript.exe D:\USER\OneDrive\Programs\_Utilities\TextCrawler\MN_Run.vbs %*</menuitem>
		<menuitem name="Search on the Web" icon="D:\USER\OneDrive\Command\EnvScripts\Bin\WebSearch.exe,0">D:\USER\OneDrive\Command\EnvScripts\Bin\WebSearch.exe %*</menuitem>
		<menuitem name="WinMerge Compare" workdir="." icon="D:\USER\OneDrive\Programs\WinMerge-Compare\WinMergeU.exe,0">D:\USER\OneDrive\Programs\WinMerge-Compare\WinMergeU.exe %*</menuitem>
		</menu>
	</menu>

	<!-- Images Context -->
	<!-- The use for console="false" allows to execute a console program but hide the console -->
	<menu name="Convert for the Web" class="${var:image}" icon="D:\USER\OneDrive\Depot\Icons\{Folder}\images.ico">
		<menuitem name="Cover 1:1" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\generic.ico">D:\USER\OneDrive\Command\EnvScripts\image-magick.cmd -aspectratio 1:1 -center %@</menuitem>
		<menuitem name="Photo 3:2" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\generic.ico">D:\USER\OneDrive\Command\EnvScripts\image-magick.cmd -aspectratio 3:2 -center %@</menuitem>
		<menuitem name="----" />
		<menuitem name="Wide 16:9 (top)" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\generic.ico">D:\USER\OneDrive\Command\EnvScripts\image-magick.cmd -aspectratio 16:9 -top %@</menuitem>
		<menuitem name="Wide 16:9 (middle)" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\generic.ico">D:\USER\OneDrive\Command\EnvScripts\image-magick.cmd -aspectratio 16:9 -center %@</menuitem>
		<menuitem name="Wide 16:9 (bottom)" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\generic.ico">D:\USER\OneDrive\Command\EnvScripts\image-magick.cmd -aspectratio 16:9 -bottom %@</menuitem>
		<menuitem name="----" />
		<menuitem name="JPEG 3000L" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\jpg.ico">D:\USER\OneDrive\Command\EnvScripts\image-transform.cmd %@ jpeg 85 3000 defa defa nometa</menuitem>
		<menuitem name="JPEG 2000L" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\jpg.ico">D:\USER\OneDrive\Command\EnvScripts\image-transform.cmd %@ jpeg 85 2000 defa defa nometa</menuitem>
		<menuitem name="JPEG 1200L" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\jpg.ico">D:\USER\OneDrive\Command\EnvScripts\image-transform.cmd %@ jpeg 85 1200 defa defa nometa</menuitem>
		<menuitem name="JPEG 1000L" console="false" icon="D:\USER\OneDrive\Depot\Icons\{Filetype}\jpg.ico">D:\USER\OneDrive\Command\EnvScripts\image-transform.cmd %@ jpeg 85 1000 defa defa nometa</menuitem>
	</menu>

	<!-- Desktop Context -->
	<!-- The var ${Desktop} is preset in KuShellExt and the use for "at:" sets the location where the menu should appear -->
	<menu name="Applications" class="at:${Desktop}" icon="C:\Windows\System32\dsuiext.dll,9">
		<menuitem name="CherryTree" icon="D:\USER\OneDrive\Programs\CherryTree\cherrytree.ico">D:\USER\OneDrive\Programs\CherryTree\mingw64\bin\cherrytree.exe</menuitem>		
		<menuitem name="Typora" icon="D:\USER\OneDrive\Programs\Typora-MD\Typora\Typora.exe,0">D:\USER\OneDrive\Programs\Typora-MD\Typora\Typora.exe</menuitem>
		<menuitem name="----" />
		<menuitem name="Draw.io" icon="D:\USER\OneDrive\Programs\_Diagram\Draw.io\draw.io.exe,0">D:\USER\OneDrive\Programs\_Diagram\Draw.io\draw.io.exe</menuitem>
		<menu name="LibreOffice //" class="at:${Desktop}" icon="D:\USER\OneDrive\Programs\LibreOffice\program\soffice.exe,0">
			<menuitem name="LibreOffice Base" icon="D:\USER\OneDrive\Programs\LibreOffice\program\sbase.exe,0">D:\USER\OneDrive\Programs\LibreOffice\program\sbase.exe</menuitem>
			<menuitem name="LibreOffice Calc" icon="D:\USER\OneDrive\Programs\LibreOffice\program\scalc.exe,0">D:\USER\OneDrive\Programs\LibreOffice\program\scalc.exe</menuitem>
			<menuitem name="LibreOffice Draw" icon="D:\USER\OneDrive\Programs\LibreOffice\program\sdraw.exe,0">D:\USER\OneDrive\Programs\LibreOffice\program\sdraw.exe</menuitem>
			<menuitem name="LibreOffice Impress" icon="D:\USER\OneDrive\Programs\LibreOffice\program\simpress.exe,0">D:\USER\OneDrive\Programs\LibreOffice\program\simpress.exe</menuitem>
			<menuitem name="LibreOffice Web" icon="D:\USER\OneDrive\Programs\LibreOffice\program\swriter.exe,0">D:\USER\OneDrive\Programs\LibreOffice\program\sweb.exe</menuitem>
			<menuitem name="LibreOffice Writer" icon="D:\USER\OneDrive\Programs\LibreOffice\program\swriter.exe,0">D:\USER\OneDrive\Programs\LibreOffice\program\swriter.exe</menuitem>
		</menu>
	</menu>
</config>

As for how KuShellExt handles parameters: with %* all parameters are sent at once to the program, when filenames contain spaces double quotes are added; and with %@ the program is executed once for each parameter. There are also other options like: %1 %2 %3 ... %9; built-in variables like: ${env:Desktop} ${env:ProgramFiles} ${env:Downloads}; and environment vars can be used like; ${env:JAVA_HOME} ... Classes are somewhat similar to what I read with ShellAnything: ".ext" ".*" ".folder" "drive" "drive:removable" "drive:fixed" "drive:network" "drive:optical" "drive:ramdisk" "at:PATH" "in:DIR"

I hope this helps..

[mdnava]

Hello again..

After some trial and error I made it work so the menu opens in all folders, excluding the Desktop:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <shell>
    <menu name="ShellAny Test">
      <icon path="C:\Windows\System32\dsuiext.dll" index="0" />
      <visibility class="directory" pattern="${env.Desktop}" inverse="pattern" />
      <menu name="Code">
        <icon path="D:\USER\OneDrive\Programs\VSCode\Code.exe" index="0" />
        <actions>
          <!-- <property name="selection.multi.separator" value="&quot; &quot;" /> -->
          <exec path="D:\USER\OneDrive\Programs\VSCode\Code.exe" arguments="&quot;${selection.path}&quot;" />
          <!-- <property name="selection.multi.separator" value="${line.separator}" /> -->
        </actions>
      </menu>
      <menu name="Sublime">
        <icon path="D:\USER\OneDrive\Programs\SublimeText\sublime_text.exe" index="0" />
        <actions>
          <!-- <property name="selection.multi.separator" value="&quot; &quot;" /> -->
          <exec path="D:\USER\OneDrive\Programs\SublimeText\sublime_text.exe" arguments="&quot;${selection.path}&quot;" />
          <!-- <property name="selection.multi.separator" value="${line.separator}" /> -->
        </actions>
      </menu>
    </menu>
  </shell>
</root>

Which is awesome :) .. But some questions arise..

[== 1 ==]
Is there a way to change the position of the context menus?..
I tried this.. I renamed:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shellex\ContextMenuHandlers\ShellExtension.ShellAnything

To:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shellex\ContextMenuHandlers\aShellExtension.ShellAnything

And it worked, the context menu in folders shows up above the AntiVirus scan, which is what I want.. but will this keep working? would the extension restore or create the original registry entry at some point?.. If so, can the change be made permanent?

[== 2 ==]
How can I execute a console program but hide the console?..
Could not find it in the manual, and is very important.

[== 3 ==]
According to the manual, to handle multiple arguments, I should use this:

<actions>
<property name="selection.multi.separator" value="&quot; &quot;" />
<exec path="D:\USER\OneDrive\Programs\VSCode\Code.exe" arguments="&quot;${selection.path}&quot;" />
<property name="selection.multi.separator" value="${line.separator}" />
</actions>

I tried it but it didn't work, I got this in the log:

E0421 23:29:43.632731 14660 shellext.cpp:708] CContextMenu::InvokeCommand(), action #2 has failed: El nombre de archivo, el nombre de directorio o la sintaxis de la etiqueta del volumen no son correctos.

But it works with a single selection (any of the same folders I tried with the multiple selection)..

[== 4 ==]
Also, If I may comment about this last issue.. this is very verbose. I think config files are gonna be triple the size they should be, which makes them harder to maintain. In my particular case almost every command I use handles multiple arguments, being files and/or folders and/or options. I believe ${selection.path} should handle the use of quotes when there are any spaces in arguments, or at the very least a new var (like ${selection.paths}) should. Just a thought.

For what I've been able to see, ShellAnything has an edge in memory usage in comparison with KuShellExtension (which works great when the config file is left alone, but seems to have some sort of incremental memory leakage after each configuration update – a restart of explorer.exe or the OS is often required after about 20 or so updates). However, I think the verbosity of ShellAnything makes it difficult to implement. A 900 line config file could easily become 10.000 lines or more.

BTW!.. log files.. VERY useful..

Hoping to read your feedback..

Have a nice weekend !!

[end2endzone]

Thank you for the feedback. Much appreciated.

[== 1 ==]
I didn't know you could do this. Does this means Windows shows extensions according to the alphabetical order of their entries in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shellex\ContextMenuHandlers? To answer your question, no, ShellAnything does not read or write to this location in the registry unless you register or unregister the shell extension with unregister.bat, or register.bat.

However, if you try to unregister, the shell extension will expect the registry key to be named ShellExtension.ShellAnything and will probably fail to delete the key ShellExtension.ShellAnything and also fail to unregister itself from the system. This will be a problem if you want to upgrade to a newer version of the extension.

If so, can the change be made permanent?

Just to be clear, are you asking to rename the extension to aShellExtension.ShellAnything within the source code ? That is a possibility. However, it is only temporary. It will "work" until you register a shell extension named 1foobar which will create menu entries before ShellAnything. I would like to keep this issue specific to "moving the location of Configuration and Logs directories". Other considerations should be tracked in a different issue. No offence but its a lot easier for me to plan changes in the software.

[== 2 ==]
Unfortunately, that is a feature that is not supported by ShellAnything at the moment. I do not see any problem implementing such a feature. For example, the <exec> action could have a new attribute called console that accept values such as true or false. It would be very similar to the KuShellExt example above. I suggest that you open a new issue for tracking this feature. I would also appreciate a little help with this and would gladly accept a pull request that implements such a feature.

Until then, you could implement our own executable that spawn your final process and hide the console.

[== 3 ==]
I don't understand your issue. It should work as expected. For example, to see how the whole thing gets expanded, you can display the list of arguments with "${selection.path}" with the following:

<message title="&quot;${selection.path}&quot;" />

I also created the following Configuration example which is using Visual Studio Codium instead of Visual Studio Code (both software have the same code base) :

<?xml version="1.0" encoding="utf-8"?>
<root>
  <shell>
  <menu name="Open with VSCodium">
    <icon path="C:\Program Files\VSCodium\VSCodium.exe" index="0" />
    <visibility exists="C:\Program Files\VSCodium\VSCodium.exe" />
    <actions>
      <property name="selection.multi.separator" value="&quot; &quot;" />
      <message title="&quot;${selection.path}&quot;" />
      <exec path="C:\Program Files\VSCodium\VSCodium.exe" arguments="&quot;${selection.path}&quot;" />
      <property name="selection.multi.separator" value="${line.separator}" />
    </actions>
  </menu>    
  </shell>
</root>

And clicking on 4 files actually show the expected message:

note the " character before and after each files. A space is inserted between files but Windows automatically show the full string as if there were ${line.separator} between each files. That is not the case.
After pressing OK, all the files are opened in Visual Studio Codium:

Maybe you are having an issue since your Windows copy is Spanish. Or because the path to "D:\USER\OneDrive\Programs\VSCode\Code.exe" is incorrect. Its hard to say from my point of view. The message you see in the logs is one reported by your Operating System, not from ShellAnything. I suggest you try again. Also debugging visually with the <message> action could also help. You can press CTRL+C on the popup displayed by a MessageBox (<message>) which will copy the content of the MessageBox as text. This is usefull to validate if the paths displayed in the message are correct. You can also try to "paste" the result (including the double quotes) in a command prompt and see if VSCode is launched and actually opens all the files in the arguments.

[== 4 ==]

If I may comment about this last issue.. this is very verbose. I think config files are gonna be triple the size they should be, which makes them harder to maintain.

Looking at how many menus you have in your screenshot above, I have no doubt about this! I have created #109 as a suggestion to reduce the amount of logging. I suggest you add a comment for feedback or another idea to solve the problem in order to keep track of the progress about this problem and receive a notification when it will be resolved.

I believe ${selection.path} should handle the use of quotes when there are any spaces in arguments, or at the very least a new var (like ${selection.paths}) should. Just a thought.

Respectfully, I disagree since I do not think this is necessary. Like I said in 3, please try again. Other users has confirmed this issue working on their side. See #87 and #52 for details. If the issue persist, create another issue and I will request help from other users that have a non-English Windows. I have also created #110 which once available, could help other in the same situation. Again, I suggest you add a "dummy comment" just to get a notification when it will be resolved.

Thank you again for all your help and suggestion. It is much appreciated. I did not know about KuShellExt before I started this project. I am glad to see that most features can be mapped to ShellAnything because people seems to be migrating from KuShellExtension to ShellAnything. This means the application is "mature" (kind of) and can be used by a lot a people - from multiple locations - speaking different languages.

[mdnava]

[== 1 ==] I didn't know you could do this. Does this means Windows shows extensions according to the alphabetical order of their entries in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shellex\ContextMenuHandlers? To answer your question, no, ShellAnything does not read or write to this location in the registry unless you register or unregister the shell extension with unregister.bat, or register.bat.

Yes.. First "shell" entries and then "shellex\ContextMenuHandlers".. And also counts where in the registry they're loaded from. If I'm not mistaken "Classes\Directory" goes before "Classes\Folder". However, there's also the possibility that this order can be overridden in shell extensions, but I'm not sure at this time.

However, if you try to unregister, the shell extension will expect the registry key to be named ShellExtension.ShellAnything and will probably fail to delete the key ShellExtension.ShellAnything and also fail to unregister itself from the system. This will be a problem if you want to upgrade to a newer version of the extension.

Ok. I tested this. I unregistered the ShellAnything extension (having the renamed registry key) and it was done correctly. As you mentioned the "aShellExtension.ShellAnything" key was NOT REMOVED, but the extension was SUCCESSFULLY UNREGISTERED and context menus DISAPPEARED. Then I registered again ShellAnything and the "ShellExtension.ShellAnything" registry key was created again, so now there were two registry keys for ShellAnything but only one context menu, and is loaded in the position of the first appearance in the registry (the one I renamed). I checked loaded shell extensions in the system and "ShellAnything Class" is loaded only once. So it's posible it would be harmless to have both registry keys, but I could just update the register script to remove duplicated entries for ShellAnything.

Just to be clear, are you asking to rename the extension to aShellExtension.ShellAnything within the source code ? That is a possibility.

No. I don't think it would be a good idea to rename the application registry key to satisfy one user's request. Some users might want it on top, others right where it is. I do think other users might find this information relevant (that it is indeed possible to change the menu position but not supported). I was asking in case there was such an option to rename the key or change the context menu location. But I got the answer, and a workable solution.

However, it is only temporary. It will "work" until you register a shell extension named 1foobar which will create menu entries before ShellAnything.

I try to keep my context menus as clean as possible. I have a script that keeps disabled a bunch of shell extensions in the registry. Anyways, in this case I just want ShellAnything menus to appear above the antivirus and a separator.

I would like to keep this issue specific to "moving the location of Configuration and Logs directories". Other considerations should be tracked in a different issue. No offence but its a lot easier for me to plan changes in the software.

Understood!.

Regarding the "Logs" directory, I still think it would best if it was located within LOCALAPPDATA. If I'm not mistaken I think it could be implemented with one (or a few) lines of code.

[== 2 ==] Unfortunately, that is a feature that is not supported by ShellAnything at the moment. I do not see any problem implementing such a feature. For example, the <exec> action could have a new attribute called console that accept values such as true or false. It would be very similar to the KuShellExt example above. I suggest that you open a new issue for tracking this feature. I would also appreciate a little help with this and would gladly accept a pull request that implements such a feature.

Ok. I will definitely create the new issue.
This is a very important feature, not just for me.

[== 3 ==] I don't understand your issue. It should work as expected. For example, to see how the whole thing gets expanded, you can display the list of arguments with "${selection.path}" with the following: [...]
I also created the following Configuration example which is using Visual Studio Codium instead of Visual Studio Code (both software have the same code base) . [...]

And clicking on 4 files actually show the expected message: [...] note the " character before and after each files. A space is inserted between files but Windows automatically show the full string as if there were ${line.separator} between each files. That is not the case. After pressing OK, all the files are opened in Visual Studio Codium: [...]

Maybe you are having an issue since your Windows copy is Spanish. Or because the path to "D:\USER\OneDrive\Programs\VSCode\Code.exe" is incorrect. Its hard to say from my point of view. The message you see in the logs is one reported by your Operating System, not from ShellAnything. I suggest you try again. Also debugging visually with the <message> action could also help. You can press CTRL+C on the popup displayed by a MessageBox (<message>) which will copy the content of the MessageBox as text. This is usefull to validate if the paths displayed in the message are correct. You can also try to "paste" the result (including the double quotes) in a command prompt and see if VSCode is launched and actually opens all the files in the arguments.

A Halloween Mystery. Every path I try work when there's only one argument sent, but fails when there's more than one.
Perhaps I'm making a dumb mistake somewhere. I'll try again next week. I did a list of things to try with the extension.
However, it does highlight (perhaps) it would be a good idea to simplify the handling of multiple arguments.

Looking at how many menus you have in your screenshot above, I have no doubt about this! I have created #109 as a suggestion to reduce the amount of logging. I suggest you add a comment for feedback or another idea to solve the problem in order to keep track of the progress about this problem and receive a notification when it will be resolved.

To be clear. When I said "verbose" I meant for the config file, specifically for the use of three lines in the XML file in order to be able to handle multiple arguments, each time.

I believe ${selection.path} should handle the use of quotes when there are any spaces in arguments, or at the very least a new var (like ${selection.paths}) should. Just a thought.

Respectfully, I disagree since I do not think this is necessary. Like I said in 3, please try again. Other users has confirmed this issue working on their side. See #87 and #52 for details. If the issue persist, create another issue and I will request help from other users that have a non-English Windows. I have also created #110 which once available, could help other in the same situation. Again, I suggest you add a "dummy comment" just to get a notification when it will be resolved.

Ok. I understand.
However, even if I make it work, I do believe the handling of arguments should be simpler.

Thank you again for all your help and suggestion. It is much appreciated. I did not know about KuShellExt before I started this project. I am glad to see that most features can be mapped to ShellAnything because people seems to be migrating from KuShellExtension to ShellAnything. This means the application is "mature" (kind of) and can be used by a lot a people - from multiple locations - speaking different languages.

Thank you, for your work.

[end2endzone]

Hi @mdnava
I am revisiting this issue and I would like to know if you are still available for feedback. I will try to solve your issue as best as possible.

I think your fundamental issue is that logs are stored under main ShellAnything directory and this directory also contains configurations files. I recently started to find this structure hard to work with. This is indeed annoying and I've been thinking of changing the directory structure to separate things a little better.

I think the easier way to go would be to move the "Logs/" directory to %LOCALAPPDATA%\ShellAnything\Logs and leave the config files on %USERPROFILE%\ShellAnything (or put them in the roaming directory: "%APPDATA%\ShellAnything").

I am not keen on the idea of having the logs and config files at different locations. Even though I am using Windows for 30+ years, I am still trying to figure out the differences (and potential use cases) for Local, LocalLow and Roamnig directories. TLDR; When everything is at the same place, you stop searching. My point is : it is more convenient to have all the data of an application located at the same place.

But I've been thinking that I could migrate to the following directory structure (or something like this) :

──%USERPROFILE%\ShellAnything
  ├───config
  │       default.xml
  │       shellanything.xml
  │
  ├───logs
  │       sa.shellextension.dll.ERROR.20240915-100937.9528.log
  │       sa.shellextension.dll.INFO.20240915-100918.9528.log
  │       sa.shellextension.dll.WARNING.20240915-100918.9528.log
  │
  └───plugins
      └───sa_plugin_demo
          ├───bin
          │       sa_plugin_demo.dll
          │
          └───lib
                  sa_plugin_demo.lib

Like I said, I really like the idea of having all data of a single software located at one place.

To solve your original issue, you would still have to create a junction from %USERPROFILE%\ShellAnything\config to %OneDrive%\CloudAppData\ShellAnything\config. A second junction could be required if you desire to also share plugins through OneDrive/Dropbox/etc. This would allow you to share your configurations across multiple computers.
Such a configuration will preserve logs in their original location and help debugging an issue about a specific computer.

But a junction may not be required!
There is also a second way to resolved the issue. Since the implementation of #109, there are "options" that can be set through environment variable. These options can change the default behavior of ShellAnything.
I am thinking of implementation options such as SA_OPTION_CONFIG_DIR and SA_OPTION_LOG_DIR to allow overriding default directory locations.
For example, in your setup, you could define an environment variable such as SA_OPTION_CONFIG_DIR=%OneDrive%\CloudAppData\ShellAnything (notice the config folder is missing in OneDrive) and only share configuration files through OneDrive/Dropbox.

I would gladly appreciate your feedback regarding this new feature.

[== 1 ==]

Is there a way to change the position of the context menus?

I tried this on my Windows 10 system. I can confirm this is working.
I renamed the original HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shellex\ContextMenuHandlers\ShellAnything to change its order in the list. You can rename to !ShellAnything in order to be moved to the top of the list or you can also rename to ΩShellAnything to move ShellAnything as the last element of the list.

I do not really plan to support this "officially" through ShellAnything. However, I could document this behavior as a way to "reorder" shell extensions for a user.

However, you need to do this for every locations where ShellAnything is registered as a shell extension:

• * (star character)
• Directory
• Directory\Background
• Folder
• Drive

There is also shell extensions registered under AllFilesystemObjects. ShellAnything do not register this element. This could create confusion since the I do not know if Directory has priority over AllFilesystemObjects.

[== 2 ==]

How can I execute a console program but hide the console?

You have not open a new issue for tracking this feature. Do you still requires this feature?

[== 3 ==]
About selecting multiple files and properly sending the list to a single application...
There is a new tool bundled with ShellAnything called arguments.debugger.console.exe and arguments.debugger.window.exe. These were introduced in version 0.10.0 (PR #176 issue #174).
They can be used to diagnose the actual command send to an executable and how command line arguments are actually received.
See the documentation in the UserManual.md#argumentsdebugger for more details.
Also, these are not officially released yet. You may want to get a nightly build of ShellAnything from https://ci.appveyor.com/project/end2endzone/shellanything

To be clear. When I said "verbose" I meant for the config file, specifically for the use of three lines in the XML file in order to be able to handle multiple arguments, each time.

In the examples, I do indeed change selection.multi.separator before and after the <exec> element :

<actions>
<property name="selection.multi.separator" value="&quot; &quot;" />
<exec path="D:\USER\OneDrive\Programs\VSCode\Code.exe" arguments="&quot;${selection.path}&quot;" />
<property name="selection.multi.separator" value="${line.separator}" />
</actions>

The double <property> change is required because you are changing the "default" value which might be required in another <exec> action of another configuration file. So the second <property> is there to revert this change.
However, if you want to always use double quotes characters as the separators, you could set it once as a global property:

<default>
  <property name="selection.multi.separator" value="&quot; &quot;" />
</default>

This should considerably reduce the size of a configuration file.
Make sure to add it to every configuration that requires double quoting multiple selected elements because ShellAnything does not define in which order configuration files are processed.

See UserManual.md#default-properties for details about Default configuration properties.

I will update the documentation to be more precise. If your use case is "always use double quotes and sometimes use CRLF", then you might set a new default value for selection.multi.separator and change it to ${newline} before and after exec only when you need to use CRLF.

I realize its been a long time.
Hoping to hear from you again.

---

TODO:

• Update directory structure as per example above:
  • Configurations under directory %USERPROFILE%\ShellAnything\configurations.
  • Plugins under directory %USERPROFILE%\ShellAnything\configurations.
  • Logs under directory %LOCALAPPDATA%\ShellAnything\logs.
• Implement options SA_OPTION_CONFIG_DIR and SA_OPTION_LOG_DIR.
  • Update documentation about the new options.
• Update documentation about reordering registry key such as HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shellex\ContextMenuHandlers\ShellAnything to reorder elements of ShellAnything.
• Update documentation about property selection.multi.separator. If you mostly need the opposite (double-quotes instead of CRLF) then you should override <property name="selection.multi.separator" value="&quot; &quot;" /> in a <default> element.

[mdnava]

Hi @mdnava I am revisiting this issue and I would like to know if you are still available for feedback. I will try to solve your issue as best as possible.

@end2endzone hi, thank you for writing.. sure! I'm still pretty much interested in ShellAnything.

I must mention first, that at this point I'm still using KuShellExt and not ShellAnything, mainly because of no option to run console programs without a popup window, and to a lesser extent because of the logging issue. But KuShellExt is abandonware since around 2012 (I think) so it's getting obsolete and seems to cause memory leaks in Windows Explorer.. So I'd be eager to move on. That's why I found ShellAnything in the first place.

I'll go in order of things:

[== 0 ==]

I really like the idea of having all data of a single software located at one place

I do too.. It simplifies things when you have to handle multiple programs and utilities. However, there are some important considerations to this. First, any file that requires locking (such as log files) will cause syncing problems if its location is set on any Cloud service such as OneDrive or Google Drive. Synchronization will just stop and access errors are thrown. Second, temporary files and/or folders should be kept out of the program or the config folder, or they could become polluted.

Regarding the mentioned Windows folders:

1. ROAMING: This is where software keeps configuration files, non volatile information and important data to the application. Think of a Browser's configuration files, search engines, extensions, context menus. This is where Adobe keeps camera and lens profiles. For Windows it has also more technical meaning for the logon process. These are folders required for roaming the user into another system within a networked environment. These folders are theoretically expected to be lighter in size.
2. LOCAL: This is where software keeps caching. logging, and specific temporary files. Think of a Browser cache, history, extensions cache, cookies?. Files that require locking should be put here. This is also where Adobe saves cache for its products when is not directly used by actual image editing (which has its own big cache file). Whatever you put on the "Local" folder is not expected to be synchronized in a networked environment, but only used by the software in the current computer. These folders can become big in size.
3. LOCALLOW: This is the same as "Local", but with lesser access level. Think of a Browser incognito cache folder, that gets deleted after each use (it's how is suppose to work).
4. TEMP: This is a drop in folder for temporary files. Files that require locking can also be put here. No program should expect to have any data written to this folder available after a reboot, a log off, or even after a while in the same session.

Following these rules in the context of ShellAnything, it would make sense to have config files on %APPDATA%\ShellAnything (config files that can be synced among different computers), while log files or other temps to be kept on %LOCALAPPDATA%\ShellAnything (which are related only to the currently running computer). Config files could also be kept on the same program folder, as in portable mode.

That being said..
The proposed solution with environment vars SA_OPTION_CONFIG_DIR and SA_OPTION_LOG_DIR is perfect in my opinion.

[== 1 ==]

Is there a way to change the position of the context menus?

I tried this on my Windows 10 system. I can confirm this is working.
I do not really plan to support this "officially" through ShellAnything. However, I could document this behavior as a way to "reorder" shell extensions for a user.

Understood. I was just asking, I don't think is actually an issue.
However, keep it in mind just in case ShellAnything re-writes to the Registry, and removes user customizations.

And also, it would be a good idea to test how some context menu positions will work out-of-the-box. For example, we wouldn't want a context menu for a file editor to appear below Windows Defender.

[== 2 ==]

How can I execute a console program but hide the console?

You have not open a new issue for tracking this feature. Do you still requires this feature?

Yes!.. This is actually the main reason why I'm not currently using ShellAnything. I do think running console programs without a window should be a "must" feature in ShellAnything. But if this feature is implemented I will most likely start to migrate out of KuShellExt. It could take me a while though. I use KuShell extensively and config files are very different.

For example, these context menus use ImageMagick commands to transform images, without showing a console:

I will open the issue.

[== 3 ==]

About selecting multiple files and properly sending the list to a single application...

I don't remember exactly of what I experienced in this regard with ShellAnything. I would have to try it again.
I'd be open to review again this in the future.

But in case is relevant, if I select three files and I then select a program from a ShellAnything context menu, that program should receive the three selected file paths between double quotes (if any of the paths has spaces). The program should also receive any other parameter that's given.

To put an example in KuShellExt, in this line using %*:

<menuitem name="Code" icon="Code.exe,0">Code.exe %*</menuitem>

In this case I can select six (6) text files and code.exe will receive all of them in the same command, something like:

code.exe "file1.txt" "file2.txt" "file3.txt" "file4.txt" "file5.txt" "file6.txt"

However, with this line using @*:

<menuitem name="Code" icon="Code.exe,0">Code.exe @*</menuitem>

In this case the program will be executed for every parameter, resulting in something like:

code.exe "file1.txt" 
code.exe "file2.txt" 
code.exe "file3.txt" 
code.exe "file4.txt" 
code.exe "file5.txt" 
code.exe "file6.txt"

Again, I'd have to check again how ShellAnything handles this.

Thank you for writing.. best regards!

[end2endzone]

@mdnava

It could take me a while though. I use KuShell extensively and config files are very different.

Have you ever considered writing a migration tool ? Since you are familiar with both methods and have many configuration files, this would be a good opportunity to document in code your experience and methods of migrating from KuShellExt to ShellAnything. Such a tool could be written in any language. I could then link to this tool to bring in more users. Parts that cannot be migrated could be left with a special key where manual configuration would be required.

[== 3 ==]

I can select six (6) text files and code.exe will receive all of them in the same command, something like:
code.exe "file1.txt" "file2.txt" "file3.txt" "file4.txt" "file5.txt" "file6.txt"

ShellAnything already supports this feature by default. See the Multi-selection-based properties section. This is the default behavior of selection.multi.separator property : it will add double quotes characters between arguments.

But I agree that this is not ideal and may be confusing a little.

with this line using @*:
<menuitem name="Code" icon="Code.exe,0">Code.exe @*</menuitem>
In this case the program will be executed for every parameter, resulting in something like:
code.exe "file1.txt"
code.exe "file2.txt"
code.exe "file3.txt"
code.exe "file4.txt"
code.exe "file5.txt"
code.exe "file6.txt"

Such expansion can be "achieved" with adding "newline characters" between arguments. More specifically, see the Example 2 of selection.multi.separator property. It can be written in such a specific way that the result could be 5 successive process calls when having selected 5 elements. However, to be honest, it feels more like a hack to use this for creating a batch file which content is the 5 commands. This might also be a security concern as the generated file could be intercepted, modified and then executed by ShellAnything. Not ideal.

However, the mechanism is clearly justified when used with the <clipboard> element.

We are indeed in need of a better way to do this. I have created a new issue (#181) for brainstorming about this new feature. I would gladly appreciate any comment on the design of the new feature. I would also like that you add a comment so that I could give you the credit for the idea.

Note that I do not really like the way @* seems to be handled in KuShellExt. In other words, I do not wish to have a special property that when used in the arguments attribute would trigger the <exec> element to process files one by one.

---

Other than that, I started looking at how I will design things to resolved this issue. Please be patient. Once I have a working candidate that solves this issue, I will release a new version of ShellAnything.

[mdnava]

@mdnava

It could take me a while though. I use KuShell extensively and config files are very different.

Have you ever considered writing a migration tool ? Since you are familiar with both methods and have many configuration files, this would be a good opportunity to document in code your experience and methods of migrating from KuShellExt to ShellAnything. Such a tool could be written in any language. I could then link to this tool to bring in more users. Parts that cannot be migrated could be left with a special key where manual configuration would be required.

Ok, understood. I'll consider a tool for this but I think a migration tool would largely depend on actual
matching features between both programs.

Whether I can make the tool or not, I can make documentation for it once I have a more complete picture.

[== 3 ==]

I can select six (6) text files and code.exe will receive all of them in the same command, something like:
code.exe "file1.txt" "file2.txt" "file3.txt" "file4.txt" "file5.txt" "file6.txt"

ShellAnything already supports this feature by default. See the Multi-selection-based properties section. This is the default behavior of selection.multi.separator property : it will add double quotes characters between arguments.

But I agree that this is not ideal and may be confusing a little.

Understood.. but I would think that usage of %* ( and of %1 %2 %3 ...) is kinda universal.
As for @* is just convenient to have a way to expand to a multiple command, instead of a single command.

Convenience is the key word. When you're writing long scripts and and long configuration files you just want
a simple way to handle program parameters. I would say this is one of the reasons why batch files are still very
much alive today, because of its simplicity to deal with params. It just works. I love how PowerShell allows
for a plethora of new features and advanced parameters, but it can be somewhat overkill for simpler uses.

We are indeed in need of a better way to do this. I have created a new issue (#181) for brainstorming about this new feature. I would gladly appreciate any comment on the design of the new feature. I would also like that you add a comment so that I could give you the credit for the idea.

Understood, I'll comment and bookmark the issue.

Note that I do not really like the way @* seems to be handled in KuShellExt. In other words, I do not wish to have a special property that when used in the arguments attribute would trigger the <exec> element to process files one by one.

Well.. is just quick and convenient. However, every programmer can decide how to offer and handle features.
Perhaps the exception would be when there are standards to follow. But even then sometimes following
standards to the letter can be inconvenient. For example, PowerShell naming conventions recommend names
that are very useful for a developer community, in the grand scheme of things, but at the same time recommended
names can be too long and verbose for constant scripting and command line usage, so I tend to use shorter names.

In the end, I believe the truly important thing it would be, to have the feature available and easy to implement.

Other than that, I started looking at how I will design things to resolved this issue. Please be patient. Once I have a working candidate that solves this issue, I will release a new version of ShellAnything.

Understood!

Best regards!