zsh in Emacs output junk characters - emacs

No matter I use term or ansi-term to start zsh in Emacs, I encounter this problem, whenever I input commands, the output will have some junk characters like:
[ruby-1.9.2] ~ pwd
2;pwd1;pwd/Users/tyraeltong
the 2;pwd1;pwd is screwing the output, don't know whether others are experiencing same problem? I found a similar thread here Getting Emacs ansi-term and Zsh to play nicely but by [[ $TERM == eterm-color ]] && export TERM=xterm I still see the junk characters.

Emacs doesn't play nice with ZLE, so I have this in my ~/.zshrc:
if [[ -n ${INSIDE_EMACS} ]]; then
# This shell runs inside an Emacs *shell*/*term* buffer.
prompt walters
unsetopt zle
fi

Found the solution in the related post mentioned earlier
In a nutshell, in emacs M-x package-install and install multi-term. M-x multi-term kicks off a shell, with all the bells & whistles oh-my-zsh has to offer

It could be an erronious PROMPT_COMMAND that has bash syntax. Try:
export PROMPT_COMMAND=""
and see if that helps.

Related

How to stop Emacs from rendering junk characters in shell?

In my emacs shell, I see this output:
^[[J~% echo $PS1
%2c%%
On my other machine, this stuff doesn't show up at all. Can anyone suggest a reason why and how to fix it?
It's related to your PS1 setting. Basically Emacs will not accept TOO fancy settings of PS1. I used the following code in ~/.bashrc to distinguish PS1 between xterm and other term simulators such as Emacs. You can give it a try.
case $TERM in
xterm)
export PS1='\[\e]0;\u#\h: \W\a\]\[\e[31;1m\]\w\n\[\e[0m\]'
;;
*)
export PS1='\[\e[31;1m\]\w\n\[\e[0m\]'
;;
esac

How to view man pages using emacs when invoking man command in command line?

I would like to view man pages using emacs when invoking man command.
I modified the pager parameter in /etc/man.conf PAGER to emacs.
But, it doesn't work. Is there anything I should modify ?
Indeed, emacs cannot read STDIN into a buffer, meaning
cat foobar | emacs
does not work in any case. So setting your PAGER variable to 'emacs', or 'emacs -nw' does not do the job.
Only way around I see is to write the man output into a tmp-file and then load that file into emacs:
man find > tmp-file; emacs tmp-file
You could alias this.
For example, assuming a tc-shell, and a directory called 'tmp' in your home-path, you can put the following line into your ~/.tcshrc file:
alias man '/usr/bin/man \!* > ~/tmp/tmp-file; emacs ~/tmp/tmp-file; rm ~/tmp/tmp-file'
So next time you call man find, emacs will fire up.
Emacs has a "Man mode", which can be invoked by M-x man RET and then typing in your command.
You can profit from emacs's function man. Just define a function in bash that will run emacs that will call it:
function man () {
emacs -e '(man "'"$1"'")'
}
You might want to call emacs -nw or even emacsclient instead.

Emacs: Tramp doesn't work

