search

google-code-export / windows-package-manager

Automatically exported from code.google.com/p/windows-package-manager
1 stars 1 forks source link

System PATH not updated #36

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Steps performed:
1. Install (e.g.) Mercurial
2. Type "hg" in a command prompt

I would expect my system to find the installed "hg" command. 

Adding the newly installed package to the PATH manually has two problems:

1. The package manager is supposed to take care of all such details.
2. When the package is updated the directory will change, which breaks 
functionality.

Ideally, Npackd should be "PATH-aware" and a new XML tag could specify which 
directories (if any) should be added to the system PATH. When the package is 
uninstalled, these directories should be removed.

Original issue reported on code.google.com by petter.s...@gmail.com on 28 Mar 2011 at 11:28

GoogleCodeExporter commented 9 years ago 
here is what I think about PATH: 
http://code.google.com/p/windows-package-manager/wiki/SharingResources

Original comment by tim.lebe...@gmail.com on 28 Mar 2011 at 4:33

GoogleCodeExporter commented 9 years ago 
I have now read that document. I agree that modifying the PATH is not the best 
option, but what is the alternative? How should Mercurial be installed? If the 
directory changes every time the software is updated, the package manager will 
create more problems for the user than it solves.

Original comment by petter.s...@gmail.com on 28 Mar 2011 at 9:04

GoogleCodeExporter commented 9 years ago 
You surely exaggerate saying that it "will create more problems for the user 
than it solves". The current solution is to write a batch file like the one 
below to find the newest installed Mercurial. 

set npackd_cl=c:\program 
files\wpm\com.googlecode.windows-package-manager.NpackdCL-1
set onecmd="%npackd_cl%\npackdcl.exe" "path" 
"--package=com.selenic.mercurial.Mercurial" "--versions=[1.8, 2)"
for /f "usebackq delims=" %%x in (`%%onecmd%%`) do set mercurial=%%x

set path=%mercurial%

Original comment by tim.lebe...@gmail.com on 29 Mar 2011 at 5:03

GoogleCodeExporter commented 9 years ago 
Sure, but that script makes assumptions about the Npackd installation directory 
and that NpackCL will be installed with version exactly 1.

The reason for using a package manager is that it makes it easy to install 
software. On a typical Linux distribution it is possible to write something 
like 

> apt-get install mercurial

And then immediately afterwards:

> hg clone <...>

Right now, things are still complicated.

Original comment by petter.s...@gmail.com on 30 Mar 2011 at 5:29

GoogleCodeExporter commented 9 years ago 
let's try to optimize this particular case with this issue.

BTW, the following line will not be necessary in Npackd 1.15. The system-wide 
environment variable npackd_cl is always defined and points to the newest 
installed version of NpackdCL.

set npackd_cl=c:\program 
files\wpm\com.googlecode.windows-package-manager.NpackdCL-1

Original comment by tim.lebe...@gmail.com on 30 Mar 2011 at 5:51

GoogleCodeExporter commented 9 years ago 
what do you think about the line below? It would start another command line 
processor (cmd.exe) with the path to the newest Mercurial and Make in the 
specified version (the last argument).

"%npackd_cl%\npackdcl.exe" paths -p Mercurial\bin;Make-[3,4)\bin

hg clone would work after this line.

Original comment by tim.lebe...@gmail.com on 6 Apr 2011 at 6:02

GoogleCodeExporter commented 9 years ago 
That is not a bad idea.

I have another idea as well. Have a special directory, e.g. C:\Program 
files\Npackd\bin

Then each package could specify:
<commandlinetool>hg.exe</commandlinetool>

Npackd would then make sure that a symlink to the latest executable exists in 
C:\Program files\Npackd\bin. Then it is up to the user to modify the PATH 
variable or  access that directory in any other way.

This would not make any changes to the system, but still provide a good 
solution for users wanting to install command-line tools.

Alternatively, the new directory could contain .cmd batch files of the type you 
describe above.

Original comment by petter.s...@gmail.com on 7 Apr 2011 at 1:15

GoogleCodeExporter commented 9 years ago 
unfortunately this will not work. Many Windows programs expect some files at 
relative locations to the .exe itself (*.dll, settings, files for translation 
into other languages, etc.). The only way to make many different command line 
tools accessible without typing the path is to modify the PATH variable.

Original comment by tim.lebe...@gmail.com on 7 Apr 2011 at 4:45

