We are currenly using bat/cmd files to execute jobs, examine a return code and based on the return code execute the next sequence.
I am thinking that .VBS extensioned files may give us a richer language for doing this kind of thing than batch files.
If this is correct, why would someone choose bat files over VBS files? Are VBS files considered "Windows Scripting Host" files? how is this related to Powershell?
Sorry, I am a bit ignorant on my options and the differences.
Writing batch files was powerfull, it still persist nowdays, in fact people are still maintaining batch but it's old fashion.
A few years ago Microsoft introduced Windows Script Host, which is an infrastructure of scripting languages that allows the writing of Visual Basic or Java scripts. This infrastructure allowed scripters to interact with COM objects and in so doing access to almost everything in Windows. (edited) according to #EBGreen remark, WSH is present from W2K to W2K8 R2
In 2006 Microsoft introduced PowerShell. This scripting environment works on the top of the .Net framework. This means that the PowerShell scripter is able to do most of the things a C# prorammer does. The difference with VBS is that PowerShell is more concise and more coherent than VBS because everything is done using .NET types. Powershell is procedural programming using objects (properties and methods). (edited) according to #EBGreen remark, PowerShell V1.0 is present in Vista and W2K8 and PowerShell V2.0 is present in Windows 7 and W2K8 R2. Powershell 2.0 can be deployed begining on Windows XP SP2.
As far as process control is concern, with powershell you can start, stop, wait for the end of a process.
Related
we have application that needs to simply copy somefiles from source to destination and manipulate config files based on the environment. We use Jenkins for deployment. Since i am comfortable with C# i thought of writing simple console application (.exe ) and invoke that exe on post-deployment by passing some command line argument. and i think this would work.
But i see people are recommending power-shell for deployment. and i have used PS for other projects for deployment.
i just wanted to know what powershell can do that windows console application cannot do?
Since PowerShell could be wholly embedded (not really the right term but it works for this explanation) in C# , there's nothing you could do in PowerShell that couldn't also be achieved in C#.
You can also embed C# in PowerShell, but for various reasons you don't get exactly the same scope of functionality that you can with an .exe.
The point of using PowerShell has to do with the context of it being part of a deployment step.
A PowerShell command or script is more easily changed. A build process is not required.
Its contents are more readily visible and readable to someone who wants to understand the process.
The code written will (likely) be less verbose, further making it easier to understand, and for deployment steps it may be much more straightforward to do those steps in PowerShell (a single cmdlet may do what would be several (dozen) lines in C#).
I've been using powershell script to automate some tasks on production servers. However, it reaches its limitation when I try to do something about async and parallel processing, etc.
Is F# script a good to replace powershell script? (Guess it will be more cumbersome when access file system and other other OS objects, which is very easy in Powershell). The servers don't have visual studio installed. Is it OK just copy fsi.exe to the server to run the fsx files?
A use case,
Download big zip files from a slow FTP server
Unzip the files
Execute an executable files to process the unzipped files
each steps take a while so I want to do something like the following which is hard to do it in powershell
//Limit download 3 files at the same time maximum.
async {
let! zip = GetFromFTP ...
let! file = Unzip zip
do! ... //Run exe to parse file
}
You may find FAKE even more useful that just fsi.exe. It automates builds, but it is just an .fsx file with different targets that could be run from a command line.
F# script is not a good choice to replace powershell altogether - as you mentioned, F# is a much lower-level language, so you will need to write a ton more code to do basic system automation stuff. F# also isn't as well-integrated with other Windows server technologies, so that will be another uphill battle. If you really want to go that route, you should install the F# 3.1.2 bundle on your server, that will deploy the FSharp.Core runtime and fsc/fsi.
Since both powershell and F# are based on .NET, another option is to write your more algorithmic, computationally intensive code in F# as a DLL, then simply load that into powershell. You can even write Powershell cmdlets directly in F#. I've used this approach successfully in the past.
If your specific question is related to parallel/async execution of code, powershell background jobs might be relevant.
Edit: On the topic of powershell/F# interoperability, the Powershell Type Provider might also be worth investigating.
F# could certainly be an interesting choice for writing automation code on servers, but you'll end up writing a lot of basic cmdlets first. Yes, F# could be a good choice in time, but you'll most likely struggle in the beginning. Don't expect to take a 20-line power shell script and get a 20-line F# script. The point, where you'll have a real advantage with F# is more likely to be at close to 1000 lines of powershell code, i.e. when you actually write programs in it.
Powershell is not a very good language, but it comes with much more built-in than F#. That is, I bet what V.B. was talking about with respect to FAKE. FAKE comes with a lot of built-in things as well, but nowhere near as much as powershell.
So if your goal is to write a few cp, mv and rm or anything with pre-existing cmdlets, you'll be disappointed with F#. But if you are writing more complex processing, where the cmdlets are only input / output, you might be happy with F# in the long run.
I was reading Learn Windows PowerShell 3 in a Month of Lunches by Jones and Hicks and this passage from Chapter 1 caught my attention:
Microsoft's goal for Windows PowerShell is to build 100% of a production's administrative functionality in the shell. Microsoft continues to build GUI consoles, but those consoles are executing PowerShell commands behind the scenes. That approach forces the company to make sure that every possible thing you can do with the product is accessible through the shell. If you need to automate a repetitive task or create a process that the GUI doesn't enable well, you can drop into the shell and take full control for yourself.
A number of Microsoft products have already adopted this approach, including Exchange Server 2007 and 2010, SharePoint Server 2010, many of the System Center products, and many components of Windows itself. Going forward, more and more products and Windows components will follow this pattern. The latest version of Windows Server, which is where PowerShell v3 was introduced, is almost completely managed from PowerShell - or by a GUI sitting atop PowerShell. That's why you can't afford to ignore PowerShell - over the next few years, it'll become the basis for more and more administration.
I was wondering if it is possible to capture the PowerShell commands that are generated from Windows GUIs and tools like IIS?
It would make it very easy to create automation scripts that way, and also help in learning PowerShell.
Stick a Start-Transcript call in your all-host profile ($Profile.CurrentUserAllHosts), probably generating a filename for it based on date or counter or something.
Use something like this Transcript module to add support first for hosts that don't normally allow it (ISE v4.0 and below, SharePoint, etc), possibly only including it if the host isn't PowerShell itself.
Hi I'm wondering if it's possible to create application installers for MSI's. What I want it to do is when I run an MSI I want to be able to run it in it's own process so I can reference it via it's process ID so I can send various keys to it so it installs the way I want it too.
I can code in both C and Java but for the Sys Admins would be good if I could code it in Powershell for them. Also I've seen other installers that can detect when the next instance of the install screen appears so it immediately send the new command keys, well appears that way.
Any advice is welcomed.
MSI's traditionally allow for admins to provide an answer file or arguments using msiexec.
See this q/a on SuperUser or this SO Q/A for more info.
You can then use PowerShell to call the exe's by using the 3rd party Windows Installer PowerShell Module
.
[The Windows Installer PowerShell Module] Exposes Windows Installer functionality to PowerShell, providing means to query installed product and patch information and to query views on packages.
for example:
install-msiproduct .\example.msi -destination (join-path $env:ProgramFiles Example)
See this page for additional examples.
If you need to send keystrokes to the msi gui; you could look in to the Windows Automation Snapin for PowerShell. I have never used this personally.
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