I have this makefile:

all: 
        sudo watch "ls -l" > /dev/null &
        @echo line 1
        @echo line 2
        @echo line 3
        @echo line 4

Running watch (**or any other process that somehow changes the terminal**) ruins the terminal. This is the output. You can see these big spaces. Also, I can't see the characters afterwards, when I write:

me@me:/tmp$ make
watch "ls -l" > /dev/null &
line 1
line 2
      line 3
            line 4
                  me@me:/tmp$

Is there a way to prevent a process changing the terminal? **A clarification**: watch is just a **reproductible example**. I'm using another app that should run as daemon, but still ruins the terminal. --- Edit: I start this app (on this example, the app is watch) with sudo **A workaround** is to start it without sudo - then the terminal isn't ruined. The disadvantage in that is, that I need to chown this process to not be root:root.

We would like to run some curses based apps in background. These apps use curses and get the current tty port name to be used internally to map log files and others context-terminal associations. In some tests just redirecting the input from curses apps that don't read the keyboard to a known pts, worked. And so they can be executed in background, since I reserve a tty (or pseudo tty) for that. Is it possible to mock a tty, or has a reserved pts to some automatic running purposes, like that? We plain to launch them through crontab.

I have a script which implements a simple menu using dialog (an ncurses app for generating TUI widgets). This runs immediately after boot on an Arch-based system. The dialog script works when standalone, but there's a problem when it's run after boot. The boot process writes some delayed output to the console ("Starting network manager script dispatcher service", and possibly a later timeout), and this writes over the menu, and messes up the tty modes. I can fix the tty mode (stty sane), but I also need to stop the text reaching the console. Is there some way I can dump any kernel console output from the script?

I've noticed that using Ctrl+L to clear my terminal has some differences from using the clear command (from ncurses 6.5.20240427). It seems that the clear command will wipe every character in the terminal, set the cursor at the top left, and then type out the prompt. Ctrl+L might seem to do the same, but the upper 2 lines of my prompt (and the blank line above it) don't show. Interestingly, if I had something typed after the prompt, it retains that - and not just the line that the prompt was on, but everything after the prompt. I looked into man clear and found no options to replicate this behaviour, so what exactly is Ctrl+L doing under the hood? Is it invoking a program, or is it a behaviour built into most terminal emulators with implementation down to the specific terminal?

I was following the guide here and when I tried running make menuconfig it said

Unable to find the ncurses libraries or the required header files.
'make menuconfig' requires the ncurses libraries.
Install ncurses (ncurses-devel) and try again

ncurses-devel doesn't exist on the AUR though. I tried reinstalling ncurses but it still wouldn't work. It does work when working on the Linux kernel. Also I do want to compile a 64 bit version so I don't think that I would need a 32 bit version of ncurses. Edit: I have given up on this I don't really need to do it anyways.

Supose you present the following TUI in the shell: I need a set of libraries that can be used in the shell to do it. Being sure, ncurses has not been used, because it make a dependecy. Question: How to build the widget/window or another TUI in the shell?

I am working on an ncurses application that creates some very blocky graphics using alpha‐numeric characters. I’d like to be able to detect the dimensions (specifically the aspect ratio) of the font glyphs so that I can correct for it by changing how I render my graphics (such that a square always looks like a square). I am able to use the

void getmaxyx(WINDOW *win, int y, int x);

function in ncurses to get the size of the screen/window in character cells, but since many windows can be freely resized, it is not reliable. Is there a similar function (or external mechanism) for retrieving the font dimensions?

What library does Clonezilla use to show menus, dialogs, etc in its text user interface? I would like to use it directly as a fail-safe option for GUI apps when no GUI subsystem is available. I presume it is a C library. Does it have python bindings? I think it would be built on curses, but is there any additional layer on top of that, or is it bare-bones curses? I'd like to be able to create UIs like this:

This came from ~/.bashrc PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ ' Notice the \03301;32m I know \033[ is a Control Sequence Introducer. I know 32 is the color code for green. But, what are the 01; and m? Which part of [ANSI escape code does \033[01;32m belongs to.