GoogleCodeExporter commented 9 years ago 
slightly changed syntax:

"%npackd_cl%\npackdcl.exe" path-batch -s Mercurial;;\bin --select 
org.gnu.Make;[3,4);\bin > a.bat && call a.bat

a.bat would contain:
set path=c:\program files\Mercurial-1.6\bin
set path=%path%;c:\program files\Make-2.24\bin

Original comment by tim.lebe...@gmail.com on 18 May 2011 at 7:59

GoogleCodeExporter commented 9 years ago 
another way to find an application:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
http://msdn.microsoft.com/en-us/library/ee872121%28v=vs.85%29.aspx#appPaths

Original comment by tim.lebe...@gmail.com on 19 May 2011 at 6:25

GoogleCodeExporter commented 9 years ago 
Any new ideas that would avoid the work around using "set path=" in a batch 
file? Because like for hg there is no java command after installing JDK...
Could NPackD provide an option that adds dir to PATH? But before adding dir all 
executables in dir are determined. Only if there are no disambiguities 
extending PATH succeeds otherwise an error is thrown.

Original comment by NotDiffi...@googlemail.com on 17 Jun 2011 at 3:47

GoogleCodeExporter commented 9 years ago 
set path= is the only "perfect" way to configure your path. Also a .bat file 
that runs every time you start your cmd.exe is very handy: 
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/c
md.mspx?mfr=true

HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun REG_EXPAND_SZ

Original comment by tim.lebe...@gmail.com on 23 Jun 2011 at 5:45

GoogleCodeExporter commented 9 years ago 
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun 
is run also for non-interactive shells and cmd.exe tries to run it even if the 
file does not exist setting the ERRORLEVEL to <> 0. It's OK for a user, but not 
on the HKEY_LOCAL_MACHINE level.

Also the syntax from my comment #9 seems to be an overkill. Nobody will try to 
type something like this just to get to his tools.

Original comment by tim.lebe...@gmail.com on 27 Jun 2011 at 2:45

GoogleCodeExporter commented 9 years ago 
Current set of solutions
- don't do anything and let the user setup an AutoRun.bat using 
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun 
- modify the PATH
- modify a variable NPACKD_PATH that can be used like this: 
set PATH=%NPACKD_PATH%
- put .exe files into 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
- symbolic links to package directories
- symbolic links to single executables (this probably does not work with .dlls 
from the same directory)
- a directory with .cmd files that point to the right executables

Original comment by tim.lebe...@gmail.com on 27 Jun 2011 at 3:02

GoogleCodeExporter commented 9 years ago 
Confirmed: symbolic links to single executables do not find .dlls

Original comment by tim.lebe...@gmail.com on 27 Jun 2011 at 7:07

GoogleCodeExporter commented 9 years ago 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
is also a non-shareable resource as all registry keys should be named as .exe 
files. Additionally it is also not as well-known as PATH.

Original comment by tim.lebe...@gmail.com on 27 Jun 2011 at 7:55

GoogleCodeExporter commented 9 years ago 
a directory with .cmd files is also a non-shareable resource and you cannot run 
hg.exe this way, only hg.

Symbolic links to package directories are only unique if full package names are 
used. So we end typing commands like com.example.Editor\vi.exe

Original comment by tim.lebe...@gmail.com on 28 Jun 2011 at 8:39

GoogleCodeExporter commented 9 years ago 
Current set of solutions
- don't do anything and let the user setup an AutoRun.bat using 
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun 
- modify the PATH
- modify a variable NPACKD_PATH that can be used like this: 
set PATH=%NPACKD_PATH%

Original comment by tim.lebe...@gmail.com on 28 Jun 2011 at 8:40

GoogleCodeExporter commented 9 years ago 
OK, here is the plan: machine-level PATH variable will be updated using 
pathman.exe. A new path will be appended and not inserted in the front. PATH is 
not meant to be a perfect solution as there is no way to order its parts. 

Any objections?

Original comment by tim.lebe...@gmail.com on 29 Jun 2011 at 1:43

GoogleCodeExporter commented 9 years ago 
Perfect! This should work out just fine for most users. Those who are using two 
versions of the same program in parallel, probably know their stuff. For them 
changing PATH (back) is easy. If you are also planning to remove the added path 
on uninstall using pathman.exe, I'd say you have an automatic solution for 99% 
of all unpackd users!

Original comment by NotDiffi...@googlemail.com on 29 Jun 2011 at 2:48

