Linux allows me to have a short system path by placing binaries in just a few locations. I don't have to edit the path because I just installed a new application, and I don't have to hunt for applications I want to run. How can I, with PowerShell as the program I use to launch programs from, accomplish the same thing on Windows (Vista)?
Windows Vista has symlinks now via mklink.
Perhaps you could setup a "C:\bin" folder and generate symlinks to point back to the original binaries. That is assuming that Windows Vista's symlinks work similarly to the ones in Linux. Here's a short tutorial.
Many programs create an application paths entry in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths). For those applications, you can start them like so:
PS> Start-Process <application name>
PS> Start-Process excel
If you don't have PowerShell V2, which provides Start-Process, you can use the PowerShell Community Extensions on V1.
It sounds like adding a few directories to your path environmental variable might help. From the command prompt you can view all environmental variables with the set command. Then you can cut and paste your path and use set again to add to it.
If you prefer the GUI route, right click on My Computer → Properties → (in Windows Vista and Windows 7 go to "Advanced System Settings" on the left. In Windows XP, skip this step) → Advanced Tab → At the bottom there is an Environmental Variables button.
When something is invoked from the command line, Windows checks in all the directories marked in the path first. After your application directory is in the path, you can execute it without fully qualifying your path.
You could always add a .cmd file as an alias.
I install applications into C:\bin.
Using specifically PowerShell you can just create aliases for programs you want to start. I doubt that this is actually less work than editing the PATH environment variable, though.
Related
I downloaded and installed the program "cppcheck" (http://cppcheck.sourceforge.net/).
This program has both a GUI (which I can access without problems) and a command line interface.
However, when I go to the windows command prompt and type "where cppcheck", nothing can be found.
Am I crazy? Or is the command line interface for cppcheck only accessible on Unix systems?
Since I usually don't work with Windows, I didn't realise that the "where" command just looks in the current folder and child folders of the current folder. That's why I didn't get any results.
You have to add it in the environment variables since the cppcheck installer does not add it automatically. This way you can use the where command from any folder as it also checks the environment variables too.
Just checked my path ... noticed that C:\windows\system32 was not present.
How can I add this to my path variable, since setx isn't a recognized command? I'm using Windows 8.1 Enterprise if that helps.
PATH=%PATH%;c:\windows\system32
would work at the command line. This will only change it until the command shell exists.
If you go to user accounts and your account I think there is edit environment variables on the left. This will change it for all subsequent sessions.
Consider not changing it permenantly
Putting %appdata% into the run window will open up the Appdata folder, but what is the command to open the User's Documents folder, even when someone else logs in? I thought it was something like %userdir%, but I can not find out what it is. Not sure what to search for in Google either so I am at a loss.
There is no environment variable for this. You'll need to set one. Here's a list of all Windows default environment variables:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx?mfr=true
*This is for XP, but should be the same for newer versions of Windows
For a single terminal session, you can just use
set USERDOCS=%USERPROFILE%\Documents
For all terminal sessions, you'll need to set a system environment variable. You can do this using the GUI or using setx -m USERDOCS %USERPROFILE\Documents, as described here.
The command to make this happen would be
explorer %USERDOCS%
But if you wanted to make an alias to that (i.e. a openuserdocs command), I can update and explain.
I want to set an alias to my installation of firefox so I can easily start a web page, the problem is that I dont want the script to be system dependent.
Namely I want it to be able to run on a linux distribution where the command to start firefox is already mapped to 'firefox' and can easily be run that way through bash, but on my windows machine I cant seem to get it to assign to the same variable.
I saw that I could set it to '%firefox%' via the set command but that's not quite what I want.
I believe creating aliases is possible on a windows environment because the version of svn that I use auto-installed and was able to assign itself to 'svn'. Anyone know what was involved in them being able to get their alias working, or a similar way to alias a command?
If you include your Firefox path in the %PATH% environment variable, you can start FF with "firefox". Under Windows, you should edit the system-wide settings (see this link).
AFAIK, there is nothing similar to aliases under DOS/Windows (except the %firefox% way you mentioned, too). The 'svn' command you talked about most likely is the same thing, a 'svn.exe' and its path included to %PATH%.
This is a bit restrictive, as you can only use the original filename to launch a program, but you can work around this by creating a batch file in the program's path that launches the program, f.e. a FF.BAT that contains "firefox %1".
Alternatively, you can place a batch file in a path that already is in %PATH%, f.e. the Windows directory. That way, you don't have to modify %PATH%.
Following the guide from Microsoft,
http://msdn.microsoft.com/en-us/library/ee872121(VS.85).aspx , I am able to get my program to be able to make a program resolve the dynamic libraries that are required in order for it to work.
So I add a value with the full name and path to my executable, and add subkey to this entry (named path) with the full path the directory of the DLL files.
And magic. It works. I go the start menu, and types myprogram.exe and it starts up and is now able to locate the dll files correctly.
However, if I start the command prompt using the command cmd.exe, and then try to run myprogram.exe is not able to resolve the DLL's anymore. For some reason the command prompt do not seems to respect/read the values of the registry when it is set under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Any suggestion to how I can get this behavior to work from within the command prompt as well as from the start menu?
It is correct. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths is used by ShellExecuteEx and not by CreateProcess. So not all programs will use the settings from App Paths of your application. If you want to define PATH for cmd.exe you can either use subkey of App Paths with the name cmd.exe or use an old %SystemRoot%\System32\autoexec.nt file to modify PATH environment variable.
It's also possible to use "START /WAIT app.exe" from command line which uses ShellExecuteEx.
I'll give it my best shot.
First, notice that both the cmd & the run\start menu options are running everything in C:\WINDOWS\system32.
If you're dll was there then it would work.
if you don't want to put it there, you can change the "environmental variables" by clicking right mouse button on "my computer"-> "properties" -> "Advanced" -> "environmental variables".
good luck.