Better than MSDOS batch files? [closed] - powershell

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Is there something better than using MSDOS in a bat file to run commmand line operations and copy files around.
I am running into the old chestnut "gotchas" with long file names etc - and for some reason the bat file wont pause - when I insert PAUSE in my script after running a command - it's just annoying.
Whats better out there?
Cheers folks.
BTW - Just looked at Powershell and looks like the network/sys admin has blocked Powershell on our PCs (nice).

Take a look at PowerShell

There are a few rules of thumb when working with bat files.
Use setlocal endlocal to preserve your enviroment variables outside the script
Use double quotes whenever you work with files to allow files with spaces in the name
Use pushd/popd instead of cd to move between directories also works with UNC paths
If you run another bat file use the call keyword before it or your script will transfer control the new bat file and never return to the original.
Example: quicksql.bat
#echo off
setlocal
if "%1"=="" goto USAGE
set server=%1
if "%2"=="" goto USAGE
set database=%2
if "%3"=="" goto USAGE
set script=%3
sqlcmd.exe -S %server% -d %database% -i "%script%"
goto EOF
:USAGE
echo %0 server database script
:EOF
endlocal

Actually, answers referring to VBScript really mean Windows Scripting Host:
WSH is a language-independent scripting host for 32-bit Windows platforms. Microsoft provides both Microsoft Visual Basic Script and Java Script scripting engines with WSH. It serves as a controller of ActiveX scripting engines, just as Microsoft Internet Explorer does. Because the scripting host is not a full Internet browser, it has a smaller memory footprint than Internet Explorer; therefore, WSH is appropriate for performing simple, quick tasks. Scripts can be run directly from the desktop by double-clicking a script file, or from a command prompt. WSH provides a low-memory scripting host that is ideal for non-interactive scripting needs such as logon scripting, administrative scripting, and so on. WSH can be run from either the protected-mode Windows-based host (Wscript.exe), or the real-mode command shell-based host (Cscript.exe).
Any windows language (besides vbs and js) that has access to good old COM (ActiveX) can use the same scripting objects. Python is one example, and .NET with P-Invoke is another.
The Script Center Script Repository on technet contains many examples of WSH usage in system administration, most in VBS.

VB Script in a plain .vbs file.

I routinely install bash and friends on every Windows box I use. A lot of folks use cygwin for this, but I far prefer MinGW.

Install cygwin and use bash scripts, or install perl and use perl scripts, or install ant and use...... hmmm... I forget what you use there. Oh wait... ant scripts

see - Windows Powershell (formerly monad)

Scripting PowerShell is supposed to be quite nice. I have never done it, though, and you if you intend to distribute the script, the script users will need PowerShell as well.

Microsoft's new-hotness command line and scripting language is called PowerShell. It fixes many of the gotchas of batch files.

Also out of date is 4DOS. Mind the licensing.

Windows Scripting Host.
You can use a variety of languages to
implement such as VBScript, JScript,
or Python (I think I've even seen
Perl).
You get full access to the
language built-in libraries.
You get
richer API's than with the
plain-ole-shell.
WSH is included with
all shipping versions of Windows.
You
can mix-and-match languages, reuse
blocks, add new libraries, etc.

Take Command is an option. I use it and love it:
http://www.jpsoft.com/index.html
Provides a Real Windows Scripting Language
164 Built-in Commands 245
Functions 159 System Variables
Mature well tested code Upwardly
compatible with CMD.EXE with literally
thousands of additions

You might consider Tcl. You can get a single file executable named tclkit, and associate it with .tcl files. Tcl has very robust file handling commands, and you also have the option of displaying native windows to display progress, add file choosers and the like.
Tcl isn't everyone's cup of tea, but it is a very powerful scripting tool. And with tclkits, deployment is trivial since it's just a smallish single file executable.

Use ZTreeWin, it's a powerful Win32 text-mode file/directory manager and can be run without having to be installed.

Learn about Python or Ruby, It does whatever Powershell, VBScript, Perl, PHP does and more ;)

Related

How can I use powershell to run through an installer?

