Skip to content

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

Closed

Description

@mkht

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

Activity

  1. added
    Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a
    on May 31, 2019
  2. vexx32 commented on May 31, 2019

    @vexx32
    Collaborator

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

  3. SeeminglyScience commented on May 31, 2019

    @SeeminglyScience
    Contributor

    Rain Sallow (/u/ta11ow) (@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.

  4. vexx32 commented on May 31, 2019

    @vexx32
    Collaborator

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

  5. mkht commented on May 31, 2019

    @mkht
    ContributorAuthor

    Thanks Rain Sallow (/u/ta11ow) (@vexx32)
    I understood about the behavior. I appreciate your good solution. 😄
    May I close this issue ?

  6. vexx32 commented on May 31, 2019

    @vexx32
    Collaborator

    Of course! 😄

  7. iSazonov commented on Jun 28, 2019

    @iSazonov
    Collaborator

    Rain Sallow (/u/ta11ow) (@vexx32) Please open new tracking issue if you plan to pull a fix.

  8. vexx32 commented on Jun 28, 2019

    @vexx32
    Collaborator

    Ilya (@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aResolution-AnsweredThe question is answered.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions