"tcsetattr: Interrupted system call" after rapid-fire ^C chars
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=i686 -O2 -pipe uname output: Linux crater 2.6.27-gentoo #1 SMP PREEMPT Mon Oct 13 13:37:45 MDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 33 Release Status: release Description: (Note that this may be hard to reproduce, at least how I did it, on a stock kernel) I've been doing some work in the kernel N_TTY line discipline and pty code, and one issue was that when a tty is stopped (with ^S) and a lot of input/output happens - enough to fill the buffer more than 1/2 way, the tty will stop being polled for more data. Holding down a key, thereby producing a rapid series of characters, will slowly let the tty continue to process blocks of characters. I've fixed the issue in the kernel, but it seems I uncovered a potential bash issue. Anyway, when testing this with the "tr" program in a bash shell, I tried holding down ctrl-C. Eventually the tty got to reading these characters and produced an interrupt as expected. However, instead of breaking out of tr, as usual, I got: "-bash: [6630: 5] tcsetattr: Interrupted system call" So my question is: is this because there is a small window of opportunity for ^C to cause tcsetattr() to get interrupted? Is there any way to close this window if so? Sorry if this problem has already been addressed in bash 4... Repeat-By: Well, without a hacked kernel, you'll probably not hit *this* manifestation of the issue, but what I did was: - run a text processing program (like "cat" or "tr") - hit ctrl-S - enter lots of text that will then produce lots of output - hold down ctrl-C until the error is produced Fix: Should interrupts be trapped during call to tcsetattr()? Thanks, Joe P.S. Please cc my email address in any replies...
Readline : move to previous/next path component
One frequently needed function that readline does not seem to have is a way to move to the beginning of the next or previous path component. This is what I've come up with : \C-t: "\C-b\C-b\e\C-]/\C-f" \C-y: "\C-]/\C-f" Three problems with this kludge : 1. The definition uses keys, not functions. Is there a way to mix functions and string literals in a readline binding ? 2. If you press ^Y while past the last slash in a word, the cursor moves to the first slash in the next word if there is one, or the next character otherwise. It would be more useful to move immediately past the end of the current word. 3. If you press ^T while you're already on the first slash in a word, the cursor moves to the last slash in the previous word if there is one, or the previous character otherwise. It would be more useful to move to the beginning of the current word. Is there a better way ? Thanks in advance. -- André Majorel http://www.teaser.fr/~amajorel/> You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists -- Abbie Hoffman.
why does bash not execute .bashrc with ssh -t ?
I am trying to work out why .bashrc is not executing when I invoke ssh with the -t option and _does_ execute when I invoke ssh without the -t option. ssh -qt remote-host which rsync # indicates ~/.bashrc has not executed on remote host ssh -q remote-host which rsync # indicates ~/.bashrc has executed on remote host ssh -qt remote-host tty # reports /dev/pts/1 ssh -q remote-host tty # reports not a tty ssh -qt remote-host echo '$-' # reports hBc ssh -q remote-host echo '$-' # reports hBc ssh -q remote-host ps -o "pid,ppid,args" -u xjsrs PID PPID COMMAND 8704 8702 sshd: [EMAIL PROTECTED] 8705 8704 ps -o pid,ppid,args -u xjsrs ssh -qt remote-host ps -o "pid,ppid,args" -u xjsrs PID PPID COMMAND 8733 8731 sshd: [EMAIL PROTECTED]/1 8734 8733 ps -o pid,ppid,args -u xjsrs According to echo '$-' neither shell is interactive.Yet, the one that is started without a pseudo terminal does have .bashrc executed. I added an debug statements to .bash_profile and it not getting executed in either case. There is no /etc/sshrc file and I don't have a ~/.ssh/rc file. The bash version is: GNU bash, version 3.00.15(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2004 Free Software Foundation, Inc. Upon reading the manual, the rule that bash seems to be using to decide that .bashrc should be executed if -t is not specified, is this one: Bash attempts to determine when it is being run by the remote shell daemon, usually rshd. If bash determines it is being run by rshd, it reads and executes commands from ~/.bashrc, if that file exists and is readable. It will not do this if invoked as sh. The --norc option may be used to inhibit this behavior, and the --rcfile option may be used to force another file to be read, but rshd does not generally invoke the shell with those options or allow them to be specified. However, when I use the ssh -t option, it would seem that allocation of a pseudo-tty is causing bash to assume that it is not being invoked by a remote shell daemon. Is there any way I can have an ssh pseudo-tty and get bash to execute ~/.bashrc? jon seymour.
Re: why does bash not execute .bashrc with ssh -t ?
Jon Seymour wrote: > Bash attempts to determine when it is being run by the remote shell > daemon, usually rshd. If bash determines it is being run by rshd, it > reads and executes > commands from ~/.bashrc, if that file exists and is readable. It > will not do this if invoked as sh. The --norc option may be used to inhibit > this behavior, and > the --rcfile option may be used to force another file to be read, but > rshd does not generally invoke the shell with those options or allow them to > be specified. > > However, when I use the ssh -t option, it would seem that allocation of a > pseudo-tty is causing bash to assume that it is not being invoked by a > remote shell daemon. Correct. One of the criteria bash uses to decide whether it's being invoked by rshd or sshd is that its stdin is a socket. Allocating a pseudo-tty makes that false. You can force bash to source .bashrc when it finds the various ssh variables in its startup environment by defining SSH_SOURCE_BASHRC in config-top.h and rebuilding bash. That will cause .bashrc to be sourced more times than it should, but it will catch the cases you are interested in. Chet > > Is there any way I can have an ssh pseudo-tty and get bash to execute > ~/.bashrc? > > jon seymour. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: 'bash -c' does not execute 'trap ... EXIT' command when last command is an external command
Steffen Kieß wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib > -g -O2 -Wall > uname output: Linux fips 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC > 2008 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 39 > Release Status: release > > Description: > 'bash -c' does not execute a 'trap ... EXIT' command when the last > command is an external command. Thanks for the report. This has been fixed for the next version of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Readline : move to previous/next path component
Andre Majorel wrote: > One frequently needed function that readline does not seem to > have is a way to move to the beginning of the next or previous > path component. This is what I've come up with : > > \C-t: "\C-b\C-b\e\C-]/\C-f" > \C-y: "\C-]/\C-f" Readline doesn't have any built-in knowledge of Unix pathnames. You might want to take a look at emacs-mode M-b, which moves backward by strings of alphabetic characters, and M-f, which moves forward. You might have to play around with a macro that moves forward additional characters past the `/', but that should get you further. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: "tcsetattr: Interrupted system call" after rapid-fire ^C chars
Joe Peterson wrote: > Well, without a hacked kernel, you'll probably not hit > *this* manifestation of the issue, but what I did was: > > - run a text processing program (like "cat" or "tr") > - hit ctrl-S > - enter lots of text that will then produce lots of output > - hold down ctrl-C until the error is produced > > Fix: > Should interrupts be trapped during call to tcsetattr()? I don't think so. Readline already blocks interrupts when it calls tcsetattr, and bash handles that call returning -1/EINTR appropriately. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: "tcsetattr: Interrupted system call" after rapid-fire ^C chars
Chet Ramey wrote:
> Joe Peterson wrote:
>
>> Well, without a hacked kernel, you'll probably not hit
>> *this* manifestation of the issue, but what I did was:
>>
>> - run a text processing program (like "cat" or "tr")
>> - hit ctrl-S
>> - enter lots of text that will then produce lots of output
>> - hold down ctrl-C until the error is produced
>>
>> Fix:
>> Should interrupts be trapped during call to tcsetattr()?
>
> I don't think so. Readline already blocks interrupts when it calls
> tcsetattr, and bash handles that call returning -1/EINTR appropriately.
Hi,
Yep, I see the code that returns -1 in jobs.c:
-
if (tcgetattr (tty, &shell_tty_info) < 0)
{
#if 0
/* Only print an error message if we're really interactive at
this time. */
if (interactive)
sys_error ("[%ld: %d] tcgetattr", (long)getpid (), shell_level);
#endif
return -1;
}
-
And that sys_error message is, I believe, the exact error I am seeing.
What I am wondering is how did I manage to invoke this by using ^C? Did
I hit some small window when readline was not running and when the
program that would normally catch the kill signal was not listening
(i.e. bash itself somehow caught it)? I did not think this was
possible. Just wondering if this is something that should not happen.
Thanks, Joe
Regular experssions are not working in 3.2.39 as in 3.1.17
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux metairie 2.6.26.5-tce #65 SMP PREEMPT Fri Oct 3 11:20:48 PDT 2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: regular expression are broken in 3.2.39 version 3.1.17 (debian etch) = [EMAIL PROTECTED]:~# echo $BASH_VERSION 3.1.17(1)-release [EMAIL PROTECTED]:~# ss="dsfds f dsf ESSID:bob" [EMAIL PROTECTED]:~# [[ "$ss" =~ 'ESSID:(.**)' ]] && echo $? 0 version 3.1.29 (debian lenny ) [EMAIL PROTECTED]:/D/home/david$ echo $BASH_VERSION 3.2.39(1)-release [EMAIL PROTECTED]:/D/home/david$ ss="dsfds f dsf ESSID:bob" [EMAIL PROTECTED]:/D/home/david$ [[ "$ss" =~ 'ESSID:(.**)' ]] && echo $? [EMAIL PROTECTED]:/D/home/david$ echo $? 1 === thanks Repeat-By: see above
Re: Regular experssions are not working in 3.2.39 as in 3.1.17
[EMAIL PROTECTED] wrote: > regular expression are broken in 3.2.39 It's not broken; it's different. See entry E14 in the bash FAQ, and check out the compat31 option in shopt. paul
Development snapshot
Hello, is there something like a development snapshot for Bash 4 or is the code "hidden" during development phase and I need to wait for the first release? Thanks in advance, Jan -- This is my life - this is my net! - Jan
