A nicer shell ?
Stelios Kyriacou
Hi to everybody: I have a quick question. When i open a shell in
xemacs (probably same happens for emacs) i get:
tcsh: using dumb terminal settings.
And due to the dumb terminal settings the terminal emulation is not as
good as an xterm emulation - Is there a nicer shell mode?
Thanks for any help
Stelios
Anders Stenman
kyri...@umbc.edu (Stelios Kyriacou) writes:
>
> Hi to everybody: I have a quick question. When i open a shell in
> xemacs (probably same happens for emacs) i get:
> tcsh: using dumb terminal settings.
This happens bacause you don't have any entry for TERM=emacs in your
terminfo database (located at '/usr/share/lib/terminfo' on my system
[Solaris 2.5]). I think that terminfo files for emacs is included in the
distribution, so one way of fixing this is to put
(setenv "TERMINFO" data-directory)
in your '.emacs' file.
>
> And due to the dumb terminal settings the terminal emulation is not as
> good as an xterm emulation - Is there a nicer shell mode?
Try the eterm package, i.e. 'M-x term'!
/Anders
--
______________________________________________________________
Anders Stenman
| Division of Automatic Control
/|\ Dept. of EE, Linköping University
\|/ S-581 83 Linköping, Sweden
/|\ Tel: +46 13 284079
/ | \ Email: ste...@isy.liu.se
() | () WWW: http://www.control.isy.liu.se/~stenman
Bryan Oakley
Stelios Kyriacou wrote:
Hi to everybody: I have a quick question. When i open a shell in
xemacs (probably same happens for emacs) i get:
tcsh: using dumb terminal settings.
good as an xterm emulation - Is there a nicer shell mode?
Stelios
Try M-x terminal-emulator
--
Bryan Oakley, Software Engineer
Healthcare Communications, Inc.
oak...@healthcare.com
Martin Buchholz
>>>>> "Stelios" == Stelios Kyriacou <kyri...@umbc.edu> writes:
Stelios> Hi to everybody: I have a quick question. When i open a shell in
Stelios> xemacs (probably same happens for emacs) i get:
Stelios> tcsh: using dumb terminal settings.
Stelios> And due to the dumb terminal settings the terminal emulation is not as
Stelios> good as an xterm emulation - Is there a nicer shell mode?
If you want a run curses-based programs, it's probably best to use
xterm. shell-mode is best for running programs that just use
stdin/stdout. This is not necessarily bad. I have mostly weaned
myself from using curses-based programs. XEmacs gives you most of the
editing capabilities you need for free. The main curses program
people tend to run is vi, and there's no need for *that*, when you're
in XEmacs already anyways.
There exist terminal emulators within XEmacs that do support curses:
terminal.el and term.el - you may want to give them a try (I don't use
them).
Martin
--
Martin Buchholz
XEmacs Developer
Developers' Product Business Unit, SunSoft, Sun Microsystems, Inc.
Mailstop: MPK16-305 | Email: Martin....@sun.com
2550 Garcia Avenue | Phone: (415) 786-5895
Mountain View, CA 94043-1100 | Fax: (415) 786-9552
tim werner
>From: Bryan Oakley <oak...@healthcare.com>
>Date: Fri, 31 May 1996 09:03:05 -0600
>Try M-x terminal-emulator
I tried this, and also M-x term, and neither one would let me use "C-x"
or "Esc" sequences to switch out of the buffer. I had to use the mouse
to get out. How do you use them in "-nw" (no window) mode?
thanks,
tw
--
The shadow of the bamboo sweeps the steps,
but the dust does not stir.
Per Bothner
In article <WERNER.96J...@asta.mc.ab.com>,
tim werner <wer...@asta.mc.ab.com> wrote:
>I tried ... M-x term [which did not] let me use "C-x"
>or "Esc" sequences to switch out of the buffer. I had to use the mouse
>to get out. How do you use them in "-nw" (no window) mode?
From the README:
In character ("raw") sub-mode:
Each character type is sent to the inferior process, except for C-c.
C-c C-c Send a C-c to the inferior.
C-c C-j Enter line sub-mode
C-c OTHER Same as cooked C-x map
In line ("cooked") mode:
Like traditional shell mode
C-c C-k Enter character sub-mode
The README contains much useful information. It should be in the
xemacs distribution.
I'll see if I can get my changes to the manual merged in.
--
--Per Bothner
Cygnus Support bot...@cygnus.com
Ben Wing
|>Date: Fri, 31 May 1996 09:03:05 -0600
|
|>Try M-x terminal-emulator
|
|or "Esc" sequences to switch out of the buffer. I had to use the mouse
|to get out. How do you use them in "-nw" (no window) mode?
Try C-c C-x b or something like that.
ben
--
"... then the day came when the risk to remain tight in a bud was
more painful than the risk it took to blossom." -- Anais Nin
tim werner
[also posted]
>From: bot...@cygnus.com (Per Bothner)
>Date: 10 Jun 1996 18:52:59 -0700
>From the README:
>In character ("raw") sub-mode:
>Each character type is sent to the inferior process, except for C-c.
I don't seem to be getting that. When I type a TAB, it just gets echoed
to the term buffer, instead of being sent to tcsh. The reason I am
trying an alternative to shell.el is that I have grown weary of it's
inability to keep track of the current directory, and the way that
completely messes up filename-completion. Tcsh does a fine job with
completion. How do I get term.el to pass TAB, C-x, C-a, C-u, and so on,
directly to tcsh?
>The README contains much useful information. It should be in the
>xemacs distribution.
I am running emacs-19.31. Is there any documentation in that
distribution?
Per Bothner
In article <w4rohmm...@asta.mc.ab.com>,
>>In character ("raw") sub-mode:
>>Each character type is sent to the inferior process, except for C-c.
>
>I don't seem to be getting that. When I type a TAB, it just gets echoed
>to the term buffer, instead of being sent to tcsh.
If you're runnning under X, some of the special keys are special events.
The keybindings in "raw-mode" may not be quite right. (Esc is known
to only work as a prefix character, which means using vi is difficult.)
However, tab does work for me using 19.30 under Linux under X,
and as far as I know it still works in 19.31.
Make sure that the mode-line say "Term: char run". That indicates it
it is in char (raw) mode. "Term: line run" indicates it is in
line (cooked) mode. See below for more info.
>The reason I am trying an alternative to shell.el is that I have grown
>weary of it's inability to keep track of the current directory, and
>the way that completely messes up filename-completion.
You can ask the shell to *tell* Term what the current directory is.
See below.
>Tcsh does a fine job with completion. How do I get term.el to pass TAB, C-x,
>C-a, C-u, and so on, directly to tcsh?
This should all work, as long as you are in char mode.
>I am running emacs-19.31. Is there any documentation in that
>distribution?
Not as far as I know. Here is the current README.eterm:
This new term-mode is a merge of the comint shell mode with a
ANSI-compatible terminal-emulator.
If you're using emacs-19.23 (or newer) or xemacs-19.11 (or newer),
and only want the terminal-emulator itself, just load the file
term.el. (You probably want to byte-compile it first, especially
if you have a slow machine.)
To start term do M-x term RETURN.
Compared to terminal.el:
* Uses standard ANSI (vt102) escape sequences.
* High-lighting (inverse video, underline, bold) are supported.
* Fully integrated into shell mode.
* Can switch back and forth between character mode (acts like xterm)
and line mode (acts like old shell mode).
* Tab and line breaks are stored in buffer (so cut and paste will get
the correct tabs and line breaks), but terminal motion uses the
"visible" layout of the screen (and display programs can assume
tab, cr and lf work as on plain terminal).
In character ("raw") sub-mode:
Each character type is sent to the inferior process, except for C-c.
C-c C-c Send a C-c to the inferior.
C-c C-j Enter line sub-mode
C-c OTHER Same as cooked C-x map
Can use bash line editing, filename completion, and history.
Can run emacs in an emacs window! (bash users first do: export -n DISPLAY)
In line ("cooked") mode:
Like traditional shell mode
C-c C-k Enter character sub-mode
Either character or line sub-mode:
C-c C-q Toggle pager sub-mode (enable or disable)
The "pager" provides functionality similar to the "more" program:
Whenever a screenful has been received, emacs stops reading from
the process until you type the appropriate key. (The key 'h' provides help.)
The pager is smart enough that you can leave it on, even while
running full-screen interactive programs inside a shell window.
(The pager does not work under xemacs 19.11.)
The file tshell.el is a preliminary replacement for shell mode.
After loading it, you invoke it with M-x tshell RET.
This needs a little work, and is not recommended. It differs from
term-mode in that it starts in line mode, and it performs directory
tracking. Such directory tracking cannot be made reliable.
It you're running bash, it is better to just use term-mode and have
bash tell term the current directory. You can do that by adding
the following to your ~/.bashrc:
if [ "$TERM" = "eterm" ]; then
PROMPT_COMMAND='echo "^Z/${PWD}"'
fi
[Note the ^Z is a literal ctrl/Z.]
The file tgud.el is a preliminary replacement for gud.el, including
gdb-mode. After loading it, invoke "tgdb-mode" with M-x tgdb RET.
An alternative is to run gdb from term (or tshell) mode.
Just start gdb with the --fullname flag. This will cause gdb to
ask emacs to display proper source frame on break-points -
even over a telnet/rlogin link! You would not be able to use the
gud-specific commands, but you can use gdb/readline line editing.
If you're using terminfo, copy the e directory (itself, not just
the files in it) into the emacs 'etc' directory (as given by
ESC ESC data-directory RET), so you have ..../etc/e/eterm.
(Your system uses terminfo if ESC ESC (boundp 'system-uses-terminfo) RET
return t.) If you can't do that, replace the word "data-directory"
in term.el by a string naming this directory.
The file TODO.term notes ideas for improvements.
The file term.texi contain some notes that one day may become part
of a manual.
Term.el will be in the next emacs release from the FSF.
It will also probably be in the next xemacs release.
The comint-based shell.el and gud.el will be replaced later.
Telnet.el can then be junked.
Long-term, term.el will replace comint.el, but can co-exist with it.
Comments and bug fixes should be sent to Per Bothner (bot...@cygnus.com).
Note that I'm new to emacs hacking, so improvements are very welcome.
tim werner
[this was also posted]
>From: bot...@cygnus.com (Per Bothner)
>In article <w4rohmm...@asta.mc.ab.com>,
>>>In character ("raw") sub-mode:
>>>Each character type is sent to the inferior process, except for C-c.
>>I don't seem to be getting that. When I type a TAB, it just gets echoed
>>to the term buffer, instead of being sent to tcsh.
>However, tab does work for me using 19.30 under Linux under X,
>and as far as I know it still works in 19.31.
>Make sure that the mode-line say "Term: char run". That indicates it
>it is in char (raw) mode. "Term: line run" indicates it is in
>line (cooked) mode. See below for more info.
>This should all work, as long as you are in char mode.
When I start term, it comes up in "Term: char run" mode. And all the
control characters are just echoed to the buffer instead of being passed
to the shell.
Haven't tried it on my Linux box, yet. I'm sitting at a DECstation-5000
running Ultrix-4.3 with fvwm. Windowing back to my workstation from a
Sparc SunOS-4.3 box it behaves the same (wrong) way.
Maybe there is something wrong with the version of term.el that is
shipped with emacs-19.31? The version I have doesn't seem to have any
version or date, but I can tell you it is 3261 lines long.
Kai Grossjohann
>>>>> On 14 Jun 1996 14:52:35 -0400, wer...@asta.mc.ab.com (tim
>>>>> werner) said:
tim> [...] The reason I am trying an alternative to shell.el is
tim> that I have grown weary of it's inability to keep track of the
tim> current directory, and the way that completely messes up
tim> filename-completion. [...]
While I think that eterm is a useful thing (I use xterm for that,
though :) I would like to call your attention to the nifty shellFOO
packages by Si.
There is shelldb, shellt, shellc and shells and one other (which
doesn't start with shell) all of which can be found in the LCD.
The combination of these allows you to do nifty stuff like typing
`find . -na' then hitting TAB and getting the `-na' expanded to
`-name'. Of course, you can define your own completions for commands,
so that `lpr -P TAB' gives you a list of printers and stuff like that.
Also, I have rather seldom got any problem with shellt losing track of
the current directory. Sometimes, strange things appear on my screen
(`IgnoreThisLineOfDirectoryInfo' or something); I just hit RET once
again and everything is just fine.
There is also j-shell which I had been using a couple of years ago.
Don't know if it still works, though. Also nice.
hth,
kai
--
Life is hard and then you die.
Miles Daly Duke
wer...@asta.mc.ab.com (tim werner) wrote:
>The reason I am
>trying an alternative to shell.el is that I have grown weary of it's
>inability to keep track of the current directory, and the way that
>completely messes up filename-completion.
I used to have a problem with that, but there's a variable or command
controlling whether shell.el should try to follow cd, pushd, popd
commands, etc. Something like "shell-dirtrack-toggle". The things
that cause problems are:
- aliases that change the directory to something not deducible from
the command line. A simple alias for cd/pushd/popd would not be a
problem, because you can specify a regexp that tells shell.el which of
those commands to look out for. A "supercd" alias that lets you enter
part of the path and figures out the rest is a problem, because
shell.el doesn't see the path you are cd'ing to.
- when you repeat a cd/pushd/popd using the ! command instead of using
Meta-n or Meta-p to suck the retrieve the command from shell.el's
history. [ This seems odd, because csh echos the substituted command,
but perhaps shell.el doesn't know to look at it ]
In any case, if you get off track, you can always run M-x
shell-resync-dirs and shell.el should resynchronize with your current
directory stack.
Mind you, I am using XEmacs 19.13, so perhaps it was bundled with a
different version of shell.el.
Scott Byer
Miles Daly Duke writes:
Miles> wer...@asta.mc.ab.com (tim werner) wrote:
>> The reason I am trying an alternative to shell.el is that I have grown
>> weary of it's inability to keep track of the current directory, and the
>> way that completely messes up filename-completion.
Miles> I used to have a problem with that, but there's a variable or command
Miles> controlling whether shell.el should try to follow cd, pushd, popd
Miles> commands, etc. Something like "shell-dirtrack-toggle". The things
Miles> that cause problems are:
A solution that I've used very successfully for a while now - though a
little complex - is to have my shell spit out escape sequences containing
the current directory name and to have a comint filter prepared to find
them. You can do all sorts of funky stuff like this (I have shell
"commands" that invoke emacs for editing a file, grepping in a directory,
starting a make, or ediffing two files).
This method is so much more robust, captures the _true_ pathname of the
working directory. But it does require .cshrc (or whatever) to be setup
properly.
--
Scott Byer, Unix Photoshop Project Lead mailto:by...@mv.us.adobe.com
Adobe Systems Incorporated These are my opinions, and
1585 Charleston Road, P.O. Box 7900 do not necessarily reflect
Mountain View, CA 94039-7900 the opinions of my employer.
=== ===
tim werner
>From: mil...@atl.mindspring.com (Miles Daly Duke)
>Date: Wed, 19 Jun 1996 01:08:05 GMT
>wer...@asta.mc.ab.com (tim werner) wrote:
>>The reason I am trying an alternative to shell.el is that I have grown
>>weary of it's inability to keep track of the current directory, and
>>the way that completely messes up filename-completion.
>I used to have a problem with that, but there's a variable or command
>controlling whether shell.el should try to follow cd, pushd, popd
>commands, etc. Something like "shell-dirtrack-toggle".
I just tried turning off directory tracking, and this doesn't really
help. The main problem with shell when it loses track of the directory
is that it breaks filename completion. Shell.el is still trying to do
filename completion, instead of letting tcsh do it.
Kai Grossjohann
>>>>> On 24 Jun 1996 09:23:33 -0400, wer...@asta.mc.ab.com (tim
>>>>> werner) said:
tw> I just tried turning off directory tracking, and this doesn't
tw> really help. The main problem with shell when it loses track of
tw> the directory is that it breaks filename completion. Shell.el
tw> is still trying to do filename completion, instead of letting
tw> tcsh do it.
Emacs shell *always* does filename completion. If you turn off
directory tracking, filename completion will work even less well.
I advise you to consider the fabulous shell*.el files from Simon
Marshall. Among them is a file that tells the shell to spit out some
magic string that Emacs detects and extracts the current directory
from it. Another is a file that lets you do completion even for
command line arguments: You enter
find -n TAB
and shell completes
find -name
How's that?
Kai Grossjohann
>>>>> said:
>>>>> On 24 Jun 1996 21:16:35 +0200, Kai Grossjohann said:
Kai> I advise you to consider the fabulous shell*.el files from
Kai> Simon Marshall.
Justin> Where are these?
archive.cis.ohio-state.edu in a directory called elisp-archive. I
forget the exact location. In that directory, you will find a file
LCD-datafile which you can search in. In that file "~" means the
directory where you found the LCD-datafile.
Justin> Any recommendation in terms of csh vs. ksh?
Theses shell*.el files work just as well with csh as with ksh. But
when you use csh you will have to get used to the fact that the Emacs
shell mode uses TAB for filename completion (as does the rest of
Emacs) rather than ESC like the csh does.
Also, it is important to realize that the concept of the *shell* mode
is that Emacs reads one line of input, and only when you hit RET is
that line sent to the shell. This means that programs that expect
single-character inputs won't work.
Russ Allbery
>>>>>> wer...@asta.mc.ab.com (tim werner) said:
tw> I just tried turning off directory tracking, and this doesn't really
tw> help. The main problem with shell when it loses track of the
tw> directory is that it breaks filename completion. Shell.el is still
tw> trying to do filename completion, instead of letting tcsh do it.
I definitely hear you. I use cdpaths constantly.
> I advise you to consider the fabulous shell*.el files from Simon
> Marshall. Among them is a file that tells the shell to spit out some
> magic string that Emacs detects and extracts the current directory from
> it. Another is a file that lets you do completion even for command line
> arguments: You enter
> find -n TAB
> and shell completes
> find -name
> How's that?
Sounds like tcsh. Try:
complete find 'C/-*/(-name -exec -print -mode)/'
(adding more switches, of course).
tcsh is quite good at being tcsh. emacs does not need to try to be tcsh
too. :)
--
Russ Allbery (r...@cs.stanford.edu) <URL:http://www.eyrie.org/~eagle/>
giacomo boffi
> tcsh is quite good at being tcsh. emacs does not need to try to be
> tcsh too. :)
please explain your point --- emacs succeded in being everything
else, why emacs should leave tcsh alone?
ty
gb
Russ Allbery
Good question. And if someone ever implements as good of a shell in emacs
as Gnus is a news/mail reader, maybe I'll change my mind. But it hasn't
happened yet, a shell "feels" different than a mail or news reader in this
respect, tcsh has a lot of features that emacs *doesn't* have, and I
object to emacs actively interfering with a person's ability to use those
features.
Steve Kettle
In article <960629102...@hp735.stru.polimi.it>,
giacomo boffi <bo...@hp735.stru.polimi.it> wrote:
>Russ Allbery writes:
> > tcsh is quite good at being tcsh. emacs does not need to try to be
> > tcsh too. :)
>
> please explain your point --- emacs succeded in being everything
> else, why emacs should leave tcsh alone?
>
> gb
Hey if emacs can be made to behave like tcsh that's great - I just hope
that you woun't have to jump through to many hoops to get it to behave
like tcsh.
Steve.
--