3 ms·
The guy who implemented that really did a disservice to the filesystem metaphor, though. Instead of making values analogous to files, they're properties of reg
by 13of40 5y ago
The guy who implemented that really did a disservice to the filesystem metaphor, though. Instead of making values analogous to files, they're properties of registry keys, so instead of Get/Set-Content, Get-ChildItem, etc. you need to do some gymnastics with Get/Set-ItemProperty to work with them. For example, if you want to find a registry value with a particular name, you can't just do 'dir -rec SomeValueName' to find it like you can on the filesystem provider.
- naikrovek 5y agowell, the registry has types. files are raw binary data that is almost entirely untyped. how could they possibly enforce typed data without diverging from the filesystem metaphor?
- 13of40 5y agoCmdlets can have provider-specific parameters, so in this case I would add a registry-provider-specific data type parameter with sensible default behavior to New-Item and Set-Content. For example... Set-Content hklm:\software\xyz\abc -value 1 ...could create a DWORD value by default based on the type of the value argument, while adding '-DataType String' would enable creating a string value.
- jaclaz 5y agoFiles are raw binary data, but a (BTW unreliable) method to understand what they contain has been in use since years: file extensions. I can see no reason why in a filesystem-like representation of the Registry you cannot have a value.dwd (which is a DWORD), a value.bin (which is a BINary), value.esz, etc., or at least that is what I would use.