Bash Download ((LINK)) Emacs
Blythe Detlefs
When you are working in a shell you certainly don't want to waste your time using arrow keys or home/end keys to navigate around the command line. One of the most popular shells, bash - Bourne Again SHell, uses GNU's Readline library for reading the command line.
The GNU Readline library provides a set of functions for use by applications that allow users to edit command lines as they are typed in. The readline library also includes functions to maintain a list of previously-entered command lines, to recall and perhaps reedit those lines, and perform csh-like history expansion on previous commands. Both emacs and vi editing modes are available.
I'll typically start a Screen window with Emacs, and keep that running for months (in some cases years). The buffer ends up containing hundreds of thousands of lines of commands and their results, and becomes a kind of journal of my activity. Searching through the buffer for commands, output, etc is simple. When I want to notate something I know I'll want to find in the future, I add a comment to the end of the command (for example: bash$ ./runSomeObscureCommand.pl foo foo foo # MELTDOWN COMMAND). Plus this buffer can be saved for future reference.
The other reason is I'm often running remote screen sessions which is very useful when connections die. Although emacs is pretty stable it does sometimes lock up on me, certainly more often than screen has let me down.
Perhaps you could also talk about remote terminals (and the interaction between remote tramp and compile-mode) in a future post? I shall certainly try to use in-emacs term-mode more often when I want to do quick things in a shell.
Have you tried binding your terminal buffers in emacs to different buttons? If you enable Hyper/Super (with xmodmap) you have a full set of keybindings available to you, such as H-0 through to H-9. Here's a random snippet of code to demonstrate what I'm talking about:
I could use some suggestions, though... right now I usually have both emacs and Terminal open on my Mac, and the Terminal window usually has a couple tabs open, most of which have ssh sessions to different servers. I occasionally will run emacs in one of those ssh sessions to do some quick editing; I've noticed that when I do, (1) my alt/option key doesn't work as Meta, so I have to use Esc instead, and (2) I don't get any colors, just all green. Often though, I have much more involved editing to do on files on those servers, so I'll open them in my local emacs using TRAMP. But then I'm usually going back to my Terminal do issue shell commands on the server. It seems like ansi-term could help a lot here, but the first thing I'd be doing in the ansi-term buffer would be sshing to a server; once I do, I'm finding that some things don't work, for example if I try to run 'top' I get the error "'eterm-color': unknown terminal type."
I'm not even completely sure which would be better to fix -- get emacs on the servers set up nicer, or get it working better to run ssh sessions to the servers within M-x ansi-term on my local machine's emacs.
In my shell environment I have aliases and custom functions. When I am in an instance of emacs (I always use emacs -nw) and I execute a shell command (M-!) I cannot use them. This makes sense since I imagine it launches it's own subshell to do these... but is there a way (maybe in my .emacs) to get this to work? Perhaps even if it involved sourcing an environment by default before executing any shell command given?
We need to enable alias expansion in non-interactive shells, preferably only when they are called from emacs (to avoid causing subtle differences when we run other shells). What worked for me was to create two files: /.alias has all my aliases, e.g.
For non-interactive shells, the only file that is sourced is the value of the BASH_ENV environment variable. You invoke emacs like BASH_ENV=/.bashrc emacs if emacs will use bash for shell commands -- some programs specifically use "/bin/sh"
To get shell-command to read /.bashrc before executing the command per the technique described in , without potential side effects due to $BASH_ENV being defined for your entire Emacs session, try this in your /.emacs.d/init.el (or .emacs) file:
Note that your /.bashrc might need to be changed to define non-interactive aliases even when [ -z "$PS1" ] is true (which indicates a non-interactive shell). That's the approach I'm taking for my own environment (such as it is), which is at
Setting shell-command-switch directly will substantially make shell-command much more sluggish (if you use many (baz)sh plugins), which is invoked by various non-interactive functions like shell-command-to-string, eshell-remote-command,... and numerous calls of it from other functions, all of which won't ever need .bashrc or .zshrc
I'm trying cygwin with emacs.My environment is Windows 7 x64, emacs-24.0.93.1, cygwin 2.769, system encoding is gbk, cygwin's coding system is default to utf-8, and emacs's coding system is default to gbk
Emacs sends the new shell the contents of the file /.emacs_SHELLNAME' as input, if it exists, where SHELLNAME is the name of the file that the shell was loaded from. For example, if you use bash, the file sent to it is/.emacs_bash'. If this file is not found, Emacs tries with `/.emacs.d/init_SHELLNAME.sh'.
start a new terminal (bash) with strace -o bash.log bash could help debugging this problem. What it looks like is that some device that bash tries to open is missing appropriate permissions or doesn't even exist.
During the cygwin setup process, make sure to choose the emacs packages - I picked "regular" emacs, emacs-x11, and emacs-w32 (native compiled for windows). The emacs-w32 looks/feels just like the regular Windows emacs binary as far as I can tell.
You will probably also want to pass the --login argument to bash, because you're starting a new Cygwin session. You can do that by setting explicit-bash-args. (Note that M-x shell uses explicit-PROGRAM-args, where PROGRAM is the filename part of the shell's pathname. This is why you should not include the .exe when setting the shell.
This elisp snippet belongs in your /.emacs file. If you want to use Cygwin instead of MinGW, change the first string to C:/cygwin/bin/bash. The second string is prepended to your Windows PATH (after converting that PATH to an appropriately unixy form); in Cygwin you probably want "/bin:/usr/local/bin:/usr/bin:" or something similar.
If you setup Emacs to use cmd as the shell (which is the way NT emacs installs), then dos shell works fine, but if you type bash or bash -i to run a bash shell, the resulting shell doesn't work right - see answer 0.
The --noediting option prevents interference with the GNU readline library and the -i option specifies that the shell is interactive. I also use the .emacs_bash file in my home directory for any emacs specific bash customizations.
You can look in the "standard" bashrc (/etc/bashrc). You should see code that checks for an iteractive shell (is PS1 set), and then checks for xterm (looking at $TERM variable), and does something different there than for other terminal types.
I suspect somewhere in the bash initialization is a hard-coded setup, which should only be done on xterm-compatible console programs. Read man bash to find a total list of files you can look for and through.
It may be something to do with the terminal type of the emacs shell vs your regular shell. Check what the TERM environment variable is set to in both shells. If they are different then you should be able to change the emacs shell terminal type or use a different PS1 definition for the emacs terminal type in .bashrc.
I'm using Git Bash on Windows 7 and have a problem with setting up emacs as the default text editor - I've tried git config --global core.editor emacs, then git config --global core.editor "'C:/emacs-23.3/bin/runemacs.exe'", git config --global core.editor emacsclientw but to no avail. Each time I enter something like 'emacs README.txt' in Bash, the below error shows:
I've put up with this for the longest time, choosing to just open up emacs separately and opening up the related file, but this time I really want to set things up properly so that I can save time and simply invoke emacs from Git Bash. Does anyone know what I can do? Thanks in advance for your help.
You need to ensure the emacs bin directory is on the PATH so that the binary can be found when just entering emacs or emacsclient. You can set the default editor for most unix type tool to use your current emacs session by setting the environment variable EDITOR to emacsclient. You should use emacsclient rather than emacsclientw because you need the launching tool to wait for the edit to be completed and they do that by waiting for the editor to exit. If you only want git to use this then git config --global core.editor emacsclient would do the job, or setting GIT_EDITOR=emacsclient in the environment.
Emacs sends the new shell the contents of the file/.emacs_shellname as input, if it exists, whereshellname is the name of the file that the shell was loadedfrom. For example, if you use bash, the file sent to it is/.emacs_bash. If this file is not found, Emacs tries with/.emacs.d/init_shellname.sh.
It works in the terminal but not in the Emacs shell. What conspiracy is this? Turns out that Emacs and bash have put a lot of effort into making sure completion does not work. The first thing to notice is that explicit-bash-args contains the argument --no-editing, which will disable readline completion. Let get rid of that shall we?
I'm starting to use emacs more and more as my main editor, but I would like to know how to make it always run in the terminal. I currently launch it as "emacs -nw" because I created a bash alias that runs it like that when I type "emacs".
Another problem is that I can't set it as the default editor in my .bashrc. I use midnight commander for file management, and it looks for the default bash editor when I choose to edit a text file. If I set the default editor as "emacs", even when I have an alias set for emacs to run emacs -nw, the program still launches its GUI mode. Attempting to set "EDITOR emacs -nw" returns an error.
df19127ead