So we all have the diff command installed by default. I certainly don't know how to use it *well*. But I would expect some reasonable default usage. Yet when I type diff file1 file2 I get ... a text ... which I have to parse in my head ... which is not helped by the fact that this is a weird combination of two texts, which are in turn very complex themselves. So I looked for a graphical solution, e.g. meld. That works much much better out of the box. Yet I would prefer to have the luxury of staying on the command line all the time. Is there a fairly standard command which: - uses colour by default and can adopt syntax highlighting - presents side-by-side diffs and does 3-way merges by default - works on the command line, e.g. via libncurses - depends on neither vim, emacs nor an IDE - can modify edited files in place? If not, why not? I looked into colordiff but it doesn't quite cut it.

I'd like to send a keystroke to ranger, when I have ranger running and have gotten it's PID with: Output of ps aux | grep '[/]usr/bin/python -O /usr/bin/ranger': chris 5054 3.1 0.1 116248 27828 pts/0 S+ 16:57 0:00 /usr/bin/python -O /usr/bin/ranger Following from https://serverfault.com/a/178470/135542 , if I send the value j to it's STDIN with: echo "j" > /proc/5440/fd/0 I just seem to get j mixed in the output (after I ran the command a few times): However when I press j on my keyboard, it reacts correctly.

The thread's title pretty much says it all. When I googled this question, I found mentions of a program called untic that supposedly does what I want to do, but this program does not seem to be available in any of my distro's (Debian) official packages. Is there some other way to go from (compiled) terminfo to termcap?

I am using Fedora 37 and have Linux kernel: 6.1.7-200.fc37.x86_64. While trying to replace some libraries (libncurses.so.5) for STMCubeIDE I have deleted some files in /usr/lib/libncurses*. Now, when I try to use anything with dnf I get the following message:

$ sudo dnf update
Traceback (most recent call last):
  File "/usr/bin/dnf", line 61, in 
    from dnf.cli import main
  File "/usr/lib/python3.11/site-packages/dnf/cli/__init__.py", line 30, in 
    from dnf.cli.cli import Cli  # :api
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf/cli/cli.py", line 44, in 
    from . import output
  File "/usr/lib/python3.11/site-packages/dnf/cli/output.py", line 42, in 
    import dnf.cli.progress
  File "/usr/lib/python3.11/site-packages/dnf/cli/progress.py", line 19, in 
    from dnf.cli.term import _term_width
  File "/usr/lib/python3.11/site-packages/dnf/cli/term.py", line 21, in 
    import curses
  File "/usr/lib64/python3.11/curses/__init__.py", line 13, in 
    from _curses import *
ImportError: libncursesw.so.6: cannot open shared object file: No such file or directory

I would like to know if there is an easy way to just repair dnf or this specific problem.

How do command-line applications like Vim work? Specifically, how do they take control of the terminal in the manner they do? Also, for future reference, is there a specific term for applications that take control of the terminal the way Vim does?

I'm writing TUI software on fbterm using python-curses library. To get full color in fbterm, I read it's man page and concluded I need to change environmental variable TERM to fbterm. > Man page: By default, FbTerm sets environment variable "TERM" to value "linux", user need run "TERM=fbterm /path/to/program" to enable 256 color mode. When I set TERM=fbterm, and run my python program. String-texts are OK, but the box/rectangle drawing character (- | ┌ ...) gets scrambled to (Ä ³ ¿ etc). ÚÄÄÄÄÄ¿ ³Meas.³ ÀÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄ¿ ³1-shot ³³n-shot ³ ³Setup³ ³ ³³ ³ ÀÄÄÄÄÄÙ ³ ³³ ³ ÚÄÄÄÄÄ¿ ³ ³³ ³ ³Data ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÙ ÚÄÄÄÄÄ¿ ³About³ ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÀÄÄÄÄÄÙ ³Target ³³Weather ³ ÚÄÄÄÄÄ¿ ³ ³³ ³ ³Sys. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÙ What am I doing wrong (missing)?? Yesterday I cross posted on stackoverflow , Then I realize this problem is more to do with fbterm's environmental value. So I'm posting here. The original post contains my reasoning, what I did, how I conclude so on ... (in more details).

I'm having a problem when compiling ninja IRC client. (http://ftp.iij.ad.jp/pub/linux/gentoo/distfiles/5b/ninja-1.5.9pre14.tar.gz) It compiles fine, but segfaults upon executing. When strace'ing the program, it says that it is using

/lib64/libtinfo.so.6

