Windows removes quotes from target in shortcut - windows

My shortcut target is: %APP_HOME%\abc.bat
The problem is that %APP_HOME% has spaces and when i save the shortcut, window's removes the double quotes and says it can't find the path. Now a requirement for me is the environment variable and to run the target with admin rights.
EDIT: APP_HOME is C:\myFolder\my app folder\current
it breaks due to the spaces in my app folder.
For those wondering, so far i've tried ", using %20, using^ to escape spaces.

So i never found an answer for this on how to use an environment variable which contains spaces in a windows shortcut, i really hope someone can find an answer. For the moment, my work around is to use a windows cmd.exe shortcut that's run as administrator with the following target:
C:\WINDOWS\system32\cmd.exe /k cd %HOMEDRIVE%%HOMEPATH% && "%APP_HOME%\abc.bat" -installdir "%APP_HOME%"
SOLUTION: In my case i was trying to create a shortcut abc.bat, then i modified the target to be "%APP_HOME%\abc.bat" -installdir "%APP_HOME%"
but this failed because windows would remove the " and as a result it could not find the target. The solution is so simple that i didn't think of it.
Right Click on Desktop -> New -> Shortcut -> Paste the Target that you want in there
Windows will still remove the " but at least it will expand properly.
as for why? I have absolutely no idea but i hope someone can shed light on this in the future.
THE PROBLEM w/ Solution So it's not an actual solution because what i just realized is that this breaks when you go to Advanced and try to run as administrator. But if you run it with normal user permissions, it will expand properly. Which sadly goes back to the original band aid mentioned above, create a cmd.exe shortcut that runs as administrator and executes the bat file.

Related

Using the %~dp0 special character in a Windows shortcut

I am trying to create a shortcut in windows which points to an .exe file in the same folder. The catch is that I would like the shortcut to work even when the .exe and shortcut are moved to different folder together. Therefore the shortcut should point to a relative path, not an absolute path
My first idea was to create a .bat file which (1) first navigates to its own location using the special character %~dp0, then (2) runs the exe.
cd %~dp0
MyFile.exe
However, this is not working because command line is disabled on the network I am working on.
My second idea was to follow the instructions here: Is it possible to make a shortcut to a relative path in Windows that runs as admin? and set the shortcut's target to %windir%\system32\cmd.exe or %COMSPEC%, both are kinda of faux ways of making a shortcut run the command line.
Still no luck, my network administrator has disabled this functionality as well.
That being said, is there a way to use the special character %~dp0 directly in the "target" field of a windows shortcut? I would ideally like to just set the target of the shortcut to
%~dp0/MyFile.exe
But maybe there is some syntax I am missing here.

How to launch a new cmd window with the correct path from Cygwin?

When I start cmd.exe from start menu, I get the registered (in registry) PATH variable, in a new window.
I want to have exactly the same effect from my cygwin+mintty, and try the followings:
Firstly I try:
bash$ cmd
This gives me a cmd shell, right inside mintty. But I want it to be in a fresh new window. emm... Perhaps I can try:
bash$ cmd /c start cmd
It nicely gives me a cmd shell in a new window. Good. However, the PATH inside that command shell is not the same as a fresh new one.
C:\>path
PATH=C:\cygwin64\usr\local\bin;C:\cygwin64\bin;C:\ProgramData\Oracle\Java\javapa
th;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\W
indowsPowerShell\v1.0;C:\opencv\myrelease\bin;C:\Qt\5.3\mingw482_32\bin;C:\Progr
am Files (x86)\Skype\Phone;C:\Program Files (x86)\Windows Kits\8.1\Windows Perfo
rmance Toolkit;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\cygwin64\
lib\lapack;D:\home\robin_hsu\bin
C:\>
You can see those paths with cygwin64 are not wanted. So, what can I do to get a new fresh cmd window, with correct PATH?
Note: I believe the problem is due to PATH is inheritable, from bash to cmd.
Perhaps someone can give me some hint to get the registered PATH of windows system under cygwin's bash. If that is possible, I can first change the PATH to the desired one, and then call cmd
So, this is basically a duplicate question to Start new cmd.exe and NOT inherit environment?. However, that question doesn't ask to open a new window, and at least for me the answers there didn't give me a correct path. The following command gives both (for me, on XP).
cygstart "$WINDIR\explorer.exe" "$WINDIR\system32\cmd.exe"
The only issue is that it also brings up dialog boxes 'File Download - Security Warning' AND 'Windows Explorer - Security Warning'. This link shows how you can avoid this in general, but I'm not sure if it's possible to remove the warnings for just one specific file. There are also a couple of answers here and here on superuser.com about disabling the warnings.
Hope this helps.

