View previous topic :: View next topic |
Author |
Message |
cadaker Tux's lil' helper
Joined: 05 Jun 2004 Posts: 102 Location: Stockholm, Sweden
|
Posted: Wed Jul 28, 2004 8:31 pm Post subject: New bash version dislikes my 2-line prompt [solved] |
|
|
I'm the kind of person who likes to have a lot of useless information in my bash prompt. In fact, it's so long I've split it into two lines to make it a bit more manageable.
Code: | PS1="\[\e[32m\]<\A>(\u@\h ?\$? $(uname -r) \w)\[\e[30;0m\]\n\\$ " |
However, bash-3.0 (since I can't recall having this problem before, I assume it's just this version) doesn't handle the newline properly, and keeps breaking the typed-in line where the terminal screen should have ended, had the newline not been in the prompt. Something like this:
Code: | $ bash is being ve
ry annoying |
Any bash guru who can come up with a solution? _________________ ++?????++ Out of Cheese Error. Redo From Start.
Last edited by cadaker on Thu Jul 29, 2004 11:18 pm; edited 1 time in total |
|
Back to top |
|
|
dhalsiim Guru
Joined: 29 Jan 2003 Posts: 486
|
Posted: Thu Jul 29, 2004 12:51 am Post subject: |
|
|
I just emerged to bash 3.0, and tried your PS1, it's working fine. Isn't this supposed to be your bash prompt:
<12:49>(sam@meguchan ?0 2.6.7-mm6 ~)
Try source /etc/profile then define your PS1 again? |
|
Back to top |
|
|
cadaker Tux's lil' helper
Joined: 05 Jun 2004 Posts: 102 Location: Stockholm, Sweden
|
Posted: Thu Jul 29, 2004 1:23 am Post subject: |
|
|
Nope, still not working over her. A straight line of 'x's turn out as
Code: | <03:20>(cadaker@binky ?0 2.6.7-gentoo-r11 ~)
$ xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
Cut off in the middle.
I'll try reemerging bash, and see if it helps.
<edit>
Still the same problem after emerging bash again. _________________ ++?????++ Out of Cheese Error. Redo From Start. |
|
Back to top |
|
|
dhalsiim Guru
Joined: 29 Jan 2003 Posts: 486
|
Posted: Thu Jul 29, 2004 3:00 am Post subject: |
|
|
Where do you specify the PS1? In your .bash_profile? or in /etc/profile directly?
xxxx's appear, like as soon as you specify PS1 and re-run an xterm/aterm etc, automatically? Do they keep on going or just stop after a few?
Post your .bashrc .bash_profile and /etc/profile if you have made changes to any of them! |
|
Back to top |
|
|
Evil Dark Archon Guru
Joined: 21 Dec 2002 Posts: 562 Location: Santa Rosa, CA
|
Posted: Thu Jul 29, 2004 4:16 am Post subject: |
|
|
AFAIK bash 3 has 1 environment variable for each line in the prompt, so the first line would be PS1 second line wound be PS2, you can check the changes file in the bash 3.0 tarball. _________________ This post has been over explained for newb-informing purposes.
Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro |
|
Back to top |
|
|
cadaker Tux's lil' helper
Joined: 05 Jun 2004 Posts: 102 Location: Stockholm, Sweden
|
Posted: Thu Jul 29, 2004 11:12 am Post subject: |
|
|
Ok, I don't seem to have described the problem well enough...
The problem is, that bash miscalculates where the terminal window ends. Normally, when you type a long line to the shell, the line wraps right at the end of the terminal window. However, when I type a long line, bash wraps it at the wrong point.
Code: | <13:00>(cadaker@binky ?0 2.6.7-gentoo-r11 ~)
$ cd /usr/share/doc/gentoolkit-0.2.0
_pre8/ |
If I've calculated it correctly, it seems that the length at which bash wraps it is where the terminal window should have ended if the prompt was only one line long.
PS2 is, as far as I could see, not used when simply wrapping a long line.
Can anyone confirm bash is doing this wrong everywhere? If so, I'll file a bug report to the bash people.
<edit>Ah, someone else has apparently already done so:
gnu.bash.bug newsgroup _________________ ++?????++ Out of Cheese Error. Redo From Start. |
|
Back to top |
|
|
dhalsiim Guru
Joined: 29 Jan 2003 Posts: 486
|
Posted: Thu Jul 29, 2004 3:47 pm Post subject: |
|
|
Oh ok we were like your PS1 prompt isn't working correctly >_<"
Well even what you have described now, isn't happening with me. I can go over 2 lines and it won't wrap the text at the wrong point. I guess it happens with certain dependencies, packages, etc?
Sorry if I couldn't help out on this. |
|
Back to top |
|
|
cadaker Tux's lil' helper
Joined: 05 Jun 2004 Posts: 102 Location: Stockholm, Sweden
|
Posted: Thu Jul 29, 2004 4:07 pm Post subject: |
|
|
At the moment, I've masked bash-3.0 and gone back to 2.05. The previous version worked well enough for me. _________________ ++?????++ Out of Cheese Error. Redo From Start. |
|
Back to top |
|
|
neonman- n00b
Joined: 29 Jul 2004 Posts: 5 Location: Luleå, sweden
|
Posted: Thu Jul 29, 2004 11:06 pm Post subject: |
|
|
You can solve this bu enclosing PS1 with "\[\]", i.e PS1="\[$PS1\]"
Taken from the bash manpage, section "PROMPTING":
-- cut --
\[ begin a sequence of non-printing characters, which could be used to embed a terminal control sequence into the prompt
\] end a sequence of non-printing characters
-neon |
|
Back to top |
|
|
cadaker Tux's lil' helper
Joined: 05 Jun 2004 Posts: 102 Location: Stockholm, Sweden
|
Posted: Thu Jul 29, 2004 11:16 pm Post subject: |
|
|
Hah! I had been testing several variants of \[ and \] in the prompt, but now I tried again, and
Code: | PS1="\[\e[32m<\A>(\u@\h ?\$? $(uname -r) \w)\e[30;0m\]\n\\$ " |
really does seem to work.
Thanks! _________________ ++?????++ Out of Cheese Error. Redo From Start. |
|
Back to top |
|
|
neonman- n00b
Joined: 29 Jul 2004 Posts: 5 Location: Luleå, sweden
|
Posted: Thu Jul 29, 2004 11:35 pm Post subject: |
|
|
I'm glad i could help. |
|
Back to top |
|
|
hyp0r Tux's lil' helper
Joined: 11 Oct 2003 Posts: 139
|
Posted: Fri Jul 30, 2004 6:32 am Post subject: |
|
|
I you leave out the last line feed in in your Prompt (\n), you'll get the same maniac breaks.
Bash even overwrites the second line. This cannot be a "feature". |
|
Back to top |
|
|
Der_Kaplan n00b
Joined: 17 Jun 2004 Posts: 23
|
Posted: Sun Aug 01, 2004 11:49 am Post subject: same problem here! |
|
|
same problem here :
i use this prompt since bash 2.05x :
PS1="\[\033[1;34m\][ \w ]\[\033[0m\]\n[\[\033[31m\]\u@\h \[\033[0m\]\t]\[\033[31m\]=>\[\033[0m\]"
and and i see on my console/terminal:
[ /tmp ]
[heinz@h0me 12:14:56]=>
(with bash 3.0, too)
BUT:
the newline function (\n) is strange since bash 3.0
example:
[ /tmp ]
[heinz@h0me 12:14:56]=>eeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
and it should be:
[ /tmp ]
[heinz@h0me 12:14:56]=>eeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeee
and i can't edit the line, because the cursor has a hiccup and didn't reach the first line.
playing around with PS1="\u \w \n" shows strange effects, too.
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
and it should be:
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
does anybody have a idea to solve this behaviour ?
thanks
Kaplan |
|
Back to top |
|
|
eNTi Veteran
Joined: 20 Oct 2002 Posts: 1011 Location: Salzburg, Austria
|
Posted: Sun Aug 01, 2004 3:45 pm Post subject: |
|
|
same here. this definitly sux. _________________ If you fall off a cliff, you might as well try to fly. After all, you got nothing to lose.
-- John Sheridan - Babylon 5, Season 4 |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2998 Location: Bay Area, CA
|
Posted: Tue Aug 24, 2004 5:42 am Post subject: |
|
|
eNTi wrote: | same here. this definitly sux. | same for me too! anybody find any solutions to this problem. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2998 Location: Bay Area, CA
|
Posted: Mon Aug 30, 2004 3:22 am Post subject: Solved at last! |
|
|
devsk wrote: | eNTi wrote: | same here. this definitly sux. | same for me too! anybody find any solutions to this problem. | well, here is the patch for this madness:
Code: | --- display.c.orig 2004-08-29 20:12:23.598586000 -0700
+++ display.c 2004-08-29 20:12:46.087352000 -0700
@@ -349,14 +349,14 @@
local_prompt = expand_prompt (p, &prompt_visible_length,
&prompt_last_invisible,
(int *)NULL,
- (int *)NULL);
+ (int *)&prompt_physical_chars);
c = *t; *t = '\0';
/* The portion of the prompt string up to and including the
final newline is now null-terminated. */
local_prompt_prefix = expand_prompt (prompt, &prompt_prefix_length,
(int *)NULL,
&prompt_invis_chars_first_line,
- &prompt_physical_chars);
+ (int *)NULL);
*t = c;
return (prompt_prefix_length);
}
|
|
|
Back to top |
|
|
eNTi Veteran
Joined: 20 Oct 2002 Posts: 1011 Location: Salzburg, Austria
|
Posted: Mon Aug 30, 2004 12:45 pm Post subject: |
|
|
could you file a bug report and attach the patch there please? i don't really want to mess around in the code myself _________________ If you fall off a cliff, you might as well try to fly. After all, you got nothing to lose.
-- John Sheridan - Babylon 5, Season 4 |
|
Back to top |
|
|
eNTi Veteran
Joined: 20 Oct 2002 Posts: 1011 Location: Salzburg, Austria
|
Posted: Mon Aug 30, 2004 11:54 pm Post subject: |
|
|
i've tried it out, and it really seems to work . is this a bug or a feature? _________________ If you fall off a cliff, you might as well try to fly. After all, you got nothing to lose.
-- John Sheridan - Babylon 5, Season 4 |
|
Back to top |
|
|
Roguelazer Veteran
Joined: 10 Feb 2003 Posts: 1233 Location: San Francisco, CA
|
Posted: Tue Sep 07, 2004 1:42 am Post subject: |
|
|
Call me a n00b, but how do I get this to apply? I tried dumping this in /usr/portage/distfiles and adding an epatch line to the ebuild, but no luck... Manually running patch gives this error:
Code: |
patching file display.c.orig
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 349.
1 out of 1 hunk FAILED -- saving rejects to file display.c.orig.rej
|
I manually applied the patch (ie editted the file), and it works with a hand-compile. But I'd rather this get in the ebuild... I read the bug report (36393), and it appears that nobody even mentioned this patch. Stupid readline... _________________ Registered Linux User #263260 |
|
Back to top |
|
|
Roguelazer Veteran
Joined: 10 Feb 2003 Posts: 1233 Location: San Francisco, CA
|
Posted: Tue Sep 07, 2004 2:41 am Post subject: |
|
|
Hmm. I made it work, but I'm not sure if I did it right. Here's my fixxored ebuild. Save the patch at the end of this post as "/usr/portage/distfiles/bash-3.0-line_fix_thingy.diff", then save the ebuild wherever you save ebuilds. Voilia
Code: |
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-shells/bash/bash-3.0-r5.ebuild,v 1.2 2004/08/19 22:08:00 vapier Exp $
inherit eutils flag-o-matic gnuconfig
# Official patches
PLEVEL=""
DESCRIPTION="The standard GNU Bourne again shell"
HOMEPAGE="http://www.gnu.org/software/bash/bash.html"
SRC_URI="ftp://ftp.cwru.edu/pub/bash/${P}.tar.gz
mirror://gnu/bash/${P}.tar.gz
mirror://gentoo/${P}-gentoo.diff.bz2
${PLEVEL//x/mirror://gnu/bash/bash-${PV}-patches/bash${PV/\.}-}"
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~x86 ~ppc ~mips ~alpha ~arm ~hppa ~amd64 ~ia64 ~ppc64 ~s390 ~sparc"
IUSE="nls build uclibc"
# we link statically with ncurses
DEPEND=">=sys-libs/ncurses-5.2-r2"
RDEPEND=""
src_unpack() {
unpack ${P}.tar.gz
cd ${S}
epatch ${DISTDIR}/${P}-gentoo.diff.bz2
epatch ${DISTDIR}/${P}-line_fix_thingy.diff
cd ${S}
# Remove autoconf dependency
sed -i -e "/&& autoconf/d" Makefile.in
# Readline is slow with multibyte locale, bug #19762
# (No longer applies to bash-3.0)
#epatch ${FILESDIR}/${P}-multibyte-locale.patch
# Segfault on empty herestring
# (Fixed in bash-3.0 with STRLEN instead of strlen)
#epatch ${FILESDIR}/${P}-empty-herestring.patch
# Fix broken rbash functionality
# (Fixed in bash-3.0)
#epatch ${FILESDIR}/${P}-rbash.patch
# Fix parallel make, bug #41002.
# (Added to bash-3.0-gentoo.diff.bz2)
#epatch ${FILESDIR}/${P}-parallel-build.patch
# Revert trap behavior for the sake of autoconf-generated configure scripts.
# The problem here is that bash -c 'trap 0' works, but sh -c 'trap 0'
# doesn't work because the bash developers are trying to adhere to POSIX in
# that case. Since all the configure scripts are #!/bin/sh, this breaks
# them
epatch ${FILESDIR}/${P}-posixtrap.patch
# Patch display.c so that only invisible characters actually on the first
# line are counted in it. (This patch doesn't fix everything and Chet says
# he has a better patch... so watch for it in bash-3.0.1)
epatch ${FILESDIR}/${P}-invisible.patch
# Patch readline's bind.c so that /etc/inputrc is read as a last resort
# following ~/.inputrc. This is better than putting INPUTRC in
# the environment because INPUTRC will override even after the
# user creates a ~/.inputrc
epatch ${FILESDIR}/${P}-etc-inputrc.patch
# Chet Ramey (upstream maintainer) provided this patch in
# http://news.gmane.org/gmane.comp.shells.bash.bugs/cutoff=4115
# to fix bug 58961 (segfault on local arrays)
epatch ${FILESDIR}/${P}-local-array.patch
# Chet Ramey (upstream maintainer) provided this patch to solve
# bug 60127 (bash 3 breaks array stripping)
epatch ${FILESDIR}/${P}-array-stripping.patch
# Enable SSH_SOURCE_BASHRC (#24762)
echo '#define SSH_SOURCE_BASHRC' >> config-top.h
# Enable system-wide bashrc (#26952)
echo '#define SYS_BASHRC "/etc/bash/bashrc"' >> config-top.h
# Force pgrp synchronization
# (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81653)
#
# The session will hang cases where you 'su' (not 'su -') and
# then run a piped command in emacs.
# This problem seem to happen due to scheduler changes kernel
# side - although reproduceble with later 2.4 kernels, it is
# especially easy with 2.6 kernels.
echo '#define PGRP_PIPE 1' >> config-bot.h
gnuconfig_update
}
src_compile() {
filter-flags -malign-double
local myconf=
# Always use the buildin readline, else if we update readline
# bash gets borked as readline is usually not binary compadible
# between minor versions.
#
# Martin Schlemmer <azarah@gentoo.org> (1 Sep 2002)
#use readline && myconf="--with-installed-readline"
# Don't even think about building this statically without
# reading Bug 7714 first. If you still build it statically,
# don't come crying to use with bugs ;).
#use static && export LDFLAGS="${LDFLAGS} -static"
use nls || myconf="${myconf} --disable-nls"
econf \
--disable-profiling \
--with-curses \
--without-gnu-malloc \
${myconf} || die
make || die
}
src_install() {
einstall || die
dodir /bin
mv ${D}/usr/bin/bash ${D}/bin
dosym bash /bin/sh
dosym bash /bin/rbash
use uclibc && rm -f ${D}/usr/bin/bashbug ${D}/usr/share/man*/bashbug*
insinto /etc/bash
doins ${FILESDIR}/bashrc
if use build; then
rm -rf ${D}/usr
else
doman doc/*.1
dodoc README NEWS AUTHORS CHANGES COMPAT Y2K
dodoc doc/FAQ doc/INTRO
dosym bash.info.gz /usr/share/info/bashref.info.gz
fi
}
|
And here's the patch. It's mostly the same as the one before, but slightly different. Plus this one works, and that one failed for me.
Code: |
*** lib/readline/display.c.orig Mon Sep 6 22:19:55 2004
--- lib/readline/display.c Mon Sep 6 22:20:36 2004
***************
*** 351,364 ****
local_prompt = expand_prompt (p, &prompt_visible_length,
&prompt_last_invisible,
(int *)NULL,
! (int *)NULL);
c = *t; *t = '\0';
/* The portion of the prompt string up to and including the
final newline is now null-terminated. */
local_prompt_prefix = expand_prompt (prompt, &prompt_prefix_length,
(int *)NULL,
&prompt_invis_chars_first_line,
! &prompt_physical_chars);
*t = c;
return (prompt_prefix_length);
}
--- 351,364 ----
local_prompt = expand_prompt (p, &prompt_visible_length,
&prompt_last_invisible,
(int *)NULL,
! (int *)&prompt_physical_chars);
c = *t; *t = '\0';
/* The portion of the prompt string up to and including the
final newline is now null-terminated. */
local_prompt_prefix = expand_prompt (prompt, &prompt_prefix_length,
(int *)NULL,
&prompt_invis_chars_first_line,
! (int *)NULL);
*t = c;
return (prompt_prefix_length);
}
|
_________________ Registered Linux User #263260 |
|
Back to top |
|
|
|