Echo to file descriptor overwrites the file?












1















I am having trouble understanding what is happening when I try to write to a file descriptor? It appears to be overwriting the original contents? Is this expected behaviour?



I have replicated this in the example below:



$ echo "The quick brown fox ..." > example.txt  

$ echo "The quick brown fox ..." >> example.txt

$ cat example.txt

The quick brown fox ...  

The quick brown fox ...

$ exec 88<>example.txt

$ cat example.txt

The quick brown fox ...  

The quick brown fox ...

$ echo "jumped" >&88  

$ cat example.txt

jumped  

ck brown fox ...  

The quick brown fox ...

$ echo "jumped" >&88  

$ cat example.txt

jumped  

jumped  

n fox ...  

The quick brown fox ...





bash files exec







share|improve this question









New contributor




Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

























    1















    I am having trouble understanding what is happening when I try to write to a file descriptor? It appears to be overwriting the original contents? Is this expected behaviour?



    I have replicated this in the example below:



    $ echo "The quick brown fox ..." > example.txt  
    
$ echo "The quick brown fox ..." >> example.txt
    
$ cat example.txt
    
The quick brown fox ...  
    
The quick brown fox ...
    
$ exec 88<>example.txt
    
$ cat example.txt
    
The quick brown fox ...  
    
The quick brown fox ...
    
$ echo "jumped" >&88  
    
$ cat example.txt
    
jumped  
    
ck brown fox ...  
    
The quick brown fox ...
    
$ echo "jumped" >&88  
    
$ cat example.txt
    
jumped  
    
jumped  
    
n fox ...  
    
The quick brown fox ...





    bash files exec







    share|improve this question









    New contributor




    Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.























      1












      1








      1


      3






      I am having trouble understanding what is happening when I try to write to a file descriptor? It appears to be overwriting the original contents? Is this expected behaviour?



      I have replicated this in the example below:



      $ echo "The quick brown fox ..." > example.txt  
      
$ echo "The quick brown fox ..." >> example.txt
      
$ cat example.txt
      
The quick brown fox ...  
      
The quick brown fox ...
      
$ exec 88<>example.txt
      
$ cat example.txt
      
The quick brown fox ...  
      
The quick brown fox ...
      
$ echo "jumped" >&88  
      
$ cat example.txt
      
jumped  
      
ck brown fox ...  
      
The quick brown fox ...
      
$ echo "jumped" >&88  
      
$ cat example.txt
      
jumped  
      
jumped  
      
n fox ...  
      
The quick brown fox ...





      bash files exec







      share|improve this question









      New contributor




      Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      I am having trouble understanding what is happening when I try to write to a file descriptor? It appears to be overwriting the original contents? Is this expected behaviour?



      I have replicated this in the example below:



      $ echo "The quick brown fox ..." > example.txt  
      
$ echo "The quick brown fox ..." >> example.txt
      
$ cat example.txt
      
The quick brown fox ...  
      
The quick brown fox ...
      
$ exec 88<>example.txt
      
$ cat example.txt
      
The quick brown fox ...  
      
The quick brown fox ...
      
$ echo "jumped" >&88  
      
$ cat example.txt
      
jumped  
      
ck brown fox ...  
      
The quick brown fox ...
      
$ echo "jumped" >&88  
      
$ cat example.txt
      
jumped  
      
jumped  
      
n fox ...  
      
The quick brown fox ...





      bash files exec




      bash files exec






      share|improve this question









      New contributor




      Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited 1 hour ago









      Community♦

      1




      1






      New contributor




      Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 3 hours ago









      ZoonoseZoonose

      83




      83




      New contributor




      Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Zoonose is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






















          1 Answer
          1






          active

          oldest

          votes


















          3














          Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.



          If, instead, you'd read the file before then, then appends happen:



          bash-4.2$ cat <&88
          
The quick brown fox ...
          
The quick brown fox ...
          

          
bash-4.2$ echo hello >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          

          
bash-4.2$ echo more >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          
more





          share|improve this answer
























          • Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt

            – Zoonose
            1 hour ago











          • Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!

            – Zoonose
            1 hour ago













          • @Zoonose: When you execute cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.

            – P Daddy
            11 mins ago











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });






          Zoonose is a new contributor. Be nice, and check out our Code of Conduct.










          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501266%2fecho-to-file-descriptor-overwrites-the-file%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3














          Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.



          If, instead, you'd read the file before then, then appends happen:



          bash-4.2$ cat <&88
          
The quick brown fox ...
          
The quick brown fox ...
          

          
bash-4.2$ echo hello >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          

          
bash-4.2$ echo more >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          
more





          share|improve this answer
























          • Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt

            – Zoonose
            1 hour ago











          • Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!

            – Zoonose
            1 hour ago













          • @Zoonose: When you execute cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.

            – P Daddy
            11 mins ago
















          3














          Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.



          If, instead, you'd read the file before then, then appends happen:



          bash-4.2$ cat <&88
          
The quick brown fox ...
          
The quick brown fox ...
          

          
bash-4.2$ echo hello >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          

          
bash-4.2$ echo more >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          
more





          share|improve this answer
























          • Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt

            – Zoonose
            1 hour ago











          • Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!

            – Zoonose
            1 hour ago













          • @Zoonose: When you execute cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.

            – P Daddy
            11 mins ago














          3












          3








          3







          Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.



          If, instead, you'd read the file before then, then appends happen:



          bash-4.2$ cat <&88
          
The quick brown fox ...
          
