Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

On MacOSX 10.7, Apple puts into /etc/bashrc a function: update_terminal_cwd that checks to see if Apple Terminal is running AND if we are not in emacs (snippet pasted below). Unfortunately, by including autojump into my bashrc config file, invoking an inferior shell (i.e. M-x shell) results in update_terminal_cwd being invoked. I get this output for any command invoked in the inferior shell:

bash: update_terminal_cwd: command not found
achan[10:29 AM]~ > echo $PROMPT_COMMAND

When I include autojump in my bashrc, echo $PROMPT_COMMAND inside of emacs looks like this:

{ [[ "$AUTOJUMP_HOME" == "$HOME" ]] && (autojump -a "$(pwd -P)"&)>/dev/null 2>>"${AUTOJUMP_DATA_DIR}/.autojump_errors";} 2>/dev/null ; update_terminal_cwd;

If I don't include autojump, I just get a null string for echo $PROMPT_COMMAND.

In the autojump code, it is inserting the first part:

{ [[ "$AUTOJUMP_HOME" == "$HOME" ]] && (autojump -a "$(pwd -P)"&)>/dev/null 2>>"${AUTOJUMP_DATA_DIR}/.autojump_errors";} 2>/dev/null ;

The update_terminal_cwd is being added just by appending $PROMPT_COMMAND to the end of the above string.

Somehow, autojump is being instantiated in an environment where:

[ "$TERM_PROGRAM" == "Apple_Terminal" ] && [ -z "$INSIDE_EMACS" ]

is true. But, because it is being run in emacs, update_terminal_cwd isn't defined; hence the error.

The autojump folks have suggested that I use iTerm2 instead or figure out why $INSIDE_EMACS isn't working.

I suspect it's something like the following:

Invoking M-x shell is somehow tied to the shell environment that already exists when emacs is invoked. This is why changing the .bashrc file while emacs is running doesn't propagate the changes to emacs. Instead, you to have to create a new bash environment and then invoke emacs with an inferior shell before you see those changes.

Is there a way to tell an inferior shell to disregard the default environment and try to start up bash from scratch?

Apple /etc/bashrc

# System-wide .bashrc file for interactive bash(1) shells.
if [ -z "$PS1" ]; then
   return
fi

PS1='\h:\W \u\$ '
# Make bash check its window size after a process completes
shopt -s checkwinsize
# Tell the terminal about the working directory at each prompt.
if [ "$TERM_PROGRAM" == "Apple_Terminal" ] && [ -z "$INSIDE_EMACS" ]; then
    update_terminal_cwd() {
        # Identify the directory using a "file:" scheme URL,
        # including the host name to disambiguate local vs.
        # remote connections. Percent-escape spaces.
    local SEARCH=' '
    local REPLACE='%20'
    local PWD_URL="file://$HOSTNAME${PWD//$SEARCH/$REPLACE}"
    printf '\e]7;%s\a' "$PWD_URL"
    }
    PROMPT_COMMAND="update_terminal_cwd; $PROMPT_COMMAND"
fi
share|improve this question

3 Answers 3

After M-x shell you can get a shell with an fairly empty environment (started with the same options that emacs uses) by:

exec -c bash --noediting -i

or you can place the above command in ~/.emacs_bash or ~/.emacs.d/init_bash.sh

If that removes too much of the environment, instead of the exec maybe you can just set $PROMPT_COMMAND to a correct value inside the .emacs_bash startup script.

share|improve this answer
    
I edited both ~/.emacs_bash and/or ~/.emacs.d/init_bash.sh as per your suggestion. Both of these files do get touched when the shell starts up, but it still doesn't do a way with the problem. In fact, I get a complaint from brew that $HOME isn't defined (though this only happens once after executing a command). –  Avery Chan May 18 '12 at 9:22

I know this topic is old, but I had the same issue and found no solution (and this page is the first google result). Here is my fix (might not be the best, but works):

if [ `(type update_terminal_cwd | grep -q 'shell function' | wc -l) 2> /dev/null` -eq 0 ]; then
    update_terminal_cwd() {
        return
    }
fi

[[ -s `brew --prefix`/etc/autojump.sh ]] && . `brew --prefix`/etc/autojump.sh

Regards,

share|improve this answer

I upgraded to 24.3.50.1 and am not seeing this issue. That's a good solution (i.e. upgrade to the latest emacs).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.