Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can not overwrite files in the pipeline. Is it by design? #9782

Closed
mkht opened this issue May 31, 2019 · 7 comments
Closed

Can not overwrite files in the pipeline. Is it by design? #9782

mkht opened this issue May 31, 2019 · 7 comments
Labels
Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-Answered The question is answered.

Comments

@mkht
Copy link
Contributor

mkht commented May 31, 2019

When I tried to read a file using a pipeline, edit the contents, and save it, I got unexpected behavior.
Is this correct behavior by design ?

# Create a text file for testing
PS> 'A' | Out-File -FilePath C:\test.txt

# Read file , modified, overwrite
PS> Get-Content -Path C:\test.txt -Raw | ForEach-Object {$_ + 'B'} | Out-File -FilePath C:\test.txt

# I expect that the output is 'AB', but it outputs nothing
PS> Get-Content -Path C:\test.txt -Raw
@mkht mkht added the Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a label May 31, 2019
@vexx32
Copy link
Collaborator

vexx32 commented May 31, 2019

Yeah this is what you can call by design. Because Get-Content passes items along the pipeline one at a time, it's not going to be done reading the file by the time the Out-File cmdlet is called. In fact, the way the cmdlet is designed, the file handle isn't released until the pipeline is completed, so you can't read and write to a file in the same pipeline.

The short solution is to force all the input to be pulled before sending it along the pipe; this can be done pretty simply with some parentheses:

$Path = 'C:\Test.txt'
'A' | Set-Content -Path $Path
(Get-Content -Path $Path -Raw) | ForEach-Object { $_ + 'B' } | Set-Content -Path $Path
Get-Content -Path $Path -Raw

Given the behaviour of -Raw I don't see why it wouldn't be able to release the file handle early in that particular situation, since it's reading the whole file in one go anyway. That would be a possible feature enhancement, I would think. 🙂

@SeeminglyScience
Copy link
Collaborator

SeeminglyScience commented May 31, 2019

@vexx32 This is a little off topic but this is a great example of why it'd be nice if commands were disposed directly after EndProcessing. You could place an Out-String before Set-Content and the whole thing would just work.

@vexx32
Copy link
Collaborator

vexx32 commented May 31, 2019

@SeeminglyScience Good point! I guess this will be a bit easier moving forward. I have a couple PRs to put in first, though. 😄

@mkht
Copy link
Contributor Author

mkht commented May 31, 2019

Thanks @vexx32
I understood about the behavior. I appreciate your good solution. 😄
May I close this issue ?

@vexx32
Copy link
Collaborator

vexx32 commented May 31, 2019

Of course! 😄

@mkht mkht closed this as completed May 31, 2019
@iSazonov
Copy link
Collaborator

@vexx32 Please open new tracking issue if you plan to pull a fix.

@iSazonov iSazonov added the Resolution-Answered The question is answered. label Jun 28, 2019
@vexx32
Copy link
Collaborator

vexx32 commented Jun 28, 2019

@iSazonov a true fix is pretty dicey but some of the changes necessary for #9900 will make this much less tricky to handle, as the file handle should be closed as soon as the command is done with its output.

I'll have to see if that actually is the case or there needs to be changes in Get-Content specifically. I'll open a tracking issue. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-Answered The question is answered.
Projects
None yet
Development

No branches or pull requests

4 participants