Re: PATH value doesn't get updated
В Пнд, 12/05/2008 в 17:02 -0600, Bob Proulx пишет: > The $0 is the name used to invoke the shell. If it starts with a '-' > then this is used to instruct the shell that it is a login shell. The > second variable $- is the flags set to the shell. The 'i' for > interactive should be in there. Actually that's not exactly true. It's possible to start bash as login shell but - will be absent. Quoting relevant part of manual: "A _login_ shell is one whose first character of argument zero is `-', or one invoked with the `--login' option." Better way to check if shell is login is: $ shopt | grep login_shell login_shell on -- Peter.
Multibyte characters in prompt still confuse Ctrl+R.
Hello. Another bug report was filled in in our bugzilla: http://bugs.gentoo.org/177095 bash-3.2 patch level 17. If PS1 contains multibyte characters this confuses readline during update_line. To reproduce set PS1='абвгдежзиклмноп ' and then press Ctrl+R. I've debuged problem a bit and although I'm not sure how to fix I'll report my observations. gdb shows that update_line() is called with the following arguments: update_line (old=0x812a558 "абвгдежзиклмноп ", new=0x8124628 "(reverse-i-search)`': ", current_line=0, omax=31, nmax=22, inv_botlin=0)at display.c:1220 when program gets display.c:1517 col_lendiff=6 >0 and lendiff=-9. And this negative value is passed to 1534: insert_some_chars (nfd, lendiff, col_lendiff); which leads to output corruption. Or in English this bug is reproducible when difference in characters (length on the screen) for new and old buffers is positive but difference in number of bytes is negative. To successfully reproduce bug PS1 (in bytes) should be longer then 22 (the length of '(reverse-i-search)`': '). Note that this is also reproducible if PS1 contains \W or \w and directory name is multibyte with the above mentioned conditions. -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.2 regression: command history display with coloured PS1.
On Пнд, 2007-03-26 at 17:35 +0200, Andreas Schwab wrote: > Peter Volkov <[EMAIL PROTECTED]> writes: > > Steps to reproduce: > > PS1="\e[36m[\e[34m\u\e[0m \e[32m\w\e[36m] \\$\e[0m " > > This is broken. You need to bracket escape sequences with \[ \]. Eh. Right. Sorry for noise. -- Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash-3.2 regression: command history display with coloured PS1.
Hello. The following bug (http://bugs.gentoo.org/172260) == Steps to reproduce: PS1="\e[36m[\e[34m\u\e[0m \e[32m\w\e[36m] \\$\e[0m " LC_ALL="en_US.UTF8" ls echo ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz Bash 3.1.* works correctly. == is reproducible with patch Chet provided in thread "bash-3.2 regression: broken colour prompt". So i think this is another bug. Thank you in advance. -- Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: How to use [[ string =~ regexp ]]?
On Вск, 2006-05-21 at 15:55 -0400, Paul Jarc wrote: > [a-z] matches only one charater, but the pattern is not required to > match against the entire string. On Вск, 2006-05-21 at 13:57 -0600, Mike Stroyan wrote: > The =~ regexp match will match a substring by default. You can use ^ and $ > to anchor the expression to the start and end of the string. Yes! That was what I missed. On Вск, 2006-05-21 at 22:40 -0400, Chet Ramey wrote: > It seems reasonable that quoting any part of the rhs to the =~ > operator should cause it to behave in the same manner. > > Since the arguments to [[ don't undergo any of the expansions that > require quoting to protect them, there's no reason for =~ to act > differently than the other operators that do pattern matching. Never noticed that. This is really interesting. Thank you all for your answers, Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
How to use [[ string =~ regexp ]]?
Hello. Please CC my email to answers as I'm not subscribed to the list. I have problems using =~ operator. I've tried to search for answer, but failed. I'm using GNU bash, version 3.1.17. Can anybody give me some examples of usage? I really do not understand why $ [[ "string" =~ "[a-z]" ]] && echo something something echo me something. IIUC the regular expression [a-z] matches any single letter, so how string "string" matches one letter? Seems that I missed the point, or did I encounter bug? Thank you for any help, Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Spam] Re: Why bash stops process in background?
On Чтв, 2005-08-25 at 08:46 -0600, Bob Proulx wrote: > Peter Volkov Alexandrovich wrote: > > P.S. I'm not subscribed to the list, so please CC me. > > > I need to run ssh in background just to forward ports. But anytime I put > > it into background process state became stoped and this does not allow > > me to send packets through forwarded ports. 'bg' command does not help. > > Very likely the ssh program is trying to do I/O. The kernel will > notice this and stop the process so that you can bring it into the > foreground and interact with it. > > This really has nothing to do with bash and is simply the behavior of > BSD style job control as implemented by the kernel. Very interesting. I did not know that. Thank you for explanation. > Try giving ssh the -n option. Also, you may want to use -N too. Here > is the ssh man page snippets. [snip info from man page.] Yes. -nN options help me. Thank you, Bob, again, Peter. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Why bash stops process in background?
Hello. I need to run ssh in background just to forward ports. But anytime I put it into background process state became stoped and this does not allow me to send packets through forwarded ports. 'bg' command does not help. How can I tell bash not to stop process? I've tried to trap signals, but I can not trap STOP signal. What else can I do? I'm using: [EMAIL PROTECTED] ~ $ bash --version GNU bash, version 3.00.16(1)-release (i686-pc-linux-gnu) Copyright (C) 2004 Free Software Foundation, Inc. Thank you for your time, Peter. P.S. I'm not subscribed to the list, so please CC me. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
