How can I track script which gives me “command not found” right after the login?
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
New contributor
add a comment |
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
New contributor
2
Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile
– Raman Sailopal
yesterday
add a comment |
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
New contributor
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
bash centos login startup troubleshooting
New contributor
New contributor
edited 10 hours ago
Jeff Schaller
43.4k1160140
43.4k1160140
New contributor
asked yesterday
Denis SablukovDenis Sablukov
1335
1335
New contributor
New contributor
2
Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile
– Raman Sailopal
yesterday
add a comment |
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
add a comment |
4 Answers
4
active
oldest
votes
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.
6
One more place to look for :~/.bash_aliases
– Weijun Zhou
yesterday
1
Another option is to usestrace -e open your-shell
, from Stéphane's answer over here
– Jeff Schaller
10 hours ago
add a comment |
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
add a comment |
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.
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
add a comment |
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.
New contributor
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
6
One more place to look for :~/.bash_aliases
– Weijun Zhou
yesterday
1
Another option is to usestrace -e open your-shell
, from Stéphane's answer over here
– Jeff Schaller
10 hours ago
add a comment |
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.
6
One more place to look for :~/.bash_aliases
– Weijun Zhou
yesterday
1
Another option is to usestrace -e open your-shell
, from Stéphane's answer over here
– Jeff Schaller
10 hours ago
add a comment |
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.
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.
answered yesterday
ilkkachuilkkachu
61.5k10100177
61.5k10100177
6
One more place to look for :~/.bash_aliases
– Weijun Zhou
yesterday
1
Another option is to usestrace -e open your-shell
, from Stéphane's answer over here
– Jeff Schaller
10 hours ago
add a comment |
6
One more place to look for :~/.bash_aliases
– Weijun Zhou
yesterday
1
Another option is to usestrace -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
add a comment |
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
add a comment |
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
add a comment |
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
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
answered yesterday
Kevin_KinseyKevin_Kinsey
1964
1964
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
New contributor
add a comment |
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.
New contributor
add a comment |
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.
New contributor
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.
New contributor
New contributor
answered 22 hours ago
Ben MillwoodBen Millwood
1314
1314
New contributor
New contributor
add a comment |
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
2
Try looking at the .bashrc,.bash_profile and profile files in your home directory as well as /etc/profile
– Raman Sailopal
yesterday