How to run VBScript from command line without Cscript/Wscript - vbscript

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

Related

octave-gui invoked by bat script does not work unless you run octave(-gui) before (or "run octave-cli.exe with qt")

I want to run octave-gui (Octave 5.1 installed with installer and "C:\Octave\mingw64\bin" is in path variable) scripts run by Windows Task Scheduler. I have to run octave-gui since I want to use the qt toolkit for plotting that octave (without gui) does not support. Therefore I normally use simple bat files like "octave-gui --no-gui c:\path\myfile.m".
But the problem is that I cannot run this bat file by clicking in the Windows Explorer or running from command line. Even the most simple bat file with the content "octave-gui --no-gui" gives me the following error:
But the funny part is that I can make it work somehow:
open command line
run "octave" or "octave-gui" and close/quit it
then I can the bat file from the command line
But this could not be the solution, could it? This only works in the (interactive) command line. How does it work in the Task Scheduler?
So, do you have a solution to run either batch files using octave-gui or octave with qt toolkit.
Here is the workaround with "where" as asked by Gerhard:
The command octave is technically incorrect.
It works only from your Command Prompt window because its extension .bat is listed within the values assigned to an unmodified environment variable %PATHEXT%. It also assumes that there are no other files named octave.com or octave.exe, anywhere within the any of the directories listed under your environment variable %PATH%. Additionally it also assumes that there is not an executable file named octave with any extension listed under %PATHEXT% in the current directory when invoked.
You should, for safety, use octave.bat instead.
octave.bat
Octave.bat will parse any input arguments, set up the required environment, and then run either start octave-gui.exe --gui %* or octave-cli.exe %* if it detected --no-gui as one of the input arguments.
Additionally when running a batch file from another, (in this case start_my_octave_script.bat), you should Call it if you're wanting control to return to it afterwards, which will almost certainly be the case.
call octave.bat <command line options>
If you're satisfied that your %PATHEXT% environment variable is unmodified or at least holds the default values, you can omit the .batextension, but please bear in mind the previous advice.
call octave <command line options>
I made a workaround thanks to the hints made by Compo. It seems to me that a solution must be done in the "octave.bat" and so I did. I made a copy and named it "octave-gui-nogui-withqt.bat" and removed all the gui checking stuff and only run "octave-gui.exe --no-gui" (scroll down):
:; # if running from bash, recall using cmd.exe
:; cmd.exe //c "$0" "$#"; exit $?
#echo off
Rem Find Octave's install directory through cmd.exe variables.
Rem This batch file should reside in Octaves installation bin dir!
Rem
Rem This trick finds the location where the batch file resides.
Rem Note: the result ends with a backslash.
set OCT_HOME=%~dp0\.\..\
Rem Convert to 8.3 format so we don't have to worry about spaces.
for %%I in ("%OCT_HOME%") do set OCT_HOME=%%~sI
Rem Set up PATH. Make sure the octave bin dir comes first.
set PATH=%OCT_HOME%qt5\bin;%OCT_HOME%bin;%PATH%
Rem Set up any environment vars we may need.
set TERM=cygwin
set GNUTERM=wxt
set GS=gs.exe
Rem QT_PLUGIN_PATH must be set to avoid segfault (bug #53419).
IF EXIST "%OCT_HOME%\qt5\bin\" (
set QT_PLUGIN_PATH=%OCT_HOME%\qt5\plugins
) ELSE (
set QT_PLUGIN_PATH=%OCT_HOME%\plugins
)
Rem set home if not already set
if "%HOME%"=="" set HOME=%USERPROFILE%
if "%HOME%"=="" set HOME=%HOMEDRIVE%%HOMEPATH%
Rem set HOME to 8.3 format
for %%I in ("%HOME%") do set HOME=%%~sI
Rem Start Octave (this detaches and immediately returns).
Rem make this call in order to have qt on the cli
octave-gui.exe --no-gui %*
Is this the most elegant one? I guess that upstream Octave should allow a new option like "--no-gui-but-use-qt" or similar. What do you think?
It still confuses me that "octave-cli.exe" and "octave-gui.exe" have more differences besides the visible gui.

