So I have this code:
$userprofile=Get-ChildItem Env:USERPROFILE
$localpath="$userprofile\some\path"
I would expect output of the below from $localpath:
c:\users\username\some\path
However what I get is:
System.Collections.DictionaryEntry\some\path
So, of course, something like cd $localpath fails. How would I accomplish what I need?
A convenient way to obtain the string value rather than the dictionary entry (which is technically what Get-ChildItem is accessing) is to just use the variable syntax: $Env:USERPROFILE rather than Get-ChildItem Env:USERPROFILE.
$localpath = "$env:USERPROFILE\some\path"
For more information:
PowerShell Environment Provider
about_Environment_Variables
Also, the Join-Path cmdlet is a good way to combine two parts of a path.
$localpath = Join-Path $env:USERPROFILE 'some\path'
Related
I have a process where files containing data are generated in separate locations, saved to a networked location, and merged into a single file.
And the end of the process, I would like to check that all locations are present in that merged file, and notify me if not.
I am having a problem finding a way to identify that a string specific to each location isn't present, to be used in an if statement, but it doesn't seem to be identifying the string correctly?
I have tried :
get-childitem -filter *daily.csv.ready \\x.x.x.x\data\* -recurse | where-object {$_ -notin 'D,KPI,KPI,1,'}
I know it's probably easier to do nothing if it is present, and perform the warning action if not, but I'm curious if this can be done in the reverse.
Thank you,
As Doug Maurer points out, your command does not search through the content of the files output by the Get-ChildItem command, because what that cmdlet emits are System.IO.FileInfo (or, potentially, System.IO.DirectoryInfo) instances containing metadata about the matching files (directories) rather than their content.
In other words: the automatic $_ variable in your Where-Object command refers to an object describing a file rather than its content.
However, you can pipe System.IO.FileInfo instances to the Select-String cmdlet, which indeed searches the input files' content:
Get-ChildItem -Filter *daily.csv.ready \\x.x.x.x\data\* -Recurse |
Where-Object { $_ | Select-String -Quiet -NotMatch 'D,KPI,KPI,1,' }
We are trying to bulk update our Azure Active Directory. We have a excel csv list of UserPrincipalNames that we will update the Title, Department, and Office attributes
# Get List of Clinical CMs
$PATH = "C:\Users\cs\Documents\IT Stuff\Project\Azure AD Update\AD-Update-ClinicalCMs-Test.csv"
$CMs = Import-csv $PATH
# Pass CMs into Function
ForEach ($UPN in $CMs) {
# Do AD Update Task Here
Set-Msoluser -UserPrincipalName $UPN -Title "Case Manager" -Department "Clinical" -Office "Virtual"
}
The CSV:
User.1#domain.com
User.2#domain.com
User.3#domain.com
The Set-MsolUser command will work on its own, but it is not working as intended in this For loop. Any help or insight is greatly appreciated
As Jim Xu commented, here my comment as answer.
The input file you show us is not a CSV file, instead, it is a list of UPN values all on a separate line.
To read these values as string array, the easiest thing to is to use Get-Content:
$PATH = "C:\Users\cs\Documents\IT Stuff\Project\Azure AD Update\AD-Update-ClinicalCMs-Test.csv"
$CMs = Get-Content -Path $PATH
Of course, although massive overkill, it can be done using the Import-Csv cmdlet:
$CMs = (Import-Csv -Path $PATH -Header upn).upn
I have written a small user Interface with PowerShell in order to create checksums comfortable. At the moment I see a difference between using the ISE and the powershell itself.
When running the PowerShell script within the ISE I get perfect results.
This is the code I am using (Just a snippet):
$aaa = (Get-FileHash -Algorithm SHA512 -Path $str_filepath |
Select-Object -Property hash |
Format-Table -HideTableHeaders |
Out-string).TrimEnd().TrimStart()
So I create a checksum (SHA512) from a file. These are the results for one file as example:
Running the script in ISE:
0518E6DF62AB7B8D7A238039262C7A0E9F1F457D514EDE2BB8B3F4719340EF4B61053EC85ED30D07688B447DBC756F3A7455D7E0C84C7BCF62A8884E4715C8A0
Running the script in PowerShell:
0518E6DF62AB7B8D7A238039262C7A0E9F1F457D514EDE2BB8B3F4719340EF4B61053EC85ED30D07688B447DBC756F3A7455D7E0C84C7BCF62A8...
As you can see the string is shortend when using PowerShell. More confusing is that the shortening is not consistent. At home on my Windows 7 machine the string is even shorter then on my Windows 8.1 System at work. I know that there are some differences between ISE and PowerShell when running scripts regarding to styles. But shorter strings... Hmm.
So now the question. Does anyone of you have expierenced that difference between ISE and Powershell regarding to String length limitations? And if so. Does have anyone an answer for me how I can script it that there will be no different string results?
Do not use Format-* cmdlets if you need to process your data further. Those cmdlets are only for displaying data to a user. Instead expand the Hash property of the object Get-FileHash returns, either like this:
$str_checksum_sha512 = (Get-FileHash -Algorithm SHA512 -Path $str_filepath).Hash
or like this:
$str_checksum_sha512 = Get-FileHash -Algorithm SHA512 -Path $str_filepath |
Select-Object -Expand Hash
Problem:
Update a specific string within numerous configuration files that are found within the subfolders of a partial path using PowerShell.
Expanded Details:
I have multiple configuration files that need a specific string to be updated; however, I do not know the name of these files and must begin my search from a partial path. I must scan each file for the specific string. Then I must replace the old string with the new string, but I must make sure it saves the file with its original name and in the same location it was found. I must also be able to display the results of the script (number of files affected and their names/path). Lastly, this must all be done in PowerShell.
So far I have come up with the following on my own:
$old = "string1"
$new = "string2"
$configs = Get-ChildItem -Path C:\*\foldername\*.config -Recurse
$configs | %{(Get-Content $_) -Replace $old, $new | Set-Content $_FullName
When I run this, something seems to happen.
If the files are open, they will tell me that they were modified by another program.
However, nothing seems to have changed.
I have attempted various modifications of the below code as well. To my dismay, it only seems to be opening and saving each file rather than actually making the change I want to happen.
$configFiles = GCI -Path C:\*\Somefolder\*.config -Recurse
foreach ($config in $configFiles) {
(GC $config.PSPath) | ForEach-Object {
$_ -Replace "oldString", "newString"
} | Set-Content $config.PSPath)
}
To further exasperate the issue, all of my attempts to perform a simple search against the specified string seems to be posing me issues as well.
Discussing with several others, and based on what have learned via SO... the following code SHOULD return results:
GCI -Path C:\*\Somefolder\*.config -Recurse |
Select-String -Pattern "string" |
Select Name
However, nothing seems to happen. I do not know if I am missing something or if the code itself is wrong...
Some questions I have researched and tried that are similar can be found at the below links:
UPDATE:
It is possible that I am being thwarted by special characters such as
+ and /. For example, my string might be: "s+r/ng"
I have applied the escape character that PowerShell says to use, but it seems this is not helping either.
Replacing a text at specified line number of a file using powershell
Find and replacing strings in multiple files
PowerShell Script to Find and Replace for all Files with a Specific Extension
Powershell to replace text in multiple files stored in many folders
I will continue my research and continue making modifications. I'll be sure to notate anything that get's me to my goal or even a step closer. Thank you all in advance.
What is the benefit of using Join-Path to create a file path instead of just doing something like the following?
$Folder\$FileName
Join-Path benefits:
Uses the path-separator defined for the provider on which it's running
Supports more than just filesystems (Certificates, registry, etc)
Accepts multiple items to join.
Accepts credentials
Can resolve the result to a full path if it's relative
Accepts arguments from the pipeline without a Foreach-Object intermediary