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

          الفوسفات في المغرب

          Image
          قطار ينقل فوسفات من منطقة خريبكة متجه نحو الدار البيضاء. ديار عمال بمصانع الفوسفات بمدينة آسفي. المحتوى هنا ينقصه الاستشهاد بمصادر. يرجى إيراد مصادر موثوق بها. أي معلومات غير موثقة يمكن التشكيك بها وإزالتها. (أغسطس 2015) الفوسفات في المغرب هو ثالث مصدر عالمي للفوسفات، ويتوفر المغرب على %75 من الاحتياطي العالمي  [بحاجة لمصدر] ويتوزع بنسب متفاوتة بين عدة مناطق أساسية وهي: وادي زم بن جرير بوكراع خريبكة اليوسفية أولاد عبدون كنتور واد الذهب مستقلة. هذه الأخيرة لم تفتح بعد للاستغلال. الصادرات الحامض الفوسفوري P205 تمتص الهند %50 من ا لصادرات الإجمالية آسيا (دون روسيا)%59 أوروبا %30 أمريكا اللاتينية %11 أسمدة صلبة أوروبا 38 % أمريكا اللاتينية %30 آسيا (دون روسيا) 22 % أستراليا 9 % بوابة المغرب هذه بذرة مقالة عن علم الاقتصاد أو موضوع متعلق به بحاجة للتوسيع. شارك في تحريرها. This page is only for reference, If you need detailed information, please check here
          Read more

          Four equal circles intersect: What is the area of the small shaded portion and its height

          Image
          3 $begingroup$ In terms of $R$ which is the radius of all four circles, what is the area of the intersection region of these four equal circles and the height of the marked arrow in the figure? The marked arrow is along the line CD, also the midpoint of all the circles are points A, B, C and D. Looking for a very short intuitive solution. I have checked similar questions on this site for example this and this. geometry circle share | cite | improve this question edited 2 hours ago Abdulhameed asked 2 hours ago ...
          Read more

          جامعة ليفربول

          Image
          جامعة ليفربول University of Liverpool الأسماء السابقة كلية ليفربول الجامعية (1882-1884) جامعة فيكتوريا في ليفربول (1884-1903) معلومات التأسيس 1882 (منذ 137 سنة) الإنتماءات رابطة الجامعات الأوروبية مجموعة راسل جامعات القرميد الأحمر المنحة المالية 143.5 مليون £ النوع جامعة عامة الكليات 6 الموقع الجغرافي إحداثيات 53°24′22″N 2°58′01″W  /  53.406°N 2.967°W  / 53.406; -2.967   المدينة ليفربول المكان   إنجلترا البلد   المملكة المتحدة رقم الهاتف 7942000 151 (44+) إحصاءات الطلاب 17,405 (سنة 2008) عضوية مجموعة رسل [1] أورسيد [2]   طلاب الدراسات العليا 3,860 الموقع www.liverpool.ac.uk تعديل   جامعة ليفربول مبنى فكتوريا جامعة ليفربول (بالإنجليزية: The University of Liverpool )) إحدى الجامعات البريطانية العريقة، تقع في مدينة ليفربول على الساحل الشمالي الغربي من أنجلترا . وهي عضو في مجموعة راسل للجامعات وتعتبر من ضمن جامعات الطوب الأحمر الستة. محتويات ...
          Read more