The quick brown fox ...
          

          
bash-4.2$ echo hello >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          

          
bash-4.2$ echo more >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          
more





          share|improve this answer













          Because you hadn't done any reads on descriptor 88, the current seek position was "0", and so the write took place at that point.



          If, instead, you'd read the file before then, then appends happen:



          bash-4.2$ cat <&88
          
The quick brown fox ...
          
The quick brown fox ...
          

          
bash-4.2$ echo hello >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          

          
bash-4.2$ echo more >&88
          

          
bash-4.2$ cat example.txt 
          
The quick brown fox ...
          
The quick brown fox ...
          
hello
          
more






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 2 hours ago









          Stephen HarrisStephen Harris

          26.1k24577




          26.1k24577













          • Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt

            – Zoonose
            1 hour ago











          • Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!

            – Zoonose
            1 hour ago













          • @Zoonose: When you execute cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.

            – P Daddy
            11 mins ago



















          • Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt

            – Zoonose
            1 hour ago











          • Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!

            – Zoonose
            1 hour ago













          • @Zoonose: When you execute cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.

            – P Daddy
            11 mins ago

















          Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt

          – Zoonose
          1 hour ago





          Wow! So this means that the file descriptor (in this example 88) maintains a separate seek position to the standard cat? i.e. cat example.txt

          – Zoonose
          1 hour ago













          Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!

          – Zoonose
          1 hour ago







          Thanks Stephen. Just tested this out and you are right. Interestingly enough, if I continue to echo out to the file again, and then echo to the descriptor (without reading on the descriptor) the problem persists. So if other processes are writing to the file, then I need to constantly read in on the descriptor, before writing out!

          – Zoonose
          1 hour ago















          @Zoonose: When you execute cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.

          – P Daddy
          11 mins ago





          @Zoonose: When you execute cat example.txt, cat opens the file, getting a descriptor with a seek position starting at the beginning of the file, reads it until the end, and then closes the descriptor. When you execute exec 88<>example.txt, bash opens the file, getting a descriptor with a seek position starting at the beginning of the file. The file itself doesn't maintain a seek position, instead a position is maintained for each open file descriptor.

          – P Daddy
          11 mins ago










          Zoonose is a new contributor. Be nice, and check out our Code of Conduct.










          draft saved

          draft discarded


















          Zoonose is a new contributor. Be nice, and check out our Code of Conduct.













          Zoonose is a new contributor. Be nice, and check out our Code of Conduct.












          Zoonose is a new contributor. Be nice, and check out our Code of Conduct.
















          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid …



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501266%2fecho-to-file-descriptor-overwrites-the-file%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          -

          Popular posts from this blog

          flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

          Image
          0 I recently upgraded an Ubuntu 16.04 virtual machine to 18.04. I regularly use this VM to run apt-mirror at school on their high-speed internet, then rsync these files to my rack-mount server at home for updating multiple computers at home without wasting the tiny amount of bandwidth I have there. Since updating I can't get apt-mirror to run on my VM. It keeps giving the error: flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror line 214 immediately followed by: apt-mirror is already running, exiting at /usr/bin/apt-mirror line 217 apt-mirror is NOT running, and does not have a cron job. I've tried rebooting, and even looked for the old-style lockfile to delete, but I guess that method is no longer used. Is there some way to force unlock this so I can run apt-mirror? UPDATE: So... I f...
          Read more

          Mangá

          Image
            Nota:  Não confundir com Manga. Mangás e Animes Mangá Mangaká • Tankōbon Film comic La nouvelle manga Mangá original em inglês Anime História Animação influenciada por animes • Filler • OVA • Seiyū Públicos Kodomo • Shōjo • Shōnen Josei • Seinen Gêneros Mahō shōjo • Mecha • Harém Ecchi • Hentai ( Yaoi • Yuri Futanari • Shotacon • Lolicon Toddlercon ) Termos Bishōjo • Chibi • Fan service Gaiden • Kawaii • Kaitō • Light novel Mahō shōnen • Moe (antropomorfismo • Kemonomimi Nekomimi ) • Super deformed Omake • Tsundere • Yonkoma Listas Mangás • Animes • Ecchi • Mangaka • Estúdios • Revistas Fãs ( otaku ) Anime Music Video Convenções • Cosplay Dōjinshi • Fansub • Fandub • Fujoshi OS-tan • Scanlation Portal de Anime e mangá v d e O mangá (português brasileiro) ou manga (português europeu) [ 1 ] (em japonês: 漫画 , manga ? , lit. “história em quadrinhos”) , é a ...
          Read more

          Eduardo VII do Reino Unido

          Image
          Eduardo VII Rei do Reino Unido da Grã-Bretanha e Irlanda e dos Domínios Britânicos de Além-mar Imperador da Índia Rei do Reino Unido e Imperador da Índia Reinado 22 de janeiro de 1901 a 6 de maio de 1910 Coroação 9 de agosto de 1902 Delhi Durbar 1 de janeiro de 1903 Predecessora Vitória Sucessor Jorge V   Esposa Alexandra da Dinamarca Descendência Alberto Vitor, Duque de Clarence e Avondale Jorge V do Reino Unido Luísa, Princesa Real Vitória de Gales Maud de Gales Alexandre João de Gales Casa Saxe-Coburgo-Gota Nome completo Alberto Eduardo Nascimento 9 de novembro de 1841   Palácio de Buckingham, Londres, Reino Unido Morte 6 de maio de 1910 (68 anos)   Palácio de Buckingham, Londres, Reino Unido Enterro Capela de São Jorge, Windsor, Berkshire, Reino Unido 20 de maio de 1910 Pai Alberto de Saxe-Coburgo-Gota Mãe Vitória do Reino Unido Assinatura ...
          Read more