adding a shell context menu item so that I can add folder to path by right clicking

Often at work I have to install new frameworks etc which do not add themselves to path and I have to go through the tedious process of adding the exectuables to path. I therefore decided to add a shell context menu item so that I can add any given folder to the path just by right clicking it and selecting "add to path".
I went through the normal routine of creating a context menu item and I used the following command to add the folder to path:
setx PATH "%PATH%;%1%"
This seems to not evaluate the PATH-variable, and instead replaces my PATH with something like this:
PATH;C:\Program Files (x86)\Android\android-sdk\platform-tools
Is there a way to make the context menu item evaluate %PATH% instead of just ignoring the percentage signs?
I've read about using \,^ and just adding an additional % but none of these approaches seem to work.
In case it matters, this is on a Windows 7 Enterprise computer
Managed to find a permanent solution.
Since setx sets the user path and not the system path, the command mentioned in my question will add all elements in the combined userpath + system path to PATH, effectively doubling its size every time you run the script.
This can either be fixed by removing user path, or as I did, add another user variable and append that to path. I then ended up with the following script afterwards to set the path correctly:
cmd /k setx UPATH "%%UPATH%%;%1%" && exit
This way I don't need to use a bat-file. Using double %s and &s seem to work as a way to escape the character, thus making it look like this to cmd:
setx UPATH "%UPATH%;drive:/theFolderYouRightClicked" & exit
I am still not sure why you have to pass this through cmd in order to see the PATH-variable, but at least this is a semi-clean way of solving my problem
Wowwwwww! I just spent the last 6+ hours of my life trying to be able to add a directory to my path (permanently) from the context menu. Well done Windows!
nircmd.exe elevate "cmd.exe" /k "setx /M PATH %%PATH%%;%1" && exit
Big thanks to #Metareven for some crucial bits (the double %s). Failed a few years back. Links below for related info and hopefully a reg file. AddToPath.reg
Wiped all my paths in the process! Totally worth it! :)
You need nircmd.exe in your C:\windows\system32 folder (or in your path!). The "/k" is necessary for god only knows why. "/M" is for machine, for system, for permanente. (I was like two attemps from giving up and wasting all these hours).
Use RapidEnvironmentEditor (in admin mode) to check, the cmd prompt that opens will not have the current PATH info. Get double ;s for some reason. Still doesn't work by reg file below (anyone know why??) You'll have to use regedit or AdvancedRegistryEditor to make an entry manually (see link below). Use EcMenu.exe to erase context menu mistakes (and other crud).
Windows Registry Editor Version 5.00 **doesn't work**
[HKEY_CLASSES_ROOT\Folder\shell\AddToPath]
"Add To Path"
[HKEY_CLASSES_ROOT\Folder\shell\AddToPath\command]
nircmd.exe elevate "cmd.exe" /k "setx /M PATH %%PATH%%;%1"
This did actually work for me (without the double %s) but only to User PATH:
cmd /k setx PATH "%PATH;"%1 && pause
How add context menu item to Windows Explorer for folders
How to Run a Program Elevated via the Right-Click Menu in Windows ...
This might also work instead of nircmd somehow: https://superuser.com/a/938121 "C:\Windows\System32\cmd.exe"="~ RUNASADMIN"
Tried this, didn't work: https://superuser.com/questions/266974/any-freeware-program-for-adding-editing-path-from-context-menu

Adding a Application specific paths, so it works from the command line in Windows

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.

Administrator's shortcut to batch file with double quoted parameters

