I tried to create a .emacs-bash file and that works for M-x shell. But if I use the ansi-term, it appears that the .emacs-bash file is not loaded... How can I solve this?
I used M-x ansi-term and then \bin\bash.
The ~/.emacs_SHELLNAME (or ~/.emacs.d/init_SHELLNAME.sh) behaviour is special to the shell function (which, naturally, knows that you're going to be running a shell).
ansi-term is a terminal emulator. It doesn't know what kind of process you're going to be running with it, so it doesn't attempt to apply any custom config files.
If you run a shell in the terminal, that shell should apply its normal rules for config files, so I would try .bashrc for starters.
Failing that, read the bash man page to see what the rules are. Environment variables would likely come into play (and you could test for environment variables in your .bashrc to provide Emacs-specific behaviour).
Related
I am using fish terminal inside of Emacs term
My normal prompt on load looks like the following
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
$>
Ok, when I load fish term inside of term.el it looks like this
Welcome to fish, the friendly interactive shell
Type helpB for instructions on how to use fish
7;file://Collins-MacBook-Air.local/Users/collinbell/Programs/riddley⏎
$>
A cd command in my normal terminal looks like this
$> cd ~/
$>
However in the emacs term.el it looks like this
$> cd ~/
7;file://Collins-MacBook-Air.local/Users/collinbell⏎
$>
I have no idea why it is pasting the cwd into the buffer, but it does it every time a directory changes. Emacs also makes the system sound after this, while other commands like ls do not make the system sound.
This is obviously not the biggest issue in the world, but I do run clear as a pre-command to keep my terminal looking clean (although I turned it off for this example) and Emacs pasting this line into the buffer really messes with sublime usage.
You seem to be experiencing a known issue.
Try this fix:
In your fish config file ~/.config/fish/config.fish add the following:
function fish_title
true
end
Also, see this from the fish documentation, though according to the github issue, the fix suggested in the docs might not work, while the above function does.
According to the fish documentation, this is what's going on:
Fish is trying to set the titlebar message of your terminal. While
screen itself supports this feature, your terminal does not.
Unfortunately, when the underlying terminal doesn't support setting
the titlebar, screen simply passes through the escape codes and text
to the underlying terminal instead of ignoring them. It is impossible
detect and resolve this problem from inside fish since fish has no way
of knowing what the underlying terminal type is. For now, the only way
to fix this is to unset the titlebar message, as suggested above.
Usually I use my .bashrc file to load some functions for my bash environment. When I call these functions (that I created based on some frameworks I use). So, I play around with variables such as PATH and PYTHONPATH when I use the functions depending on the environment I'm working on.
So far so well with the terminal. The problem is that when I use emacs these functions and these environmental variables that I activate with my functions, they don't exist. .bashrc is not read by emacs, and therefore I don't have the functions loaded by .bashrc don't work. I would like them to work.
Any Ideas?
The issue might be that emacs, as many other programs you run, reads your login shell rc files, such as ~/.bash_login or ~/.profile, but not ~/.bashrc, where as your terminal also reads you user shell rc file: ~/.bashrc.
I am using cygwin on windows 7. I have a question regarding the Emacs shell.
Whenever I use the shell inside of the Emacs(M-x shell)
It echo pwd directory after prints out the result.
I found it very annoying since it distracts me.
e.g.
$ ls
workspace
^[]0;~/cs61bl^G
myname#pc ~/cs61bl
Is there any way to remove these lines?
^[]0;~/cs61bl^G
myname#pc ~/cs61bl
When using Emacs, try using the eshell: M-x eshell. The eshell does not suffer from this problem.
You might be looking for "shell-dirtrack-mode". You can either do an M-x shell-dirtrack-toggle or (shell-dirtrack-mode 1) in your init file. Recent emacs versions seem to disable it by default.
There is this file http://www.emacswiki.org/emacs/setup-cygwin.el that simplifies setup of various packages in Emacs (including shell) to use cygwin. Also try not to use ANSI sequences in your PS1 prompt because Emacs shell mode wouldn't interpret them, something like
export PS1="\h \W\$ "
should do.
I have a program that I'd like to debug with gdb via emacs. In order to run development versions of this program, I have a shell script that I can source that sets up the calling environment to see the right libraries, etc. What I can't sort out is how to ask emacs/gud to source this file before executing gdb.
I've tried using a command like "source env.sourceme && gdb my_program", but emacs complains that it doesn't know what "source" means. I guess it's not really running gdb in a shell, so these kinds of tricks won't work.
So, how can I convince gud/emacs/whatever to run gdb in my custom environment? I've got a hacky solution in place, but I feel like I must be missing something.
gdb has its own syntax for setting environment variables:
set environment varname [=value]
Instead of a shell script, write your variable definitions in a file using the above syntax, then source the file from a running gdb session. Note that this is not bash's built-in source command, but gdb's own, so naturally bash-style environment variable definitions will not work.
What's your hacky solution?
Why wouldn't you just have a wrapper script that sources env.sourceme and then run gdb?
#!/usr/bin/env bash
source env.sourceme
gdb -i=mi $1
You can modify the Emacs environment using setenv, either interactively (M-x setenv) or programmatically:
(setenv "FOOBAR" "whatever")
When you run gud-gdb, whatever you set using setenv will be passed to the gdb process.
I use emacs as my editor-of-choice, and since I'm doing a lot of work in a terminal I always run emacs as
emacs -nw
so that it runs in the terminal instead of in a window.
I'd like to just run emacs and have it know that it should run in a terminal. My question is - how do I edit my .emacs file so that this is the default behavior?
You can't do this in the .emacs file. By the time that file is being parsed, the "chosen" emacs binary is already running.
You can install the emacs-nox package as one commenter suggests, or create an alias in your shell so that "emacs" is always treated as "emacs -nw".
Randy
I'm using a bash alias instead of .emacs to do that.
Add this line to your ~/.bashrc.
alias emacs='emacs -nw'
There is any easy way to solve the problem in general that has nothing to do with emacs at all and will work for any program that can choose between running in the console vs X:
unset DISPLAY
Of course you may not want to put that in your configuration file to be applied globally to all your shell sessions, so if you want it to apply to only emacs, then either call it from the command line like this:
DISPLAY= emacs
note the space!!! if you leave the space out it means you're setting the DISPLAY to emacs instead of setting DISPLAY to nothing... this command is a shorthand for:
DISPLAY=; emacs
So either use the above from the command line(s) or put that in a wrapper script that would look something like this:
#!/bin/bash
unset DISPLAY
exec emacs
I recommend the exec there because it will replace your wrapper script with emacs; to see the difference between the two you can run:
pstree -p
When I was first setting up a "emacs -nw" alias for emacs in windows I got stuck in a situation where I thought tototoshi's explanation hadn't worked. Yet all that was required was a restart of my terminal. Therefore, i think its worth mentioning that in windows (at least) if you are using emacs within the git bash terminal to create the .bashrc file and add "alias emacs='emacs -nw" to it (as tototoshi mentions) you have to close and reopen your terminal for it to work.