Re: graphic characters set
On Feb 25, 4:20 am, Antonio Macchi wrote: > this command should starts the graphic character set (to create masks) > > $ tput smacs > > but, using aterm or Eterm, it does not work > > but it works using this form (lieing...) > > $ TERM=xterm tput smacs > > does anyone know where is the problem? tput (and ncurses in general) is unrelated to bash. As I suggested, the place to start is in the terminfo manpage, where it describes line-drawing. (Look in that manpage for "alternate", "acs", etc). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: readline: edit (mode:vi) means eol unreachable
Hugh Sasse <[EMAIL PROTECTED]> wrote: > I see that a terminfo entry for PuTTY is on the wishlist. So meanwhile > I've asked them to re-examine this. On PuTTY developer's wishlist, I assume. ncurses has had a "putty" terminfo for a few years (iirc, the example given on PuTTY's website has some problems). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: shouldn't prompt printing be smarter?
Chet Ramey <[EMAIL PROTECTED]> wrote: > Fran Litterio wrote: >>> Also, creating an "option" to decide which behaviour should be followed >>> (current one or the one I propose) would make everyone happy >> >> It should be possible to code a value for PROMPT_COMMAND that sends >> the cursor position report escape sequence (for xterm this is >> "\033[6n"), learn the position of the cursor, and conditionally output >> a newline if the cursor is not in column 1. >> >> Some quick experimentation shows that this sequence of commands will >> do just that: > This is the right approach. In general, it's not possible for readline > to do this in a terminal-independent way -- termcap and terminfo do not > provide the appropriate capability. If you want to do this, you will > have to decide yourself which terminals to support. yes/no: since termcap doesn't have a standard, one can add capabilities if they're needed. ncurses's terminfo has a convention: # The System V Release 4 and XPG4 terminfo format defines ten string # capabilities for use by applications, In this file, we use # certain of these capabilities to describe functions which are not covered # by terminfo. The mapping is as follows: # # u9 terminal enquire string (equiv. to ANSI/ECMA-48 DA) # u8 terminal answerback description # u7 cursor position request (equiv. to VT100/ANSI/ECMA-48 DSR 6) # u6 cursor position report (equiv. to ANSI/ECMA-48 CPR) The feature won't work on some terminal types (Sun console for instance). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Would bash ever use xterm color support as default?
shirish agarwal <[EMAIL PROTECTED]> wrote: > Hi all, >Most of us use bash by default. And bash is not intuitive atleast for > people who are new to the system. I'm sure there have been suggestions made > for this before & would be made after me and I guess the people maintaining > bash would have some valid points why things like intelligent history > completion, tab-completion, having color support have not been made > defaults. Please lemme know any links or rationale which are behind these > decisions. >Couple of links https://wiki.ubuntu.com/Spec/EnhancedBash as well as however the examples given are all hardcoded, and (given the limitation to specific terminal types) more/less work without requiring any modification to bash. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Invisible characters in prompt with multi-byte support enabled
Alexander Becher <[EMAIL PROTECTED]> wrote: > Short version: bash-2.05b/lib/readline/display.c:update_line:1353 > calculates _rl_last_c_pos incorrectly if multibyte support is enabled > and there are invisible characters in the line that include zero-width > characters. There's a similar problem with bash 3.0 - see http://groups-beta.google.com/group/muc.lists.netbsd.users/browse_thread/thread/74cc6170139c4a9d/a8ea4643fdd0e00d?q=netbsd+termcap+bash&rnum=1&hl=en#a8ea4643fdd0e00d I spent enough time analyzing it to see that it's in the same general area. The logic in display.c seems to assume that all of the invisible characters are in one chunk. > I would have loved to include a fix, but that part of readline's code > is incomprehensible to me (for the moment, at least). ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
incorrect handling of invisible characters in prompt string
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: netbsdelf Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='netbsdelf' -DCONF_MACHTYPE='i386--netbsdelf' -DCONF_VENDOR='' -DLOCALEDIR='/usr/pkg/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I/usr/include -O2 -I/usr/include uname output: NetBSD colwyn.zhadum.de 3.0_BETA NetBSD 3.0_BETA (COLWYN) #0: Sat Jun 18 20:48:09 BST 2005 [EMAIL PROTECTED]:/export/scratch/tron/build.21314a/sys/compile/COLWYN i386 Machine Type: i386--netbsdelf Bash Version: 3.0 Patch Level: 16 Release Status: release Description: An extra character is displayed in the prompt. Tracing the code to see where it went astray, I could see that it appears to assume that the invisible characters are all in one chunk. Using the bundled copy of readline, it is producing incorrect results starting at display.c in this chunk beginning at line 1372: /* If we are changing the number of invisible characters in a line, and the spot of first difference is before the end of the invisible chars, lendiff needs to be adjusted. */ After that, it makes these calls (note that the "c" is passed as part of the invisible-character chunk): _rl_output_some_chars([01;35mc) _rl_output_some_chars(olwyn[00m:~$) _rl_move_cursor_relative(new=22, data=[01;35mcolwyn[00m:~$) Finally, the extra character shows up via putc() called from line 1686. The problem shows up if $TERM is xterm which includes :ei=\E[4l:im=\E[4h: and causes the _rl_move_cursor_relative() call to switch to insert mode when adding the extra character. There is no logic to handle the case where insert-mode is not available - it appears to simply overwrite the cell in that case. Repeat-By: Set TERM=xterm PS1='\[\033[01;35m\]\h\[\033[00m\]:\w\$' then "cd ~". Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
