WARNING: terminal is not fully functional
Irving Kimura
I find it infuriating that M-x shell does not give me a fully
functional bash (or rather, a fully functional terminal). For
instance, I can't pipe things through less ("WARNING: terminal is
not fully functional"). And /bin/ls --color results in gobbledygook.
Etc.
Of course, my main reason for using M-x shell is to be able to
treat stdout as any other Emacs buffer. (In particular, I find it
very useful to be able to easily copy selected chunks of stdout to
another Emacs buffer.) Is this capability fundamentally antithetical
to a "fully functional terminal" that would allow me to pipe outputs
through less, run /bin/ls --color, run man, run top, etc? If not,
is there any way to configure Emacs so that M-x shell operates
under a "fully functional terminal"?
Thanks!!!
-Irv
lawrence mitchell
> I find it infuriating that M-x shell does not give me a fully
> functional bash (or rather, a fully functional terminal). For
> instance, I can't pipe things through less ("WARNING: terminal is
> not fully functional"). And /bin/ls --color results in gobbledygook.
> Etc.
> Of course, my main reason for using M-x shell is to be able to
> treat stdout as any other Emacs buffer. (In particular, I find it
> very useful to be able to easily copy selected chunks of stdout to
> another Emacs buffer.) Is this capability fundamentally antithetical
> to a "fully functional terminal"
No, but the way Emacs interacts with the external shell,
claiming to be a dumb terminal, is. I think.
> that would allow me to pipe outputs through less, run /bin/ls
> --color, run man, run top, etc? If not, is there any way to
> configure Emacs so that M-x shell operates under a "fully
> functional terminal"?
For the ls --color, you need to do M-x
ansi-color-for-comint-mode-on RET, or add it to some hook. This
will then correctly parse the colour escapes.
Regarding the others, there would seem to be no need to pipe
things through less when running a shell inside Emacs. After
all, the Emacs buffer has scrollback anyway. I can still use
less within an Emacs shell buffer, it just doesn't work that
well. For man pages, you could try M-x man RET, which reformats
man pages for viewing within Emacs.
I'm not sure what to do for top, I think there's an interface to
it somewhere, but I can't remember anything less vague than that.
> Thanks!!!
> -Irv
--
lawrence mitchell <we...@gmx.li>
Paolo Gianrossi
> I find it infuriating that M-x shell does not give me a fully
> functional bash (or rather, a fully functional terminal). For
> instance, I can't pipe things through less ("WARNING: terminal is
> not fully functional"). And /bin/ls --color results in gobbledygook.
> Etc.
for colors, get ansi-color.el from the ell, it resolves ansi color codes
nicely. less doesn't work, but more does... Anyway, why not open files in
an emacs buffer directly? man is bound to M-x man; top works for me, but
obviously, as it is actually inserting in a buffer, instead of changing
the screen, it replicates information *under* the old one...
hope it helps
paolino
--
God is dead. Nietzche
Nietzche is dead. God
-
Paolo Gianrossi
paoli...@disi.unige.it
Member of the GNU@DISI project.
Students Representative @ DISI, University of Genoa (ITALY)
Phillip Lord
Irving> I find it infuriating that M-x shell does not give me a
Irving> fully functional bash (or rather, a fully functional
Irving> terminal). For instance, I can't pipe things through less
Irving> ("WARNING: terminal is not fully functional"). And /bin/ls
Irving> --color results in gobbledygook. Etc.
This sounds to me like the system is just not recognising the terminal
type. I used to have this problem with ssh if I remember, as it
thought the terminal was no interactive.
Irving> Of course, my main reason for using M-x shell is to be able
Irving> to treat stdout as any other Emacs buffer. (In particular,
Irving> I find it very useful to be able to easily copy selected
Irving> chunks of stdout to another Emacs buffer.) Is this
Irving> capability fundamentally antithetical to a "fully functional
Irving> terminal" that would allow me to pipe outputs through less,
less is not going to work because its a pager. Nor is anything using
ncurses interfaces. You don't need less though. You can page back
using normal emacs buffer commands.
Irving> run /bin/ls --color, run man, run top, etc? If not, is
Irving> there any way to configure Emacs so that M-x shell operates
Irving> under a "fully functional terminal"?
I think that there is a ansi-color package around somewhere, which
turns the colour codes into colour.
In fact I've just found it. Type M-x ansi-color-for-comint and it all
works.
Cheers
Phil
Stefan Monnier
> functional bash (or rather, a fully functional terminal). For
M-x shell does not try to give you a fully functioning terminal.
Try M-x term RET if you want a terminal.
Stefan
Kevin Rodgers
> I find it infuriating that M-x shell does not give me a fully
> functional bash (or rather, a fully functional terminal).
Then run bash under M-x term (and `C-h f terminal-emulator' first).
> For
> instance, I can't pipe things through less ("WARNING: terminal is
> not fully functional"). And /bin/ls --color results in gobbledygook.
> Etc.
Because those terminal control sequences are not appropriate for M-x shell's
dumb terminal.
--
<a href="mailto:<kevin.rodgers@ihs.com>">Kevin Rodgers</a>
Pascal Bourguignon
Irving Kimura <irving...@lycos.com> writes:
(add-hook 'shell-mode-hook
'(lambda ()
(set-variable 'tab-width 8)
(ansi-color-for-comint-mode-on)
(process-send-string (get-buffer-process (current-buffer))
"alias less=cat ; alias more=cat")))
M-x term is no use for tops...
A good emacs exercise would be to add support for basic VT100 escape
sequences to shell or term, moving the cursor, and overwritting the
characters, etc. Should not be too difficult.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Irving Kimura
That almost worked! But ls hangs (in fact brings all of Emacs to
its knees) after printing the first line of files (in color,
though!). As I said, Emacs at this point falls into a deep coma;
the only thing to do is to kill -9 the process. What am I doing
wrong?
Thanks!
-Irv
Burton Samograd
> M-x term is no use for tops...
>
> A good emacs exercise would be to add support for basic VT100 escape
> sequences to shell or term, moving the cursor, and overwritting the
> characters, etc. Should not be too difficult.
Isn't that what M-x ansi-term is for? I just found it recently and it
works quite nicely, although you have to C-c before some commands are
passed to emacs.
--
burton samograd
kru...@kruhft.dyndns.org
http://kruhftwerk.dyndns.org
Kai Großjohann
> That almost worked! But ls hangs (in fact brings all of Emacs to
> its knees) after printing the first line of files (in color,
> though!). As I said, Emacs at this point falls into a deep coma;
> the only thing to do is to kill -9 the process. What am I doing
> wrong?
Starting from "emacs -q -no-site-file", can you reproduce this? If
so, please make a bug report and describe how you reproduced the
problem.
If you can't reproduce it from "emacs -q -no-site-file", then there
must be a problem in your init files.
--
This line is not blank.
Irving Kimura
>Irving Kimura <irving...@lycos.com> writes:
>> That almost worked! But ls hangs (in fact brings all of Emacs to
>> its knees) after printing the first line of files (in color,
>> though!). As I said, Emacs at this point falls into a deep coma;
>> the only thing to do is to kill -9 the process. What am I doing
>> wrong?
>Starting from "emacs -q -no-site-file", can you reproduce this? If
>so, please make a bug report and describe how you reproduced the
>problem.
I can definitely reproduce the bug starting from "emacs -q
-no-site-file". The problem seems to be confined to one machine,
though (when I tried the term command while Emacs was running on
a different host, ls and everything else worked normally), so I'm
not sure it is an Emacs bug.
I suppose that the problem with that machine has to do with to do with
the environment, but I have not being able to test this. This is
because when I start from "emacs -q -nw -no-site-file" and try "M-x
term" with "/usr/bin/env -i /bin/bash --noprofile --norc" I get:
..: [: too many arguments
..: /usr/bin/env -i /bin/bash --noprofile --norc: No such file or directory
..: exec: /usr/bin/env -i /bin/bash --noprofile --norc: cannot execute: No such file or directory
Process terminal exited abnormally with code 126
I'm not sure which files do not exist ("No such file or directory"),
since the only files mentioned definitely exist:
$ /bin/ls -l /bin/bash /usr/bin/env
-rwxr-xr-x 1 root root 511400 Apr 8 2002 /bin/bash
-rwxr-xr-x 1 root root 10332 Jul 26 2001 /usr/bin/env
Similarly, when I start from "env -i emacs -q -nw -no-site-file" and
try "M-x term" with "/bin/bash --noprofile --norc" I get:
I get similar results if I start from
..: [: too many arguments
..: /bin/bash --noprofile --norc: No such file or directory
..: exec: /bin/bash --noprofile --norc: cannot execute: No such file or directory
Process terminal exited abnormally with code 126
I this point I don't know what to do. I can report this as an Emacs
bug, but I really don't think I have isolated the problem to Emacs.
-Irv
Barry Margolin
Irving Kimura <irving...@lycos.com> wrote:
>I suppose that the problem with that machine has to do with to do with
>the environment, but I have not being able to test this. This is
>because when I start from "emacs -q -nw -no-site-file" and try "M-x
>term" with "/usr/bin/env -i /bin/bash --noprofile --norc" I get:
>
>
>
>..: [: too many arguments
>..: /usr/bin/env -i /bin/bash --noprofile --norc: No such file or directory
>..: exec: /usr/bin/env -i /bin/bash --noprofile --norc: cannot execute:
>No such file or directory
>
>Process terminal exited abnormally with code 126
>
>
>
>I'm not sure which files do not exist ("No such file or directory"),
>since the only files mentioned definitely exist:
The file you mentioned is "/usr/bin/env -i /bin/bash --noprofile --norc".
The spaces are being treated as part of the file name, it's not parsing it
as a shell command line (what shell should it use to parse it, if the whole
point is to specify the shell to use?).
Try creating a shell script that contains the "/usr/bin/env" command you
want, and then specify the pathname of that script as the shell to use with
M-x term.
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Tim X
lawrence> Irving Kimura wrote:
>> I find it infuriating that M-x shell does not give me a fully
>> functional bash (or rather, a fully functional terminal). For
>> instance, I can't pipe things through less ("WARNING: terminal is
>> not fully functional"). And /bin/ls --color results in
>> gobbledygook. Etc.
>> Of course, my main reason for using M-x shell is to be able to
>> treat stdout as any other Emacs buffer. (In particular, I find it
>> very useful to be able to easily copy selected chunks of stdout to
>> another Emacs buffer.) Is this capability fundamentally
>> antithetical to a "fully functional terminal"
lawrence> No, but the way Emacs interacts with the external shell,
lawrence> claiming to be a dumb terminal, is. I think.
>> that would allow me to pipe outputs through less, run /bin/ls
>> --color, run man, run top, etc? If not, is there any way to
>> configure Emacs so that M-x shell operates under a "fully
>> functional terminal"?
lawrence> For the ls --color, you need to do M-x
lawrence> ansi-color-for-comint-mode-on RET, or add it to some hook.
lawrence> This will then correctly parse the colour escapes.
lawrence> Regarding the others, there would seem to be no need to
lawrence> pipe things through less when running a shell inside Emacs.
lawrence> After all, the Emacs buffer has scrollback anyway. I can
lawrence> still use less within an Emacs shell buffer, it just
lawrence> doesn't work that well. For man pages, you could try M-x
lawrence> man RET, which reformats man pages for viewing within
lawrence> Emacs.
lawrence> I'm not sure what to do for top, I think there's an
lawrence> interface to it somewhere, but I can't remember anything
lawrence> less vague than that.
>> Thanks!!!
The view-process mode for emacs provides a 'top' equivalent. Not sure
where to find it though. Maybe do a google.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Tim X
Irving> In <5lllwpq...@rum.cs.yale.edu> "Stefan Monnier"
Irving> <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:
>>> I find it infuriating that M-x shell does not give me a fully
>>> functional bash (or rather, a fully functional terminal). For
>> M-x shell does not try to give you a fully functioning terminal.
>> Try M-x term RET if you want a terminal.
Irving> That almost worked! But ls hangs (in fact brings all of
Irving> Emacs to its knees) after printing the first line of files
Irving> (in color, though!). As I said, Emacs at this point falls
Irving> into a deep coma; the only thing to do is to kill -9 the
Irving> process. What am I doing wrong?
Irving> Thanks!
Irving> -Irv
Hi Irving,
I think you need to re-evaluate a bit how you do things. Everything
you need/want to do can be done very functionally from within emacs,
but you need to approach it in a different way. For example, instaed
of greping something and then passing ti to less, just use M-x
shell-command (bound to M-!). You will be prompted for the shell
command and the output from that command will be ut into an emacs
buffer which you can page through just like other emacs buffers.
Note that in fact, emacs has a built in grep, so you would probably
use that instead of the shell grep, but it suffices for an
example. Essentially, any shell command you execute with M-x
shell-command will write its ouput to a buffer where you can then
manipulate it as you want.
M-x shell gives you a very basic shell interface. Use ansi-color mode
to have it interpret ansi escape codes correctly. for a more
functional terminal, try out M-x term. For a very powerful shell
interface, try out M-x eshell - a shell written in emacs lisp which
will allow you to execute arbitrary emacs lisp functions as well as
provide basic shell interaction with the operating system.
For viewing man pages try either M-x man or M-x woman.
For viewing processes in a similar way to top, get hold of the
view-process mode.
Essentially, I find the best way for doing things when working with
emacs is to first check to see if emacs has the ability to get the
info or do what you want natively. If not, I then check to see if
there is an add on package which will do what I want and if that
fails, then I revert to using things like M-x shell, term, eshell. I
find 90% of the time, I can do everything from within emacs and rarely
need to resort to shell or term.
Pascal Bourguignon
> Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
> > M-x term is no use for tops...
> >
> > A good emacs exercise would be to add support for basic VT100 escape
> > sequences to shell or term, moving the cursor, and overwritting the
> > characters, etc. Should not be too difficult.
>
> Isn't that what M-x ansi-term is for? I just found it recently and it
> works quite nicely, although you have to C-c before some commands are
> passed to emacs.
Just try:
M-x ansi-term RETURN
RETURN
top RETURN
and get:
8:06am up 20:04, 8 users, load average: 2.57, 2.40, 2.33
124 processes: 113 sleeping, 10 running, 1 zombie, 0 stopped
CPU states: 1.7% user, 2.4% system, 36.0% nice, 0.2% idle
Mem: 1030876K av, 1015332K used, 15544K free, 0K shrd, 257944K buff
Swap: 3156648K av, 23308K used, 3133340K free 364616K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1736 pascal 20 19 14760 13M 800 R N 47.2 1.3 580:49 setiathome
1735 pascal 19 19 14792 13M 792 R N 46.3 1.3 580:43 setiathome
16275 pascal 16 0 988 984 740 R 6.4 0.0 0:00 top
1 root 8 0 76 64 44 S 0.0 0.0 0:04 init
2 root 9 0 0 0 0 SW 0.0 0.0 0:01 keventd
3 root 9 0 0 0 0 SW 0.0 0.0 0:00 kapmd
4 root 19 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0
5 root 9 0 0 0 0 SW 0.0 0.0 0:14 kswapd
6 root 9 0 0 0 0 SW 0.0 0.0 0:00 bdflush
7 root 9 0 0 0 0 SW 0.0 0.0 1:11 kupdated
Kevin Rodgers
> I think you need to re-evaluate a bit how you do things. Everything
> you need/want to do can be done very functionally from within emacs,
> but you need to approach it in a different way. For example, instaed
> of greping something and then passing ti to less,
Indeed, why do you need less when Emacs can scroll and search the output
for you? (I set PAGER to cat in my .emacs_ksh file.)
> just use M-x
> shell-command (bound to M-!). You will be prompted for the shell
> command and the output from that command will be ut into an emacs
> buffer which you can page through just like other emacs buffers.
The OP may want to run the command from a *Shell* buffer because of its
context (current directory, environment variables, etc.).
If I know a command is going to generate a lot of output, I may narrow
the *Shell* buffer before running it so that moving to the top of the
buffer takes me to the beginning of the output (actually, the prompt and
the command itself).