I tried to open a remote file via Emacs via Tramp.
(require 'tramp)
(setq tramp-default-method "ssh")
I get a message from Emacs
Tramp: Waiting for prompts from remote shell
Emacs hung and did not respond to any action after that
Emacs was installed on Windows; the remote file was on a Linux machine.
If the account you're connecting to uses some weird fancy shell prompt, then there is a good chance that this is what makes tramp trip.
Log in as root, then enter
PS1="> "
(that's a normal, standard shell (ZSH, BASH, younameit) prompt, one that tramp will understand)
then switch to the user account, and launch emacs -q (to make sure that your .emacs is not causing this mess) and try to C-x C-f /sudo:root#localhost:/etc/hosts and see what's what.
You can (not recommended) also customize the regexp that defines what tramp expects :
M-x customize-variable RET tramp-terminal-prompt-regexp
My approach :
Make sure the variable tramp-terminal-type is set to "dumb"
M-x customize-variable RET tramp-terminal-type
Test that in your .*shrc and serve the correct prompt :
case "$TERM" in
"dumb")
PS1="> "
;;
xterm*|rxvt*|eterm*|screen*)
PS1="my fancy multi-line \n prompt > "
;;
*)
PS1="> "
;;
esac
Your Windows ssh client is the key here, and the 'ssh' Tramp method is almost certainly wrong.
If you're using Cygwin, then you need to use the 'sshx' method, and you probably need to use ssh-agent to handle authentication. Details are here:
Using tramp with EmacsW32 and cygwin, possible?
I imagine the same applies to any stand-alone ssh client which does not require a full Cygwin installation, but does use the Cygwin DLLs. (I mention this, because I'm pretty sure I remember seeing such a thing.)
If you're using PuTTY then you want the 'plink' method, as Alex Ott pointed out. If the Wiki doesn't suffice, a search here will probably turn up solutions for configuring that approach.
Other alternatives I can suggest are:
Use the Cygwin-native Emacs. That will be slower than NTEmacs, but Tramp seems to work well with the 'ssh' method, and password-prompting works as well.
Host a Linux VM on your Windows box, and run Emacs on that. That's a fairly large hoop to jump through, but it's my preferred way of using Tramp when working in Windows.
Well, this is a defect of tramp.
The real solution is to prevent loading .bashrc when tramp is used. (because now it is PS1, but it can be PATH, or any other thing that your .bashrc will do that will displease tramp...).
This can be done by asking ssh to set an environment variable, and testing it in .bashrc:
Add this to ~/.emacs:
(require 'tramp-sh nil t)
(setf tramp-ssh-controlmaster-options (concat "-o SendEnv TRAMP=yes " tramp-ssh-controlmaster-options))
and that at the beginning of ~/.bashrc:
if [ ! -z ${TRAMP-x} ] ; then
return
fi
Another default of tramp is that it doesn't have a variable to pass random arguments to the ssh command, we have to piggy-back on tramp-ssh-controlmaster-options.
Had you checked Emacs wiki for solution? ssh is in PATH? It's also recommended to use plink on MS Windows - see section "Inline methods" in Tramp documentation
If the problem is your fancy custom prompt in the remote shell, an easy workaround is to add to your .bashrc or equivalent:
if [[ $TERM == "dumb" ]]; then
export PS1="$ "
fi
After you define your PS1.
Note: the credit goes to ChasingLogic as this is their suggestion in this thread.
By the way -- if You need tramp to sudo -- You can actually sudo without tramp using sudoedit.
Currently I'm using this bash function:
erf () { SUDO_EDITOR="emacsclient -a emacs" sudoedit $#; }

emacsclient window focus

How do I consistently control window focus after running emacsclient?
Currently, focus depends on if I already have an emacs server running. When emacsclient invokes an alternative editor, focus is shifted to the new emacs window. When emacsclient connects to an existing emacs server, focus is not shifted (ie. it stays on my putty client).
I would like to consistently focus on the emacs window, since I usually go to emacs after opening a file.
Any help would be greatly appreciated!
Notes
Version Info
emacs: 21.4.1
emacsclient: 21.4
client os: Windows XP Service Pack 3
x server: Exceed 11.0.0.0
Relevant section of my .bash_profile
# a wrapper is needed to sandwich multiple command line arguments in bash
# 2>/dev/null hides
# "emacsclient: can't find socket; have you started the server?"
emacs_wrapper () {
if [ 0 -eq $# ]
then
emacsclient -n -a emacs ~/notes.txt 2>/dev/null &
else
emacsclient -n -a emacs $* &
fi
}
alias x="emacs_wrapper"
Also, at the end of my .emacs I have
(server-start)
My current workaround is a simple autohotkey script, which focuses on my first Exceed window
^+x::
If WinExist("ahk_class EXCEEDW:MWCLIENT0")
WinActivate
return
As a side note, it seems my redirection to /dev/null confused the syntax-highlighter :(
How about:
emacsclient -e "(select-frame-set-input-focus (selected-frame))"
works for me on emacs 23.1
To unfocus (lower-frame) might be useful.
Would the "--create-frame" option to emacsclient work for you? You'd get a new frame for each file you opened this way, but at least it would be focused (I think).
For some unknown reason, the issue fixed itself. Opening files now consistently changes focus to the emacs frame with the corresponding file. I'm honestly unsure what changed the behavior, but I'm happy.
Thanks to everyone for their comments and suggestions!

Commands from .bashrc not available in Emacs

I have some aliases and functions defined in ~/.bashrc.
I start emacs from a terminal window using emacs -nw
When I execute M-x shell-command, the aliases and functions from ~/.bashrc are not available, but give a "command not found".
I've googled quite a bit but all the posts I come across say, if I understand them correctly, that ~/.bashrc is the place where this should work (rather than ~/.profile or ~/.bash_profile).
What am I missing?
Aliases are available only in interactive shell - a snapshot from bash man page:
Aliases are not expanded when the
shell is not interactive, unless the
expand_aliases shell option is set
using shopt
(see the description of shopt under SHELL BUILTIN COMMANDS below).
If you start Emacs from an interactive shell (in which .bashrc, etc. have executed), then the commands from your .bashrc should be available for both shell-command and shell, at least that's how it works for me.
But yeah as the other answer says, there is not real way to get a .bashrc environment in emacs. There are some documentation about a .emacs_bash file, but that never worked for me.
Okay misread your question here. If you are looking for functions and aliases instead of commands by changing paths in .bashrc, the non-interactiveness is the problem. I guess you can change the default argument to shell-command (take a look at explicit-bash-args) to make bash interactive, but that probably has unintended consequences.
The accepted answer correctly states that "aliases are available only in interactive shell".
This means that in order to load (rightly located indeed) aliases from ~/.bashrc, an interactive shell would have to be launched with Emacs's M-x shell-command (M-!).
To achieve this, add -i (interactive) switch to the M-x shell-command with:
(setq shell-command-switch "-ic")
Side Note, not Emacs related:
On some operating systems users would need to add the line source ~/.bashrc to ~/.bash_profile (or similar), since ~/.bashrc is not always auto-read by a system.