GoogleCodeExporter commented 9 years ago

Original comment by tim.lebe...@gmail.com on 17 Jul 2011 at 1:30

GoogleCodeExporter commented 9 years ago 
64 bit software:
7-ZIP 64 bit
ActivePerl 64 bit\bin (currently creates an additional sub-directory)
Agent Ransack 64 bit
GTK+ with dependencies 64 bit\bin
JDK 64 bit\bin
JRE 64 bit\bin
Lazarus 64 bit
Mercurial 64 bit
MiKTeX 64 bit\miktex\bin\x64
MinGW-w64 64 bit\bin
Python 64 bit
Subversion 64 bit\bin
Vim 64 bit\vim73
cURL 64 bit

Original comment by tim.lebe...@gmail.com on 17 Jul 2011 at 6:37

GoogleCodeExporter commented 9 years ago 
7-ZIP
7-ZIP A
ActivePerl\bin
Ant\bin
Blat
CMake\bin
Contig
Core Utilities\bin
GTK+ with dependencies\bin
GetText\bin
Go MinGW\bin
GraphicsMagick Q16\bin
Handle
JDK\bin
JRE\bin
Lazarus
LibXML
MSysGit\bin
Make\bin
Maven\bin
Mercurial
MiKTeX\miktex\bin
MinGW-w64\bin
NirCmd
NpackdCL
Path Manager
Processing
Putty
Python
Sed
Subversion\bin
UPX
Vim
Wget
WinSCP
XXCopy
cURL

Original comment by tim.lebe...@gmail.com on 17 Jul 2011 at 6:47

GoogleCodeExporter commented 9 years ago 
Done! Packages have to be re-installed

Original comment by tim.lebe...@gmail.com on 24 Jul 2011 at 9:10

GoogleCodeExporter commented 9 years ago

Original comment by tim.lebe...@gmail.com on 26 Aug 2011 at 8:17

GoogleCodeExporter commented 9 years ago 
this issue seems to be a never ending story. A limit of 2048 characters for 
PATH exists even in Windows 7. My PATH is already full.

What is your experience?

Original comment by tim.lebe...@gmail.com on 13 Sep 2011 at 9:08

GoogleCodeExporter commented 9 years ago

Original comment by tim.lebe...@gmail.com on 13 Sep 2011 at 9:08

GoogleCodeExporter commented 9 years ago 
What about creating directory junctions inside one directory, and adding *that* 
to the path?

For example, I need `SubWCRev.exe` (part of TortoiseSVN) and `WinMerge.exe`, 
but I don't need their respective directories to be in my path. Create two 
junctions (and have NPackd keep them updated) like so:

    mklink /J %ProgramFiles%\NPackd\Installed\WinMerge WinMerge-2.12.4\WinMerge-2.12.4-exe
    mklink /J %ProgramFiles%\NPackd\Installed\TortoiseSVN TortoiseSVN-1.6.16\WinMerge-1.6.16-exe

, then add %ProgramFiles%\NPackd\Installed\ to PATH.

This assumes, of course, that PATH can be recursive. 
http://stackoverflow.com/questions/5585109/path-recursively/5585137#5585137 
suggests that it isn't. :\

Original comment by chucker...@gmail.com on 10 Oct 2011 at 7:18

GoogleCodeExporter commented 9 years ago 
You're right. PATH does not include the sub-directories.

Original comment by tim.lebe...@gmail.com on 10 Oct 2011 at 5:56

GoogleCodeExporter commented 9 years ago

Original comment by tim.lebe...@gmail.com on 15 Oct 2011 at 7:00

GoogleCodeExporter commented 9 years ago 
all PATH handling is now done by CLU 
(http://code.google.com/p/windows-package-manager/source/browse/#hg%2Fclu)

Original comment by tim.lebe...@gmail.com on 28 Oct 2011 at 9:41

GoogleCodeExporter commented 9 years ago 
My path is not being updated after a package installation.

Original comment by jayn...@gmail.com on 23 May 2014 at 12:09

GoogleCodeExporter commented 9 years ago 
@jaynano: PATH is not updated anymore by packages. Here is why: 
https://code.google.com/p/windows-package-manager/wiki/IdealPackage#PATH
I plan to use EXE Proxy in the future to make command line utilities 
accessible: https://npackd.appspot.com/p/exeproxy
This will be probably ready by the end of 2014

Original comment by tim.lebe...@gmail.com on 23 May 2014 at 6:15