Take an excruciatingly simple batch file:
echo hi
pause
Save that as test.bat. Now, make a shortcut to test.bat. The shortcut runs the batch file, which prints "hi" and then waits for a keypress as expected. Now, add some argument to the target of the shortcut. Now you have a shortcut to:
%path%\test.bat some args
The shortcut runs the batch file as before.
Now, run the shortcut as administrator. (This is on Windows 7 by the way.) You can use either right-click -> Run as Administrator, or go to the shortcut's properties and check the box in the advanced section. Tell UAC that it's okay and once again the shortcut runs the batch file as expected.
Now, change the arguments in the target of the shortcut to add double quotes:
%path%\test.bat "some args"
Now try the shortcut as administrator. It doesn't work this time! A command window pops up and and disappears too fast to see any error. I tried adding > test.log 2>&1 to the shortcut, but no log is created in this case.
Try running the same shortcut (with the double quotes) but not as Administrator. It runs the batch file fine. So, it seems the behavior is not because of the double quoted parameters, and it's not because it's run as Administrator. It's some weird combination of the two.
I also tried running the same command from an administrator's command window. This ran the batch file as expected without error. Running the shortcut from the command window spawned a new command window which flashed and went away. So apparently the issue is caused by a combination of administrator, the shortcut, and the double quotes.
I'm totally stumped, does anyone have any idea what's going on? I'd also like a workaround.
I just ran Process Monitor on this and here is what I saw:
Run as User:
cmd /c ""C:\Users\Sunbelt\Desktop\test.bat" "some args""
Run as Admin:
"C:\Windows\System32\cmd.exe" /C "C:\Users\Sunbelt\Desktop\test.bat" "some args"
For some reason, the Run as Admin case is not quoting the entire command. It seems it is trying to run the command:
C:\Users\Sunbelt\Desktop\test.bat" "some args
I would guess that since the first space is quoted it actually trying to run the following command:
"C:\Users\Sunbelt\Desktop\test.bat some" args
And in Process Monitor logs there is a file system entry of "NO SUCH FILE" for "C:\Users\Sunbelt\Desktop\test.bat some". I don't know why it is different when run as Admin, but that's what appears to be happening.
To work around this, create another bat file on a path without spaces, and with a filename without spaces, that simply does this:
call "Long path to original bat file\Original bat file.bat"
This secondary bat file can be run as admin.
You can now create a shortcut to this secondary bat file and check run as admin in the shortcut's advanced options. The shortcut can be placed on a path with spaces and it can have a filename containing spaces.
In my case I just want to pass one filename as parameter, but the path has spaces.
I found a solution that worked for this case (if that's okay to truncate the file name).
Create another bat file (input_gate.bat) to remove the spaces in the path using the syntax of CALL.exe.
Assuming that the shortcut is named test.lnk and is on the same route as the input_gate.bat:
call %~sdp0test.lnk %~sf1
This pass as a parameter to test.bat the full file name in short format, with administrator privileges.
%~sdp0 -> Is the current path (for the input_gate.bat) in short format.
%~sf1 -> Is the first parameter passed to input_gate.bat (in my case the full filename with spaces)
This worked for me in Windows 7:
ShortcutTarget: C:\Windows\System32\cmd.exe /C myscript.bat Param1 "Param Two with spaces"
StartIn: "C:\Path containing\my script"
Not tried it yet as Admin. I don't think it would work if myscript.bat contained spaces
I finally figured it out, in a way that allows the use of long filenames (short filenames weren't adequate for my use case). My solution works on Win 7, 8, and 10. I think it was inspired by Luke's mention of the missing double-quote.
Here it is:
1.) For the shortcut you create to the batch file, which you set to run as admin, use the following command line:
cmd /s /c ""path_to_batch_file"
Note that there are 2 double-quote characters at the beginning of the command, and only 1 at the end, even though there should normally be 2 at the end also. But that is the trick in getting it to work!
2.) In your batch file, add back the missing double-quote character:
set user_file=%1"
That's it! Here's an example to let you see it in action:
1.) On your desktop, create "test.bat" with the following content:
#echo off
set user_file=%1"
echo The file is: %user_file%
pause
3.) Create a shortcut to the batch file. Set it to run as admin, and give it the following command line:
cmd /s /c ""%userprofile%\desktop\test.bat"
4.) Drag a file onto the shortcut. Success! (I hope...)
Answer here worked for me: https://superuser.com/questions/931003/passing-variables-with-space-to-the-command-line-as-admin
Which is...
Adding cmd /C before the target.
I also had to make sure my script's name and path didn't have spaces, and not quote the script's path in target.

Resources