You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
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.:
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.
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:
Hmm, the PSCX implementation has an elaborate way of supporting Path/LiteralPath that won't port over. Steve Lee (@SteveL-MSFT) is there a canonical sample of Path/LiteralPath C# code I can use?
Steve Lee (@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 -Include and -Filter parameters which wouldn't make so much sense for this cmdlet.
Steve Lee (@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 -Encoding parameter isn't normally needed unless you also want to change the file's encoding.
Steve Lee (@SteveL-MSFT) OK found some code in Out-File.cs but ... the Encoding parameter support required me to copy a number of internal classes. 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 Path and LiteralPath.
Anyway, I should have an initial WIP PR out in a few days.
We may choose to include Jim's version and call it Edit-TextFile as there have been asks to edit other file types.
Steve Lee (@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.
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. Steve Lee (@SteveL-MSFT) is there a canonical sample of Path/LiteralPath C# code I can use?
SteveL-MSFT commentedon Nov 25, 2020
Keith Hill (@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
Steve Lee (@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 Oisin Grehan (@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
Keith Hill (@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
Steve Lee (@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
Steve Lee (@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
Steve Lee (@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.