Short and sweet, I am making shortcuts in PS, so long as the Target Path does not have a space in it the shortcut works fine. Once the Target has a space in it the Shortcut Target is wrapped in double quotes and as such doesn't work... Below is the non-working code. If you were to remove the space it would correctly (well except for the fact that it isn't pointing to the EXE at that point). Basically it wouldn't wrap the target in quotes.
$shell = New-Object -ComObject WScript.Shell
$shortcutX = $shell.CreateShortcut("C:\Short.lnk")
$shortcutX.TargetPath = "C:\apps\application --switch"
$shortcutX.Save()
TL;DR:
Works.
$shortcutX.TargetPath = "C:\apps\application"
Doesn't work!
$shortcutX.TargetPath = "C:\apps\application --switch"
Why?!?!?!?!
From MSDN:
This property is for the shortcut's target path only.
You can add arguments to the shortcut in the Argument's property.
$shortcutX.Arguments = "-- switch"
On my box (Windows 7 Pro), I can make shortcut with the path destination having spaces.
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.
http://www.mathworks.com/support/solutions/en/data/1-5YQCPR/index.html?product=ML says:
By default, the 'pathdef.m' file may be located in either the
'$MATLABROOT/toolbox/local' directory or the '$USERPATH' directory,
where $MATLABROOT and $USERPATH are the directories displayed after
entering the commands matlabroot (e.g. C:\Program Files\MATLAB\R2013b) and userpath (e.g. C:\Users\francky\Documents\MATLAB)
So, what determines the location of the pathdef.m file on Windows (matlabroot vs. userpath)?
According to this help page:
By default, pathdef.m is in matlabroot/toolbox/local.
However, there is apparently more to it than that.
If we add matlabpath to the top of matlabrc.m, it will tell use the search path before it has even "set up" the search path:
MATLABPATH
C:\Program Files (x86)\MATLAB\R2013a\toolbox\local
>>
So the only thing on the path is matlabroot/toolbox/local and that's where MATLAB will find pathdef.m by default. Right? I thought so, but a simple test with a pathdef.m in userpath proved that in fact userpath was the first priority for pathdef.m. Why? Because in MATLAB, the working directory takes priority over anything on the matlabpath, and the startup folder is determined by userpath!
There are multiple ways to specify the startup working directory, with and without the use of userpath's functional form. I just verified that changing the "Start in:" property of the Windows shortcut will prevent the pathdef.m in the default userpath from running. You can achieve the same change in startup folder with the userpath(path) syntax, but then what would be the difference between the startup path and userpath unless you use the shortcut "Start in:" method?
To add to the confusion, the last line of the default pathdef.m under matlabroot/toolbox/local is p = [userpath,p];, so after matlabrc.m adds this to the path on startup, MATLAB will then give userpath precedence over matlabroot, if ther is a pathdef.m under userpath.
I am trying get the parent folder of a Windows user's profile path. But I couldn't find any "parameter" to get this using SHGetSpecialFolderPath, so far I am using CSIDL_PROFILE.
Expected Path:
Win7 - "C:\Users"
Windows XP - "C:\Documents and Settings"
For most purposes other than displaying the path to a user, it should work to append "\\.." (or "..\\" if it ends with a backslash) to the path in question.
With the shell libary version 6.0 you have the CSIDL_PROFILES (not to be confused with CSIDL_PROFILE) which gives you what you want. This value was removed (see here), you have to use your own workaround.
On any prior version you'll have to implement your own workaround, such as looking for the possible path separator(s), i.e. \ and / on Windows, and terminate the string at the last one. A simple version of this could use strrchr (or wcsrchr) to locate the backslash and then, assuming the string is writable, terminate the string at that location.
Example:
char* path;
// Retrieve the path at this point, e.g. "C:\\Users\\username"
char* lastSlash = strrchr(path, '\\');
if(!lastSlash)
lastSlash = strrchr(path, '/');
if(lastSlash)
*lastSlash = 0;
Or of course GetProfilesDirectory (that eluded me) which you pointed out in a comment to this answer.
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.