I'm normally a Linux guy, but I need to write a batch script on Windows to change the target of some shortcuts. Is there a command to do that?
I doubt there is a way to do it with a batch script. It's doable in VBScript, though.
Set sh = CreateObject("WScript.Shell")
Set shortcut = sh.CreateShortcut("C:\Wherever\Shortcut.lnk")
shortcut.TargetPath = "C:\Wherever\Whatever.txt"
shortcut.Save
Save the script in a file ending in vbs and run it from the command line using cscript whatever.vbs.
(Don't be fooled by the name -- CreateShortcut is used to both create and modify shortcuts.)
There isn't a native program that comes with windows to achieve this. I scoured the internet for this same functionality awhile ago and stumbled upon the free software XXMKLINK.
With XXMKLINK, you can write a batch
file for software
installation which has been done by specialized instllation
programs. Basically, XXMKLINK is to gather the information
from a command line and package it into a shortcut.
Command syntax of XXMKLINK:
xxmklink spath opath [ arg [ wdir [ desc [ mode [ icon[:n] ]]]]]
where
spath path of the shortcut (.lnk added as needed)
opath path of the object represented by the shortcut
arg argument string (use quotes with space, see below)
wdir path of the working directory (for "Start in")
desc description string (shown in Shosrtcut's Properties)
mode display mode (1:Normal [default], 3:Maximized, 7:Minimized)
icon[:n] icon file [with optional icon index value n]
In addition to the above, the following switches are supported
which can be placed in any position in the command line.
/p prompts before action
/q no output when successful (quiet)
/e checks error condition strictly
The downside is you'll need to copy the xxmklink exe onto each computer with the batch script.
A link to download it is available at the bottom of the linked page.
Related
I have an .exe that runs in command prompt, it then asks me to press a letter to perform a task. I want a batch file that runs the .exe file and presses y to perform the action. This is what I have so far:
start cmd.exe /k ""C:\Users\mayes\Documents\Utilities\Macros\Second Keyboard Macros\Intercept\intercept\intercept.exe""
All what it does is open the .exe file. I need it to press y also.
Demonstration of what I want the batch file to do:
https://media.giphy.com/media/Ujsia9OeUqJuo/giphy.gif
So there is another much easier way, the program has built in arguments,
C:\Stack\intercept>intercept.exe /help
*** Keyboard Remapper v. 1
*** Based on Oblitum Interception http://oblita.com/Interception.html
Use /help for help on command-line options
Command line parameters:
/ini path oile.ini specify alternate config file (optional)
/apply non-interactive, apply filters on startup (optional)
C:\Stack\intercept>
if you type /help so just make a shortcut with a /apply and you're GOLDEN! it's a useful tip to check console applications for built in arguments and options by typing /help.
you can send keys with vb script witch can be run from batch.
Try this:
set shell = CreateObject("WScript.Shell")
shell.run"C:\Users\mayes\Documents\Utilities\Macros\Second Keyboard Macros\Intercept\intercept\intercept.exe"
WScript.Sleep 1500
shell.SendKeys"{Y}"
shell.SendKeys"{ENTER}"
save it as .vbs, and it you want to run it from batch you can use:
cscipt "nameoffile".vbs
hope it works for you!
When I was trying to get elevated rights for my batch script, when I found two related SO questions
How to request Administrator access inside a batch file
How can I auto-elevate my batch file, so that it requests from UAC administrator rights if required?
...that led to answers that worked partially. For some reason, I had issues with command line passing for file path arguments containing spaces within the VBS script, so I tried to break the solution into 3 parts and concentrated on the inner (VBS) step, then adding the last step by calling a batch from that VBS which could not be found, despite in the same folder as the VBS script. I found that drag & drop isn't "that easy" and that it's different when using .vbs instead of .bat or .exe as drop targets.
Here is my actual question:
If I drag a file and drop it onto an executable (exe) or batch file (bat, cmd), The current working directory is determined by the source of the dragged item. Its directory is set as the working directory for the program or script that processes it.
If I drop a file onto a VBS script, it's different. On Windows 8.1 x64 I observe it to be C:\Windows\System32 even if the argument resides in the same folder as the VBS.
I can simply use a batch file (as drag'n'drop relay) like this
my.vbs %*
to get "the normal" .bat behaviour (drop source dictates CWD), but I also want to understand it.
Is it a bug or a feature? Is it consistent over all Windows versions?
edit: added the background (on top) for the question showing how I got there (+minor corrections)
After some API monitoring, this is what I see
When you drop a file over a .exe file the explorer.exe uses CreateProcess API function to start the process, passing the executable as lpApplicationName, and the executable and dropped file as lpCommandLine. The lpCurrentDirectory is set in the function call by the caller process to the folder containing the dropped file[1].
When you drop a file over a .cmd file the explorer.exe also uses CreateProcess API, but in this case the lpApplicationName is null and the lplCommandLine contains the batch file and the dropped file. lpCurrentDirectory is also set to the parent folder of the dropped file[1].
When you drop a file over a .vbs file, ShellExecuteEx is used and the lpDirectory field of the SHELLEXECUTEINFO structure is null, so, the process created inherits the current active directory of the parent process. By default the current active directory of the explorer.exe process is %systemroot%\system32, but it is possible to start a explorer instance with a different current active directory that will be inherited in this kind of drop operations.
[1] If we drop more than one file, the path of the file passed as first argument is used
note just for information: to test the active directory inherit the process followed was:
Open a cmd instance and change the current active directory to c:\temp
Kill all explorer.exe instances
From the cmd instance call explorer.exe. This explorer instance has the active directory in the cmd window as its current active directory.
The Arguments property holds the full paths to all items dropped on the script, so you can determine the directory of each dropped item like this:
Set fso = CreateObject("Scripting.FileSystemObject")
For Each item In WScript.Arguments
WScript.Echo fso.GetParentFolderName(item)
Next
Assuming that the working directory would be defined by what is dropped onto a script is a misguided approach. If you require that logic you can implement it in the script yourself, though, e.g. like this:
Set fso = CreateObject("Scripting.FileSystemObject")
Set sh = CreateObject("WScript.Shell")
For Each item In WScript.Arguments
sh.CurrentDirectory = fso.GetParentFolderName(item)
'working directory is now the parent folder of the current item
'...
Next
If you need the working directory to be the parent directory of the VBScript file you can derive that from the ScriptFullName property:
Set fso = CreateObject("Scripting.FileSystemObject")
WScript.Echo fso.GetParentFolderName(WScript.ScriptFullName)
If I lookup the file types in the Windows registry, I see the following in their Shell\Open\Command values:
batfile: "%1" %*
cmdfile: "%1" %*
exefile: "%1" %*
VBSFile: "%SystemRoot%\System32\WScript.exe" "%1" %*
This seems to suggest that bat, cmd, exe are treated as executable on their own, maybe for historical reasons, whereas VBS is considered an ordinary script, that is only executable because its extension is registered with some executable to be called to interpret it. Pretty much the same as Python or Perl.
[Update] Indeed I proved that a Python script shows exactly the same behaviour as my VBS script: calling it from the command line providing arguments keeps the CWD, dropping a file on it causes the CWD to be C:\Windows\System32. So my question seems to be sort of wrong, but finally it helped people to point me into the right direction for further research...
c:\windows\system32\CScript.exe or c:\windows\system32\Wscript.exe are the programs that run vbscript. As you can see they are in system32.
Windows uses ShellExecuteEx to start programs - see it's rules at MSDN: ShellExecuteEx function (Windows)
ShellExecuteEx uses CreateProcess (CreateProcessEx) to actually start a program. CreateProcess function (Windows)
Edit
CMD doesn't use the registry for it's own stuff. Those registry entries are for programs other than CMD.
CMD main goal is to be MS Dos 5 compatible while enhancing it, it will correctly run most DOS batch files. It was written by IBM engineers working on OS/2 NOT Windows.
Edit 2
The core of your problem is that you are attempting to write programs as if you are a user typing to operate a computer.
As a programmer you don't make assumptions. The easiest way to not take assumptions is to specify full paths to what you want. Your batch file shouldn't care what the current directory is. EG In CMD there is a current directory per drive for compatibility with MSDos 5 (and programs in a console tend to share them but don't have to). In Windows there is one current directory per program. The default current directory has changed over the years.
The only time you should work with the current directory is if you are writing a batchfile for a user to use. EG If you type dir it does the current directory, a batchfile meant to be a general command should work the same way.
I am a beginner in VBScript. I googled it & got to know that we can run VBScript from command line by executing below command:
For Example my vbscript name is Converter.vbs & it's present in folder D:\VBS.
I can run it through following methods:
CScript "D:\VBS\Converter.vbs"
OR
WScript "D:\VBS\Converter.vbs"
Now I would like to execute above VBScript without Cscript or Wscript command by simply typing the name of VBscript name i.e. Converter.
I DON'T WANT TO SPECIFY THE FULL PATH OF VBSCRIPT EVERYTIME.
Can anyone please guide me on how to do that ?
I'll break this down in to several distinct parts, as each part can be done individually. (I see the similar answer, but I'm going to give a more detailed explanation here..)
First part, in order to avoid typing "CScript" (or "WScript"), you need to tell Windows how to launch a * .vbs script file. In My Windows 8 (I cannot be sure all these commands work exactly as shown here in older Windows, but the process is the same, even if you have to change the commands slightly), launch a console window (aka "command prompt", or aka [incorrectly] "dos prompt") and type "assoc .vbs". That should result in a response such as:
C:\Windows\System32>assoc .vbs
.vbs=VBSFile
Using that, you then type "ftype VBSFile", which should result in a response of:
C:\Windows\System32>ftype VBSFile
vbsfile="%SystemRoot%\System32\WScript.exe" "%1" %*
-OR-
C:\Windows\System32>ftype VBSFile
vbsfile="%SystemRoot%\System32\CScript.exe" "%1" %*
If these two are already defined as above, your Windows' is already set up to know how to launch a * .vbs file. (BTW, WScript and CScript are the same program, using different names. WScript launches the script as if it were a GUI program, and CScript launches it as if it were a command line program. See other sites and/or documentation for these details and caveats.)
If either of the commands did not respond as above (or similar responses, if the file type reported by assoc and/or the command executed as reported by ftype have different names or locations), you can enter them yourself:
C:\Windows\System32>assoc .vbs=VBSFile
-and/or-
C:\Windows\System32>ftype vbsfile="%SystemRoot%\System32\WScript.exe" "%1" %*
You can also type "help assoc" or "help ftype" for additional information on these commands, which are often handy when you want to automatically run certain programs by simply typing a filename with a specific extension. (Be careful though, as some file extensions are specially set up by Windows or programs you may have installed so they operate correctly. Always check the currently assigned values reported by assoc/ftype and save them in a text file somewhere in case you have to restore them.)
Second part, avoiding typing the file extension when typing the command from the console window.. Understanding how Windows (and the CMD.EXE program) finds commands you type is useful for this (and the next) part. When you type a command, let's use "querty" as an example command, the system will first try to find the command in it's internal list of commands (via settings in the Windows' registry for the system itself, or programmed in in the case of CMD.EXE). Since there is no such command, it will then try to find the command in the current %PATH% environment variable. In older versions of DOS/Windows, CMD.EXE (and/or COMMAND.COM) would automatically add the file extensions ".bat", ".exe", ".com" and possibly ".cmd" to the command name you typed, unless you explicitly typed an extension (such as "querty.bat" to avoid running "querty.exe" by mistake). In more modern Windows, it will try the extensions listed in the %PATHEXT% environment variable. So all you have to do is add .vbs to %PATHEXT%. For example, here's my %PATHEXT%:
C:\Windows\System32>set pathext
PATHEXT=.PLX;.PLW;.PL;.BAT;.CMD;.VBS;.COM;.EXE;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY
Notice that the extensions MUST include the ".", are separated by ";", and that .VBS is listed AFTER .CMD, but BEFORE .COM. This means that if the command processor (CMD.EXE) finds more than one match, it'll use the first one listed. That is, if I have query.cmd, querty.vbs and querty.com, it'll use querty.cmd.
Now, if you want to do this all the time without having to keep setting %PATHEXT%, you'll have to modify the system environment. Typing it in a console window only changes it for that console window session. I'll leave this process as an exercise for the reader. :-P
Third part, getting the script to run without always typing the full path. This part, in relation to the second part, has been around since the days of DOS. Simply make sure the file is in one of the directories (folders, for you Windows' folk!) listed in the %PATH% environment variable. My suggestion is to make your own directory to store various files and programs you create or use often from the console window/command prompt (that is, don't worry about doing this for programs you run from the start menu or any other method.. only the console window. Don't mess with programs that are installed by Windows or an automated installer unless you know what you're doing).
Personally, I always create a "C:\sys\bat" directory for batch files, a "C:\sys\bin" directory for * .exe and * .com files (for example, if you download something like "md5sum", a MD5 checksum utility), a "C:\sys\wsh" directory for VBScripts (and JScripts, named "wsh" because both are executed using the "Windows Scripting Host", or "wsh" program), and so on. I then add these to my system %PATH% variable (Control Panel -> Advanced System Settings -> Advanced tab -> Environment Variables button), so Windows can always find them when I type them.
Combining all three parts will result in configuring your Windows system so that anywhere you can type in a command-line command, you can launch your VBScript by just typing it's base file name. You can do the same for just about any file type/extension; As you probably saw in my %PATHEXT% output, my system is set up to run Perl scripts (.PLX;.PLW;.PL) and Python (.PY) scripts as well. (I also put "C:\sys\bat;C:\sys\scripts;C:\sys\wsh;C:\sys\bin" at the front of my %PATH%, and put various batch files, script files, et cetera, in these directories, so Windows can always find them. This is also handy if you want to "override" some commands: Putting the * .bat files first in the path makes the system find them before the * .exe files, for example, and then the * .bat file can launch the actual program by giving the full path to the actual *. exe file. Check out the various sites on "batch file programming" for details and other examples of the power of the command line.. It isn't dead yet!)
One final note: DO check out some of the other sites for various warnings and caveats. This question posed a script named "converter.vbs", which is dangerously close to the command "convert.exe", which is a Windows program to convert your hard drive from a FAT file system to a NTFS file system.. Something that can clobber your hard drive if you make a typing mistake!
On the other hand, using the above techniques you can insulate yourself from such mistakes, too. Using CONVERT.EXE as an example.. Rename it to something like "REAL_CONVERT.EXE", then create a file like "C:\sys\bat\convert.bat" which contains:
#ECHO OFF
ECHO !DANGER! !DANGER! !DANGER! !DANGER, WILL ROBINSON!
ECHO This command will convert your hard drive to NTFS! DO YOU REALLY WANT TO DO THIS?!
ECHO PRESS CONTROL-C TO ABORT, otherwise..
REM "PAUSE" will pause the batch file with the message "Press any key to continue...",
REM and also allow the user to press CONTROL-C which will prompt the user to abort or
REM continue running the batch file.
PAUSE
ECHO Okay, if you're really determined to do this, type this command:
ECHO. %SystemRoot%\SYSTEM32\REAL_CONVERT.EXE
ECHO to run the real CONVERT.EXE program. Have a nice day!
You can also use CHOICE.EXE in modern Windows to make the user type "y" or "n" if they really want to continue, and so on.. Again, the power of batch (and scripting) files!
Here's some links to some good resources on how to use all this power:
http://ss64.com/
http://www.computerhope.com/batch.htm
http://commandwindows.com/batch.htm
http://www.robvanderwoude.com/batchfiles.php
Most of these sites are geared towards batch files, but most of the information in them applies to running any kind of batch (* .bat) file, command (* .cmd) file, and scripting (* .vbs, * .js, * .pl, * .py, and so on) files.
When entering the script's full file spec or its filename on the command line, the shell will use information accessibly by
assoc | grep -i vbs
.vbs=VBSFile
ftype | grep -i vbs
VBSFile=%SystemRoot%\System32\CScript.exe "%1" %*
to decide which program to run for the script. In my case it's cscript.exe, in yours it will be wscript.exe - that explains why your WScript.Echos result in MsgBoxes.
As
cscript /?
Usage: CScript scriptname.extension [option...] [arguments...]
Options:
//B Batch mode: Suppresses script errors and prompts from displaying
//D Enable Active Debugging
//E:engine Use engine for executing script
//H:CScript Changes the default script host to CScript.exe
//H:WScript Changes the default script host to WScript.exe (default)
//I Interactive mode (default, opposite of //B)
//Job:xxxx Execute a WSF job
//Logo Display logo (default)
//Nologo Prevent logo display: No banner will be shown at execution time
//S Save current command line options for this user
//T:nn Time out in seconds: Maximum time a script is permitted to run
//X Execute script in debugger
//U Use Unicode for redirected I/O from the console
shows, you can use //E and //S to permanently switch your default host to cscript.exe.
If you are so lazy that you don't even want to type the extension, make sure that the PATHEXT environment variable
set | grep -i vbs
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyw;.tcl;.PSC1
contains .VBS and there is no Converter.cmd (that converts your harddisk into a washing machine) in your path.
Update wrt comment:
If you 'don't want to specify the full path of my vbscript everytime' you may:
put your CONVERTER.VBS in a folder that is included in the PATH environment variable; the shell will then search all pathes - if necessary taking the PATHEXT and the ftype/assoc info into account - for a matching 'executable'.
put a CONVERTER.BAT/.CMD into a path directory that contains a line like cscript p:\ath\to\CONVERTER.VBS
In both cases I would type out the extension to avoid (nasty) surprises.
I am wondering why you cannot put this in a batch file. Example:
cd D:\VBS\
WSCript Converter.vbs
Put the above code in a text file and save the text file with .bat extension. Now you have to simply run this .bat file.
Why don't you just stash the vbscript in a batch/vbscript file hybrid. Name the batch hybrid Converter.bat and you can execute it directly as Converter from the cmd line. Sure you can default ALL scripts to run from Cscript or Wscript, but if you want to execute your vbs as a windows script rather than a console script, this could cause some confusion later on. So just set your code to a batch file and run it directly.
Check the answer -> Here
And here is an example:
Converter.bat
::' VBS/Batch Hybrid
::' --- Batch portion ---------
rem^ &#echo off
rem^ &call :'sub
rem^ &exit /b
:'sub
rem^ &echo begin batch
rem^ &cscript //nologo //e:vbscript "%~f0"
rem^ &echo end batch
rem^ &exit /b
'----- VBS portion -----
Dim tester
tester = "Convert data here"
Msgbox tester
You may follow the following steps:
Open your CMD(Command Prompt)
Type 'D:' and hit Enter. Example: C:\Users\[Your User Name]>D:
Type 'CD VBS' and hit Enter. Example: D:>CD VBS
Type 'Converter.vbs' or 'start Converter.vbs' and hit Enter. Example: D:\VBS>Converter.vbs Or D:\VBS>start Converter.vbs
I'm trying to "hide" some of my Perl program from the end user to make things easier on them. I'm doing what I can to keep them out of the command prompt. The program itself has a GUI designed in Perl/Tk, so they don't have to worry about the command prompt.
Could I write out a quick batch file that goes along the lines of:
START perl 'C:\[some path here]\myscript.pl'
with START to start a program, the Perl interpretor as my program, and the path/name of my Perl script as the parameter?
Would I have to specify where to find perl or would Windows just know because perl is in the computer's PATH variable?
I have a totally evil VBS script and batch file to deal with this kind of thing with Strawberry Perl Portable. The VBS script runs the batch file without spawning a cmd window. The batch file works out where it is, where perl.exe is relative to it, and runs the perl script. In this case it's to run a Catalyst server, but can be used for anything else too.
Here's the vbs (shudder):
Set fso = CreateObject("Scripting.FileSystemObject")
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run chr(34) & fso.GetParentFolderName(wscript.ScriptFullName) & "\perlshell.bat"& Chr(34), 0
Set WshShell = Nothing
And here's the batch script (only slightly less shudder):
echo off
set bindir=%~dp0
set perlpath=%bindir%perl\bin
set buildpath=%bindir%\bin
set PATH=%PATH%;%perlpath%;%buildpath%
"%perlpath%\wperl.exe" "%bindir%MyPhp\script\myphp_server.pl" -p 35900
you don't need "start" for this. either add perl.exe from your path or specify the full path to the perl interpreter.
so ... put this in your batch file:
c:\program files\perl.exe "c:\whatever\myscript.perl"
-don
If the idea is to keep them away from the command line, why use a batch file at all? Why not just make a shortcut? (You could use Win32::Shortcut if you don't want to make one by hand.)
There's an easier way. For windows:
Go to the desktop -> right click -> create a shortcut
make your target look like (i.e. the path to the perl.exe file) something like the following - I'll show you what mine looks like
C:\Strawberry\perl\bin\perl.exe
In my case I have Strawberry Perl installed
right click desktop shortcut -> click properties
In the target input box, alter it to look something like mine:
C:\Strawberry\perl\bin\perl.exe D:\Developer\CustomTools\login.pl
where login.pl is the absolute path to my perl script
from there you should have a shortcut created to allow execution of a perl script.
In case you might be interested:
in the properties popup you can also assign this invocation of the perl script to a keyboard button press and assign it a shortcut key to launch anytime ^_^
For me, I chose to do:
ctrl+alt+i
to stand for login - to invoke the login.pl script I wrote. be aware of default system keyboard combinations
If you have any questions, let me know!
Thanks for you time!
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.