Where should the trailing semicolon in the Windows PATH environment variable be placed when adding a new folder?
Is it
[oldPATH];C:\My Folder
[oldPATH]C:\My Folder;
[oldPATH];C:\My Folder;
?
I saw different practices.
This is not really a syntax thing, actually. The correct answer here is: Place the semicolon so the result is a valid PATH.
This usually means one of the following:
set PATH=%PATH%;C:\Foo\Bar
set PATH=C:\Foo\Bar;%PATH%
because usually PATH doesn't end in a semicolon, so you have to add one appropriately to not mangle an existing path in it.
Just look at how PATH looks like and consider what you need to do if you add another path. This means you have to add a separator (the semicolon) and the path itself.
The first one. At least thats what Windows does on mine, so if Windows does it that way then that will probably be best :)
The first one:
[oldPATH]; C:\My Folder.
If you want to be sure, you can use the formula:
"%PATH%;C:\My Folder".
If it is only to execute something in, for example, a BAT script, use:
SET PATH "%PATH%;C:\My Folder".
(this one will be working just as a temporal variable)
To add a permanent User Enviroment Variable through command line:
SETX PATH "%PATH%;C:\My Folder".
Your oldPATH may end with semicolon, so when using fourth style [newPath];[OldPath] you don't add double semicolons.
path=%cd%;%path%
Note that windows doesn't care whether you write commands upper- or lowercase.
Related
I have a program shortcut on my desktop with the target set to:
"c:\folder\program.exe"
When drag'droping a folder on to this I get:
"c:\folder\program.exe" d:\myfolder
This used to work well for many years, but a newer version of the program only excepts paths with quotes like:
"c:\folder\program.exe" "d:\myfolder"
Windows automatically adds the quotes for paths with spaces, but not if the paths do not contain any spaces.
How can I force Windows to add the quotes or is there any easy way to change the target to enclose drag'dropped paths with quotes?
Thanx for reading, Needly
You can try to add an explicit parameter placeholder %1 in the target field:
"c:\folder\program.exe" "%1"
This should work since Windows does nothing else than to fill the drag&dropped file or folder path into %1 ("parameter one") or %2 etc. if a list of files/folders was dropped.
HTH, GL, HF :)
Hello stackoverflowers,
i'm afraid i can't figure out how to open an UNC path with spaces within Windows Explorer in perl.
Purpose is, i want the user to put a file within the path. To make it more comfortable, the path should open in explorer automatically. Which it does for any local drives.
The UNC path that should open is: \\srvr1\mean space dir
My code so far:
use strict
use warnings
my $sourceDir = "\\\\srvr1\\mean space dir";
system("start $sourceDir");
Which gives the error: "Win can't access \\srvr1\mean."
Ok, so i tried to quote the string:
my $sourceDir = "\\\\srvr1\\\"mean space dir\"";
Which lead to: "Win can't access \\srvr1\"mean space dir"."
Next thing i tried was:
my $sourceDir = q{"\\\srvr1\\mean space dir"}
Which lead to an cmd window being opened with the correct path within the title?!
Is maybe the system call itself wrong?
I really appreciate any help. Thanks.
The second form is correct, but then you have to account for the fact that the start command treats its first quoted argument as a window title. If you want to start a quoted path, you need to give a window title argument too (the empty string is fine).
Like so:
my $sourceDir = q{\\\\srvr1\\mean space dir};
system(qq{start "" "$sourceDir"});
For this kind of thing the array style system call is a good fit. You don't need to worry about quoting the path or escaping as much.
$path = '\\\\srvr1\mean space dir';
system('start', '', $path);
Quoting (or forgetting to quote) paths in system calls is a significant source of bugs where I've worked. A habit of doing it as above means you never need to worry about it.
Even when I try to put the path to the containing folder of MSBuild.exe e.g. C:\Windows\Microsoft.NET\Framework\v4.0.30319\, calling MSBuild from a command-line doesn't work.
How can I reach that?
I figure it out my mistake. It seems I have one extra space preceeding C:\ when adding to PATH; i.e. (something before); C:\my\path. It should be (something before);C:\my\path
I have added a include directory in my home directory. I can run "ls -l ~/include" from the build directory.
I have added that directory in both "Header Seach Path" and in "User Header Search Path". In both places I have tried with both non-recursive and recursive.
But xcode 4.5.1 can not in any situation find the first stated header file.
It is stated in source code calls.m as:
#include <directory/file.h>
I get a "Lexical or Preprocessor issue 'directory/file.h' file not found."
But when running xcodebuild from cli it has no problems what so ever to build the source.
I have tried many of the suggestions found on internet
Putting a include in /usr/ om my drive
Adding a index to the project, adding files with no copy and no "Add to target" marked.
Restart xcode.
Specifying all specific paths.
But still no go.
What is the problem. Bug´s in xcode?
I just had a similar issue, and it was because there were spaces in the path which I defined for the Header Search Path. For example, I was defining the following as a search path:
$(SRCROOT)/Frameworks/Headers
which was being expanded out to the following:
/Users/skoota/Documents/Xcode Projects/My App/Frameworks/Headers
as you can see, there are spaces within the path (which are not immediately evident, as you are using the $(SRCROOT) variable) and the compiler doesn't particularly appreciate the spaces. I solved this problem by changing the search path to this:
"$(SRCROOT)"/Frameworks/Headers
(note the quote marks around $(SRCROOT) which escapes the spaces). This now expanded out to:
"/Users/skoota/Documents/Xcode Projects/My App"/Frameworks/Headers
which works perfectly, although looks a bit odd with the embedded " marks. This took me a while to figure out, so hopefully it helps!
This usually happens if there are spaces in your directory's path. To overcome this problem, use double quotes around the path.
Suppose you want to use your project directory, then you should use: $PROJECT_DIR. Enable recursive if you want to search within the folders as well. Alternatively, you can use $(SRCROOT)
I am trying to use an autorun.inf to run my executable file under a sub-folder with space in its folder name. Like this:
H:\
autorun.inf
FOLDER NAME 1
file.exe
FOLDER NAME 2
some other stuffs
If there's no space in the folder name, it works well. But if there are some, it's not work for me.
Is this a restrict? or I am doing something wrong?
My autorun.inf:
[autorun]
open=FOLDER NAME 1\Setup.exe
icon=FOLDER NAME 1\Setup.exe
With some trials I have found that pairs of double quotes are needed. Sounds strange though.
open=""FOLDER NAME 1\Setup.exe""
Expanding on from Sanjay's answer of using two sets of quotes, like
open=""FOLDER NAME 1\Setup.exe""
If you want your icon from the folder, you need to put a single set of quotes around the whole line. E.g.
icon="FOLDER NAME 1\Setup.exe,0"
My uninformed guess: use quotes.
[autorun]
open="FOLDER NAME 1\Setup.exe"
icon="FOLDER NAME 1\Setup.exe"
In addition to doing as Thomas suggests and using quotes, you can also use the short/"DOS" style names. Which are the first 6 letters of the name followed by a tilde (~) and then a number. So "FOLDER NAME 1" would usually become "FOLDER~1".
This also works:
open=.\FOLDER NAME 1\Setup.exe
edit: works for icon, NOT for open command...a bit strange!