DosTips.com

One of the shortcomings of my System Tools Library is that it has no setup program.
And the reason I never wrote one is that I don't know where, nor how, to install these tools in the general case.
So I'm doing a poll now:

• Where do you store your own program and scripts?
• Would you have any recommendation for me on what this setup should do?

To answer the first question of my own poll:

Long ago, I installed my own tools in "C:\Tools".
Since Windows XP, I install them in "C:\JFL\Tools", with "C:\JFL" (my initials) a junction pointing to C:\Users\Larvoire\Documents (My home documents directory).
A further complication is that since I have many VMs that share access to these tools, I also have Tools subdirectories with OS-specific versions for those that require it (MS-DOS, Windows.x86, Windows.amd64, Windows.arm64, Linux.x86, Linux.x86_64, ...).

---

And about the second question, here are a few relevant facts that I know already...

Unix has standards (POSIX, FSSTND), including a list of standard folders where to put scripts and apps: /sbin, /bin, /usr/bin, /usr/local/bin, ...
Each of these folders has a well-defined role. (SysAdmin apps, System apps, Shared apps, User apps, ...)
I don't know of an equivalent standard folder hierarchy in Windows.

Unix also has a set of rules for what the `make install` command does.
GNU coding standards define environment variables that allow to override the standard places if desired: prefix, bindir, ...
Again, I don't know of any equivalent standard in Windows.

The only rule I know for Windows is that setup programs are supposed to create a folder named %ProgramFiles%\COMPANY\APPLICATION.
Which leads to a ridiculous growth of the Windows PATH, as each setup adds its own application directory to the system PATH.

Windows package management tools have taken other routes to work around this.

Chocolatey installs every package into C:\ProgramData\chocolatey\lib\PACKAGENAME.
Yet it adds just one path in the PATH: C:\ProgramData\chocolatey\bin
The trick is to store there numerous "shims" (= homonyms of your own executables), which in turn run your actual executable.
Unfortunately, it does not have the same shim system for scripts. (I do have Batch, PowerShell, Tcl, Python, and Posix Shell scripts in my library.)

Winget is just a wrapper for Windows setup programs.
Furthermore, it requires Windows 10 version 1809 or later.
So it's no help for my problem. (I wish my setup would work at least since Windows XP.)
(But once I figure-out where to install my tools, I can create a winget package for them!)

I've never looked into the other (presumably less popular) package managers.

This is a complicated question, not easy to answer.
Some ideas/remarks/suggestions.

I would like to see at least 2 options, 'standard install', and 'portable or user-specific install'

'standard install' follows windows rules, installs into folder in %ProgramFiles(x86)% and/or %ProgramFiles%.
This will fail if some tools need write-access to the installed folder.
This will make the tools available to all users but might need UAC.

'portable or user-specific install' follows no windows rules.
Allows for install to external disk, usb stick, etc. for example X:\JFL_Tools
Allows for install somewhere into %USERPROFILE%. This makes the tools only available to the user who installs the tools.
Make 2 subfolders, one for win32 and one for win64.
Clearly separating these makes it less likely users will mix use of 32/64 tools with all the resulting confusing problems/errors.
for example X:\JFL_Tools\win32
X:\JFL_Tools\win64

Regarding the foldername:
Splitting the folder in Company\Product is mostly used by companies with many products.
This seems like overkill for a single toolset. So I prefer to combine both in the foldername.

To path or not to path, that's the question!
Regarding adding the tools-folder to the path.

This should be optional, possible options.

1. add installed folder to path, choose betweeen win32 and win64.
Advantage: all tools can be used through path, user must explicitly choose between win32/win64
Disadvantage: possible conflict with other stuff on the path (first in path wins).

2. add sytem variable(s) to installed folder(s)
for example JFL_Tools_win32=X:\JFL_Tools\win32
JFL_Tools_win64=X:\JFL_Tools\win64
Advantage: Lesser chance of conflict with other installed programs, user must explicitly choose between win32/win64
Disadvantage: tools must be used prefixed with the correct 'full-path-variable'.

3. No change to path or system variables.
Advantage: truely portable, no permanent changes to path or system variables.
Disadvantage: Setting the correct path to the tools must be done in scripts using the tools.
The drive-letter might change so scripts better use relative path instead of full path.