I am trying to install a piece of software that when done manually has configuration options you can choose from when going through the process. I am trying to figure out a way to automate this using powershell but am stuck as to how I can set those configuration options. I believe I would need to run the start-process command on the installer .exe but I don't know where to go from there. Can I use the parameters on the start-process command to pass in the configurations I want?
UPDATE: Several links towards the bottom with information on how to handle installation, configuration and file extraction for setup.exe files.
UPDATE: See Windows Installer PowerShell Module on github.com (scroll down for description, use releases tab for download). I haven't really tested it much, but it is from Heath Stewart - Microsoft Senior Software Engineer (github).
I had a quick look for that installer, but didn't find it easily. Essentially the installer is either a Windows Installer database (MSI) or something else - generally a setup.exe of some kind. An MSI database can also be wrapped in a setup.exe.
You should be aware that for legacy style installers a common practice for large scale deployment is to capture the legacy install with an application repackager tool, and then compile an MSI file to use for installation (effectively converting an installer from an old format to modern MSI format). This is a specialist task requiring good understanding of Windows and setups. It is generally done in large corporations for very large software distributions. If you are in a large company there might be a team dedicated to packaging software like the one you mention. Maybe check with your management. If the setup is an MSI the same team can also modify that for you according to your specifications.
With regards to your installer EXE. Try to run setup.exe /a from the command line and see if you get an option to extract files to a "network install point" (administrative install). Then you are dealing with an MSI file wrapped in a setup.exe. If that doesn't work you can try setup.exe /x or setup.exe /extract as well.
Windows Installer has built-in features to allow you to customize the install via PUBLIC properties (uppercase) set at the command line or applied via a transform (Windows Installer's mechanism to apply substantial changes to the vendor file - it is a partial database that gets applied to the installation database from the vendor at runtime).
Non-MSI, legacy installer technologies generally have fewer reliable ways to customize the installation settings, and they tend to be rather ad hoc when they are there. In particular the silent running and uninstall may be features that are missing or poorly executed. These installs are generally all wrapped in EXE format, and there are many tools used to generate them - each with their own quirks and features.
In other words, it all depends on what the installer is implemented as. Give that setup.exe /a a go, and update your answer with new information for us (don't add too many comments - we will check back).
With regards to using PowerShell. I haven't used PowerShell for deployment so far to be perfectly honest. Here is a basic description of how to install using PowerShell: https://kevinmarquette.github.io/2016-10-21-powershell-installing-msi-files/
You can also invoke automation for MSI files from PowerShell, I don't think this is relevant for what you asked, but here is a quick link for modifying a transform file: http://www.itninja.com/question/ps-how-to-edit-a-mst-file.
The normal way to install MSI files is via Window's built-in msiexec.exe command line. The basic msiexec.exe command line to install software is:
msiexec.exe /I "C:\Your.msi" /QN /L*V "C:\msilog.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Quick Parameter Explanation:
/I = run install sequence
/QN = run completely silently
/L*V "C:\msilog.log" = verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst (see below).
What is a transform? Explained here: How to make better use of MSI files.
Advanced Installer has a general page on msiexec.exe command lines. And here is Microsoft's msiexec.exe documentation on MSDN.
Some links:
Perhaps see Michael Urman's answer here: Programmatically extract contents of InstallShield setup.exe. This is for Installshield packaged EXE files only.
Installshield setup.exe commands (general reference with some sample command lines - towards the end of the document it looks like the command lines are not correct, but the first ones look ok. The later ones are pretty obscure anyway - just thought I'd let you know since I link to it). Here is the official Installshield help documentation.
Wise setup.exe commands - Wise is no longer available, but if the setup is older it can still be packaged with Wise.
Advanced Installer standard command line. For this tool setups can apparently be extracted with setup.exe /x or setup.exe /extract. See the link for full list.
There was also a "silent switch finder" tool used to find hidden switches in exe files (for deployment), but it failed a virustotal.com scan so I won't link to it. Maybe it is using something exotic, such as scanning a file's header at a bit level or something weird that is flagged as malware by mistake? Either way, not a tool I would use.
And finally: http://unattended.sourceforge.net/installers.php. This link isn't bad, it presents some of the tools above and a few others - and the most common switches used. Untested by me, but looks ok.
And there are other deployment tools that have their own way of packaging and delivering EXE files - it can be a jungle. I can provide a list of such tools with more links, but maybe that's just confusing. Please try what is provided above first.
Here is a generic answer that might be helpful as well: Extract MSI from EXE

Get executable (.exe) methods powershell

I need to install an application via powershell, but the application doesn't have all the available install parameters well documented.
I have done it with libraries, by loading the libraries an getting the members of it, but I havent achieved it with an .exe,
My question is there is a way to get the methods of a .exe via powershell?.
The simple answer is no.
Many executables will attempt to use common install parameters. And your odds are increased if it uses a common installer platform (MSI, InstallShield).
If it is the EXE used with an MSI, use the MSI instead as the command line arguments are effectively universal. (For some insight into what to expect from an MSI for example you can see my answer here to a very different question)
If the installer is InstallShield or another common framework for building an installer, you can try common switches, or google "productName" + install.exe switches and hope they are documented somewhere.
The last option you have is to try the common help switches:
/h
/H
/?
-h
-H
-?
--h
--?
-help
--Help
And whatever other combinations you can think of. Often times they are documented that way.

How can make 2 versions of perl run on Windows 7?

I need to run 2 versions of perl on Windows 7.
The first one is bundled with VMware vCLI, it is Active State Perl 5.8.8.
The one I need for script dev is Stawberry 5.12.4 (something like that).
When I type perl -v It calls the AS perl which does not seem to support things like named captures and other things I took for granted in perl.
Both perls are installed I just don't know how to call Stawberry instead of AS perl.
Any idea?
Your specific problem can be addressed by editing the PATH environment variable, as noted by David Heffernan.
System control panel
> Advanced system settings
> Environment variables
> Path
> Edit...
More broadly, here's the general approach I am currently using to manage multiple versions of Perl, Python, etc. on Windows 7. I would appreciate tips for better ways to do this.
I create a Perl installation area like this:
C:\usr\perls\
5.10\
5.12\
etc.
current # Symbolic link.
In that same area I create a symbolic link (current) referring to the version I want as my default, and I make sure that all Perl references in my PATH environment variable use current rather than specific version numbers.
# Open cmd window as an administrator.
cd C:\usr\perls
mklink /D current 5.12
Under that approach, I can quickly modify my system's default Perl by changing one symbolic link rather than making multiple edits to PATH, which is a more tedious.
In addition, I add a directory to my PATH containing batch scripts to invoke specific Perls.
C:\usr\bin
perl5.10.bat
perl5.12.bat
etc.
Those scripts look like this example:
# C:\usr\perls\5.12\perl\bin\perl.exe %*
I'd do this by changing the PATH environment variable. Make it point to the 5.12 version and you may find that the VMware code continues working because it knows where to find it its Perl. If not, make a .bat file that sets PATH to refer to the 5.12 installation and use that to launch into a cmd window from which calls to perl invoke 5.12.

Easiest language to produce a Windows executable to prefix running another executable with system calls?

I want to run some system commands (to fix things) before running an executable. I have a reasonably locked down (work) Windows XP system and so can't change what a shortcut points to. For my users' convenience, I must keep the same shortcut. However, I am able to swap out the .exe (renaming) and potentially replace it with another .exe (of the same name) which runs my system commands and then runs the original .exe.
What would be the easiest and quickest language/compiler to do this in? Previously, I've done this sort of thing in C (and tried it today in Python using py2exe without much success). Preferably free solutions.
Visual C# 2008 Express Edition is
free
comes with a compiler
outputs exes
C# is a good choice if you have C
experience
.net currently is the "canonical"
Windows platform

Future of cmd & powershell

We were just today discussing it, so I went on a little search but found nothing, zip, nada.
What is the future of ms's cmd shell? Do they intend to replace it completely with powershell in the future versions of windows, or just ship powershell as a parallel alternative ?
Does anyone have any links, articles, ... whatever regarding the above mentioned, cause I haven't been able to mind ms's stand regarding.
The latest build of Windows 7 has the two shells separately. I believe they won't replace the good-ol' cmd.exe. They need it mainly for compatibility reasons. A lot of programs call cmd /c, and replicating the exact same mechanism for powershell would be a duplication of effort. So, I suppose the cmd.exe remains.
cmd.exe is not going anywhere (it's far too widely used).
However, I don't think you'll be seeing any enhancements to it (not that they've been burning through them anyway).
Powershell is extremely good at doing complex tasks. However it is harder to learn and it runs much, much slower.
CMD will remain because you can run batch files and command line ops EXTREMELY quickly. Additionally it is extremely inexpensive to pop up a command shell and execute a command.
Imagine how many login scripts would break if they removed cmd.exe? Even if Powershell could run all cmd commands seamlessly (which it can't), login scripts running under Powershell would be far too slow during user login, as you would need to wait while .NET loaded up as well.
I once heard of a Citrix Admin who converted his login scripts to Powershell and then quickly realised that this was a bad idea.