This repository was archived by the owner on Mar 5, 2025. It is now read-only.
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
Add Edit-File command #19
Open
Description
I would really love to see this command added. PS has been missing an easy way to modify files since v1. This comes in so handy for build systems. Our builds, first thing, edit a number of files to modify version numbers using this command e.g.:
# Update C# interop assembly version
Edit-FileContent -Path (Join-Path $rootPath 'src/Adapters/Acme.Wiley.Coyote.Api/Acme.Wiley.Coyote.Api.csproj') `
-Pattern '(?<=\<Version\>)(.*?)(?=\</Version\>)' `
-Replacement "${wileyVersion}.0"
Edit-FileContent -Path (Join-Path $rootPath 'src/Adapters/Acme.Wiley.Coyote.Api/Acme.Wiley.Coyote.Api.csproj') `
-Pattern '(?<=\<InformationalVersion\>)(.*?)(?=\</InformationalVersion\>)' `
-Replacement "${wileyVersion}${suffix}"
# WileyClient Conan C++ Support
Edit-FileContent -Path (Join-Path $rootPath 'src/WileyClient/conanfile.py') `
-Pattern '(?<= version\s*=\s*'')(.*?)(?='')' `
-Replacement "${wileyVersion}${suffix}"
# WileyManagement Conan C++ Support
Edit-FileContent -Path (Join-Path $rootPath 'src/WileyManagement/conanfile.py') `
-Pattern '(?<= version\s*=\s*'')(.*?)(?='')' `
-Replacement "${wileyVersion}${suffix}"
Edit-FileContent -Path (Join-Path $rootPath 'src/WileyManagement/conanfile.py') `
-Pattern '(?<=WileyClient/)(.*?)(?=@Acme)' `
-Replacement "${wileyVersion}${suffix}"
# NuGet C# Support
Edit-FileContent -Path (Join-Path $rootPath 'build/NuGet/WileyClientPkg/Acme.Wiley.Coyote.Api.nuspec') `
-Pattern '(?<=\<version\>)(.*?)(?=\</version\>)' `
-Replacement "${wileyVersion}${suffix}"
Edit-FileContent -Path (Join-Path $rootPath 'build/NuGet/WileyClientPkg/Acme.Wiley.Coyote.Api.nuspec') `
-Pattern '(?<=id="runtime\.native\.Acme\.Wiley\.Coyote\.Api"\s+version=")(.*?)(?=")' `
-Replacement "${wileyVersion}${suffix}"
Edit-FileContent -Path (Join-Path $rootPath 'build/NuGet/runtime.native.WileyClientPkg/runtime.native.Acme.Wiley.Coyote.Api.nuspec') `
-Pattern '(?<=\<version\>)(.*?)(?=\</version\>)' `
-Replacement "${wileyVersion}${suffix}"
# API Help Docs
$regexForHelpDocs = if ($Final) { '(?<== ")(\d)(.\d)*-?.* PRELIMINARY(?=")' } else { '(?<== ")(\d)(.\d)*-?.*(?= PRELIMINARY")' }
Edit-FileContent -Path (Join-Path $rootPath 'doc/CppReference/wiley-cpp-doxyfile') `
-Pattern $regexForHelpDocs `
-Replacement "${wileyVersion}${suffix}"
And here's the implementation - feel free to use as much (or little) as you want. https://github.com/Pscx/Pscx/blob/master/Src/Pscx/Commands/IO/EditFileCommand.cs
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Participants
Activity
rkeithhill commentedon Nov 25, 2020
OK, I'm taking a swag at importing the PSCX EditFileCommand.cs. Hopefully will have a PR soon-ish.
SteveL-MSFT commentedon Nov 25, 2020
Should it just be
Edit-Contentto match the other*-Contentcmdlets? It could accept text via pipeline and also allow editing?AdilHindistan commentedon Nov 25, 2020
I needed this once or twice and used something like (gc {file}) -replace {pattern}, {replacement} | out-file ...to do that. This would be a nice shortcut.
rkeithhill commentedon Nov 25, 2020
I'm fine with
Edit-Content. The main thing we were trying to avoid is this approach:Where you have the file locking problem (trying to write to file while reading it) as well as this doesn't preserve the file's original encoding which should be a goal of this command. Anway, the above pattern is common enough to warrant a simpler form:
rkeithhill commentedon Nov 25, 2020
Hmm, the PSCX implementation has an elaborate way of supporting Path/LiteralPath that won't port over. @SteveL-MSFT is there a canonical sample of Path/LiteralPath C# code I can use?
SteveL-MSFT commentedon Nov 25, 2020
@rkeithhill check https://github.com/PowerShell/PowerShell/blob/15e4e8a6af2f120bbd1eef8607131d878677c0ad/src/Microsoft.PowerShell.Commands.Management/commands/management/ContentCommandBase.cs#L35-L44
rkeithhill commentedon Nov 26, 2020
@SteveL-MSFT Do you think this cmdlet should derive from
ContentCommandBase? If not, I can't quite use that code as-is since it calls down into a base class to suppress wildcard expansion. And if yes, won't that require-Includeand-Filterparameters which wouldn't make so much sense for this cmdlet.To be honest, the implementation of the functionality isn't too bad but dealing with Path/LiteralPath parameters has been such a PITA that @oising added easier handling for these parameters in PSCX in the form of
PscxPathInfo(see https://github.com/Pscx/Pscx/blob/master/Src/Pscx.Core/Commands/PscxPathCommandBase.cs)SteveL-MSFT commentedon Nov 26, 2020
@rkeithhill sorry, pointed you to the wrong thing. Perhaps do something similar to https://github.com/PowerShell/PowerShellGet/blob/f1ddcb3bc602c61f9b98f79b1ab02b00331da8f5/src/code/PublishPSResource.cs#L95
rkeithhill commentedon Dec 5, 2020
@SteveL-MSFT Thanks. That got me past the Path/LiteralPath parameter issue. I have something that compiles and runs. However, I had to copy over some crufty PSCX code for the Encoding parameter (to do string conversion, checks, etc). I'm hopeful I can find some more modern and hopefully SMA built-in support. Do you have any pointers for that? I could submit a PR now but ... I'd rather have better Encoding parameter support implemented first.
FYI the command's default behavior is to try to preserve the file's original encoding so the
-Encodingparameter isn't normally needed unless you also want to change the file's encoding.rkeithhill commentedon Dec 7, 2020
@SteveL-MSFT OK found some code in Out-File.cs but ... the Encoding parameter support required me to copy a number of
internalclasses. Sigh... In order to support "easier to write", "more consistent & correcrt" parameter handling in C# cmdlets (and even script cmdlets), more of these "internal" classes need to be made public.FWIW I'm not a big fan of how some of this is implemented e.g. deriving from ContentCommandBase.cs to get Path/LiteralPath handling. We did something similar in PSCX and when it worked it was nice but there were a number of cases where it didn't work. So, the answer probably isn't to just make existing internal classes public. It would be better to provide "parameter implementations" that folks can use & configure via attributes (or interfaces). Two very good parameters to start with would be
PathandLiteralPath.Anyway, I should have an initial WIP PR out in a few days.
SteveL-MSFT commentedon Jul 25, 2023
We may choose to include Jim's version and call it
Edit-TextFileas there have been asks to edit other file types.gwojan commentedon Aug 9, 2024
@SteveL-MSFT is there any status on this being included? Other than Jim's brief demo during one of the PowerShell Community calls I seem to have lost track of this.