Is there a way to continue using the name that begins with a space and splat that?
So this of course works:
$Splat = #{
name = 'chrome'
fileversioninfo = $true
}
(Get-Process #Splat)[0]
For me it returns:
ProductVersion FileVersion FileName
-------------- ----------- --------
84.0.4147.125 84.0.4147.125 C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Now, if I change the variable name to ' Chrome File Path and Version ' I get this:
${ Chrome File Path and Version } = #{
name = 'chrome'
fileversioninfo = $true
}
The variable is valid and returns the properties:
Name Value
---- -----
fileversioninfo True
name chrome
But trying to splat it, it thinks I am trying to create a hashtable because of the brackets:
At line:5 char:23
+ (Get-Process #{ Chrome File Path and Version })[0]
+ ~
Missing '=' operator after key in hash literal.
So my question is, anyone aware of a way to splat a variable that requires brackets around it?
I'm well aware a simple
$splat = ${ Chrome File Path and Version }
Would work, but the question isn't for a workaround, just if there's a way to splat variables with a space as the first character.
I've tried escape characters, single/double quotes, subexpressions and piping to drop the name in place but with no documentation on this, I'm pretty sure it's just not supported :/
Also, in case it matters, I am still on version 5.1.19041.1
Splatting is a method of passing a collection of parameter values to a command as a unit, it's supposed to make your commands shorter and easier to read.
Ok PowerShell provides a way to use special caracters in a variable name, but I don't Think it's a good practice, you should know it exists, you should not use it.
The simple fact it uses brakets interfer with the initialisation of hashtables in splatting. So as #Roman Kuzmin propose it's simply not supported
This is like you wish to have an Variablename like this: variable with space = 1; in other languages. This is not supported
Horribleness of the idea aside, splatting in PowerShell is currently quite limited, so an intermediate variable is the best way. There's a RFC draft which would improve splatting here, but its implementation isn't currently planned.
Related
I am using Get-WindowsAutopilotInfo to generate a computer's serial number and a hash code and export that info as a CSV.
Here is the code I usually use:
new-item "c:\Autopilot_Export" -type directory -force
Set-Location "C:\Autopilot_Export"
Get-WindowsAutopilotInfo.ps1 -OutputFile Autopilot_CSV.csv
Robocopy C:\Autopilot_Export \\Zapp\pc\Hash_Exports /copyall
This outputs a CSV file named "Autopilot_CSV.csv" to the C:\Autopilot_Export directory and then Robocopy copies it to the Network Share drive inside of the Hash_Exports folder listed above. In the above code, if I manually type in "test", "123", "ABC", etc. and replace "Autopilot_CSV" it will output a CSV under all of those names as well. So it looks like Get-WindowsAutopilotInfo will create a CSV file and save the file name with whatever string you pass into it. Great.
However, I am running this script on multiple different computers and I would like the exported CSV to be named something unique to the machine it is running on so I can easily identify it once it's copied. I am trying to pass the value of the environmental variable $env:computername as a string input for the CSV and it isn't working.
Here's the code I'm trying to use:
new-item "c:\Autopilot_Export" -type directory -force
Set-Location "C:\Autopilot_Export"
Get-WindowsAutopilotInfo.ps1 -OutputFile $env:computername.csv
Robocopy C:\Autopilot_Export C:\Users\danieln\Desktop /copyall
This code does not generate the CSV file at all. Why not?
Do I just have a basic misunderstanding of how environmental variables are used in Powershell? $env:computername appears to return a string of the computer's name, but I cannot pass it into Get-WindowsAutopilotInfo and have it save, but it will work if I manually type a string in as the input.
I have also tried setting it to a variable $computername = [string]$env:computername and just passing $computername in before the .CSV and that doesn't appear to work either. And per the docmentation, environmental variables are apparently already strings.
Am I missing something?
Thanks!
js2010's answer shows the effective solution: use "..."-quoting, i.e. an expandable string explicitly.
It is a good habit to form to use "..." explicitly around command arguments that are strings containing variable references (e.g. "$HOME/projects") or subexpressions (e.g., "./folder/$(Get-Date -Format yyyy-MM)")
While such compound string arguments generally do not require double-quoting[1] - because they are implicitly treated as if they were "..."-enclosed - in certain cases they do, and when they do is not obvious and therefore hard to remember:
This answer details the surprisingly complex rules, but here are two notable pitfalls if you do not use "...":
If a compound argument starts with a subexpression ($(...)), its output is passed as a separate argument; e.g. Write-Output $(Get-Location)/folder passes two arguments to Write-Output: the result of $(Get-Location) and literal /folder
If a compound argument starts with a variable reference and is followed by what syntactically looks like either (a) a property access (e.g., $PSVersionTable.PsVersion) or (b) a method call (e.g., $PSHome.Tolower()) it is executed as just that, i.e. as an expression (rather than being considered a variable reference followed by a literal part).
Aside #1: Such an argument then isn't necessarily a string, but whatever data type the property value or method-call return value happens to be.
Aside #2: A compound string that starts with a quoted string (whether single- or double-quoted) does not work, because the quoted string at the start is also considered an expression, like property access and method calls, so that what comes after is again passed as separate argument(s). Therefore, you can only have a compound strings consisting of a mix of quoted and unquoted substrings if the compound string starts with an unquoted substring or a non-expression variable reference.[2]
The latter is what happened in this case:
Unquoted $env:computername.csv was interpreted as an attempt to access a property named csv on the object stored in (environment) variable $env:computername, and since the [string] instance stored there has no csv property, the expression evaluated to $null.
By forcing PowerShell to interpret this value as an expandable string via "...", the usual interpolation rules apply, which means that the .csv is indeed treated as a literal (because property access requires use of $(...) in expandable strings).
[1] Quoting is required for strings that contain metacharacters such as spaces.
For values to be treated verbatim, '...' quoting is the better choice (see the bottom section of this answer for an overview of PowerShell string literals).
Also, using neither double- nor single-quoting and individually `-escaping metacharacters is another option (e.g. Write-Output C:\Program` Files.
[2] For instance, Write-Output a"b`t"'`c' and Write-Output $HOME"b`t"'`c' work as intended, whereas Write-Output "b`t"'`c' and Write-Output $HOME.Length"b`t"'`c' do not (the latter two each pass 3 arguments). The workaround is to either use a single "..." string with internal `-escaping as necessary (e.g. Write-Output "${HOME}b`t``c") or to use string-concatenation expression with + enclosed in (...) (e.g. Write-Output ($HOME + "b`t" + '`c'))
Doublequoting seems to work. The colon is special in powershell parameters.
echo hi | set-content "$env:computername.csv"
dir
Directory: C:\users\me\foo
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2/11/2021 1:02 PM 4 COMP001.csv
The colon is special. For example in switch parameters:
get-childitem -force:$true
Actually, it's trying to find a property named csv:
echo hi | Set-Content $env:COMPUTERNAME.length
dir
Directory: C:\Users\me\foo
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2/11/2021 3:04 PM 4 8
Basically pass it a string rather than the variable:
write-host $env:computername.csv
# output: (no output - looking for a variable called "computername.csv" instead of "computername")
Try the following syntax:
$filename = "$($env:computername).csv"
write-host $filename
# output: MYPCNAME.csv
I'm trying to make a user creation script for my company to make things more automated.
I want the script to take the Firstname + Lastname[0] to make the users logon name, but i can't get the syntax right,
I have tried writing {} and () but no luck there.
that's the original peace from my script
New-ADuser...........-UserPrincipalName $fname+$lname[0]
any tips?
Gabriel Luci's helpful answer provides an effective solution and helpful pointers, but it's worth digging deeper:
Your problem is that you're trying to pass expression $fname+$lname[0] as an argument, which requires enclosing (...):
New-ADuser ... -UserPrincipalName ($fname+$lname[0])
PowerShell has two distinct parsing modes, and when a command (such as New-ADUser) is called, PowerShell operates in argument mode, as opposed to expression mode.
Enclosing an argument in (...) forces a new parsing context, which in the case of $fname+$lname[0] causes it to be parsed in expression mode, which performs the desired string concatenation.
In argument mode, unquoted arguments are implicitly treated as if they were enclosed in "...", i.e., as expandable strings under the following circumstances:
If they don't start with (, #, $( or #(.
If they either do not start with a variable reference (e.g., $var) or do start with one, but are followed by other characters that are considered part of the same argument (e.g., $var+$otherVar).
Therefore, $fname+$lname[0] is evaluated as if "$fname+$lname[0]" had been passed:
The + become part of the resulting string.
Additionally, given that inside "..." you can only use variable references by themselves (e.g., $fname), not expressions (e.g., $lname[0]), $lname[0] won't work as intended either, because the [0] part is simply treated as a literal.
Embedding an expression (or a command or even multiple expressions or commands) in "..." requires enclosing it in $(...), the subexpression operator, as in Gabriel's answer.
For an overview of PowerShell's string expansion rules, see this answer.
The following examples use the Write-Output cmdlet to illustrate the different behaviors:
$fname = 'Jane'
$lname = 'Doe', 'Smith'
# WRONG: Same as: "$fname+$lname[0]", which
# * retains the "+"
# * expands array $lname to a space-separated list
# * treats "[0]" as a literal
PS> Write-Output -InputObject $fname+$lname[0]
Jane+Doe Smith[0]
# OK: Use an expression via (...)
PS> Write-Output -InputObject ($fname+$lname[0])
JaneDoe
# OK: Use an (implicit or explicit) expandable string.
PS> Write-Output -InputObject $fname$($lname[0]) # or: "$fname$($lname[0])"
JaneDoe
# OK: Use an intermediate variable:
PS> $userName = $fname + $lname[0]; Write-Output -InputObject $userName
Use a string for the UserPrincipalName, with the variables in the string:
New-ADuser -UserPrincipalName "$fname$($lname[0])"
PowerShell can usually figure out when you put a variable inside a string. When it can't, like in the case of $lname[0], you enclose it in $().
This is called "variable expansion" (other languages, like C#, call it "string interpolation"). Here's a good article that describes it in more detail: https://powershellexplained.com/2017-01-13-powershell-variable-substitution-in-strings/
i just saw the answers and a minute before i realized that i should actually set it up as another variable, $logon = $fname+lname[0]
and pass it as -userPrincipalName $logon.
Thanks for the help, you guy are the best!
I hava to add some environment to appPools? and i tried this code:
$Appcmd = [System.Environment]::SystemDirectory + "\inetsrv\appcmd.exe"
& $appcmd --% set config -section:system.applicationHost/applicationPools /+""[name='$Task.eProto_Pool'].environmentVariables.[name='PRODUCT_NAME',value='eProto']"" /commit:apphost"
but $Task in second line does not work, How can I past a variable to this string? I also tried %Task%
.eProto_Pool is a property of $Task. If you want to dereference (that is, retrieve one single property of an object) within a string, you need to wrap the string with $(), the subexpression operator in PowerShell.
For example, I'll make a new hashtable called $MyString that has two properties.
$MyString = #{Name = "Stephen";Value="CoolDude"}
>$MyString
Name Value
---- -----
Value CoolDude
Name Stephen
Look what happens if I try to reference it inside a string with regular string expansion. This is basically what you were doing in your example above. See how it fails to work as you would expect?
write-host " The user $MyString.Name is a $MyString.Value"
The user System.Collections.Hashtable.Name is a System.Collections.Hashtable.Value
Time to use the subexpression operator to save the day.
write-host " The user $($MyString.Name) is a $($MyString.Value)"
The user Stephen is a CoolDude
When in doubt, subexpression it out.
On second glance
I think it might be the percentage sign % which is causing you grief. This is a shorthand for the ForEach-Object command in PowerShell. Try this instead:
Invoke-expression "$appcmd --% set config -section:system.applicationHost/applicationPools /+`"`"[name='$($Task.eProto_Pool)'].environmentVariables.[name='PRODUCT_NAME',value='eProto']`"`" /commit:apphost`""
This should escape the strings like you need, and also pass the parameters in, like the eProto_Pool property of $Task.
I want to use splatting syntax, but I want to do it inline
So instead of:
$p = #{Path = '.'}
ls #p
I want to do
ls ##{Path = '.'}
but this is a syntax error.
Is there anyway to splat a hashtable without having to write a separate variable?
Why do I want to do this? I prefer the hashtable syntax for defining alot of parameters (like 4 or more). But I'd rather not define a variable, I just want to have the cmdlet I'm calling at the "top" of the hashtable definition.
The splat operator will look for a variable whose name matches the characters after the splat sign, it doesn't try to resolve the characters after the sign as a statement to get the value. You cant do it inline. Link to TechNet.
As Francois mentioned, this is not possible yet, however, there are some discussions taking place around adding expanded splatting functionality (including this feature specifically) in the PowerShell RFC repository on GitHub:
RFC: https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC0002-Generalized-Splatting.md
Discussion: https://github.com/PowerShell/PowerShell-RFC/issues/6
Is it possible to get PowerShell to always output / instead of \? For example, I'd like the output of get-location to be C:/Documents and Settings/Administrator.
Update
Thanks for the examples of using replace, but I was hoping for this to happen globally (e.g. tab completion, etc.). Based on Matt's observation that the separator is defined by System.IO.Path.DirectorySeparatorChar which appears in practice and from the documentation to be read-only, I'm guessing this isn't possible.
It's a good question. The underlying .NET framework surfaces this as System.IO.Path.DirectorySeparatorChar, and it's a read/write property, so I figured you could do this:
[IO.Path]::DirectorySeparatorChar = '/'
... and that appears to succeed, except if you then type this:
[IO.Path]::DirectorySeparatorChar
... it tells you that it's still '\'. It's like it's not "taking hold". Heck, I'm not even sure that PowerShell honours that particular value even if it was changing.
I thought I'd post this (at the risk of it not actually answering your question) in case it helps someone else find the real answer. I'm sure it would be something to do with that DirectorySeparatorChar field.
Replace "\" with "/".
PS C:\Users\dance2die> $path = "C:\Documents and Settings\Administrator"
PS C:\Users\dance2die> $path.Replace("\", "/")
C:/Documents and Settings/Administrator
You could create a filter (or function) that you can pipe your paths to:
PS C:\> filter replace-slash {$_ -replace "\\", "/"}
PS C:\> Get-Location | replace-slash
C:/