, but here's the problem, i'm using openSUSE Leap (version 15.4) and YaST uses that shared library. When I try compiling/installing a newer version of libtinfo (ncurses), it breaks YaST, to the point where it will not work. I had to

-s

the old version of

. So, my question is this: Can I force ninja to use a different version of

? I _was_ using Debian Bullseye before, and I never came upon this problem...

Many modern terminal emulators include definitions for box drawing glyphs directly in their own source code, and disregard the versions provided by the font when rendering the display. Is there a general way for a program running in the terminal to detect which glyphs are rendered this way? Specifically, if a program makes use of additional box glyphs that might not be widely supported, what's the best way to check if they're available? Perhaps in terminfo? My current use case is a small personal-use project written in Python using ncurses for the graphical component, so bonus points for something that plays nicely with those, but I'm interested in all solutions. ---- EDIT: As an example, here's a set of characters provided by [kitty](https://sw.kovidgoyal.net/kitty/) ; a comment in the source code indicates they're intended for Powerline integration: If we try to render the same glyphs in Konsole, though, we get this: The glyphs displayed by Kitty are defined by the terminal itself, whereas the ones displayed by Konsole are provided by whatever font it's configured to use. Is there a general way for a program running in some arbitrary terminal to detect whether we'll see the something like the former vs. the latter?

I cannot get commandline tools that use ncurses to work in iTerm2. They either fail or fall-back to some other UI if they have it (e.g. text only). Example for VLC (installed via Homebrew):

% /Applications/VLC.app/Contents/MacOS/VLC -I ncurses
VLC media player 3.0.16 Vetinari (revision 3.0.16-0-g5e70837d8d)
Error opening terminal: xterm-256color.

I have tried with different values for the TERM (xterm, rxvt, vt100) env variable and got the same error. More details about the iTerm2 session settings:

% env | grep -i term
LC_TERMINAL_VERSION=3.4.9beta1
ITERM_PROFILE=Default
__CFBundleIdentifier=com.googlecode.iterm2
TERM_PROGRAM_VERSION=3.4.9beta1
TERM_PROGRAM=iTerm.app
LC_TERMINAL=iTerm2
COLORTERM=truecolor
TERM=xterm-256color

Worth mentioning that this is only happening in an M1 MacBook Pro running macOS BigSur 11.5. With the same iTerm settings ncurses apps work fine in an Intel Macbook Pro running the same OS version.

I'm trying to write some code using the ncurses dialog library (available everywhere, source mirror is here ) and I'm trying to decide dynamically in code whether to use dialog or just print to stderr and prompt with getc() based on whether stdin/out/err are hooked up to char block devices, ttys, and what termcaps they have. I've stolen some code from less that seems pretty reliable at detecting whether it can render properly, and it looks for termcaps ce,cd,cl and either cm, or ho and ll, and either al or sr, otherwise it switches to dumb mode. But less has (much?) lower requirements than dialog, presumably (I just need yesno boxes, at least). I'm kind of surprised there's no check for caps in dialog or in ncurses, and no way to just ask if the terminal can handle things, or fail initscr if it doesn't have the caps? dialog on an emacs shell (not on ansi-term, it works fine there obvs) just spews nonsense text because it's a dumb terminal (same if you export TERM=dumb in a normal xterm), so there's clearly no capabilities checking going on here. I'm not a unix programmer most of the time, so is there some standard way of doing this that's robust? It's odd to me that this isn't a thing that's easy to check for. I can obviously grovel through the dialog yesno code and try to record all the ncurses stuff it calls, but that's a pain, so I'm hoping I'm just failing to find a clear terminal capabilities requirements list somewhere. **Update:** so I decided to mess around with making my own custom terminfo entry to test how minimal I could go and still get the yesno dialog, and it's pretty minimal, so the less tests are basically good. It was hard to figure out how to do this, so here's a brief summary for other folks from THE FUTURE: - Here are the termcap definitions you'll need to figure things out; you can work directly with terminfo definitions and skip a couple steps, but old software like less are using the termcap versions and so it'll be easier to just work in that space. - Assuming you've got an ncurses app that runs on your current terminal (or dialog --title Hi --yesno There 0 0), figure out what your TERM envvar is. I'm working in screen and emacs ansi-term, so they're screen and eterm-color in my tests, and of course dumb - Dump the one you want to muck with (that you're running the tests with because you want your new one to be a subset of a working one) using infocmp eterm > eterm2.info, this gives you the info version to work with. - Convert it to cap with infotocap eterm2.info > eterm2.cap - Look inside, and cut it way down, like here's my minimal cap file that will just barely run less without warnings:

