Open a powershell window from an existing powershell window, and keep it open after running code - powershell

I can open a powershell window from an existing one and provide it code to run here
But I can't get the second window to stay open once the code has run
Here's what I want to run in the first powershell window, and I would like the powershell window that opens to stay open after running the code (currently, it closes immediately)
start powershell { ECHO "hi" }
Note
I tried some suggestions here but not having any luck
Also, I got a fix (of sorts) using something like start powershell { ECHO "hi"; TIMEOUT 20 } but that's not going to keep the window permanently open

PowerShell -Command {Write-Host "Test" } -NoExit
from about Powershell. To start the Powershell in a new window you can use:
start-process powershell.exe -ArgumentList "-noExit", "-command","Write-host 'TEST'; Write-Host 'Test2'"
Important -Command must be the last parameter (about Powershell):
When the value of Command is a string, Command must be the last parameter specified because any characters typed after the command are interpreted as the command arguments.

Generally:
If you pass a command (-Command) or script file (-File) to execute to PowerShell's CLI (powershell.exe in Windows PowerShell, pwsh.exe in PowerShell [Core] v6+), PowerShell by default executes the command / script and then exits.
With a command or script specified for execution, you need to add the -NoExit switch if you want the new session to remain open.
Caveat: (Unless you call directly from within PowerShell with a script block), a positional argument - i.e., one neither preceded by -Command nor -File - is implicitly bound to:
-Command in Windows PowerShell
-File in PowerShell [Core] v6+.
Therefore, it's advisable to use the target parameter name explicitly.
With Start-Process (whose built-in alias on Windows - but not on Unix - is start):
Note: The primary use of Start-Process is to launch an independent process asynchronously in a new window. However, the latter isn't supported on Unix-like platforms, where Start-Process's utility is therefore limited.
start powershell { ECHO "hi" } happens to work from PowerShell (except that the window closes right after executing the command), but it's important to note that you cannot actually pass script blocks to Start-Process, only strings.
Start-Process accepts an executable name (implied -FilePath parameter), and an array of string arguments (implied -ArgumentList / -Args parameter).
If you pass a script block ({ ... }), it is automatically stringified, meaning that its literal string contents are used (stripped of the { and }) as the (only) -ArgumentList string value.
Thus, bypassing the unnecessary script-block creation, your command - with -NoExit applied as desired - should be (with explicitly named parameters; note that -Command and its argument must come last):
Start-Process -FilePath powershell -ArgumentList '-NoExit -Command ECHO "hi"'
Note:
While passing arguments individually, as an array to -ArgumentList is arguably conceptually cleaner, it is actually better to pass all arguments as a single string, using embedded quoting as necessary, due to a longstanding bug - see GitHub issue #5576.
Trying to open an interactive shell in a new window as a different user, via the -Credential parameter, is broken up to at least PowerShell 7.1, resulting in keyboard input getting blocked both in the new window and in the caller's window - see this answer for a workaround with runas.exe and GitHub issue #12129.

Related

Run powershell script as administrator via batch file with parameter passing

