You are not logged in.
Or at least that's what it seems. I've tried various PS1 strings and things seem to work unless I stick a 'n' and then things go haywire. Depending on where I put it, it wraps at different places, not always aligned with the newline but definitely before the screen edge. I seem to recall something similar and googled for it (and searched these forums) but found nothing useful. Re-read the bash man regarding PS1, and the xterm and setterm mans - it's not an xterm or console problem, though, because it happens either place.
Any help would be much appreciated. I have other minor issues - nedit isn't completely responding to ~/.Xdefaults customizations; mozilla seems to fall asleep sometimes - but the prompt thing is really bugging me. Otherwise, the first couple days of Arch have been okay.
The prompt I've been mostly playing with is
export PS1="[e[37;1m]n[ u@h | d t ]nw >> [e[0m]"
though I have a more complicated one that actually works slightly better.
Oh, one thing I almost forgot - I put 'clear' at the top of my bashrc because it leaves what looks like an inactive 'ghost cursor' on the first line otherwise, and shouldn't do that - but clearing removes it, at least.
Offline
dunno. I don't have any newlines in mine though.
I use single quotes instead of double quotes.
export PS1='[33[01;31m]([33[00;37m]u@h W[33[01;31m])[33[00m]$ '
I must say, I have never run into that problem...
Are you setting the prompt in .bashrc?
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Well, I sometimes put variables in and single quotes suppress the variable expansion. It doesn't have any effect on the width problem. I've continued to search (and gotten frightened by the depths of 'tput' ) but I did come across something like what I was thinking of - if you don't escape the ANSI code with the escaped brackets, the length of the color escape string is interpreted as actually taking up columns. Has the effect of shortening your columns. Now, as near as I can tell, the ANSI's escaped properly - and it *is* just the newlines causing the problem. But it's something *like* that.
Incidentally, mc and vim came up in xterm in black&white and specifying 'xterm-color' in ~/.Xdefaults fixed that (after doing 'mc -c' for awhile) but I'm wondering if that was the right way and if there's some other problem. I mean, as I say, this happens on the console, too, so it's not an xterm thing, but I thought I'd mention it in case it was somehow relevant and if there is a better way to fix the colors.
-- Oh, missed that last question. I set it from .bashrc. I also tried put it in a separate file and sourcing it from .bashrc (not to fix this, but just as a separate experiment) and neither method made any difference.
Offline
well, for color, I just put this at the top of my .bashrc
TERM=xterm-color
seems to do the trick..
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Okay, that comes out the same then. So that's really how it's supposed to go? I don't mean to criticize a distro I'm just getting introduced to, but it seems like it should default to color. I thought I'd screwed something up.
Offline
That is just the way I do it. It is far more portable across various distros. I generally just slap my .bash* files, .vim* files, and other misc config files, in the home dir of any linux system I am using. Then everything is nice and happy, the way I like it..
Path of least resistance for me.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Sorry, I think I might not have been clear in my last post - however the job gets done is good as long as nothing is broken behind the fix - I was just wondering if it was supposed to default to a non-color term. I don't remember having to specify that before (though I could have forgotten).
Not important either way, though - but this terminal truncation is driving me batty. I could strip the newlines but I like having a short prompt at the actual command line but still having some information in it. And, in X I could put it in the xterm titlebar (usually do), but I also like separating my command/output with blank lines.
Ah well, on the bright side, my PC keys work without fiddling, which is nice.
Offline
is this a good description of your problem?
http://lists.gnu.org/archive/html/bug-b … 00429.html
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Thank you! That description was kind of confusing, but the description in the bash patch report sounds right. I'd be perfectly happy to build my own but I'm not sure how to do it ABS-style yet. Assuming this is the problem and that patch hasn't been applied in the Arch package, do I need to submit a bug (and where?) or will this be fixed in the prebuilt packages pretty soon?
Offline
I have exact the same problem. Because of this I'm still using bash 2.05b.
Offline
I would say submit a bug.
It is usually quite easy to modify an existing PKGBUILD. If you aren't creating a new one, it isn't too hard.
for example...
build() {
cd $startdir/src/$pkgname-$pkgver
patch -Np1 -i ../bash-history.patch || return 1
./configure --prefix=/usr --with-curses --enable-readline
make || return 1
make DESTDIR=$startdir/pkg install
mv $startdir/pkg/usr/bin $startdir/pkg/bin
# we don't want bashbug
rm -f $startdir/pkg/bin/bashbug
rm -f $startdir/pkg/usr/man/man1/bashbug.1
install -D -m644 ../profile $startdir/pkg/etc/profile
ln -sf $pkgname $startdir/pkg/bin/sh
}
The above is from the current bash pkgbuild. It should be a simple matter of adding an additional patch line after the existing one.
Still, if you are not comfortable with such things, then I am sure someone else would be easily convinced into helping you along.
Make sure you file a bug though..it is unlikely the maintainer will be reading the forums, and it might be the only way the issue "bubbles" up to those that need to be aware of it.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Okay, I wouldn't say it was 'quite easy' - I patched it and got it in but it was a string of difficulties on the way and I feel like everything went wrong except that I have
[ j@alfredeneuman ][ Thu Jan 27 21:34:09 ]
[ ~ ] >> bash --version
GNU bash, version 3.00.16(1)-release (i686-pc-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
and it seems to work. However, I didn't know what to put for release version - it was 3 so is mine 4? I just put '1j'. And trying to set up a 'local repository' seemed confusing as hell and whatever I did was wrong. I actually got pissed and deleted bash and copied in mine manually, but then figured out I could do 'pacman -U bash-3.0-1j.pkg.tar.gz' directly. So I did that to re-overwrite stuff and get it in the package db.
What's wrong with this:
# $Id: PKGBUILD,v 1.30 2004/11/02 17:27:46 judd Exp $
# Maintainer: judd <jvinet@zeroflux.org>
pkgname=bash
pkgver=3.0
pkgrel=1j
pkgdesc="The GNU Bourne Again shell"
url="http://www.gnu.org/software/bash/bash.html"
backup=(etc/profile)
depends=('glibc' 'readline')
source=(ftp://ftp.cwru.edu/pub/bash/bash-$pkgver.tar.gz
profile
bash30-001
bash30-002
bash30-003
bash30-004
bash30-005
bash30-006
bash30-007
bash30-008
bash30-009
bash30-010
bash30-011
bash30-012
bash30-013
bash30-014
bash30-015
bash30-016)
md5sums=('26c4d642e29b3533d8d754995bc277b3'
'719b60711ee609850277bd0848516136'
'24a83f78a44a6029024371f02da174dd'
'6f4cf2aa975a1fcc0cb43a406bd47ca5'
'c8bf41e78cda16d391b9099eeba01386'
'c069dffbb3f442aac3660b883ddd97f5'
'ad06309c623ff8e1b9f039d3b7eb97c2'
'f162bf93a76759bab37b29509a4a6e20'
'89903d92ca620921aecb3f1f30c05ebe'
'9a295c02f46bc867fc096862c7380a88'
'786c7e2af1dca5104af92bbdc60f7474'
'f2d90d06ed445a285c8406016e9d9c13'
'9506c56968c58332489986633319a186'
'2753d4de0b57fc8890488463c5e86d3f'
'5de5be8289764c11a3206b06351d81a6'
'd4b531e02b6a0287cffdbf527134ca29'
'adc1ab952b42ed0c0f53d1c308a32101'
'a3bb09a185e4c6a813227f3e84e4f6e5')
build() {
cd $startdir/src/$pkgname-$pkgver
for patch in ../bash30* ; do
cat $patch | patch -p0
done
./configure --prefix=/usr --with-curses --enable-readline
make || return 1
make DESTDIR=$startdir/pkg install
mv $startdir/pkg/usr/bin $startdir/pkg/bin
# we don't want bashbug
rm -f $startdir/pkg/bin/bashbug
rm -f $startdir/pkg/usr/man/man1/bashbug.1
install -D -m644 ../profile $startdir/pkg/etc/profile
ln -sf $pkgname $startdir/pkg/bin/sh
}
It gave checksum errors but seems to have gone ahead otherwise.
In my I-know-nothing-I-just-mess-around-here opinion, *all* patches released by a *maintainer* should be applied unless the maintainer describes specific instances where it might not be a good idea. There are *16* patches for bash, and I applied all of them. What's the logic of rel-3 having *one*?
And maybe having a single source of documentation that handles the ABS stuff in a linear step-by-step would be good. I think messing with the man pages and the Install Guide and some other stuff ended being more confusing that helpful.
But you helped a lot, cactus - thanks for pointing me in the right direction. And I'll definitely take that 'helping along' offer.
Offline
If somebody wanted to submit a bug report for me, that'd be great. Apparently I have to register and it keeps saying the code is invalid and spamming my mailbox with another one. I give up.
Offline
bingo
http://bugs.archlinux.org/index.php?do=details&id=2085
pkgname=bash
pkgver=3.0
pkgrel=4-CSTM
pkgdesc="The GNU Bourne Again shell"
url="http://www.gnu.org/software/bash/bash.html"
backup=(etc/profile)
depends=('glibc' 'readline')
source=(ftp://ftp.cwru.edu/pub/bash/bash-$pkgver.tar.gz profile
bash-history.patch
ftp://ftp.cwru.edu/pub/bash/bash-3.0-patches/bash30-002)
md5sums=('26c4d642e29b3533d8d754995bc277b3'
'719b60711ee609850277bd0848516136'
'7108b64d6b21b74764a602e142ca6b2c'
'6F4CF2AA975A1FCC0CB43A406BD47CA5')
build() {
cd $startdir/src/$pkgname-$pkgver
patch -Np1 -i ../bash-history.patch || return 1
patch -Np1 -i ../bash30-002 || return 1
./configure --prefix=/usr --with-curses --enable-readline
make || return 1
make DESTDIR=$startdir/pkg install
mv $startdir/pkg/usr/bin $startdir/pkg/bin
# we don't want bashbug
rm -f $startdir/pkg/bin/bashbug
rm -f $startdir/pkg/usr/man/man1/bashbug.1
install -D -m644 ../profile $startdir/pkg/etc/profile
ln -sf $pkgname $startdir/pkg/bin/sh
}
makepkg, and install the resulting tarball with pacman -U filename.tar.gz
and..i should clarify my earlier statement. Once you get used to it, it will be easy.
ps. i haven't tried the above, but in theory, it should work.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Thanks for the bug report. How do I file a bug report on the bug report registration?
As far as the alternate method, it does make more sense to pull the patch down directly - I saw the one patch in the ABS directory so I thought there must be a convention about having the patches locally. But I still don't know why it complained about the checksums - it *should* work either way. And, like I say, the checksum complaint didn't prevent the build or installation but does make it a 'bad' package, in a way.
Anyway - true, it does kind of have that feeling that once I really get it, I'll wonder how I didn't get it in the first place.
-- Oh, I forgot to add: I did a pacman -Syu today and the first thing it wanted to do was wipe out my spiffy new bash, so I told it no, added
IgnorePkg = bash
to /etc/pacman.conf and then ran it again. I assume that's the right way to go and I'll just remove it again when I actually want to upgrade?
Offline
-- Oh, I forgot to add: I did a pacman -Syu today and the first thing it wanted to do was wipe out my spiffy new bash, so I told it no, added
IgnorePkg = bash
to /etc/pacman.conf and then ran it again. I assume that's the right way to go and I'll just remove it again when I actually want to upgrade?
Exactly! Quick learner.
As for getting a bug report account. Some time back there was an issue with the registration not working. Don't know why.
Are you using email response, or jabber? I am pretty sure that jabber doesn't work right.
Anyway, long story short, I had to email Judd and ask to be manually added to the bugtracker. funny story, someone said I should *ahem* file a bug about not being able to join the bugtracker..lol..I am sure it was said tongue in cheeck, but it was still pretty funny at the time.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I was trying email. I'll give it another shot and then I guess I'll have to email him, too, if that's the way to go.
And, yeah, there is a kind of catch-22 when you've got bugs in the bug-handling software.
Offline