0

This is an odd one to try to describe, so it is probably better to show. I have this content in my .bashrc file on MacOS, which gets called from .bash_profile:

# .bashrc

export VENV_HOME=~/.venvs
export VENV_PYTHON=/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7

source ~/skel/bashrc-include-base.sh
source ~/skel/bashrc-include-linux.sh
source ~/skel/bashrc-include-django.sh
source ~/skel/bashrc-include-git.sh
source ~/skel/venv-wrapper.sh

unalias ls
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

Nothing too exotic. But when I fire up Terminal, or try to source .bashrc or . .bashrc, it doesn't run and gives the following errors:

My-MacBook:~ me$ source .bashrc
: command not found
: command not found
: No such file or directoryashrc-include-base.sh
: No such file or directoryashrc-include-linux.sh
: No such file or directoryashrc-include-django.sh
: No such file or directoryashrc-include-git.sh
: No such file or directoryenv-wrapper.sh
: command not found
: not foundias: ls

I've checked my terminal (which is xterm-256color). I've made sure neither source nor . is an alias:

My-MacBook:~ me$ type source
source is a shell builtin
My-MacBook:~ me$ type .
. is a shell builtin

Here's what is even more bizarre: if I create a new file and add the same contents, it runs just fine. If I copy that file over .bashrc, it runs just fine. But I keep this file in version control, and git doesn't see any difference. Any idea what would cause this behavior?

FlipperPA
  • 13,607
  • 4
  • 39
  • 71
  • 2
    I'd bet each of those lines ends with a carriage-return, which is treated as part of the command (or file name). – torek Oct 16 '19 at 22:54
  • 1
    It sounds like the same problem described in [this question](https://stackoverflow.com/questions/25252573/getting-error-command-not-found-when-trying-to-run-shell-script)—the error you are seeing occurs if the file uses carriage returns. – jirassimok Oct 16 '19 at 22:55
  • 1
    Note, by the way, that some Unix editors, in a (misguided?) attempt to be "friendly" with DOS/Windows-sourced files, will remove all the `\r` endings when reading the file, let you edit it without ever knowing it had `\r` endings, then *put all the `\r` endings back* when you write out the file. – torek Oct 16 '19 at 22:57
  • Thanks y'all. Yeah, it was line endings, as suspected. – FlipperPA Oct 17 '19 at 16:14

0 Answers0