When I run the script, without an administrator, via batch file it passes the parameter, but when I run the script, as an administrator, it does not pass the parameter.
I'm trying the command in the link below, but with no success:
run-script-within-batch-file-with-parameters
Command that executes the script, as an administrator, via batch file:
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File "D:\z_Batchs e Scripts\Batchs\Normaliza_LUFS\ArqsNorms_LUFS_pass.ps1' '%_vLUF%' -Verb RunAs}"
The %_vLUF% is the parameter to be passed.
Error message:
No line:1 character:4
+ & {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolic ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Start-Process], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.StartProcessCommand
Command in powershell script to receive the parameter:
Param(
[decimal]$env:_vLUF
)
What could be wrong, the command in the batch file or in the powershell script?
Test:
When the script is executed, without being an administrator, via batch file and the Parameter in the powershell script is defined as:
Parameter in powershell:
Param(
[decimal]$env:_vLUF
)
Command in the batch file running the script without being an administrator:
powershell.exe -executionpolicy remotesigned -File "D:\z_Batchs e Scripts\Batchs\Normaliza_LUFS\ArqsNorms_LUFS_pass.ps1" %_vLUF%
Note:
No need to use a named argument with the target parameter name.
Result:
Conclusion:
When the script is running, without being an administrator, via a batch file it works correctly even if the parameter used in the script is defined as an environment parameter, eg: [decimal]$env:_vLUF and regardless of the parameter value being negative, eg : -11.0.
Why Powershell when running a script without being as an administrator correctly interprets the minus sign in the argument and when run as an administrator it does not interpret the minus sign correctly is a question I leave to the experts!
However, my question was very well answered by Mr. #mklement0.
Your .ps1 script's parameter declaration is flawed:
Param(
[decimal]$env:_vLUF # !! WRONG - don't use $env:
)
See the bottom section for more information.
It should be:
Param(
[decimal] $_vLUF # OK - regular PowerShell variable
)
Parameters in PowerShell are declared as regular variables, not as environment variables ($env:).
(While environment variables can be passed as an argument (parameter value), an alternative is to simply reference them by name directly in the body of your script.)
Your PowerShell CLI call has problems too, namely with quoting.
Try the following instead:
powershell -NoProfile -ExecutionPolicy Bypass -Command "Start-Process -Verb RunAs powershell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File \"D:\z_Batchs e Scripts\Batchs\Normaliza_LUFS\ArqsNorms_LUFS_pass.ps1\" -_vLUF %_vLUF%'"
Specifically:
Embedded " chars. must be escaped as \" (sic) when using the Windows PowerShell CLI (powershell.exe); however, given that %_vLUF% represents a [decimal], you needn't quote it at all.
However, you appear to have hit a bug that affects PowerShell versions up to at least 7.2.4 (current as of this writing): if the argument starts with -, such as in negative number -11.0, the -File CLI parameter invariably interprets it as a parameter name - even quoting doesn't help. See GitHub issue #17519.
The workaround, as used above is to use a named argument, i.e. to precede the value with the target parameter name: -_vLUF %_vLUF%
As an aside: There's no reason to use & { ... } in order to invoke code passed to PowerShell's CLI via the -Command (-c) parameter - just use ... directly, as shown above. Older versions of the CLI documentation erroneously suggested that & { ... } is required, but this has since been corrected.
As for the broken attempt to use [decimal]$env:_vLUF as a parameter declaration:
Param(
[decimal]$env:_vLUF # !! EFFECTIVELY IGNORED
)
is effectively ignored.
However, if an environment variable _vLUF happens to be defined, it is accessible in the body of a script, independently of which parameters, if any, have been passed.
In direct invocation of your .ps1 script from your batch file, _vLUF indeed exists as an environment variable, because in cmd.exe (the interpreter of batch files), variables are invariably also environment variables - unlike in PowerShell.
That is, if %_vLUF% has a value in your batch file, a powershell child process you launch from it automatically sees it as $env:_vLUF
By contrast, if you launch an elevated process via Start-Process from such a PowerShell child process, that new, elevated process does not see the caller's environment variables - by security-minded design.
Note:
That PowerShell even syntactically accepts [decimal]$env:_vLUF as a parameter declaration should be considered a bug.
What happens is that a regular variable named env:_vLUF is indeed created and bound, if an argument passed to it, but on trying to get the value of that variable in the body of your script, it is preempted by the environment variable.
As such, an invocation can break, namely if the parameter is type-constrained and you pass a value that cannot be converted to that type ([decimal] in the case at hand).
If the invocation doesn't break, the type constraint is ignored: $env:_vLUF is invariably of type [string], as all environment variables are.

Execute a PowerShell script within RunAs in a script

