I'm having some issues when trying to run some programs from the command prompt after adding their executable file paths to the PATH variable. I respected the syntax (; at the end of every path added). Has this ever happened to anyone?
You have not told us what problem you are seeing, but it you append the path to a program at the end of PATH thus:
set PATH=%PATH%;"c:\somewhere_else"
you can find the new path nevers gets seen, since there's a hard upper limit on path length. See for example this SO post
One option is to prepend the new location, bearing in mind this will drop other things off the end:
set PATH="c:\somewhere_else";%PATH%
There are various workrounds. For example, I tend to have a few set_path.bat files in a few different locations that reset my path to what's required for various different tasks.
Related
I like to modify my Windows environmental variables by opening the Advanced System Settings -> Environmental Variables. I particularly like that when I try to modify the system path (by clicking on System Variables -> Path), that I get a nice, easy to read list of the folders on the path:
However, when I click on the User Variables -> Path, I still get the old dialog, which is not very user friendly:
Is it possible to have Windows always display the list, as is the case for the System variables?
For what its worth, I think I remember seeing the desired behavior on a friend's computer, so I believe it should be possible.
EDIT:
It seems that having a variable as part of the path is the problem. Is there a way to get path list even when the path contains variables?
Context:
When I want to add a program to my path, I will create a new variable that redirects to its path. The reason to do that is simple... Programs typically have compound paths, and so making a consolidated variable seems like a wise decision. For instance, on my machine, I have multiple python instances (sometimes I need an Anaconda installation of Python 3.6, and sometimes I want a version of the bare-bones Python 3.5). To accomodate this, I create environmental variables for the paths to each installation.
Now if I want to switch which version is on my path, I can simply update my path variable from
path=...;%PATH_PYTHON35%
to
path=...;%PATH_PYTHON36A%
See how easy that was?
The problem is that the GUI doesn't seem to like this for the local variables. I can confirm that this is the case because when I remove the variables from the local path, I get the nice list like the System Variables case. However, what is perplexing to me is that the System Variables path DOES include some variables as well:
So I take this to mean that there must be a way of getting the local variables list to pop up, just like the System Variables case...
Guess I'm late to the party, but this works for me:
PATH=C:\DATA\bin;%JAVA_HOME%\bin
whereas this does not work:
PATH=%JAVA_HOME%\bin;C:\DATA\bin
A speculation based on my own observations.
It seems list view is only presented when at least one of the first two entries begins either with a drive letter notation (like C:\) or a specific variable. I'm not sure which variables are considered "valid", but here are a few environmental variables that show up as list:
%USERPROFILE%+%LOCALAPPDATA%;aaa;bbb;
aaa;Q:\%LOCALAPPDATA%;bbb;
These however show up as a string:
%LOCALAPPDATA%+%USERPROFILE%;aaa;bbb;
aaa;bbb;%USERPROFILE%;
Not sure what makes %USERPROFILE% different, but i tried a few other variables instead of %LOCALAPPDATA% (%OS%, %HOMEDRIVE%) - result was the same.
I want to set path in Visual Foxpro. In such a way that I want to keep exe file on local machine and data\tables on server. How can I do so?
I personally have never liked using SET PATH, especially if you have many "paths" that your application is expecting to use.. If you have a given table / file in multiple locations that are visible with multiple paths that qualify, you may be getting the wrong table, but you won't necessarily know it since the application just runs as normal, finds a table and continues.
Instead, I would suggest one of a few things. Yes, have your application on each user's local machine, but have the person's shortcut have the "START IN" folder pointing to the path on the server where your data is. This way, your application will BE in the folder where the data resides and processes without issue. If no data is on the local machine, during your startup, you could add a messagebox about ... hey... your shortcut should be set to "Start In" setting to X:\SomeShareOnServer\MyVFPDataPath...
If not that, then another avenue I have used is to have your application during startup, add a property to the "_Screen" object which will NEVER loose scope, and set that property to the path you have the data located such as...
_Screen.AddProperty( "cDataPath" )
_Screen.cDataPath = "X:\SomeShareOnServer\MyVFPDataPath\"
Then, in your code, any of your opening tables or SQL queries, use the path variable PLUS the table... something like
if not used( "SomeTable" )
select 0
use ( _Screen.cDataPath + "SomeTable" )
endif
if doing a query, use similar approach
select ST.* ;
from ( _Screen.cDataPath + "SomeTable" ) ST ;
where ST.SomeID = 123;
into cursor C_TmpResult readwrite
So, although the second option may take more effort, especially on an existing application, the first option to make sure the "Start In" path is where the data is might help.
Again, this is my suggestion as I hate chasing down ambiguous -- sometimes it works, but not others. If I can't find a file, I WANT TO KNOW about it and fail outright.
Your call, your app, your environment. But if you DO use the "SET PATH" command, you might want to make sure you use the ADDITIVE command, just in case there are other settings, such as pointing to the a path for forms, classes, report folders... You run a SET PATH without it, and you kill your other paths...
SET PATH TO "X:\SomeShareOnServer\MyVFPDataPath\" ADDITIVE
Also, if you have any spaces in your path in question, MAKE SURE you use quotes around it, otherwise it will fail finding the path you expect and may cause compile error, such as
SET PATH TO X:\Some Share On Server\MyVFPDataPath\ ADDITIVE
You can use VFP's Set Path command
Set Path To m.lcDataFolder
early in your client startup code, i.e. in your project's "main.PRG".
Where the content of the m.lcDataFolder could for example come from something like a custom "myConfig.XML/INI/TXT" containing the desired string, e.g. \\fileServerNameOrIP\sharedDataFolder
Use 'SET DEFAULT TO' to change the current working directory or use explicit full paths as per the answer by #DRapp.
I'm finding a lot of suggestions online for one of two basic ways to specify the PATH export in ~/.bashprofile for Git on Mac, but I haven't found an explanation for which of the two is preferable and why.
Could anyone describe the difference between these two placements of the $PATH? Thanks!
export PATH=/usr/local/git/bin:$PATH
export PATH=$PATH:/usr/local/git/bin
Changing my search terms, I found this technical piece outlining the difference: http://www.troubleshooters.com/linux/prepostpath.htm
It seems placing the $PATH at the end of the statement (export PATH=/usr/local/git/bin:$PATH) assures that the system looks in this custom place before searching default places (that is, the specified path is appended before the standard places contained within $PATH).
Placing the $PATH variable at the beginning of the statement (export PATH=$PATH:/usr/local/git/bin) doesn't work in cases where a default path already exists, because the system looks in the default places (given in PATH) before getting to the statement's custom-specified path.
So, is there a possible way to move Test.txt to C:\ProgramData\CsD2\Tools\("Unknown Folder Name")\data\per Using command prompt?
using foxidrives solution for your previous question for detecting the correct directory, then just
move test.txt "%folder%\"
Short answer: yes. Not quite sure what the situation is that has left only the middle part of your path unknown, and the need to use the comnand line, but I have encountered similar cases on Linux and expect the algoirthm can be adapted to Windows commands. It's possible to do this by hand rather than writing a shell script, but it's up to you and your skills.
Permissions matter. Make sure you elevate yours enough to read and write in Tools before continuing.
First, change directory to C:\ProgramData\CsD2\Tools\
Presumably there are many items here. Some may be "hidden," so list the contents of this directory and be sure to include an option to show hidden files and folders. If you can, restrict the search to directories only.
It's tempting to display contents recursively in the above step. It's up to you, but I find it makes the output cluttered without a script to do the rest of the work.
Now it's time to search for the subfolder set that theoretically only exists in your target folder. Suppose Tools contains the directories fldr1, fldr2, and fldr3. Use your command to list a directory's contents with the path "fldr1\data\per", then use "fldr2\data\per", and so on until it doesn't return an error. Per may be empty, but that should look different from the path not found error.
Now you've found the name of your mystery folder. Write it down for future reference.
At thus point, you know the path to Test.txt, and the full path to the destination directory. Do a move command to relocate Test.txt, and you're done. I like to relist the contents of the target directory after to be comfortable that it arrived.
If I have a file path (that might be later passed to the ShellExecute API) is there any way to tell if it points to an application?
I need this to work under Windows from a C++ program. Also, this path may contain start-up command line parameters.
You can use the SaferiIsExecutableFileType function in order to check if the file is executable.
So you really want to know if a string that represents a command line has the path to an executable as its first "part". How you go about this kind of depends on how accurate you want the information to be.
First, you have to parse the string to get the first argument. It's not as simple as just looking for the first space, because Windows paths can contain spaces. You'll have to handle things like "c:\program files\internet explorer\iexplore.exe" "http://stackoverflow.com".
Searching for a file is a rather complicated process that involves searching the directories in the PATH environment variable. The SearchPath API function can help.