so I have two .ps1 scripts that check for new Tasks every 60 seconds and I want to run them at the same time. I use them every day and starting them gets a little annoying.
Ideally, I want to write a script that I can run that runs those two for me.
The Problem is that as they don't stop at some point, I can't just start them one after the other and I can't find a command to open a new PS ISE instance. However, one instance can't run both scripts at the same time. The Ctrl+T Option would be perfect, but I can't find the equivalent command.
Does anyone have an idea on how to solve this?
Thanks!
I think what you want is something like
Start-Process Powershell.exe -Argumentlist "-file C:\myscript.ps1"
Start-Process Powershell.exe -Argumentlist "-file C:\myscript2.ps1"
In addition to that: Use Import-Module $Modulepath inside the scripts to ensure the availability of the modules.
If you have Powershell 3.0+ you could use workflows. they are similar to functions, but have the advantage that you can run commands parallel.
so your workflow would be something like this:
workflow RunScripts {
parallel {
InlineScript { C:\myscript.ps1 }
InlineScript { C:\myotherscript.ps1 }
}
}
keep in mind that a workflow behaves like a function. so it needs to be loaded into the cache first, and then called by running the RunScripts command.
more information:
https://blogs.technet.microsoft.com/heyscriptingguy/2013/01/09/powershell-workflows-nesting/
Use CTRL+T to create a new powershell instance (a tab is created, which is called powershell 2, I believe) inside Powershell ISE.
From the new Powershell tab you can now open a second powershell script and run it aside the script running in other powershell tabs.
Related
To preface this, I am self teaching and brand new to scripting in general, let alone powershell.
After a cumulative 12 hours, my Google fu has run out.
I had a series of programs tailored to different models of computer we support that ran a staged series of installers from a fileshare. The program would check to see if the tech deploying the software was running it as admin, if not, it used a Start-Process line to elevate and run again.
It worked flawlessly, but we wanted to see if we could remove the need for the tech to enter r to run the scripts from the share.
In trying to figure out how to add -executionpolicy bypass to the arg list for Start-Process, I've hit a wall.
It now errors on trying to call to the fileshare to retrieve the parent script, before getting to the point where I can troubleshoot the bypass can of worms.
Below is my rough framework, remember I'm self taught by googling and using tutorials point.
$principal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
if($principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
{
#usually I have a get-childitem | foreach-object loop here that runs the files from the folder one by one in a specific order,
#it also checks to see if msiexec is running or not before trying to load and install files using a if-else>do-while combo
}
else
{
Start-Process -FilePath "powershell" -ArgumentList "$('-File "\\server\dir\foo".ps1')$($MyInvocation.MyCommand.Name)$('""')" -Verb runAs
}#this calls to a script that is a 1:1 copy of the code in the if{} block
This returns an error from the -File parameter that says it can't call the file because it doesn't exist.
What am I doing wrong?
How do I pass -executionpolicy bypass as an additional arg without breaking it further?
Is there a better way to do this?
Is there a neater way to automate this?
Please help me geniuses of StackOverflow before I start gnawing on my keyboard.
I'm experiencing a weird scenario where I want to open a .rdp file and get its Process ID on a Jenkins Pipeline.
My PowerShell Script (which based from this answer):
$app = Start-Process "$env:windir\system32\mstsc.exe" -ArgumentList "C:\Users\AzureUser\Desktop\MyRDP.rdp /h:900 /w:1600" -WindowStyle Minimized -PassThru
Write-Host $app.id
When I ran this on PowerShell it works as expected. However, when I tried to execute this script on a Jenkins Pipeline, it opens the .rdp file but returns a different process ID.
Here's the screenshot of the result.
I also tried enclosing it in an Invoke-Command to make sure that it runs on a 64-bit Powershell but it did not change a thing.
I'm wondering what might be the other possible cause of this. Any help is going to be appreciated. :)
The solution is just simple. I will post my answer anyway incase anyone might encounter the same problem I have. You just need to make sure that Jenkins runs on 64-bit. That's all and worked like a charm.
I am trying to run and .exe in C:programfiles(x86)
I can launch it directly from the filepath. If I run in powershell just closes. No feedback.
Running powershell 5.1.17134 Rev 590
Start-Process -FilePath "C:\Program Files (x86)\App\App.exe"
I tried running powershell -NoExit and then start-process but it returns without any feedback.
If I run it on same machine in Powershell 6.1.0 preview - it runs fine. No issue. How can I track down whats causing this to 1) not run 2)close powershell.
Thanks,
This answer makes a general point. It doesn't solve your problem, if using Start-Process truly crashes the calling PowerShell window.
If C:\Program Files (x86)\App\App.exe is a console application that you want to run in the current console window, do not use Start-Process to invoke it.
Instead, invoke it directly.
Given that its path contains spaces and special characters (( and )), you need to:
quote it
invoke it with &, PowerShell's call operator.
PS> & 'C:\Program Files (x86)\App\App.exe'
Note:
The use of & with a command specified in a quoted string and/or via a variable reference is a syntactic necessity, given that PowerShell has two distinct parsing modes - see about_Parsing.
Invoking a console application directly:
ensures its synchronous execution
That is, control isn't returned to the caller until the application has terminated.
connects its standard output streams - stdout and stderr - to the equivalent PowerShell streams.
That is, you can capture or redirect the application's success output and/or error output, as needed.
You have an interactive shell. You spawn this new process - then your shell closes?
Clearly it is terminating its parent process, and clearly pwsh is doing something different.
I don't think this is truly a powershell question, it's a windows internals one. The suite of tools to use is Sysinternals. The first thing I'd try - and I'd do this on cmd, powershell and pwsh to establish a basis for comparison - is run Process Monitor with a filter on your app's path. Something in its last actions may prove illuminating. Process Explorer may also be useful.
Are you in a corporate environment? I have agents on my machine that kill processes based on heuristics. That can do things like this.
There may be a workaround based on how you invoke the app;
try mklement0's suggestion
try invoking through WMI; this does not provide your powershell process as a parent process: Invoke-WmiMethod -Class win32_process -Name create -ArgumentList "PathToApp.exe"
try invoking via cmd.exe if you are constrained by what's on your target machines
I do think this is off-topic, though.
I'm using a Powershell script to perform some automated testing on a web application.
Part of this script runs a small, separate script which basically monitors the web app for pop ups and closes them if they appear. It is called during the main script like so:
Start-Process Powershell.exe -Argumentlist "-file C:\Users\Documents\Monitor.ps1"
At some point though I would like to close the monitor script, perform some commands, and then start the monitor script again.
Is there a way for me to kill the monitor script from the main, without closing the main script as well in the process?
You would want to save it to a variable:
$a = start-process notepad.exe -PassThru
$a.Id
10536
So you could later kill it.
I'm using PowerShell v3.0 to start a new cmd.exe process, in which I then load up the Visual Studio Command Prompt to perform a build, like so:
Start-Process cmd.exe -ArgumentList $cmdArgumentsToRunMsBuildInVsCommandPrompt -WindowStyle $windowStyle -Wait
This works, and it opens a new command prompt window and I can see the build happen, and then when the build is finished the command prompt window closes. I would like to be able to get the text that is written to the command prompt window and store it in a variable, in order to inspect if the build passed or not. I tried using this, but it doesn't work; the $buildOutput variable is empty:
Start-Process cmd.exe -ArgumentList $cmdArgumentsToRunMsBuildInVsCommandPrompt -WindowStyle $windowStyle -Wait -OutVariable buildOutput
Write-Host "Build output = $buildOutput"
This makes sense since the cmd.exe process isn't returning any text; it is just writing it to it's own window. Is there a way for me to be able to store that text in a variable for the original powershell script to use? I know that I can provide a parameter to MsBuild to have it write the build log to a file, but I'm looking for a solution that doesn't involve writing to a log file and having to delete it later.
Any suggestions are appreciated. Thanks!
<# EDIT #>
Thanks for all of the responses so far! A popular suggestion has been to just call MsBuild.exe directly without using cmd.exe. The reason I need to go through cmd.exe is some projects don't build successfully if called directly from MsBuild.exe (e.g. XNA projects). Instead I need to call MsBuild.exe from the Visual Studio Command Prompt so that (I assume) all of the required environmental variables are set. I guess I could just call the VS Command Prompt directly, but it will have the same problem as calling cmd.exe too. If I can't find the VS Command Prompt I fallback to calling MsBuild.exe directly, so those answers are still appreciated.
You can always capture the output of console programs this way:
$output = [string](nuget.exe)
Here I used nuget ($output will contain the available commands list), but you can of course use msbuild.exe with the appropriate arguments.
I've solved my problem using a suggestion from the first comment on my question, which was to write the build output to a log file, consume it, then delete it. This allows me to still show the user the cmd window with the build progress if they need, as well inspect the build output once the build completes. It also still allows me to run the build in another process, so we can use PassThru if we don't want our script to wait for the build to complete before continuing execution.
I've created an Invoke-MsBuild powershell module to make building with MsBuild a snap while providing lots of parameters for additional functionality (returns if build succeeded or failed, can show/hide build window, can wait/not wait for build to finish, can automatically show build log on failed builds, etc.). You can view and download the script from my blog.
$process = New-Object System.Diagnostics.Process;
$process.StartInfo.UseShellExecute = $false;
$process.StartInfo.RedirectStandardOutput = $true;
$process.StartInfo.FileName = "cmd.exe";
$process.StartInfo.Arguments = $cmdArgumentsToRunMsBuildInVsCommandPrompt;
$process.Start();
$outputStream = $process.StandardOutput;
$outputStream.ReadToEnd();
You could also redirect StandardError.
edit: I ended up using #David Brabant's answer
I ran into this problem and created an echo function
function echo()
{
$input
}
which let me do this
$output = &"cmd.exe" $args | echo