i tried harder to convert the case on the fly but it seems that powershell methods does not run for backrefence matches example below:
$a="string"
[regex]::replace( "$a",'(.)(.)',"$('$1'.toupper())$('$2'.tolower())" )
> string
$a -replace '(.)(.)',"$('${1}'.toupper())$('${2}'.tolower())"
> string
expected result
> StRiNg
don't know if it's possible or not
You need a script block to call the String class methods. You can effectively do what you want. For Windows PowerShell, you cannot do script block substitutions with the -replace operator. You can do that in PowerShell Core (v6+) though:
# Windows PowerShell
$a="string"
[regex]::Replace($a,'(.)(.)',{$args[0].Groups[1].Value.ToUpper()+$args[0].Groups[2].Value.ToLower()})
# PowerShell Core
$a="string"
$a -replace '(.)(.)',{$_.Groups[1].Value.ToUpper()+$_.Groups[2].Value.ToLower()}
Note that the script block substitution recognizes current MatchInfo object ($_). Using the Replace() method, the script block is passed in the MatchInfo object as an argument in the automatic variable $args unless you specify a param() block.
Related
I need to change the encoding of a file from UTF8-BOM to UTF8 different files where the date is different. I have a variable with the Data that I need but I have problems passing that variable to the Get-Content param.
$Today = Get-Date -Format "yyyyMMdd"
Get-Content 'D:\Folder_1\Test_file.'+$(${Today})+'.csv' | Set-Content -Encoding Ascii 'D:\Folder_2\Test_file.'+$(${Today})+'.csv'
The file names are "Test_file.20220923.csv" for example.
The error:
Get-Content : A positional parameter cannot be found that accepts argument '+20220923+.
'D:\Folder_1\Test_file.'+$(${Today})+'.csv' is an expression (a string concatenation via the + operator).
In order to pass an expression as an argument to a command, you must enclose it in (...), the grouping operator.[1]
Therefore (applies analogously to your Set-Content call):
Get-Content ('D:\Folder_1\Test_file.'+${Today}+'.csv')
Note that I've omitted the unnecessary use of $(...), the subexpression operator, which is typically only needed inside expandable (double-quoted) string ("..."), and then only for embedding expressions or commands (a variable reference such as $Today by itself can be embedded as-is).
The equivalent command using an expandable string:
Get-Content "D:\Folder_1\Test_file.${Today}.csv"
As for what you tried:
# WRONG: Passes *two* arguments.
Get-Content 'D:\Folder_1\Test_file.'+$(${Today})+'.csv'
Even though 'D:\Folder_1\Test_file.'+$(${Today})+'.csv' contains no spaces, PowerShell breaks this compound token into two arguments, verbatim D:\Folder_1\Test_file. and (for instance) verbatim +20220923+.csv.[2]
It is the latter, i.e. the extra positional argument causes Get-Content to report an error, because it only supports one positional argument (which binds to its -Path parameter).
[1] $(...) is often seen in practice instead, but $(...) is only ever needed in two cases: (a) to embed entire statement(s), notably loops and conditionals, in another statement, and (b) to embed an expression, command, or statement(s) inside "...", an expandable (interpolating) string. Just (...) is enough to pass a single command or expression as a command argument. While not likely, the unnecessary use of $(...) can have side effects - see this answer.
[2] In case you're wondering how a compound token such as 'D:\Folder_1\Test_file.'+${Today}+'.csv' is parsed and results in these two arguments, see this answer.
I'm writing a quick Powershell script to import modules and update some default parameters on various machines. I'm running into an issue where in my script when I add $PSDefaultParameterValues to the $profile it changes to System.Management.Automation.DefaultParameterDictionary which then throws an error of not being recognized as the name of a cmdlet.
Here is the code in my ps1 script
Add-Content -Path $PROFILE -Value "$PSDefaultParameterValues = #{}"
Here is what gets added to the profile
System.Management.Automation.DefaultParameterDictionary = #{}
I've tried everything from using Set-Content to using variables to avoid quotation confusion.
I appreciate the help!
Use single quotes
Add-Content -Path $PROFILE -Value '$PSDefaultParameterValues = #{}'
These are literal strings so any variables will not expand.
To add to tonypags' helpful answer:
Double-quoted PowerShell strings ("...") are expandable strings, i.e they perform string interpolation of embedded variable references (e.g. $PSDefaultParameterValues) and subexpressions (e.g. $(1 + 2))
Single-quoted strings ('...') are verbatim strings, i.e. their content is used as-is (verbatim, literally).
Thus, the automatic $PSDefaultParameterValues variable was expanded in your "..." string, which in essence means it was replaced with its .ToString() representation - which in this case is simply the type name of the variable's value.
If your entire string is meant to be used verbatim, use '...' quoting, as shown in tonypags' answer.
If you do need expansions (string interpolation), but need to selectively suppress them, escape $ characters as `$, using ` (a backtick), PowerShell's escape character, as shown in the following example:
$enc = 'utf8'
# Note the backtick (`) before $PSDefaultParameterValues.
# NOTE: It is only the *outer* quoting that determines
# whether expansion is performed.
Add-Content -Path $PROFILE `
-Value "`$PSDefaultParameterValues = #{ '*:Encoding' = '$enc' }"
As far as I know, there is no way in PowerShell to execute an exe with parameters specified in a variable and direct the return of the exe into a variable. Therefore I am currently writing a small function to make this possible. But now I am stuck at the point that the parameters have to be passed individually when calling with &. (This is not necessary for all programs, but some programs cause problems if you pass all parameters as a string in a variable) Therefore I want to use a split to write the parameters passed to my function into an array. And then pass the array with the parameters in my exe call.
For this I have the following regex:
[^\s"']+|"([^"]*)"|'([^']*)'
This regex allows that single and double quotes are taken into account when passing parameters and that a text with spaces inside them is not split.
But unfortunately I don't have the slightest idea how to best escape this regex so that it doesn't cause any problems in the PowerShell script.
Here then still my function to make it a little easier to understand:
The function executes the file passed in the $Path parameter with the parameters from the $Arguments. Before the execution i try to split the $Arguments with the regex. As return of the function, you get an object with the ExitCode and the output of the executed file. Here you can see my attempt, but the quotes cause problems with the following code.
function Invoke-Process ($Path,$Arguments){
[PsObject[]] $ReturnValue = #()
$Params=$Arguments -split([regex]::escape([^\s"']+|"([^"]*)"|'([^']*)'))
$ExCode = 0
try {
$ProcOutput = & $Path $Params | out-string
}catch{
$ProcOutput = "Failed: $($_.Exception.Message)"
$ExCode = 1
}
$ReturnValue += [PsObject]#{ ExitCode = $ExCode; Output = $ProcOutput}
Return $ReturnValue
}
The function is called as follows:
$ExePath = "C:\arcconf\arcconf.exe"
$ExeParams = "getconfig 1"
$Output = Invoke-Process $ExePath $ExeParams
I hope you can understand my problem. I am also open to other ways of writing the function.
Greetings
There's nothing you need to escape - the pattern is perfectly valid.
All you need is a string literal type that won't treat the quotation marks as special. For this, I would suggest a verbatim here-string:
#'
This is a single-line string ' that " can have all sorts of verbatim quotation marks
'#
The qualifiers for a here-string is #' as the last token on the preceding line and '# as the first token on the following line (for an expandable here-string, use #" and "#).
Try running it with valid sample input:
$pattern = #'
[^\s"']+|"([^"]*)"|'([^']*)'
'#
'getconfig 1 "some string" unescaped stuff 123' |Select-String $pattern -AllMatches |ForEach-Object {$_.Matches.Value}
Which, as expected, returns:
gesture
1
"some string"
unescaped
stuff
123
As an alternative to a here-string, the best alternative is a regular verbatim string literal. The only character you need to escape is ', and the escape sequence is simply two in a row '', so your source code becomes:
$pattern = '[^\s"'']+|"([^"]*)"|''([^'']*)'''
Mathias R. Jessen's helpful answer answers your immediate question well.
Taking a step back:
there is no way in PowerShell to execute an exe with parameters specified in a variable and direct the return of the exe into a variable
No: PowerShell does support both of those things:
$output = someExternalProgram ... captures the stdout output from an external program in variable $output; use redirection 2>&1 to also capture stderr output; use >$null or 2>$null to selectively discard stdout or stderr output - see this answer for details.
someExternalProgram $someVariable ... passes the value of variable $someVariable as an argument to an external program; if $someVariable is an array (collection) of values, each element is passed as a separate argument. Instead of a variable reference, you may also use the output from a command or expression, via (...); e.g., someExternalProgram (1 + 2) passes 3 as the argument - see this answer for details.
Note: An array's elements getting passed as individual arguments only happens for external programs by default; to PowerShell-native commands, arrays are passed as a whole, as a single argument - unless you explicitly use splatting, in which case you must pass #someVariable rather than $someVariable. For external programs, #someVariable is effectively the same as $someVariable. While array-based splatting also works for PowerShell-native commands, for passing positional arguments only, the typical and more robust and complete approach is to use hashtable-based splatting, where the target parameters are explicitly identified.
A general caveat that applies whether or not you use variables or literal values as arguments: Up to at least PowerShell 7.2.x, passing empty-string arguments or arguments with embedded " chars. to external programs is broken - see this answer.
With the above in mind you can rewrite your function as follows, which obviates the need for - ultimately brittle - regex parsing:
function Invoke-Process {
# Split the arguments into the executable name / path and all
# remaining arguments.
$exe, $passThruArgs = $args
try {
# Call the executable with the pass-through arguments.
# and capture its *stdout* output.
$output = & $exe #passThruArgs
$exitCode = $LASTEXITCODE # Save the process' exit code.
} catch {
# Note: Only If $exe is empty or isn't a valid executable name or path
# does a trappable statement-terminating error occur.
# By contrast, if the executable can be called in principle, NO
# trappable error occurs if the process exit code is nonzero.
$exitCode = 127 # Use a special exit code
$output = $_.ToString() # Use the exception message
}
# Construct and output a custom object containing
# the captured stdout output and the process' exit code.
[pscustomobject] #{
ExitCode = $exitCode
Output = $output
}
}
Sample calls:
Invoke-Process cmd /c 'echo hi!'
# Equivalent, using an array variable for the pass-through arguments.
$argsForCmd = '/c', 'echo hi!'
Invoke-Process cmd #argsForCmd
Note:
Since Invoke-Process is a PowerShell command,
splatting (#argsForCmd) is necessary here in order to pass the array
elements as individual arguments, which inside the function are then reflected in the automatic $args variable variable.
The automatic $args variable is only available in simple functions, as opposed to advanced ones, which behave like cmdlets and therefore automatically support additional features, such as common parameters; to make your function and advanced one, replace the line $exe, $passThruArgs = $args at the top of the function with the following:
[CmdletBinding()]
param(
[Parameter(Mandatory)]
[string] $exe,
[Parameter(ValueFromRemainingArguments)]
[string[]] $passThruArgs
)
Assume I have (In file test.ps1):
param (
[string[]] $one
)
Write-Host $one.Count
If I do:
powershell -File test.ps1 -one "hello","cat","Dog"
I get:
1
But I expect:
3
Why?
"-one" is getting passed in as a whole string as the converting happens before calling the method.
You could alternatively call it like the following
powershell -Command {.\test.ps1 -one "hello","cat","Dog"}
To complement Kevin Smith's helpful answer:
The only way to pass an array to a PowerShell script via the PowerShell CLI (powershell.exe; pwsh for PowerShell Core) is to use -Commmand (-c).
By contrast, -File interprets the arguments as literal values, and does not recognize arrays, variable references ($foo), ...; in the case at hand, the script ends up seeing a single string with literal contents hello,cat,Dog (due to double-quote removal).
From inside PowerShell:
Use -Command with a script block ({ ... }), as shown in Kevin's answer, which not only simplifies the syntax (just use regular syntax inside the block), but produces type-rich output (not just strings, as with other external programs), because the target PowerShell instance uses the CLIXML serialization format to output its results, which the calling session automatically deserializes, the same way that PowerShell remoting / background jobs work (as with the latter, however, the type fidelity of the deserialization is invariably limited; see this answer).
Note, however, that from within PowerShell you generally don't need the CLI, which creates a (costly) child process, and can just invoke a *.ps1 script file directly:
.\test.ps1 -one hello, cat, Dog
From outside PowerShell - typically cmd.exe / a batch file - use -Command with a single, double-quoted string containing the PowerShell code to execute, given that using script blocks isn't supported from the outside.
powershell -Command ".\test.ps1 -one hello, cat, Dog"
Note that, with -Command, just as with direct invocation inside PowerShell, you must use .\test.ps1 rather than just test.ps1 in order to execute a file by that name in the current directory, which is a security feature.
Also note that with your simple argument values, "..."-enclosing them is optional, which is why the commands above use just hello, cat, Dog instead of "hello", "cat", "Dog"; in fact, using embedded " chars. in an overall "..." command string can get quite tricky - see this answer.
Function Check-PC
{
$PC = Read-Host "PC Name"
If($PC -eq "exit"){EXIT}
Else{
Write-Host "Pinging $PC to confirm status..."
PING -n 1 $PC
}
This is a snippet of a function I have written into a PowerShell script. I would like the function to run in a new instance of PowerShell, not in the main window.
Is it possible to run this in a separate process of PowerShell without writing it as a separate script and calling the script? Something like this:
$x= Start-Process powershell | Check-PC
I need to keep everything in one script if possible.
Note: It is the involvement of Start-Process that complicates the solution significantly - see below. If powershell were invoked directly from PowerShell, you could safely pass a script block as follows:
powershell ${function:Check-PC} # !! Does NOT work with Start-Process
${function:Check-PC} is an instance of variable namespace notation: it returns the function's body as a script block ([scriptblock] instance); it is the more concise and faster equivalent of Get-Content Function:Check-PC.
If you needed to pass (positional-only) arguments to the script block, you'd have to append -Args, followed by the arguments as an array (,-separated).
Start-Process solution with an auxiliary self-deleting temporary file:
See the bottom half of this answer to a related question.
Start-Process solution with -EncodedCommand and Base64 encoding:
Start-Process powershell -args '-noprofile', '-noexit', '-EncodedCommand',
([Convert]::ToBase64String(
[Text.Encoding]::Unicode.GetBytes(
(Get-Command -Type Function Check-PC).Definition
)
))
The new powershell instance will not see your current session's definitions (unless they're defined in your profiles), so you must pass the body of your function to it (the source code to execute).
(Get-Command -Type Function Check-PC).Definition returns the body of your function definition as a string.
The string needs escaping, however, in order to be passed to the new Powershell process unmodified.
" instances embedded in the string are stripped, unless they are either represented as \" or tripled (""").
(\" rather than the usual `" is needed to escape double quotes in this case, because PowerShell expects \" when passing a command to the powershell.exe executable.)
Similarly, if the string as a whole or a double-quoted string inside the function body ends in (a non-empty run of) \, that \ would be interpreted as an escape character, so the \ must be doubled.Thanks, PetSerAl.
The most robust way to bypass these quoting (escaping) headaches is to use a Base64-encoded string in combination with the -EncodedCommand parameter:
[Convert]::ToBase64String() creates a Base64-encoded string from a [byte[]] array.
[Text.Encoding]::Unicode.GetBytes() converts the (internally UTF-16 -
"Unicode") string to a [byte[]] array.
Note: To also pass arguments, you have two options:
You can "bake" them into the -EncodedCommand argument, assuming you can call a command to pass them to there - see below, which shows how to define your function as such in the new session, so you can call it by name with arguments.Thanks, Abraham Zinala
The advantage of this approach is that you can pass named arguments this way. The disadvantage is that you are limited to arguments that have string-literal representations.
You can use the (currently undocumented) -EncodedArguments parameter, to which you must similarly pass a Base64-encoded string, albeit based on the CLIXML representation of the array of arguments to pass
The advantage of this approach is that you can pass a wider array of data types, within the limits of the type fidelity that CLIXML serialization can provide - see this answer; the disadvantage is that only positional arguments are supported this way (although you could work around that by passing a hashtable that the target code then uses for splatting with the ultimate target command).
Here's a simplified, self-contained example, which uses Write-Output to echo the (invariably positional) arguments received:
$command = 'Write-Output $args'
$argList = 'foo', 42
Start-Process powershell -args '-noprofile', '-noexit',
'-EncodedCommand',
([Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($command))),
'-EncodedArguments',
([Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes(
[System.Management.Automation.PSSerializer]::Serialize($argList)
)))
In case you want to pass the complete function, so it can be called by name in order to pass arguments as part of the command string, a little more work is needed.
# Simply wrapping the body in `function <name> { ... }` is enough.
$func = (Get-Command -Type Function Check-PC)
$wholeFuncDef = 'Function ' + $func.Name + " {`n" + $func.Definition + "`n}"
Start-Process powershell -args '-noprofile', '-noexit', '-EncodedCommand', `
([Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes("$wholeFuncDef; Check-PC")))
As stated above, you can "bake" any arguments to pass to your function - assuming they can be represented as string literals - into the -EncodedCommand argument, simply by appending them inside the "$wholeFuncDef; Check-PC" string above; e.g.,
"$wholeFuncDef; Check-PC -Foo Bar -Baz Quux"
Start-Process solution with regex-based escaping of the source code to pass:
PetSerAl suggests the following alternative, which uses a regex to perform the escaping.
The solution is more concise, but somewhat mind-bending:
Start-Process powershell -args '-noprofile', '-noexit', '-Command', `
('"' +
((Get-Command -Type Function Check-PC).Definition -replace '"|\\(?=\\*("|$))', '\$&') +
'"')
"|\\(?=\\*("|$)) matches every " instance and every nonempty run of \ chars. - character by character - that directly precedes a " char. or the very end of the string.
\\ is needed in the context of a regex to escape a single, literal \.
(?=\\*("|$)) is a positive look-ahead assertion that matches \ only if followed by " or the end of the string ($), either directly, or with further \ instances in between (\\*). Note that since assertions do not contribute to the match, the \ chars., if there are multiple ones, are still matched one by one.
\$& replaces each matched character with a \ followed by the character itself ($&) - see this answer for the constructs you can use in the replacement string of a -replace expression.
Enclosing the result in "..." ('"' + ... + '"') is needed to prevent whitespace normalization; without it, any run of more than one space char. and/or tab char. would be normalized to a single space, because the entire string wouldn't be recognized as a single argument.
Note that if you were to invoke powershell directly, PowerShell would generally automatically enclose the string in "..." behind the scenes, because it does so for arguments that contain whitespace when calling an external utility (a native command-line application), which is what powershell.exe is - unlike the Start-Process cmdlet.
PetSerAl points out that the automatic double-quoting mechanism is not quite that simple, however (the specific content of the string matters with respect to whether automatic double-quoting is applied), and that the specific behavior changed in v5, and again (slightly) in v6.