I have exported a registry directory that I would like to use in a PowerShell script. The .reg file contains two very long hex strings that I have been trying to use in Set-ItemProperty and New-ItemProperty, but neither have been successful. I keep getting errors whenever I run my script because PowerShell seems to have problems with the 'cc' hex values.
Things I have tried:
Assigning the hex values to a variable and using that in Set-ItemProperty and New-ItemProperty
New-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband" -Name "Favorites" -PropertyType BINARY -Value $favorites
Putting the hex values directly into the cmdlet with no formatting
Putting the hex value into the cmdlet with double and single quotes around them
Removing the old keys and creating new ones with-PropertyType Binary
Reg file: https://pastebin.com/rrAzMivQ
PS script: https://pastebin.com/NrQFr71w
Solved
I was able to get my script to work. Here is the final result if anyone is interested: https://pastebin.com/PW5Cjy0d
"The code is very long. Follow link."
Related
The following script maps a network drive with the new-psdrive command.
It uses get-content to load the contents of an XML file to a variable.
Truncated lines modify the XML object.
Then it uses the XML save method to save the file.
The script gives the error "Exception calling "Save" with "1" argument(s): "Could not find a part of the path 'M:\folder3\pems.xml'."
clear
Remove-PSDrive M
New-PSDrive -Name M -Root "\\server1\share\folder1\folder2\" -PSProvider FileSystem
$uncpath = "\\server1\share\folder1\folder2\"
$xmlfileDrive = "M:\folder3\pems.xml"
$xmlfileUNC = $uncpath+"folder3\pems.xml"
Get-ChildItem M:
Get-ChildItem $uncpath
#####Truncated code that manipulates $xmlfile
#####Calls outside executables that don't support UNC paths.
[xml]$scheme = Get-Content $xmlfileDrive
$scheme.Save($xmlfileDrive)
If I change the last line from
$scheme.Save($xmlfileDrive)
to
$scheme.Save($xmlfileUNC)
No error appears, and the script functions properly.
Note that the "Get-Content" command on the second to last line works properly regardless of which variable I use. And the "Get-ChildItem" commands give identical results.
Why would some commands recognize the mapped drive and others not?
I've tested this in both Powershell 5 and 7.
I fixed the problem by adding "-persist" to the "New-PSDrive" command. After that the save() method and all my external calls to executables recognized the drive.
As Mathias R Jesson stated, any commands that aren't native Powershell commands won't recognize the PSDrive object (unless -persist) is used.
i'm trying to use text that is inside the clipboard inside a powershell script. So what the purpose for the script, i want to be able to copy a file directory and then run the script so it uses the copied directory as a automatic destination. So my idea was to do something like this:
Copy-Item C:\Users\gif.gif -Destination "Copied Directory"
I'm very new to powershell scripting, so an explenation of what is going on would be nice but not needed. I origionlly thought that this could work but nope XD, this should have been a simple project but yeah it wasn't meant to be easy.
Copy-Item C:\Users\J.J\Documents\TouchPortal/Make_30fps_gif.bat -Destination | Get-Clipboard
Would love to get some help with this, and thank you in advance!
To complement Steven's helpful answer:
In Windows PowerShell only, you can use Get-Clipboard's -Format parameter to request clipboard data other than text.
In PowerShell [Core, v6+], this is no longer supported, and text is indeed the only data type supported by Get-Clipboard.
In Windows PowerShell, if you've used File Explorer to copy a directory to the clipboard (using the regular Copy shortcut-menu command or the Ctrl+C keyboard shortcut), you can access it as System.IO.DirectoryInfo instance by passing -Format FileDropList to Get-Clipboard.
Note: -Format FileDropList returns a collection of file-system-info objects, so as to also support multiple files/directories having been copied to the clipboard; thanks to member-access enumeration, however, you can treat this collection like a single object - assuming truly only one file or directory was copied.
# Note: Windows PowerShell only.
# The .FullName property returns the full directory path.
Copy-Item C:\Users\gif.gif -Destination (Get-Clipboard -Format FileDropList).FullName
In PowerShell [Core, v6+] you'll indeed have to use the Shift+right-click method and select Copy as path from the shortcut menu, in order to ensure that a file/directory is copied as a (double-quoted, full) path string, as shown in Steven's answer.
In PowerShell core including versions 6 & 7 Get-Clipboard only works with text. If you use it after copying a folder it will return null.
In PowerShell 5.1 (Windows PowerShell) you can use the -Format parameter with Get-Clipboard
See mklement0's answer for a better description and example using -Format.
If you need to use the newer versions, you can use the shift + context menu choice > Copy as Path to get the folder's string path on to the clipboard, but that will quote the path. The quoted path will then be rejected by Copy-Item.
However, you could quickly replace the quotes like below.
Copy-Item 'C:\temp\BaseFile.txt' -Destination (Get-Clipboard).Replace('"',"")
Caution though, this seems hazardous and I wouldn't advise it. I use Get-Clipboard all the time to get data into a console session and can attest that it's too easy to make mistakes. The clipboard is so transient and it's use so ubiquitous that even if you make this work it's bound to burn you at some point.
Maybe you can elaborate on what you're trying to do and why. Then we can brainstorm the best approach.
The boss changed TFS servers and added a space in the path: D:\TFS Agent\xxx and it's causing my powershell script to fail upon release.
We have build/release automatic integration with TFS and I have an inline powershell task to read a file and convert it to JSON then execute some SQL. I had this working until this morning.
The problem is that the agent path is a system variable in TFS: $(System.DefaultWorkingDirectory) and I'm not sure how to handle the space in the path.
I've tried this:
# Begin inline script
Param(
[string]$path,
[string]$db,
[string]$schema,
[string]$envName
)
# Create module
$formattedPath = $path -replace " ", "` ";
$conv = Get-Content -Raw -Path "$formattedPath" | ConvertFrom-Json;
But all I get is D:\TFS. The path looks like this before the replace:
D:\TFS Agent\_work\r3\a\xxx
I can't for the life of me figure out how to replace the space with a tick mark or how to ignore spaces. I'm very new to powershell so this may just be some simple thing, but my google-fu is not strong today. Any help would be appreciated. Thanks!
It seems you are pass $(System.DefaultWorkingDirectory) with the variable path as below:
-path $(System.DefaultWorkingDirectory)
While, if $(System.DefaultWorkingDirectory) contains spaces (such as D:\TFS Agent\_work\r3\a), it will show divided the values into different lines by spaces (such as D:\TFS Agent\_work\r3\a will show in two lines with value D:\TFS and Agent\_work\r3\a). So the variable $path with the value in the first line (like D:\TFS).
To solve the problem, you just need to add double quotes for $(System.DefaultWorkingDirectory). So just change the argument in PowerShell task as:
-path "$(System.DefaultWorkingDirectory)"
I am having trouble with a seemingly simple script I have which essentially copies an item from the user's PC and places it on another computer; however, the destination file path contains a space in it. I have tried multiple methods of correcting this issue (some I don't completely understand) from using double quotation marks around the string to forcing it to run powershell.
To give a very brief precursor to this situation, I must add that I initially created this script using Powershell on Windows 10 and I should also add that it works completely fine in Powershell, just not as a .bat. I understand there may be some differences in the languages or what is interpreted through the programs.
Here is the string in the question:
Copy-Item $ENV:USERPROFILE\Desktop\VAST.accdb -destination "\\PRECDP19670\C$\Users\WAKE\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup" -Force -PassThru -Verbose
The destination contains the space in the filepath.
Any help is appreciated!
As Bill mentioned, your BAT file needs to call PowerShell as an executable.
PowerShell.exe -command 'Copy-Item $ENV:USERPROFILE\Desktop\VAST.accdb -destination "\\PRECDP19670\C$\Users\WAKE\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup" -Force -PassThru -Verbose
I've tried searching around for this, and I can't find an answer, partially because it's difficult to search for the ">" character and also because the prompt in PowerShell uses that character.
I've got an example that works well, but I don't know what this line is doing exactly:
New-Item $tempCmd -Force -Type file > $null
I get the New-Item call and its parameters, but what is "> $null" doing exactly? And specifically what role does ">" play in this statement?
The > character does output redirection.
In an example it seems like it suppresses the output by redirecting it to null.
Microsoft has published a language specification for PowerShell 2.0 and PowerShell 3.0.
From version 3.0:
The redirection operator > takes the standard output from the pipeline and redirects it to the location designated by redirected-file-name, overwriting that location's current contents.
Your example has a null filename, so the output goes nowhere.
As nochkin says, people normally do this to stop a command from producing output. By default New-Item will output metadata about the new item to the host.
To acheive the same thing in a more readable way you can pipe the output to Out-Null.
New-Item $tempCmd -Force -Type file | Out-Null
From the documentation:
Deletes output instead of sending it down the pipeline.