Use batch file to input letter to perform action in cmd

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!

How do I make my Perl scripts act like normal programs on Windows?

I want my Perl scripts to behave just like any other executable (*.exe file).
When I double-click on myscript.pl I want it to execute instead of opening in a text editor.
I want to run myscript.pl instead of perl myscript.pl.
I really want to run myscript instead of myscript.pl.
I want to run program | myscript instead of program | perl myscript.pl.
I want to be able to run my script via drag & drop.
There are a number of changes you have to make on Windows to make all of
these things work. Users typically stumble upon things that don't work one at
a time; leaving them confused whether they've made an error, there's a bug in
Perl, there's a bug in Windows, or the behavior they want just isn't possible.
This question is intended to provide a single point of reference for making
everything work up front; ideally before these problems even occur.
Related questions:
How do I make Perl scripts recognize parameters in the Win32 cmd console?
Running a perl script on windows without extension
Perl execution from command line question
How can I read piped input in Perl on Windows?
Perl on Windows, file associations and I/O redirection
How do I create drag-and-drop Strawberry Perl programs?
Note: The actions below require administrative privileges. For
steps utilizing the command prompt it must be launched via "Run as
administrator" on Windows Vista / Windows 7.
Associate *.pl files with perl
Run the following commands at a shell prompt:
assoc .pl=PerlScript
ftype PerlScript=C:\bin\perl.exe "%1" %*
Replace C:\Perl\bin\perl.exe with the path to your Perl installation. This
enables you to run myscript.pl instead of perl myscript.pl.
Default install locations are:
ActivePerl: C:\Perl
Strawberry Perl: C:\Strawberry
Add .PL to your PATHEXT environment variable.
This makes Windows consider *.pl files to be executable when searching your
PATH. It enables you to run myscript instead of myscript.pl.
You can set it for the current cmd session
set PATHEXT=%PATHEXT%;.PL
To set it permanently (under Windows Vista or Windows 7)
setx PATHEXT %PATHEXT%;.PL
Under Windows XP you have to use the GUI:
Right-click My Computer, and then click Properties.
Click the Advanced tab.
Click Environment variables.
Select PATHEXT, then click Edit.
Append ;.PL to the current value.
Make I/O redirection work
I/O redirection (e.g. program | myscript) doesn't work for programs started
via a file association. There is a registry patch to correct the problem.
Start Registry Editor.
Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
On the Edit menu, click Add Value, and then add the following registry value:
Value name: InheritConsoleHandles
Data type: REG_DWORD
Radix: Decimal
Value data: 1
Quit Registry Editor.
Warning: In principle, this should only be necessary on Windows XP. In my experience it's also necessary in Windows 7. In Windows 10 this is actively harmful—programs execute but produce nothing on stdout/stderr. The registry key needs to be set to 0 instead of 1.
See also:
STDIN/STDOUT Redirection May Not Work If Started from a File Association
Perl Scripts on Windows 10 run from Explorer but not Command Prompt
If patching the registry isn't an option running program | perl -S myscript.pl
is a less annoying work-around for scripts in your PATH.
Add a drop handler
Adding a drop handler for Perl allows you to run a Perl script via drag & drop;
e.g. dragging a file over the file icon in Windows Explorer and dropping it
there. Run the following script to add the necessary entries to the registry:
use Win32::TieRegistry;
$Registry->Delimiter("/");
$perlKey = $Registry-> {"HKEY_CLASSES_ROOT/Perl/"};
$perlKey-> {"shellex/"} = {
"DropHandler/" => {
"/" => "{86C86720-42A0-1069-A2E8-08002B30309D}"
}};
Convert your perl scripts into batch files using pl2bat once they are ready to be run by users.
The trick works through the perl -x switch which, according to perldoc perlrun, makes Perl search for the first line looking like #!.*perl.
After following the instructions in the accepted answer, a double click still led to .pl files opening with Notepad in Windows 10 — even when perl.exe was set as the default file handler.
After finding Jack Wu's comment at ActivePerl. .pl files no longer execute but open in Notepad instead I was able to run perl scripts on double-click as such:
Select and right-click a .pl file
Use the "Open With" submenu to "Choose another app"
Select "Always use this app to open .pl files" (do this now – you won't get the chance after you have selected a program)
Scroll to the bottom of the "Other options" to find "More apps", and select "Look for another app on this PC"
Navigate to C:/path/to/perl/bin/ and select Perl5.16.3.exe (or the equivalent, depending on which version of Perl you have installed: but not Perl.exe)
Then the Perl icon appears next to .pl files and a double-click leads to them opening in Perl every time, as desired.
I tried the assoc and ftype methods and they didn't work for me.
What worked was editing this registry key:
Computer\HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open\command
It was set to:
"C:\Perl64\bin\perl.exe" "%1"
When it should be:
"C:\Perl64\bin\perl.exe" "%1" %*
It is the same content as the ftype, but for arcane windows reasons, I had to set it there too.
Like some others, I had set 'assoc' and 'ftype', but also had set Notepad text editor via the GUI, and when I tried to execute a script via the command line, Windows invoked Notepad to edit the script instead of running my script.
Using the GUI to instead point the .pl file association to the script-running executable was not much of an improvement, since it would invoke the executable on my script, but would pass no command-line arguments (even when I invoked my script from the command line).
I finally found salvation here which advised me to delete some registry keys.
Key quote:
"The problem is that if you have already associated the program with the extension via the Open With dialog then you will have created an application association, instead of a file extension association, between the two. And application associations take precedence."
In my case, following the instructions to use RegEdit to delete
HKEY_CLASSES_ROOT \ Applications \ perl.exe
where perl.exe is the name of my Perl executable, and then also deleting:
HKEY_CLASSES_ROOT \ .pl
seemed to solve my problem, and then (after re-executing 'assoc' and 'ftype' commands as shown in other answers) I could then execute scripts from cmd.exe and have them run with access to their command-line parameters.
Some other related information here.

How do I create drag-and-drop Strawberry Perl programs?

I've got a Strawberry Perl program that accepts a single-file as a command-line argument. How can I set things up such that I can drag and drop the desired file onto the Strawberry Perl program (or a wrapper around it) and the program runs with that file's name as an argument?
Under Windows (tested with XP), you can create a .cmd file and simply have it run the Perl program with the argument of %1 to pass the filename over, as if executed by commandline.
perl c:\test.pl %1
Then you can simply drag and drop a file onto the .cmd file to execute.
Eeek! Please don't create a wrapper script/cmd when you don't need to.
Go into your Registry or your File Type dialog box in Windows, and redefine the Perl default action to say:
"C:\path-to-perl-folders\perl.exe" "%1" %*
This will cause double-clicking the .PL to launch perl.exe with the name of the double-clicked file (%1). The %* stuff (passing any filename arguments to the Perl script) is trickier.
Go into the Registry again (really, it's not as scary as people think) and find/create a "shellex" key under the Perl class, and then create a sub-key called "DropHandler" with a default string value of "{86C86720-42A0-1069-A2E8-08002B30309D}" (at least, that's my DropHandler in the US version of Windows XP).
This allows .pl files (actually, anything associated with the Perl class) to have a drop handler that tells Explorer what to do when you drop file(s) on the .pl script. In this case, it just means "run the Perl script with the dropped file(s) as arguments".
Hmmm, I don't think I explained that very well, but that's how I've set up Perl (running off a network drive) for a large engineering organization. Google for Perl and DropHandler, and you should be able to get the .reg Registry script to do this for you.
Here's another alternative to a "wrapper", but it requires a slight modification to the perl script:
Rename your script.pl script to script.cmd.
Add the following to the top of the file:
#SETLOCAL ENABLEEXTENSIONS
#c:\path\to\perl.exe -x "%~f0" %*
#exit /b %ERRORLEVEL%
#!perl
#line 6
# ...perl script continues here...
The script is run like any other batch file. The first three lines basically invokes Perl on the CMD file itself (%~f0, which only works if CMD extensions are turned on). The -x paremeter to perl.exe tells Perl to skip everything until the #!perl line. "#line 6" just aids in debugging.
This is my preferred solution when I don't know much about the target system (and may not be able to edit the registry).

Change a shortcut's target from command prompt

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.

Resources