How can I track script which gives me “command not found” right after the login?












6















When I login, I have these messages:



-bash: $'r' : command not found
-bash: $'r' : command not found
-bash: $'r' : command not found


It is quite clear that it is caused by Windows-style line endings in some startup script(s), so my question is:
Can I track script that causes that and how?










share|improve this question









New contributor




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
















  • 2





    Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile

    – Raman Sailopal
    yesterday
















6















When I login, I have these messages:



-bash: $'r' : command not found
-bash: $'r' : command not found
-bash: $'r' : command not found


It is quite clear that it is caused by Windows-style line endings in some startup script(s), so my question is:
Can I track script that causes that and how?










share|improve this question









New contributor




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
















  • 2





    Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile

    – Raman Sailopal
    yesterday














6












6








6


2






When I login, I have these messages:



-bash: $'r' : command not found
-bash: $'r' : command not found
-bash: $'r' : command not found


It is quite clear that it is caused by Windows-style line endings in some startup script(s), so my question is:
Can I track script that causes that and how?










share|improve this question









New contributor




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












When I login, I have these messages:



-bash: $'r' : command not found
-bash: $'r' : command not found
-bash: $'r' : command not found


It is quite clear that it is caused by Windows-style line endings in some startup script(s), so my question is:
Can I track script that causes that and how?







bash centos login startup troubleshooting






share|improve this question









New contributor




Denis Sablukov 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




Denis Sablukov 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 10 hours ago









Jeff Schaller

43.4k1160140




43.4k1160140






New contributor




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









asked yesterday









Denis SablukovDenis Sablukov

1335




1335




New contributor




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





New contributor





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






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








  • 2





    Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile

    – Raman Sailopal
    yesterday














  • 2





    Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile

    – Raman Sailopal
    yesterday








2




2





Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile

– Raman Sailopal
yesterday





Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile

– Raman Sailopal
yesterday










4 Answers
4






active

oldest

votes


















13














Bash reads a number of different files on startup, even depending on how it's started (see the manual for the description). Then there's stuff like /etc/profile.d/ that aren't directly read by the shell, but can be referenced from the other startup files in many distributions.



You'll have to go through all of those but luckily, you can just grep for the carriage return. Try e.g. something like:



