Search Results

Search found 4 results on 1 pages for 'bs0'.

Page 1/1 | 1 

• Problems installing MySQL-python via yum / missing dependency / incompatibility problem?

  - by bs0

  I have come up against problems installing MySQL-python via yum. Our server is running Centos 5.5 and MySQL Version 5.1.45, Python-dev is installed. Yum complains about the missing dependency libmysqlclient_r.so.15: Missing Dependency: libmysqlclient_r.so.15()(64bit) is needed by package MySQL-python-1.2.1-1.x86_64 (base) The server is up to date and the packages mysql mysql-devel python-devel are installed. The missing dependency is nowhere on the system: locate libmysqlclient /usr/lib64/libmysqlclient.so /usr/lib64/libmysqlclient.so.15 /usr/lib64/libmysqlclient.so.16 /usr/lib64/libmysqlclient.so.16.0.0 /usr/lib64/libmysqlclient_r.so /usr/lib64/libmysqlclient_r.so.16 /usr/lib64/libmysqlclient_r.so.16.0.0 /usr/lib64/mysql/libmysqlclient.a /usr/lib64/mysql/libmysqlclient.la /usr/lib64/mysql/libmysqlclient.so /usr/lib64/mysql/libmysqlclient_r.a /usr/lib64/mysql/libmysqlclient_r.la /usr/lib64/mysql/libmysqlclient_r.so /usr/local/cpanel/lib64/libmysqlclient.so.14 rpm -qa | grep -i mysql MySQL-devel-5.1.45-0.glibc23 MySQL-bench-5.0.89-0.glibc23 MySQL-shared-5.1.45-0.glibc23 MySQL-server-5.1.45-0.glibc23 MySQL-test-5.1.45-0.glibc23 MySQL-client-5.1.45-0.glibc23 The Python version is python-2.4.3-27.el5.x86_64: Python 2.4.3 (#1, Sep 3 2009, 15:37:37) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 Any suggestions would be greatly appreciated.

  Read the article

• Mac OS X Terminal.app Ubuntu 9.10 SSHD and incorrect keyboard mapping

  - by Jesse

  Does anyone have any Idea how to handle this? I can't stand connecting to certain Ubuntu boxes via Mac OS X because of issues with keyboard layout etc. I have set TERM=vt100 and TERM=xterm-color in Ubuntu .bashrc and also in the Terminal.app advanced preferences and nothing seems to fix this issue. Trying to use arrow keys on slim silver keyboard results in ^[[A etc. From Answer OS X 10.6.4 When I try to run /lib/terminfo/x/xterm-color I get permission denied? Maybe this is the issue?! Regular bash login shell. If I sudo often it works. Which leads me to believe the above permissions problem is the cause. Output from stty -a: $ stty -a speed 9600 baud; rows 47; columns 181; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe -echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

  Read the article

• xterm not wrapping text properly

  - by mulllhausen

  I'm configuring both my gnome-terminal and xterm columns (i still haven't picked which of these I will be using) and I have a couple of issues I would like to fix: the typing area seems to be smaller (fewer columns) than the display area the typed text is not wrapping to the next line when it reaches the end - it just continues back around on the same line, overwriting the prompt (i have set a custom bash prompt with PS1 in case this is relevant) $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 7.1 (wheezy) Release: 7.1 Codename: wheezy $ echo $TERM xterm $ stty -a [peter@pc ~] $ stty -a speed 38400 baud; rows 52; columns 126; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke $[peter@mine ~] $ # the column width only goes up to here ------------------------------------------------> the results are identical in both the xterm and in gnome-terminal 3.4.1.1 and as you can see, the output of the stty -a command goes right up to the edge of the screen, while the typing does not go that far. I have found that I can get the desired result by setting the columns to a very large number, eg: $ stty cols 1800 this fixes both problems. Is it the right way to go about solving this problem? Will this "break" any of the output from programs? So far I have tried top and stty -a and these seem OK. more info as requested in the comments i found that if i cat some input into a file then the columns actually strech the full width of the terminal window: [peter@mine applications] $ cat > /tmp/asd aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaasssssssssssssssssssssssssssssssssssssssssssssssssssssssssssqqqqqqqqqqqqqqqq qqqq does this imply that it is actually bash that is restricting the number of columns and not the terminal? if so then how to alter the number of columns in bash?

  Read the article

• SIGINT and SIGTSTP ignored by most common applications

  - by Vašek Potocek

  After the last upgrade to my Fedora, a strange behaviour started occurring in X terminal applications. I can't seem to stop any process using Ctrl+C, it just results in printing ^C to the console. Similarly, Ctrl+Z prints ^Z and the process goes on. Both work well in non-graphical virtual consoles. I checked stty -a and it seems perfectly normal: speed 38400 baud; rows 24; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke This is independent of the terminal (gnome-terminal, XFCE4 terminal, xterm). I later noticed that it may not be caused by the terminal at all: INT or TSTP sent directly to the respective process are ignored, too. This comprises various applications I used to terminate using Ctrl+C on a regular basis (and which often don't have any better means of exiting): cat, find, tail -f, java, ping, mplayer when stuck on a broken file... Even bash ignores Ctrl+C when I want to break a command line I have been entering and then changed my mind (no ^C is printed in this case). I need to delete it character by character (of which there may be hundreds if filename completion has been used) or intentionally run the unwanted command. Strangely enough, vim does recognize Ctrl+C—just to say its "use :quit", of course. This is extremely annoying and prevents me from working efficiently. Everything had been working until lately, maybe a week ago or so. I can not find any possible causes in Google, perhaps I'm trying wrong search terms or misidentifying the main problem. What could be it and how could I revert the standard behaviour, please? Update Ctrl+Z works sometimes. It seems that in the very first terminal I launch after logging in it stops the running command but stops working after that.

  Read the article

1