Is there any difference between running a Powershell script:
From the command line powershell.exe -File my_scipt.ps1
From Powershell ISE (Open the script in the editor and press the green play button to run)
From a Windows Powershell Host application?
And if there is a difference, is there a way in Powershell to check it?
The reason for asking this is that we are seeing one script have slightly different behaviour in these three environments, even though we had expected to see the same outcome. The behaviour is that a (3rd party non-public) .Net library we are using crashes in the second two environments, but works fine in the first one.
We have checked the obvious things, such as:
directory of the powershell process set the same (which we set via [System.IO.Directory]::SetCurrentDirectory($my_path) in the script)
Powershell and .Net version (confirmed via identical $PSVersionTable)
System path
My hope in asking this question is that there is some difference which we are unaware of, and that by identifying it we can resolve the crash we are seeing. I'd also be interested to hear of similar experiences from anyone here.
I'm running the tcl(which has expect script) using perl with,
system("C:/Tcl/bin/tclsh86 C:/Users/sysadmin/desktop/expect.tcl");
It's not executing the all commands in the script, but its working fine on ubuntu.
What command should i use to run this completely using perl on Windows?
On Unix Expect works using virtual terminals. By contrast, Expect on Windows uses the debugging subsystem. (There's nothing like virtual terminals on Windows.) This has the down-side that programs that are marked as being impossible to debug (i.e., some system programs, notably including telnet.exe though ftp.exe might also be on that list) cannot be automated by Expect at all. The OS just refuses to let Expect connect to the process.
Is this what is happening to you? I can't tell from the minimal information you've given, but it is by far the most common reason for problems with porting an Expect script between platforms (once you've taken into account mundane things like different paths and programs that just aren't there on all platforms).
The up-side is that both Tcl and Perl are quite capable of talking directly to anything that you'd use telnet or ftp to talk to (as both are entirely proficient at TCP/IP). In fact, both are probably better at doing it natively than anything you'd likely achieve through use of Expect.
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.
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 ;)