grep $'r' ~/.bashrc ~/.profile ~/.bash_login ~/.bash_profile /etc/bash.bashrc /etc/profile /etc/profile.d/*


See also Is it possible to find out which files are setting/adding to environment variables, and their order of precedence? for a similar issue.






share|improve this answer



















  • 6





    One more place to look for : ~/.bash_aliases

    – Weijun Zhou
    yesterday






  • 1





    Another option is to use strace -e open your-shell, from Stéphane's answer over here

    – Jeff Schaller
    10 hours ago





















4














file(1) can be helpful here as well.



$file *

signin: Python script, ASCII text
signup: Python script, ASCII text, with CRLF line terminators
site_off.htm: XML 1.0 document, ASCII text
sitemaps: directory


I can see that signup needs to have those pesky Windows CRLF line-endings removed.



For a recursive directly like /home/username you could probably combine with find and xargs (and maybe a grep, too):



$ find . | xargs file | grep CR

./foo_data/V: ASCII text, with CR, LF line terminators
./foo_data/Y: ASCII text, with CR, LF line terminators





share|improve this answer































    3














    Another method is to take all of those startup scripts mentioned, and echo a string identifying each one at the start of each one.



    $ head .bashrc
    echo "Running bashrc"


    Then, on login, you will see something like this:



    running bashrc
    running bash_aliases
    -bash: $'r' : command not found
    -bash: $'r' : command not found
    -bash: $'r' : command not found
    running something_else


    At that point you can conclude that, (in the example above) .bash_aliases contains the offending line endings.



    Once you have identified the file, but the problem lines don't jump out at you, you can use the same method to track down the line. Echo a message halfway through the file, then 3/4ths or 1/4s through, depending on the output. That way you can track down the line, depending on whether it echoes before or after your echo.






    share|improve this answer
























    • Yeah, this method is good if one can quickly automize it, otherwise it is almost the same as look through all these files.

      – Denis Sablukov
      yesterday






    • 1





      Note that you might want to also say 'done running <file>' at the end of each one. In this case it doesn't really matter unless only some of the lines have CR line endings, but if you're looking for another error it could be in your .bashrc after you source .bash_aliases.

      – Ben Millwood
      23 hours ago






    • 1





      For someone just learning to debug shell issues, or when it is not as easy as searching for 'r', THIS answer is worth having in your knowledge toolbox. I inherited a complex build system which was a rat's nest of entwined scripts to do remote builds over SSH. This was the only way to unwind it and move it to Docker containers.

      – Crossfit_and_Beer
      8 hours ago











    • Another general tip - when dealing with inter-related Bash scripts, be mindful of where you add echo statements and (whatever it is you're doing) test frequently. If a bash script is used to output strings to STDOUT and you added debug statements to STDOUT then you probably broke the thing you were debugging. Sometimes the answer is to employ the "logger" command to add info/debug to a script. Other times use STDERR, if it's a warning condition.

      – Crossfit_and_Beer
      8 hours ago











    • @DenisSablukov if your files are long, and looking through them takes a while, this method will help you narrow down the source more quickly. It doesn't take very long to at a line to the top and bottom of 6 files.

      – user394
      8 hours ago



















    3














    I take the hard part of this question to be not "hwo can I find carriage returns in a file?" but "how can I find out which files my bashrc uses?"



    For the second question, you can try something like this:



    bash -x .bashrc


    This will show you everything your bashrc does, including all the files it refers to. It's noisy, but should help you track down which files are being used.



    Except in fact, my (and many other) .bashrc files exit early if not run interactively, so you have to trick it into passing that check:



    bash -ix .bashrc


    Here the -i forces interactive mode.



    To grep out just the cases where you source a file, something like this works for me but I can't promise the regex catches everything:



    bash -ix .bashrc 2> >(grep -E '^+* (.|source)')


    I guess you might also want the error messages, so something like:



    bash -ix .bashrc 2> >(grep -E -e '^+* (.|source)' -e 'command not found')


    If for some reason none of this worked, I would resort to strace -e open bash or something like that, to find every time any file is opened by your bash session. But that's an even more heavyweight / noisy solution.






    share|improve this answer








    New contributor




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




















      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
      });


      }
      });






      Denis Sablukov 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%2f506503%2fhow-can-i-track-script-which-gives-me-command-not-found-right-after-the-login%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      13














      Bash reads a number of different files on startup, even depending on how it's started (see the manual for the description). Then there's stuff like /etc/profile.d/ that aren't directly read by the shell, but can be referenced from the other startup files in many distributions.



      You'll have to go through all of those but luckily, you can just grep for the carriage return. Try e.g. something like:



      grep $'r' ~/.bashrc ~/.profile ~/.bash_login ~/.bash_profile /etc/bash.bashrc /etc/profile /etc/profile.d/*


      See also Is it possible to find out which files are setting/adding to environment variables, and their order of precedence? for a similar issue.






      share|improve this answer



















      • 6





        One more place to look for : ~/.bash_aliases

        – Weijun Zhou
        yesterday






      • 1





        Another option is to use strace -e open your-shell, from Stéphane's answer over here

        – Jeff Schaller
        10 hours ago


















      13














      Bash reads a number of different files on startup, even depending on how it's started (see the manual for the description). Then there's stuff like /etc/profile.d/ that aren't directly read by the shell, but can be referenced from the other startup files in many distributions.



      You'll have to go through all of those but luckily, you can just grep for the carriage return. Try e.g. something like:



      grep $'r' ~/.bashrc ~/.profile ~/.bash_login ~/.bash_profile /etc/bash.bashrc /etc/profile /etc/profile.d/*


      See also Is it possible to find out which files are setting/adding to environment variables, and their order of precedence? for a similar issue.






      share|improve this answer



















      • 6





        One more place to look for : ~/.bash_aliases

        – Weijun Zhou
        yesterday






      • 1





        Another option is to use strace -e open your-shell, from Stéphane's answer over here

        – Jeff Schaller
        10 hours ago
















      13












      13








      13







      Bash reads a number of different files on startup, even depending on how it's started (see the manual for the description). Then there's stuff like /etc/profile.d/ that aren't directly read by the shell, but can be referenced from the other startup files in many distributions.



      You'll have to go through all of those but luckily, you can just grep for the carriage return. Try e.g. something like:



      grep $'r' ~/.bashrc ~/.profile ~/.bash_login ~/.bash_profile /etc/bash.bashrc /etc/profile /etc/profile.d/*


      See also Is it possible to find out which files are setting/adding to environment variables, and their order of precedence? for a similar issue.






      share|improve this answer













      Bash reads a number of different files on startup, even depending on how it's started (see the manual for the description). Then there's stuff like /etc/profile.d/ that aren't directly read by the shell, but can be referenced from the other startup files in many distributions.



      You'll have to go through all of those but luckily, you can just grep for the carriage return. Try e.g. something like:



      grep $'r' ~/.bashrc ~/.profile ~/.bash_login ~/.bash_profile /etc/bash.bashrc /etc/profile /etc/profile.d/*


      See also Is it possible to find out which files are setting/adding to environment variables, and their order of precedence? for a similar issue.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered yesterday









      ilkkachuilkkachu

      61.5k10100177




      61.5k10100177








      • 6





        One more place to look for : ~/.bash_aliases

        – Weijun Zhou
        yesterday






      • 1





        Another option is to use strace -e open your-shell, from Stéphane's answer over here

        – Jeff Schaller
        10 hours ago
















      • 6





        One more place to look for : ~/.bash_aliases

        – Weijun Zhou
        yesterday






      • 1





        Another option is to use strace -e open your-shell, from Stéphane's answer over here

        – Jeff Schaller
        10 hours ago










      6




      6





      One more place to look for : ~/.bash_aliases

      – Weijun Zhou
      yesterday





      One more place to look for : ~/.bash_aliases

      – Weijun Zhou
      yesterday




      1




      1





      Another option is to use strace -e open your-shell, from Stéphane's answer over here

      – Jeff Schaller
      10 hours ago







      Another option is to use strace -e open your-shell, from Stéphane's answer over here

      – Jeff Schaller
      10 hours ago















      4














      file(1) can be helpful here as well.



      $file *

      signin: Python script, ASCII text
      signup: Python script, ASCII text, with CRLF line terminators
      site_off.htm: XML 1.0 document, ASCII text
      sitemaps: directory


      I can see that signup needs to have those pesky Windows CRLF line-endings removed.



      For a recursive directly like /home/username you could probably combine with find and xargs (and maybe a grep, too):



      $ find . | xargs file | grep CR

      ./foo_data/V: ASCII text, with CR, LF line terminators
      ./foo_data/Y: ASCII text, with CR, LF line terminators





      share|improve this answer




























        4














        file(1) can be helpful here as well.



        $file *

        signin: Python script, ASCII text
        signup: Python script, ASCII text, with CRLF line terminators
        site_off.htm: XML 1.0 document, ASCII text
        sitemaps: directory


        I can see that signup needs to have those pesky Windows CRLF line-endings removed.



        For a recursive directly like /home/username you could probably combine with find and xargs (and maybe a grep, too):



        $ find . | xargs file | grep CR

        ./foo_data/V: ASCII text, with CR, LF line terminators
        ./foo_data/Y: ASCII text, with CR, LF line terminators





        share|improve this answer


























          4












          4








          4







          file(1) can be helpful here as well.



          $file *

          signin: Python script, ASCII text
          signup: Python script, ASCII text, with CRLF line terminators
          site_off.htm: XML 1.0 document, ASCII text
          sitemaps: directory


          I can see that signup needs to have those pesky Windows CRLF line-endings removed.



          For a recursive directly like /home/username you could probably combine with find and xargs (and maybe a grep, too):



          $ find . | xargs file | grep CR

          ./foo_data/V: ASCII text, with CR, LF line terminators
          ./foo_data/Y: ASCII text, with CR, LF line terminators





          share|improve this answer













          file(1) can be helpful here as well.



          $file *

          signin: Python script, ASCII text
          signup: Python script, ASCII text, with CRLF line terminators
          site_off.htm: XML 1.0 document, ASCII text
          sitemaps: directory


          I can see that signup needs to have those pesky Windows CRLF line-endings removed.



          For a recursive directly like /home/username you could probably combine with find and xargs (and maybe a grep, too):



          $ find . | xargs file | grep CR

          ./foo_data/V: ASCII text, with CR, LF line terminators
          ./foo_data/Y: ASCII text, with CR, LF line terminators






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered yesterday









          Kevin_KinseyKevin_Kinsey

          1964




          1964























              3














              Another method is to take all of those startup scripts mentioned, and echo a string identifying each one at the start of each one.



              $ head .bashrc
              echo "Running bashrc"


              Then, on login, you will see something like this:



              running bashrc
              running bash_aliases
              -bash: $'r' : command not found
              -bash: $'r' : command not found
              -bash: $'r' : command not found
              running something_else


              At that point you can conclude that, (in the example above) .bash_aliases contains the offending line endings.



              Once you have identified the file, but the problem lines don't jump out at you, you can use the same method to track down the line. Echo a message halfway through the file, then 3/4ths or 1/4s through, depending on the output. That way you can track down the line, depending on whether it echoes before or after your echo.






              share|improve this answer
























              • Yeah, this method is good if one can quickly automize it, otherwise it is almost the same as look through all these files.

                – Denis Sablukov
                yesterday






              • 1





                Note that you might want to also say 'done running <file>' at the end of each one. In this case it doesn't really matter unless only some of the lines have CR line endings, but if you're looking for another error it could be in your .bashrc after you source .bash_aliases.

                – Ben Millwood
                23 hours ago






              • 1





                For someone just learning to debug shell issues, or when it is not as easy as searching for 'r', THIS answer is worth having in your knowledge toolbox. I inherited a complex build system which was a rat's nest of entwined scripts to do remote builds over SSH. This was the only way to unwind it and move it to Docker containers.

                – Crossfit_and_Beer
                8 hours ago











              • Another general tip - when dealing with inter-related Bash scripts, be mindful of where you add echo statements and (whatever it is you're doing) test frequently. If a bash script is used to output strings to STDOUT and you added debug statements to STDOUT then you probably broke the thing you were debugging. Sometimes the answer is to employ the "logger" command to add info/debug to a script. Other times use STDERR, if it's a warning condition.

                – Crossfit_and_Beer
                8 hours ago











              • @DenisSablukov if your files are long, and looking through them takes a while, this method will help you narrow down the source more quickly. It doesn't take very long to at a line to the top and bottom of 6 files.

                – user394
                8 hours ago
















              3














              Another method is to take all of those startup scripts mentioned, and echo a string identifying each one at the start of each one.



              $ head .bashrc
              echo "Running bashrc"


              Then, on login, you will see something like this:



              running bashrc
              running bash_aliases
              -bash: $'r' : command not found
              -bash: $'r' : command not found
              -bash: $'r' : command not found
              running something_else


              At that point you can conclude that, (in the example above) .bash_aliases contains the offending line endings.



              Once you have identified the file, but the problem lines don't jump out at you, you can use the same method to track down the line. Echo a message halfway through the file, then 3/4ths or 1/4s through, depending on the output. That way you can track down the line, depending on whether it echoes before or after your echo.






              share|improve this answer
























              • Yeah, this method is good if one can quickly automize it, otherwise it is almost the same as look through all these files.

                – Denis Sablukov
                yesterday






              • 1





                Note that you might want to also say 'done running <file>' at the end of each one. In this case it doesn't really matter unless only some of the lines have CR line endings, but if you're looking for another error it could be in your .bashrc after you source .bash_aliases.

                – Ben Millwood
                23 hours ago






              • 1





                For someone just learning to debug shell issues, or when it is not as easy as searching for 'r', THIS answer is worth having in your knowledge toolbox. I inherited a complex build system which was a rat's nest of entwined scripts to do remote builds over SSH. This was the only way to unwind it and move it to Docker containers.

                – Crossfit_and_Beer
                8 hours ago











              • Another general tip - when dealing with inter-related Bash scripts, be mindful of where you add echo statements and (whatever it is you're doing) test frequently. If a bash script is used to output strings to STDOUT and you added debug statements to STDOUT then you probably broke the thing you were debugging. Sometimes the answer is to employ the "logger" command to add info/debug to a script. Other times use STDERR, if it's a warning condition.

                – Crossfit_and_Beer
                8 hours ago











              • @DenisSablukov if your files are long, and looking through them takes a while, this method will help you narrow down the source more quickly. It doesn't take very long to at a line to the top and bottom of 6 files.

                – user394
                8 hours ago














              3












              3








              3







              Another method is to take all of those startup scripts mentioned, and echo a string identifying each one at the start of each one.



              $ head .bashrc
              echo "Running bashrc"


              Then, on login, you will see something like this:



              running bashrc
              running bash_aliases
              -bash: $'r' : command not found
              -bash: $'r' : command not found
              -bash: $'r' : command not found
              running something_else


              At that point you can conclude that, (in the example above) .bash_aliases contains the offending line endings.



              Once you have identified the file, but the problem lines don't jump out at you, you can use the same method to track down the line. Echo a message halfway through the file, then 3/4ths or 1/4s through, depending on the output. That way you can track down the line, depending on whether it echoes before or after your echo.






              share|improve this answer













              Another method is to take all of those startup scripts mentioned, and echo a string identifying each one at the start of each one.



              $ head .bashrc
              echo "Running bashrc"


              Then, on login, you will see something like this:



              running bashrc
              running bash_aliases
              -bash: $'r' : command not found
              -bash: $'r' : command not found
              -bash: $'r' : command not found
              running something_else


              At that point you can conclude that, (in the example above) .bash_aliases contains the offending line endings.



              Once you have identified the file, but the problem lines don't jump out at you, you can use the same method to track down the line. Echo a message halfway through the file, then 3/4ths or 1/4s through, depending on the output. That way you can track down the line, depending on whether it echoes before or after your echo.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered yesterday









              user394user394

              5,037155174




              5,037155174













              • Yeah, this method is good if one can quickly automize it, otherwise it is almost the same as look through all these files.

                – Denis Sablukov
                yesterday






              • 1





                Note that you might want to also say 'done running <file>' at the end of each one. In this case it doesn't really matter unless only some of the lines have CR line endings, but if you're looking for another error it could be in your .bashrc after you source .bash_aliases.

                – Ben Millwood
                23 hours ago






              • 1





                For someone just learning to debug shell issues, or when it is not as easy as searching for 'r', THIS answer is worth having in your knowledge toolbox. I inherited a complex build system which was a rat's nest of entwined scripts to do remote builds over SSH. This was the only way to unwind it and move it to Docker containers.

                – Crossfit_and_Beer
                8 hours ago











              • Another general tip - when dealing with inter-related Bash scripts, be mindful of where you add echo statements and (whatever it is you're doing) test frequently. If a bash script is used to output strings to STDOUT and you added debug statements to STDOUT then you probably broke the thing you were debugging. Sometimes the answer is to employ the "logger" command to add info/debug to a script. Other times use STDERR, if it's a warning condition.

                – Crossfit_and_Beer
                8 hours ago











              • @DenisSablukov if your files are long, and looking through them takes a while, this method will help you narrow down the source more quickly. It doesn't take very long to at a line to the top and bottom of 6 files.

                – user394
                8 hours ago



















              • Yeah, this method is good if one can quickly automize it, otherwise it is almost the same as look through all these files.

                – Denis Sablukov
                yesterday






              • 1





                Note that you might want to also say 'done running <file>' at the end of each one. In this case it doesn't really matter unless only some of the lines have CR line endings, but if you're looking for another error it could be in your .bashrc after you source .bash_aliases.

                – Ben Millwood
                23 hours ago






              • 1





                For someone just learning to debug shell issues, or when it is not as easy as searching for 'r', THIS answer is worth having in your knowledge toolbox. I inherited a complex build system which was a rat's nest of entwined scripts to do remote builds over SSH. This was the only way to unwind it and move it to Docker containers.

                – Crossfit_and_Beer
                8 hours ago











              • Another general tip - when dealing with inter-related Bash scripts, be mindful of where you add echo statements and (whatever it is you're doing) test frequently. If a bash script is used to output strings to STDOUT and you added debug statements to STDOUT then you probably broke the thing you were debugging. Sometimes the answer is to employ the "logger" command to add info/debug to a script. Other times use STDERR, if it's a warning condition.

                – Crossfit_and_Beer
                8 hours ago











              • @DenisSablukov if your files are long, and looking through them takes a while, this method will help you narrow down the source more quickly. It doesn't take very long to at a line to the top and bottom of 6 files.

                – user394
                8 hours ago

















              Yeah, this method is good if one can quickly automize it, otherwise it is almost the same as look through all these files.

              – Denis Sablukov
              yesterday





              Yeah, this method is good if one can quickly automize it, otherwise it is almost the same as look through all these files.

              – Denis Sablukov
              yesterday




              1




              1





              Note that you might want to also say 'done running <file>' at the end of each one. In this case it doesn't really matter unless only some of the lines have CR line endings, but if you're looking for another error it could be in your .bashrc after you source .bash_aliases.

              – Ben Millwood
              23 hours ago





              Note that you might want to also say 'done running <file>' at the end of each one. In this case it doesn't really matter unless only some of the lines have CR line endings, but if you're looking for another error it could be in your .bashrc after you source .bash_aliases.

              – Ben Millwood
              23 hours ago




              1




              1





              For someone just learning to debug shell issues, or when it is not as easy as searching for 'r', THIS answer is worth having in your knowledge toolbox. I inherited a complex build system which was a rat's nest of entwined scripts to do remote builds over SSH. This was the only way to unwind it and move it to Docker containers.

              – Crossfit_and_Beer
              8 hours ago





              For someone just learning to debug shell issues, or when it is not as easy as searching for 'r', THIS answer is worth having in your knowledge toolbox. I inherited a complex build system which was a rat's nest of entwined scripts to do remote builds over SSH. This was the only way to unwind it and move it to Docker containers.

              – Crossfit_and_Beer
              8 hours ago













              Another general tip - when dealing with inter-related Bash scripts, be mindful of where you add echo statements and (whatever it is you're doing) test frequently. If a bash script is used to output strings to STDOUT and you added debug statements to STDOUT then you probably broke the thing you were debugging. Sometimes the answer is to employ the "logger" command to add info/debug to a script. Other times use STDERR, if it's a warning condition.

              – Crossfit_and_Beer
              8 hours ago





              Another general tip - when dealing with inter-related Bash scripts, be mindful of where you add echo statements and (whatever it is you're doing) test frequently. If a bash script is used to output strings to STDOUT and you added debug statements to STDOUT then you probably broke the thing you were debugging. Sometimes the answer is to employ the "logger" command to add info/debug to a script. Other times use STDERR, if it's a warning condition.

              – Crossfit_and_Beer
              8 hours ago













              @DenisSablukov if your files are long, and looking through them takes a while, this method will help you narrow down the source more quickly. It doesn't take very long to at a line to the top and bottom of 6 files.

              – user394
              8 hours ago





              @DenisSablukov if your files are long, and looking through them takes a while, this method will help you narrow down the source more quickly. It doesn't take very long to at a line to the top and bottom of 6 files.

              – user394
              8 hours ago











              3














              I take the hard part of this question to be not "hwo can I find carriage returns in a file?" but "how can I find out which files my bashrc uses?"



              For the second question, you can try something like this:



              bash -x .bashrc


              This will show you everything your bashrc does, including all the files it refers to. It's noisy, but should help you track down which files are being used.



              Except in fact, my (and many other) .bashrc files exit early if not run interactively, so you have to trick it into passing that check:



              bash -ix .bashrc


              Here the -i forces interactive mode.



              To grep out just the cases where you source a file, something like this works for me but I can't promise the regex catches everything:



              bash -ix .bashrc 2> >(grep -E '^+* (.|source)')


              I guess you might also want the error messages, so something like:



              bash -ix .bashrc 2> >(grep -E -e '^+* (.|source)' -e 'command not found')


              If for some reason none of this worked, I would resort to strace -e open bash or something like that, to find every time any file is opened by your bash session. But that's an even more heavyweight / noisy solution.






              share|improve this answer








              New contributor




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

























                3














                I take the hard part of this question to be not "hwo can I find carriage returns in a file?" but "how can I find out which files my bashrc uses?"



                For the second question, you can try something like this:



                bash -x .bashrc


                This will show you everything your bashrc does, including all the files it refers to. It's noisy, but should help you track down which files are being used.



                Except in fact, my (and many other) .bashrc files exit early if not run interactively, so you have to trick it into passing that check:



                bash -ix .bashrc


                Here the -i forces interactive mode.



                To grep out just the cases where you source a file, something like this works for me but I can't promise the regex catches everything:



                bash -ix .bashrc 2> >(grep -E '^+* (.|source)')


                I guess you might also want the error messages, so something like:



                bash -ix .bashrc 2> >(grep -E -e '^+* (.|source)' -e 'command not found')


                If for some reason none of this worked, I would resort to strace -e open bash or something like that, to find every time any file is opened by your bash session. But that's an even more heavyweight / noisy solution.






                share|improve this answer








                New contributor




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























                  3












                  3








                  3







                  I take the hard part of this question to be not "hwo can I find carriage returns in a file?" but "how can I find out which files my bashrc uses?"



                  For the second question, you can try something like this:



                  bash -x .bashrc


                  This will show you everything your bashrc does, including all the files it refers to. It's noisy, but should help you track down which files are being used.



                  Except in fact, my (and many other) .bashrc files exit early if not run interactively, so you have to trick it into passing that check:



                  bash -ix .bashrc


                  Here the -i forces interactive mode.



                  To grep out just the cases where you source a file, something like this works for me but I can't promise the regex catches everything:



                  bash -ix .bashrc 2> >(grep -E '^+* (.|source)')


                  I guess you might also want the error messages, so something like:



                  bash -ix .bashrc 2> >(grep -E -e '^+* (.|source)' -e 'command not found')


                  If for some reason none of this worked, I would resort to strace -e open bash or something like that, to find every time any file is opened by your bash session. But that's an even more heavyweight / noisy solution.






                  share|improve this answer








                  New contributor




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










                  I take the hard part of this question to be not "hwo can I find carriage returns in a file?" but "how can I find out which files my bashrc uses?"



                  For the second question, you can try something like this:



                  bash -x .bashrc


                  This will show you everything your bashrc does, including all the files it refers to. It's noisy, but should help you track down which files are being used.



                  Except in fact, my (and many other) .bashrc files exit early if not run interactively, so you have to trick it into passing that check:



                  bash -ix .bashrc


                  Here the -i forces interactive mode.



                  To grep out just the cases where you source a file, something like this works for me but I can't promise the regex catches everything:



                  bash -ix .bashrc 2> >(grep -E '^+* (.|source)')


                  I guess you might also want the error messages, so something like:



                  bash -ix .bashrc 2> >(grep -E -e '^+* (.|source)' -e 'command not found')


                  If for some reason none of this worked, I would resort to strace -e open bash or something like that, to find every time any file is opened by your bash session. But that's an even more heavyweight / noisy solution.







                  share|improve this answer








                  New contributor




                  Ben Millwood 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 answer



                  share|improve this answer






                  New contributor




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









                  answered 22 hours ago









                  Ben MillwoodBen Millwood

                  1314




                  1314




                  New contributor




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





                  New contributor





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






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






















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










                      draft saved

                      draft discarded


















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













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












                      Denis Sablukov 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%2f506503%2fhow-can-i-track-script-which-gives-me-command-not-found-right-after-the-login%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

                      Plaza Victoria

                      Puebla de Zaragoza

                      Musa