I've tried a few different solutions but haven't had any that work. I am not use to batch scripting, so this has been quite trivial for me.
Right now, I have a script in Linux that handles the execution of services in synchronous order. They depend on one another and require the other one to be completely started before they can be executed.
I am using the following line to deal with this:
grep -qi 'Service has started.\|error' <(tail -f "/opt/app/log/daemon.log")
Works great. However, this also needs to work in Windows. I've looked into using the GNU utils but I haven't really looked into their licensing, which could pose a problem. Plus, I would like to do this natively in the Windows CL.
Cheers,
Chris
P.S.
I am looking for a platform INDEPENDENT solution. Cygwin is not an answer.
You should use native Windows "dependency" of services upon one another. Use regedit.exe or sc.exe config to introduce dependencies. This way, you can leave the service startup as automatic and they will only start executing once all services this one is dependent upon has reported their condition as "started".
If you're wanting to do this natively in Windows, 'the Windows way', you'll want to be using the *-Service cmdlets (e.g. Get-Service, Stop-Service, Start-Service and Restart-Service) in PowerShell.
I'll admit, I'm not a linux user, but I assume that you checking the status of a service after starting it?
On Windows, in a PowerShell script, you'd want to do something like the following (I'm specifically picking on the Volume Shadow Copy service, because reasons):
Start-Service -Name VSS
While ((Get-Service -Name VSS).Status -ne 'Running') {
Start-Sleep -Seconds 2
}
# Start next service or continue with script here.
Apologies if this is well off base from what you're looking for. I'm just approaching this question as a Windows admin from the perspective of how I would achieve the goal.
Related
I need execute simply command in cmd.exe, for example:
ls -l
I care to read the result of executing this command, but I know I didn't Process library. Could you help me?
You can use so called "brokered components" to achieve this. This worked for Windows 8.1, I'm not 100% sure but think it still works for W10.
It's a little hacky. The reason is that it requires extra steps to get along with the security restrictions in Windows and therefore you need some additional projects and stuff
Here's a link to a blogpost on this:https://blogs.msdn.microsoft.com/mim/2014/06/24/create-a-winrt-brokered-component-feedback-from-a-real-life-developement/ You will find more details if you search for "brokered components".
You can see it in action in a video I recorded for YouTube some month ago: https://www.youtube.com/watch?v=3yiZBG6PQmY
I am trying to do my first script. To simply get PowerShell to pull up a script typed up in notepad and saved as a .ps1 file titled "test" (have also tried Script, but know names have nothing to do with it):
Write-Host "Hello, World!"
In PowerShell I am typing
& "C:\Scripts\test.ps1"
As well as
./test.ps1
And am only met with this:
./test.ps1.txt : The term './test.ps1.txt' is not recognized as the name of a
cmdlet, function, script file, or operable program. Check the spelling of the
name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ ./test.ps1.txt
+ ~~~~~~~~~~~~~~
+ CategoryInfo: ObjectNotFound: (./test.ps1.txt:String) [], CommandNotFoundException
Have tried renaming the file within PowerShell with
PS C:\Scripts> Rename-Item test.ps1.txt test.ps1
I have switched between RemoteSigned and Unrestricted, I have tried a code including executionpolicy bypass (I do apologize, I closed my window without writing that one down). As far as I know everything is up to date and I am running Windows 10, Windows PowerShell, and regular Windows Notepad.
First, I'd HIGHLY recommend using the Windows PowerShell ISE for writing scripts. It's free, and provides a pretty decent console/editor experience, given that it's free (there are allegedly better ones out there, but this has always done just fine for me). I use Visual Studio for other stuff, and while it is an EXPONENTIALLY better product (and should be), the PowerShell ISE is pretty feature-rich.
Next, if you're just getting started, you should check out Don Jone's "Learn PowerShell 3.0 in a Month of Lunches" book. It's two versions behind the most current, however, all of the information is still relevant, and once you've finished the book, you'll be able to seek help for anything else pretty easily on your own. It covers all the basics, and is a very good first step to learning the language.
Now, to answer your question: PowerShell scripts commonly have the .ps1 file extension. Other extensions are generally used for modules (.psm1) or other helper content that Windows PowerShell leverages. For most things, you'll stick to .ps1, and when you've reached a point where you start needing the other extensions, I suspect you will have no problems identifying which ones you need.
There are two ways generally call a PowerShell script. The first is from a normal command prompt, and telling PowerShell to execute your script. This is shown below:
powershell.exe -File MyScript.ps1
There are some additional parameters that I'd recommend you use, but usage is dependent on your requirements. Here's what I usually tag on mine:
powershell.exe -NoProfile -ExecutionPolicy RemoteSigned -File MyScript.ps1
This will tell the PowerShell process to ignore any PowerShell profiles you have set up, which is ideal if you have a bunch of stuff in your profile script that does things like read console input (for your current situation, I'm going to assume you don't, but you may in the future). The other is that ExecutionPolicy one: RemoteSigned will tell PowerShell to basically ignore anything that's been downloaded from the interwebs, but allow anything originating inside your network to run free. Probably not the best practice, but this isn't a TERRIBLE policy if you can trust that your script repository is secured. If not, then go for something tighter than this (you can read up on execution policies by typing "Get-Help about_Execution_Policies" in the PowerShell prompt, or by visiting the TechNet page about them -- the content should be similar if not identical).
The second way is from inside of a Windows PowerShell script. It's actually much easier to do. Note that you must set your execution policy to something that will allow scripts to run, but thereafter, you're smooth sailing.
. .\MyScript.ps1
This is called "dot-sourcing" your script. The advantage of doing this from within Windows PowerShell is that if you've got something like a script full of functions, they get added to the current scope (Get-Help about_Scopes), which means they're now available in your current session. A good example would be defining a function called "Test-DomainConnection" in a script you distribute with your main script: You'd dot-source the script that is distributed with the main one (this is done usually when you separate your "standard" PowerShell functions from your main script), and then use the functions in the main script. There are pros and cons to this approach, but it seems to be generally recommended (there may be some community extensions out there that remove the need to manage this manually).
For additional information, you can call Get-Help about_Scripts from inside Windows PowerShell. Because you're using Windows 10, you may need to run Update-Help from an administrative PowerShell window before the help content is available on your local system.
If you have any more questions, feel free to message me :) I've been doing PowerShell for a while and may be able to help out.
Powershell processes in order (top-down) so the function definition needs to be before the function call:
I'm actually interested as the question is stated, but what I'm after is a mechanism for temporarily disable the scheduled run (on multiple servers, whith shared disk), while still being able to run it interactively (if the script can be made to tell if it's started from task-scheduler or not). An external flag (the existence of a file) seemed like a simple approach to do that.
First option was using "%SESSIONNAME%" which seems to be empty when started from the scheduler, although that's also the case when started from powershell (with Start-Process, which might be an option for allowed usage while disabled).
EDIT: A second option, using the whoami cmd-command seems more promising, it reports the user as belonging to the group NT AUTHORITY\BATCH when run from task scheduler (but not when run interactively). Could I shoot myself in the foot using this - can a user be added to that group "permanently" behind my back?
We're on Windows Server 2012 R2. PowerShell solution would be interesting, as a wrapper could probably be used (or even modification/rewrite from .bat to .ps1).
Per #Alex K.: passing a separate argument to signal that we're running in a scheduled context works fine. Simple, reliable techniques that don't require you to know anything about third-party components -- in my neck of the woods we call those "wins" rather than "cheats".
If you really want, you can check for what you're literally asking -- if we're running from Task Scheduler -- by checking the properties of our parent process. From PowerShell this is quite doable, don't know about plain old batch files:
$parentpid = (gwmi "win32_process where (ProcessId = $pid)").parentprocessid
$parentname = (gwmi "win32_process where (ProcessId = $parentpid)").name
if ($parentname -eq 'taskeng.exe') {
"I think this is Task Scheduler, or maybe something else a hacker named taskeng.exe, who knows?"
} else {
"This is not Task Scheduler. Probably."
}
Of course, this might break if one day MS renames the process, or indeed if you want to use something else than TS to run the script automatically, or even if the script invokes another process which in turn invokes a script.
Personally, I would definitely go with the explicit flag. If you forget to apply it, it will be obvious, it can't suddenly break one day, and best of all, you can test if your script works correctly without actually having to schedule it first.
I need to create a GUI overlay that will provide status information to users while an install is taking place. The install happens through Powershell scripts. I would rather not rewrite the functionality that is already taking place in the scripts.
Are there any practical methods I can use to overlay a GUI over the scripts? I am thinking of something along the lines of an application installer that just calls the scripts and displays information about the status.
You can run PowerShell scripts from CSharp and interact with the PS runspace.
You can always wrap up these scripts in WinForms (PrimalForms Community Edition to design the UI) within PowerShell or use something like ShowUI (showui.codeplex.com).
Anything particularly wrong with using Write-Progress calls in your scripts?
I recently wrote an install cum config tool and this is what I did to run the PS scripts asynchronously from C#/Winforms - https://stackoverflow.com/a/10741061/763026 [Full code is there]
my goal: to create a suite of scripts that do some common system tasks, which include these
copy/move/list/search/grep files
watch/start/stop processes
run queries against Oracle via sqlplus
i grew accustomed to using Cygwin/bash to ease my life at work, and frankly speaking, i don't want to move away from bash language and start learning PowerShell, for example - so i started searching for a way to run bash scripts on Windows, ... preferably something alternative to Cygwin.
the truth is that i am still not pleased with Cygwin installation, and the fact that there is no simple way around it, that it is targeting more or less expert users, and there are a number of things that might pop up during the installation. i mean. what i am trying to do now is to write a suite of scripts that will target someone less expert than me (and i am in no way a real expert) - in most cases some kind of an administrator who doesn't want to know the script details.
i am thinking that this user will also want to be able to run these scripts on another machine, and i want to be able to explain him/her how to do it, without just saying, call the support, and, me, eventually (so that we can install cygwin on another machine etc etc.)
i tried MinGW(msys) but it also needs manual steps to set things up - i mean, these manual steps have become something of a de facto standard in these Windows ports (sorry, maybe i have a mood for bragging). win-bash looked like it could be a solution, but i ended up trashing it too, because of the old bash version, and its inability to do things i was able to do in cygwin - specifically
here documents
things like "cmd /C dir *" (don't know why) - and yes, i do cmd /C dir in cases i am in some kind of shared network folder with thousands of files, and ls is significantly slower than dir
my questions at last:
am i doomed to use PowerShell? i guess i will, reluctantly, if i have to
is there a simple pre-packaged "slim" cygwin installation.. or, portable cygwin, even better? there is a cygwin-portable project on sourceforge, but it's not that doesn't need those manual steps, again, apparently - is there a way to automate those steps, perhaps? and if there is, i wonder why somebody hasn't done it already? - and then, would it be possible to call bash scripts from Windows command prompt using a simple command like "bash somescript.sh"?
thanks for your attention.
As mentioned here, the Cygwin installation can totally be scripted and parametrized to ran in a silently and automatic mode.
If you define the minimal list of cygwin packages you need, just use a little .bat script that call the cygmin setup executable like this
setup.exe --packages=list_of_packages_you_need --quiet-mode
If you wrap the cygwin install process, it should be tolerable for a less technical user.
The cygwin install can be streamlined using command-line args;
http://sources.redhat.com/ml/cygwin-apps/2003-03/msg00526.html
You can also automate the install of most cygwin packages through cyg-apt.
I haven't verified this but I suspect that msys implements a *nix look alike by creating windows executable versions of system commands. All of the common commands have an executable on my install of msys. If that is true then it should be possible to use them separate from a complete install.
Try copying "bash.exe", "cp.exe", etc. from the msys bin directory to a machine/vm that does not have an msys install and see if it works. You may need to copy some dll's or shared libraries as well. A windows dependency checker program would show which dll's an executable is using.
You could package up the stuff you use and make a simple installer or just copy the files with your scripts.
Take a look at MKS Toolkit. Unlike Cygwin, it can live within the Windows world. Files end in CR/LF like Windows files, and you don't have that /cygdrive/c stuff. Naked drive letters work fine in MKS Toolkit.
A few caveats:
I haven't used MKS Toolkit in a long time. See following reason.
MKS Toolkit is (sit down for this) $600 per license. Ouch! That's why I use Cygwin even though I don't think it's as good or works as well.
It's Kornshell based and not Bash (although this may be a bit different). Kornshell and BASH are 95% alike. However, that last 5% gets you. I actually like Kornshell better than BASH in many respects. Kornshell has the print statement which is way superior than the echo statement. Variable names don't disappear in blocks. You can easily do double loops because almost all the commands can take unit numbers of input and output. However, Kornshell doesn't have those neat escape characters in the prompt, and it's hard to find the exit status of a command in the middle of the pipeline.