#       hacked eterm for testing dialog
eterm2|gnu emacs term.el terminal emulation:\
        :am:mi:xn:\
        :co#80:li#24:\
        :ce=\E[K:cd=\E[J:cl=\E[H\E[J:\
        :ho=\E[H:\
        :cm=\E[%i%d;%dH:\
        :al=\E[L:

- Notice I changed the name at the beginning to eterm2 as well. - Convert that back to info with captoinfo eterm2.cap > eterm2.info - mkdir infodb to make the local dir where you're going to compile this test info. - export TERMINFO=$(pwd)/infodb to tell termcap/terminfo where to find it - tic -D should output that local dir first - tic -s eterm2.info will compile it to that dir - export TERM=eterm2 to set your new hacked terminal - Run your ncurses app or dialog --title Hi --yesno There 0 0 and it should show up in all its black and white simple glory. - You can play around with adding other commands back in to see what changes, but when you're done, rm -rf infodb, export TERMINFO=, and export TERM= and make sure things run right. **Update2:** Here is the code I ended up with which seems to work in all my tests:

if(TermMode == TERM_UNINITIALIZED) {
        struct stat s;
        if((isatty(STDOUT_FILENO) && (fstat(STDOUT_FILENO,&s) == 0) && S_ISCHR(s.st_mode)) &&
           (isatty( STDIN_FILENO) && (fstat( STDIN_FILENO,&s) == 0) && S_ISCHR(s.st_mode)))
        {
            // both stdout and stdin are char block device ttys, now check termcaps
            // mostly stolen from the gnu less source code, since it seems robust
            // https://github.com/gwsw/less/blob/22e4af5cccbfab633000c7d610f868a868ad6e1a/screen.c#L1280 
            char termbuf;
            char const* term = getenv("TERM");
            int const TGETENT_OK = 1;
            if(tgetent(termbuf,term) == TGETENT_OK) {
                char sbuf;
                char* sp = sbuf;
                char* sr = 0;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wwrite-strings"
                // ce ce cl are required
                if((sr = tgetstr("ce",&sp)) && *sr &&   // eol clear
                   (sr = tgetstr("cd",&sp)) && *sr &&   // eos clear
                   (sr = tgetstr("cl",&sp)) && *sr)     // screen clear
                {
                    // cm or (ho and ll)
                    if(((sr = tgetstr("cm",&sp)) && *sr) ||   // cursor move
                       (((sr = tgetstr("ho",&sp)) && *sr) &&  // home
                        ((sr = tgetstr("ll",&sp)) && *sr)))   // lower left
                    {
                        // al or sr
                        if(((sr = tgetstr("al",&sp)) && *sr) || // add line
                           ((sr = tgetstr("sr",&sp)) && *sr))   // scroll reverse
                        {
                            // we've got what we need for ncurses dialog!
                            TermMode = TERM_DIALOG;
                            goto term_detected;
                        }
                    }
                }
#pragma GCC diagnostic pop
            }
            // we're at least connected to a tty
            TermMode = TERM_STDIO;
        } else {
            // no interaction, so gotta just abort
            TermMode = TERM_ABORT;
        }
term_detected:
        ;
    }

Anyway, it would still be very nice to know what the minimal termcaps are, but at the very least the ones listed above for less work, so I'm going to use those. Thanks, Chris

After running crontab -e, My terminal starts acting strange, where characters aren't printed in the correct position. Starting and exiting an ncurses application (like vim and nano) doesn't help, nor does reset fix it either, so I have to restart my terminal emulator. It appears to have the same symptoms as force quitting an ncurses application. How do I fix this problem? **Edit:** Screenshot: **Environment** * I my $TERM variable is set to xterm * I use uxterm as my emulator * crontab uses vim as its editor. **Edit:** On the first answer, I noticed that it still persists with xonsh, even though *it gets fixed when I type reset with bash or zsh. So, **it must be some issue with xonsh.**