I have a need to run a PowerShell script as another user (the users will actually be doing the auth) based on detected environment. The script leverages a smartcard for login. The problem I have is when the PowerShell.exe instance launches from the runas, it simply prints my command and doesn't actually run it.
Note: The filepaths have spaces that get escaped with double-`, just not shown here hence the escaped ``' in the actual command. Have also used ```".
Example:
Start-Process runas.exe "/netonly /smartcard /user:domain\$env:USERNAME ""powershell.exe -noexit -Command `'&$filePath -arg1 -arg2`' "" "
or
Start-Process runas.exe "/netonly /smartcard /user:domain\$env:USERNAME ""powershell.exe -noexit -File `'$filePath -arg1 -arg2`' "" "
File path points to the same .ps1 file. The dir is similar to: C:\Users\Username\My Documents\script.ps1
When this runs I simply get a script window that doesn't actually run, it just prints the File name. I have also tried using -File but that simply crashes (regardless of -noexit). The runas bit works fine, I get my smartcard prompt etc its just the actual PowerShell launch that I am struggling with.
These work just fine calling them directly from PowerShell Cli but when in a .ps1 it just won't work.
Any help would be greatly appreciate.
There's generally no reason to use Start-Process to run a console application such as runas.exe - unless you explicitly want the application to run in a new window, asynchronously (by default) - see this answer for more information.
Eliminating Start-Process simplifies the quoting:
runas.exe /netonly /smartcard /user:domain\$env:USERNAME "powershell.exe -noexit -File \`"$filePath\`" -arg1 -arg2"
Note the - unfortunate - need to manually \-escape the embedded " chars. (`"), which is required up to at least v7.1 - see this answer.
As for what you tried:
On Windows, passing a '...'-enclosed string to the PowerShell CLI's -Command (-c) parameter from outside PowerShell (such as via runas.exe) causes it to be interpreted as a verbatim PowerShell string, printing its content as-is (except for whitespace normalization).
You can verify this by running the following from cmd.exe, for instance:
C:\>powershell -c 'Get-Date; whatever I type here is used as-is - almost'
Get-Date; whatever I type here is used as-is - almost
Note how the multiple spaces before the word almost were normalized to a single one.
The reason is that on Windows only double-quoting ("...") has syntactic function on the command line - ' characters are interpreted verbatim and therefore passed through.
Therefore, when the -Command (-c) argument sees its argument(s) -- after command-line parsing - and then interprets the resulting space-joined, possibly double-quote-stripped arguments as PowerShell source code, a span of '...' is interpreted as a verbatim PowerShell string, as usual (see the conceptual about_Quoting_Rules help topic, which discusses the types of PowerShell string literals).
In concrete terms:
'Get-Date; whatever I type here is used as-is - almost' is parsed by the PowerShell CLI as the following arguments(!):
'Get-Date;, whatever, I, type, here, is, used, as-is, -, almost' - note how any information about the amount of whitespace that originally separated these argument is lost in the process.
These arguments are then joined with a single space to form the string that PowerShell then interprets as PowerShell source code, which yields:
'Get-Date; whatever I type here is used as-is - almost'
This amounts to a verbatim (single-quoted) PowerShell string literal, whose content is then output as-is.

Powershell Elevated and pass a command

So I am building a script that launches an executable in the common files folder of x86 folder. The issue I am having is the script uses the (x86) as if the x86 is a command that should be run first. Does anyone have any ideas on how to prevent that?
$Pulse = "${env:CommonProgramFiles(x86)}\Pulse Secure\JamUI\JamCommand.exe"
$ImportFile = '"-importfile "C:\Program Files (x86)\MyFile.preconfig"'
Start-Process powershell -ArgumentList "-noexit", "-noprofile", "-command &{Start $Pulse, $ImportFile}" -Verb Runas
As Mathias notes, there is no strict need to launch another PowerShell instance with elevation (run as admin, -Verb RunAs), because you can directly elevate the target executable, JamCommand.exe; however, if you want to run the executable in another PowerShell session that stays open afterwards - as your use of -noexit suggests - you indeed do:
$pulse = "${env:CommonProgramFiles(x86)}\Pulse Secure\JamUI\JamCommand.exe"
$importFileArg = '-importfile "C:\Program Files (x86)\MyFile.preconfig"'
Start-Process -Verb RunAs powershell #"
-noexit -noprofile -c & "$pulse" $importFileArg
"#
Note:
This runs JamCommand.exe directly in the elevated PowerShell session, synchronously (assuming it is a console application), and the interactive session is only entered after that program exits. (Your attempt contains another Start-Process call (via alias Start), which would make a console program run in yet another console window, which auto-closes when the program exits.)
All pass-through arguments are encoded in a single (here)-string passed to the (positionally implied) -ArgumentList parameter, which allows direct control of the command line that is used to launch process, and is generally the most robust approach due to a long-standing bug in how passing arguments individually, as elements of an array is handled - see this answer.

