5

What can I do about this issue? I'm using

psql, inside a ssh tunnel to ubuntu, inside a M-x shell, inside a emacsclient -nw

enter image description here

8
  • There's eshell as well, have a look at unix.stackexchange.com/questions/104325/… – A. Blizzard Jan 5 '18 at 16:02
  • And ergoemacs.org/emacs/… – A. Blizzard Jan 5 '18 at 16:03
  • 1
    @A.Blizzard eshell is not a terminal emulator either, it will produce the same, or similar, warnings as shell-mode – Tyler Jan 5 '18 at 16:35
  • Eshell indeed is a terminal emulator, fully written in LISP, what makes it a breeze to use Emacs commands like find-file or find-file-other-window to open files from the terminal. The above comment is wrong. – solr Aug 13 '20 at 17:36
  • 1
    @solr eshell is not a fully functional terminal I meant to say. It doesn't support visual commands such as the one in this question. – Tyler Aug 13 '20 at 19:22
9

Quick answer

That's not an issue, it's a statement of fact. M-x shell isn't a fully functional terminal - it simply can't do what you want it to do. If you want a full terminal emulator in emacs, you have to use M-x ansi-term instead.

Explanation

This isn't an Emacs issue per se, but a consequence of how different kinds of terminals process input, and especially output. All terminals support printing raw text, and accept lines of input ending with a return (enter key).

Some terminals also support escape sequences (which allow for coloured text), clearing lines, and controlling cursor position. Xterm is an example of this, and using these features you can create a complex interface like the Mutt mail program, or formatting and scrolling support as found in the terminal Man page viewer.

Terminals without these features are called dumb terminals. Dumb terminals can only print single color text to the screen, and can't back up or overwrite lines, as is necessary for an interactive display like Mutt provides, or Man uses to scroll up and down through a manual.

When a program that requires these features is started, it usually checks to see if the terminal supports them. One way to do this is to check the value of the environmental variable TERM. If the value of that variable is dumb, the program knows it can't rely on all the features it expects, and will warn the user with the message reported here.

You can still use a program that requires a fully functional terminal in a dumb terminal. There's no guarantee it will function properly, or at all. That's why you get the warning. If you really want to use such programs in a dumb terminal, without the warning, you could manually set the value of TERM to xterm, i.e.,

export TERM=xterm

You will no longer get the warning message, and you won't have to press enter before you can see the program output. But after that, the program will still behave strangely, because you have tricked it into thinking it can use features that aren't there.

That might work for simple cases. It would not work at all for Mutt.

In the Emacs context, M-x shell is a dumb terminal, built from the comint library. It is Emacs, so it would be possible in theory to extend it to fully support all the features of a fully-functional shell. I expect that is non-trivial. In practice, ansi-term already exists to fulfill this function.

Eshell

eshell is a different kind of entity, being a terminal and shell written completely in elisp, and making it a special case that I won't get into here. I will note that the people who developed Eshell anticipate that users will want to use programs that require fully-functional shell features from within Eshell. They provide facilities to integrate ansi-term with eshell, with a bit of configuration (Eshell manual):

If you try to run programs from within Eshell that are not line-oriented, such as programs that use ncurses, you will just get garbage output, since the Eshell buffer is not a terminal emulator. Eshell solves this problem by running such programs in Emacs’s terminal emulator.
Programs that need a terminal to display output properly are referred to in this manual as “visual commands,” because they are not simply line-oriented. You must tell Eshell which commands are visual, by adding them to ‘eshell-visual-commands’; for commands that are visual for only certain sub-commands – e.g., ‘git log’ but not ‘git status’ – use ‘eshell-visual-subcommands’; and for commands that are visual only when passed certain options, use ‘eshell-visual-options’.

This should address most use cases. Note that the recommended solution of the eshell developers is not to change eshell, but to automatically switch to ansi-term when eshell is incapable of providing the necessary features. Which brings us back to the short answer above: use ansi-term when you need a fully-functional terminal.

What about M-x shell?

Emacs' shell doesn't have built-in support for visual commands like eshell does. You can add support yourself with relatively little effort. For example, the command line program man doesn't work properly in a dumb terminal, but there is an Emacs mode for it. You can call it directly from M-x shell by including the following function in your .emacs.d/init_bash.sh file:

function man() {
    emacsclient -e "(man \"$@\")"
}

This requires that you are running emacs in daemon/server mode. If you are, using the man command from the Emacs shell will pass the argument to the elisp function man, opening the file in a buffer and displaying it properly.

You could use the same principle to replace programs with functions that do the appropriate thing for other programs. For instance, creating a function named mutt that opens and ansi-term buffer and runs the command mutt in it.

3
  • 2
    I digress with this answer and consequently voted it down: when your workflow is interrupted like with this waning message, where you need to press an extra key to move forwards, then it turns into an annoying issue. – solr Aug 13 '20 at 17:35
  • 1
    @solr Yes, it is annoying to use a terminal that isn't fully functional when you need a fully functional terminal. That's why you should use the fully functional ansi-term instead of limited functions of shell in this situation. What exactly are you disagreeing with? – Tyler Aug 13 '20 at 19:19
  • Thank you @Tyler for the more detailed explanation and the suggested workarounds. I only had enough steam left in the engine this evening to try out the answer of db48x, which worked so I went ahead and gave that forum participant the bonus points. I will also try your suggested workarounds in the next day or so. – lawlist Dec 3 '20 at 5:59
4
+50

If you don't care about whether Emacs is a "fully-functional" terminal or not and you just want it to work without making you press enter, then run the psql command \pset pager off. This will make psql skip running a pager program and just dump all the output at once. You can then scroll through the output using the Emacs scrollbar or scrolling commands. The pager that it runs is typically less, which is what prints this message. You could also use \pset pager more to run more as the pager instead. more doesn't need many terminal capabilities and so it doesn't bother to print this message.

You could also arrange for the PAGER environment variable to be unset or to have a different value such as more.

0
1

What can I do about this issue? I'm using psql, inside a ssh tunnel to ubuntu, inside a M-x shell, inside a emacsclient -nw

In short, "don't do that".

Emacs has excellent comint-based support for psql via M-x sql-postgres, and the sql-interactive-mode buffer created by that can interact with sql-mode buffers so that you can write queries in the latter and send them to the former. In Emacs I wouldn't want to be running psql any other way.

0

export TERM=eterm ; Inside your M-x shell

1
  • 1
    Welcome to Emacs.SE! Could you explain your post in more detail to make it a complete answer? – Dan Dec 24 '20 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.