Change in reaction to C-c (SIGINT) in an interactive shell

[tschwinge]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' 
-DCONF_OSTYPE='gnu' -DCONF_MACHTYPE='i486-pc-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: GNU flubber 0.3 GNU-Mach 1.3.99/Hurd-0.3 i386-AT386 GNU
Machine Type: i486-pc-gnu

Bash Version: 4.0
Patch Level: 33
Release Status: release


Hello!

The 3.2 series of bash acted like this when the user is typing C-c
(SIGINT) in an interactive shell during command line editing: cancel the
command line editing, display a new prompt, set $? to 1.  With the recent
version, this changed as follows: cancel the command line editing,
display ^C, display a new prompt, set $? to 128.  The displaying of ^C is
in line with displaying it when a running process is being signalled,
where is also was displayed with bash versions 3.2 already.  But why the
value 128 for $? -- shouldn't this rather be 128 + SIGINT?

I don't care too much about this, but noticed it, and thought that I'd
bring it to your attention.


Regards,
 Thomas

Improving the manual (was: ${!vname} not documented)

[Thomas Schwinge]

Hello!

On Tue, Oct 06, 2009 at 08:16:03AM -0400, Greg Wooledge wrote:
> On Tue, Oct 06, 2009 at 03:25:31AM -0400, Mike Frysinger wrote:
> > i imagine Chet takes patches
> 
> When I sent a patch to make the manual more human-friendly (replacing
> for example ! with $! so that people can search for $! and find it),
> it was not accepted.

I support that such a patch is installed, as it makes navigating in the
manual easier for all those who don't know in which section to look for
$!, for example.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Change in reaction to C-c (SIGINT) in an interactive shell

[Chet Ramey]

tschwi...@gnu.org wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' 
> -DCONF_OSTYPE='gnu' -DCONF_MACHTYPE='i486-pc-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: GNU flubber 0.3 GNU-Mach 1.3.99/Hurd-0.3 i386-AT386 GNU
> Machine Type: i486-pc-gnu
> 
> Bash Version: 4.0
> Patch Level: 33
> Release Status: release
> 
> 
> Hello!
> 
> The 3.2 series of bash acted like this when the user is typing C-c
> (SIGINT) in an interactive shell during command line editing: cancel the
> command line editing, display a new prompt, set $? to 1.  With the recent
> version, this changed as follows: cancel the command line editing,
> display ^C, display a new prompt, set $? to 128.  The displaying of ^C is
> in line with displaying it when a running process is being signalled,
> where is also was displayed with bash versions 3.2 already.  But why the
> value 128 for $? -- shouldn't this rather be 128 + SIGINT?

Thanks for the report.  This has already been fixed for bash-4.1.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Cannot form valid test expressions that involve brackets as string comparison targets

[Lyall Pearce]

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 
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
-DSYS_BASHRC='/etc/bash/bashrc'
-DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
-DSSH_SOURCE_BASHRC -O2 -mtune=core2 -march=core2 -fomit-frame-pointer -pipe
uname output: Linux lyalls-pc 2.6.30-gentoo-r6 #1 SMP PREEMPT Sun Sep 6
10:18:42 CST 2009 i686 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
GenuineIntel GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 4.0
Patch Level: 28
Release Status: release

Description:
Cannot form expressions which involve left or right brackets.

Repeat-By:

basePic="(2008-04)"
if [ "${basePic:0:1}" = '(' -a "${basePic:4:1}" = ')' ]
then
echo "Got brackets"
fi
if [ "${basePic:0:1}" = "(" -a "${basePic:4:1}" = ")" ]
then
echo "Got brackets"
fi
if [ "${basePic:0:1}" = '\(' -a "${basePic:4:1}" = '\)' ]
then
echo "Got brackets"
fi

Fix:
Unsure, I think the bracket parsing should not be treated as
expression delimiters if they are enclosed in quotes?
If they are bare, then treat as (brackets), if enclosed in quotes,
treat as "data".

ignoring comments in a 'cat' call

[Tamlyn1978]

I have a file with a list of programs with comments describing what they do,
e.g.

unison # file syncronisation
grass # gis program

I have a script, which I run as root and includes the command:

m...@me:~$ aptitude install $(cat programs) -y

where 'programs' is the file with the list of programs. Aptitude does not
ignore the '#' comments, reading them, and the subsequent comment text as
package files.

Is there a way to make 'cat' ignore the comments or is there a better
alternative to cat in this case?


-- 
View this message in context: 
http://www.nabble.com/ignoring-comments-in-a-%27cat%27-call-tp25796419p25796419.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.

Re: ignoring comments in a 'cat' call

[Chris F.A. Johnson]

On Wed, 7 Oct 2009, Tamlyn1978 wrote:

> I have a file with a list of programs with comments describing what they do,
> e.g.
> 
> unison # file syncronisation
> grass # gis program
> 
> I have a script, which I run as root and includes the command:
> 
> m...@me:~$ aptitude install $(cat programs) -y
> 
> where 'programs' is the file with the list of programs. Aptitude does not
> ignore the '#' comments, reading them, and the subsequent comment text as
> package files.
> 
> Is there a way to make 'cat' ignore the comments or is there a better
> alternative to cat in this case?

aptitude install $(cut -d ' ' -f1 programs) -y

-- 
   Chris F.A. Johnson, webmaster 
   ===
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Re: Cannot form valid test expressions that involve brackets as string comparison targets

[Chris F.A. Johnson]

On Wed, 7 Oct 2009, Lyall Pearce wrote:

> 
> 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 
> -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
> -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
> -DSYS_BASHRC='/etc/bash/bashrc'
> -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
> -DSSH_SOURCE_BASHRC -O2 -mtune=core2 -march=core2 -fomit-frame-pointer -pipe
> uname output: Linux lyalls-pc 2.6.30-gentoo-r6 #1 SMP PREEMPT Sun Sep 6
> 10:18:42 CST 2009 i686 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
> GenuineIntel GNU/Linux
> Machine Type: i686-pc-linux-gnu
> 
> Bash Version: 4.0
> Patch Level: 28
> Release Status: release
> 
> Description:
> Cannot form expressions which involve left or right brackets.
> 
> Repeat-By:
> 
> basePic="(2008-04)"
> if [ "${basePic:0:1}" = '(' -a "${basePic:4:1}" = ')' ]
> then
> echo "Got brackets"
> fi
> if [ "${basePic:0:1}" = "(" -a "${basePic:4:1}" = ")" ]
> then
> echo "Got brackets"
> fi
> if [ "${basePic:0:1}" = '\(' -a "${basePic:4:1}" = '\)' ]
> then
> echo "Got brackets"
> fi
> 
> Fix:
> Unsure, I think the bracket parsing should not be treated as
> expression delimiters if they are enclosed in quotes?
> If they are bare, then treat as (brackets), if enclosed in quotes,
> treat as "data".

   Try this:

basePic="(2008-04)"
if [ "${basePic:0:1}" = '(' ]#-a "${basePic:4:1}" = ')' ]
then
  echo "Got brackets"
fi
if [ "${basePic:0:1}" = "(" ]#-a "${basePic:4:1}" = ")" ]
then
  echo "Got brackets"
fi
if [ "${basePic:0:1}" = '\(' ]   #-a "${basePic:4:1}" = '\)' ]
then
  echo "Got brackets"
fi

-- 
   Chris F.A. Johnson, webmaster 
   ===
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)