Run Powershell commands sequentially in their own windows and prevent them from exiting

I want to run multiple Powershell commands sequentially in their own Powershell windows and do not want those windows to be closed after running.
Example:
Start-Process powershell {Write-Host "hello"}; Start-Process powershell
{Write-Host "hello"}; Start-Process powershell {Write-Host "hello"}
Powershell windows get closed right after running. I want them to remain open.
Edit: Multiple commands are not always same and they may vary in number.
# Asynchronously starts 3 new PowerShell windows that
# print "hello #<n>" to the console and stay open.
1..3 | ForEach-Object {
Start-Process powershell -Args '-noexit', '-command', "Write-Host 'hello #$_'"
}
-noexit is required to keep a PowerShell session open after executing a command with -command (run powershell.exe -? to see all CLI parameters)
Note how the arguments are specified individually, as ,-separated elements of an array that is passed to
-Args (short for -ArgumentList, though the parameter name can be omitted altogether in this case).
Note how the Write-Host command is passed as a string - script blocks aren't supported as such in this scenario; you can pass one, as you tried, but it will be quietly converted to a string, which simply means that its literal content is used (everything between { and }).
In other words: passing {Write-Host "hello"} is the same as 'Write-Host "hello"', but to avoid confusion you should pass a string.
You can only pass a script block as such if you invoke powershell.exe directly, not via Start-Process; you need Start-Process, however, to run the new session in a new window and to start it asynchronously.
Also, the string was changed to a double-quoted string ("...") with embedded single-quoting ('...') to ensure that the reference to $_ - the automatic variable representing the pipeline object at hand (1, 2, or 3) - is expanded (interpolated).
Using the pipeline (|) with an array of inputs (1..3, which evaluates to array 1, 2, 3) with the ForEach-Object cmdlet is just an example - you can still invoke the individual commands individually, one after the other, on individual lines, or separated with ; - thanks to Start-Process they'll still launch asynchronously.
However, if the individual commands share logic, the pipeline approach can simplify matters; you can put the shared logic in the body of the ForEach-Object call and pass the variable parts as input via the pipeline.
Put a read-host at the end of the command sequence - it will wait for you to input something before continuing execution (and presumably exiting?). To copy/paste the example in this link, you could anything like this which will pause execution until you enter something: $Age = Read-Host "Please enter your age" -> Ref: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/read-host?view=powershell-6

Call program from powershell.exe command and manipulate parameters

I'm trying to call an EXE file program that accepts command line parameters from PowerShell. One of the parameters I'm required to send is based on the string length of the parameters.
For example,
app.exe /param1:"SampleParam" /paramLen:"SampleParam".length
When I run the above, or for example:
notepad.exe "SampleParam".length
Notepad opens with the value 11 as expected.
I would like to achieve the same result when calling PowerShell from cmd / task scheduler.
For example,
powershell notepad.exe "SampleParam".length
But when I do that I get "SampleParam".length literally instead of the "SampleParam".length calculated value.
The expected result was:
running notepad.exe 11
Use the -Command parameter for powershell.exe:
powershell -Command "notepad.exe 'SampleParam'.length"
Be careful with the "'s since they can be picked up by the Windows command processor. This will also work:
powershell -Command notepad.exe 'SampleParam'.length
But this will not:
powershell -Command notepad.exe "SampleParam".length
I'd suggest using variables to store your string, etc.
$Arg1 = 'SampleParam'
## This will try to open a file named 11.txt
powershell notepad.exe $Arg1.Length
In your specific example:
app.exe /param1:$Arg1 /paramLen:$Arg1.Length
Utilizing splatting:
## Array literal for splatting
$AppArgs = #(
"/param1:$Arg1"
"/paramLen:$($Arg1.Length)"
)
app.exe #AppArgs