OK, I'm taking a swag at importing the PSCX EditFileCommand.cs. Hopefully will have a PR soon-ish.

Should it just be Edit-Content to match the other *-Content cmdlets? It could accept text via pipeline and also allow editing?

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.

I'm fine with Edit-Content. The main thing we were trying to avoid is this approach:

Get-Content foo.csproj | % { $_ -replace $pattern,$replacement } | Set-Content foo.csproj

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:

Edit-Content foo.csproj $pattern $replacement

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?

@rkeithhill check https://github.com/PowerShell/PowerShell/blob/15e4e8a6af2f120bbd1eef8607131d878677c0ad/src/Microsoft.PowerShell.Commands.Management/commands/management/ContentCommandBase.cs#L35-L44

@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.

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)

@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

@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.

@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.

We may choose to include Jim's version and call it Edit-TextFile as there have been asks to edit other file types.

@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.