bash $'foo' quoting problem

[Dr. Werner Fink]

Hi,

the bash-3.1.5 has a problem with quoting which leads to
a different output of

echo $(set -- $'a b'; echo $#)

and

echo "$(set -- $'a b'; echo $#)"

The patch below fix this problem.

  Werner


*** parse.y
--- parse.y Tue Jan 10 11:36:59 2006
***
*** 2842,2848 
  ttrans = ansiexpand (nestret, 0, nestlen - 1, &ttranslen);
  xfree (nestret);
  
! if ((rflags & P_DQUOTE) == 0)
{
  nestret = sh_single_quote (ttrans);
  free (ttrans);
--- 2842,2848 
  ttrans = ansiexpand (nestret, 0, nestlen - 1, &ttranslen);
  xfree (nestret);
  
! if (extended_quote || (rflags & P_DQUOTE) == 0)
{
  nestret = sh_single_quote (ttrans);
  free (ttrans);


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bind does not modify key bindings

[Yong Lu]

> "Chet" == Chet Ramey <[EMAIL PROTECTED]> writes:


> It does, actually.  Bash-3.1 key bindings interpret the "\M-" prefix the
> same way that the dispatch code does:  if the convert-meta flag has been
> set, the sequence is converted into an escape-prefixed sequence and
> bound accordingly.  If that variable is off, the eighth bit is turned
> on (`metafying' the following character).

> What bash-3.1/readline-5.1 did not do (and has been changed since) is
> change the code that bind -p calls to list key bindings to not use
> the \M- prefix for escape-prefixed key sequences when convert-meta is
> off.

> The following sequence of commands should illustrate the difference.
> The cat -v is in there to make the M-p visible.


Hi, thanks for your reply!  With bash2, I can simply modify the output
of `bind -vp` and read back the keybinding by `bind -f`.  How can I
make it to work with bash3 too?  

Thanks,

-Yong


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bind does not modify key bindings

[Yong Lu]

> "Chet" == Chet Ramey <[EMAIL PROTECTED]> writes:


> If you run with convert-meta disabled, take the output and convert the
> key sequences that begin with \M- to begin with \e.  (That is, make ESC
> the meta-prefix explicitly.)

> Chet

> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ( ``Discere est Dolere'' -- chet )
>  Live Strong.  No day but today.
> Chet Ramey, ITS, CWRU[EMAIL PROTECTED]
http://cnswww.cns.cwru.edu/~chet/

Now it works.  Thanks again!

-Yong


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

command history

[mwild]

hi everybody

this is my first post, and i'm not sure whether it even belongs here...

is it the shell which handles the command history? if so, here my 
feature request: it would be very convenient, to be able and narrow down 
the search in the command history by typing a few characters, instead of 
having to scroll through the whole thing.

or is it already there, without me knowing how to switch it on?



michael


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Directing to a file...

[sam]

Running program many times I noticed that

ps -p $$ -o pid,args > waiting.$$;
lockfile -1 setting
if ! cat waiting.$$ | egrep -q '[0-9]'
then
ps -p $$ -o pid,args > check.$$
echo "What's going on!!!"
exit 1;
fi


sometimes it prints "What is going on". File 
waiting.1234 contains only ps-headers, that is


  PID COMMAND

while check.1234 contains

PID COMMAND
1234./my_program arg1 arg2


Is this a bug?









--
www.TOTALIZM.com	UFO Earth Occupation 
http://jan-pajak.com/wtc.htm 
http://jan-pajak.com/shuttle.htm 
http://jan-pajak.com/predators.htm



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

bash reproducibly segfaults while globbing large directory

[Nikita Danilov]

Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux
Compiler: gcc -I/usr/src/packages/BUILD/bash-2.05b 
-L/usr/src/packages/BUILD/bash-2.05b/../readline-4.3
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' 
-DCONF_OSTYPE='linux' -DCONF_MACHTYPE='i586-suse-linux' -DCONF_VENDOR='suse' 
-DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib  -O2 -march=i586 
-mcpu=i686 -fmessage-length=0 -Wall -D_GNU_SOURCE -Wall -pipe -g 
-fbranch-probabilities
uname output: Linux tau 2.6.15-dirty #13 SMP Sat Feb 11 18:30:54 MSK 2006 i686 
i686 i386 GNU/Linux
Machine Type: i586-suse-linux

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:
bash 100% reproducibly crashes when trying to do a globbing in a huge
directory

Repeat-By:

$ bash --version
GNU bash, version 3.00.16(1)-release (i386-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
$ ls|wc
 938729  938729 11199200
$ echo $LANG
C
$ echo *
Segmentation fault

In gdb I see following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x080c3ded in internal_wstrmatch ()
(gdb) bt
#0  0x080c3ded in internal_wstrmatch ()
#1  0x080c4c42 in xstrmatch ()
#2  0x080c1f3f in glob_vector ()
#3  0x080c26cd in glob_filename ()
#4  0x08087a50 in shell_glob_filename ()
#5  0x08081858 in extract_command_subst ()
#6  0x0806c735 in execute_shell_function ()
#7  0x0806afe5 in execute_command_internal ()
#8  0x0806d702 in execute_command ()
#9  0x0805dda1 in reader_loop ()
#10 0x0805d8c9 in main ()

Another person reproduced this with bash 3.1 and directory containing
480k files.

Nikita.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Trouble evaluating embedded commands

[Van Van Cleave]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: 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   -g -O2
uname output: Linux falcon 2.6.11.12 #10 SMP Fri Jan 20 20:32:01 CST 2006
i686 pentium4 i386 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.1
Patch Level: 0
Release Status: release

Description:
bash 3.1 cannot evaluate $'***' within "$(...)" and reports a bash: ***:
command not found error.

Repeat-By:
echo "$(echo $';foo')"

Fix:
[Description of how to fix the problem.  If you don't know a
fix for the problem, don't include this section.]
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bash-3.1 Official patch 10

[Greg Schafer]

Chet Ramey wrote:

> There is a difference in behavior between bash-3.0 and bash-3.1 involving
> parsing of single- and double-quoted strings occurring in old-style
> command substitution.  The difference has to do with how backslashes are
> processed.  This patch restores a measure of backwards compatibility while
> the question of POSIX conformance and ultimately correct behavior is
> discussed.

Hi,

It appears there might be problem with this patch. Here is a test case I
distilled from the grep-2.5.1a testsuite:

status=`echo '-'| { ${GREP} -E -e 'a\' >/dev/null 2>&1 ; echo $?; }`

Put that line into a file called "myfile" then run like this:

# bash -n myfile
myfile: line 1: unexpected EOF while looking for matching `''
myfile: line 2: syntax error: unexpected end of file

AFAICT, this used to be accepted by older Bash versions.

Do you think problem lies with this Bash patch or with test case?

Thanks
Greg
--
http://www.diy-linux.org/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

bash-3.0.16 fails to compile on HP-UX 11.11

[Ackersviller, Paul (TOR)]

Configuration Information [Automatically generated, do not change]:
Machine: hppa2.0w
OS: hpux11.11
Compiler: cc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='hppa2.0w' 
-DCONF_OSTYPE='hpux11.11' -DCONF_MACHTYPE='hppa2.0w-hp-hpux11.11' 
-DCONF_VENDOR='hp' -DLOCALEDIR='/usr/local/gnu/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H -DHPUX  -I.  -I. -I./include -I./lib 
-I/usr/local/include uname output: HP-UX esi0q80d B.11.11 U 9000/800 1499339190 
unlimited-user license Machine Type: hppa2.0w-hp-hpux11.11

Bash Version: 3.0
Patch Level: 16? (maually twiddled)
Release Status: release

Description:
The compilation error shown below:
making lib/sh/libsh.a in ./lib/sh
gnumake[1]: Entering directory `/usr/local/.src/bash-3.0.16/lib/sh'
cc -c  -I. -I../.. -I../.. -I../../lib -I../../include -I. -I../../lib/intl 
-I/usr/local/.src/bash-3.0.16/lib/intl -DHAVE_CONFIG_H -DSHELL -DHPUX  -g 
-I/usr/local/include  strftime.c
cc: "strftime.c", line 101: error 1584: Inconsistent type declaration: 
"timezone".
cc: "strftime.c", line 185: warning 527: Integral value implicitly converted to 
pointer in assignment.
gnumake[1]: *** [strftime.o] Error 1

Repeat-By:
Simply configure and make bash-3.0.16 on HP-UX 11.11; this error got introduced 
sometime since 3.0 -- it builds fine for me.

Fix:
Here's the diff of lib/sh/strftime.c between 3.0.16 and 3.0. Was this change 
done for some version of HP-UX other than 11.11?
*** bash-3.0.16/lib/sh/strftime.c   Wed Mar  3 22:13:23 2004
--- bash-3.0/lib/sh/strftime.c  Sun Aug  8 22:21:26 2004
***
*** 97,99 
  extern int daylight;
! #if defined(SOLARIS) || defined(mips) || defined (M_UNIX)
  extern long int timezone, altzone;
--- 97,99 
  extern int daylight;
! #if defined(SOLARIS) || defined(mips) || defined (M_UNIX) || defined (HPUX)
  extern long int timezone, altzone;
***
*** 462,463 
--- 462,464 
 */
+ #ifndef HPUX
case 'z':   /* time zone offset east of GMT e.g. -0600 */
***
*** 496,497 
--- 497,499 
break;
+ #endif /* !HPUX */
*** Confidentiality Notice ***
ESI Canada -- Optimizing the value of drug and dental benefits

This email, its electronic document attachments, and the contents of its 
website linkages may contain confidential health information.  This information 
is intended solely for use by the individual or entity to whom it is addressed. 
 If you have received this information in error, please notify the sender 
immediately and arrange for the prompt destruction of the material and any 
accompanying attachments.

*** Avis de confidentialité ***
ESI Canada -- Optimiser la valeur des régimes d'assurance médicaments et 
dentaires

Ce courriel ainsi que tout document y étant joint de même que le contenu des 
liens vers des sites Web peuvent réunir des renseignements  confidentiels sur 
la santé.  Cette information s'adresse uniquement à l'usager ou à 
l'organisation auxquels elle est destinée.  Si vous avez reçu ce message par 
erreur, veuillez en aviser l'expéditeur immédiatement et procéder à la 
suppression du document et des fichiers joints sans tarder. 






___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

extglob and dots

[Benoît VILA]

hi

i made a bug repport few days ago but i'm not sure it reached the list, 
anyway my concern is quite simple, i got a pattern which doesn't match 
what he should do : +([[:alpha:].]) which doesn't match strings composed 
of letters and/or dots, it just match letters-only-composed string 
whereas *+([.])* works fine to match strings contenning dots and only 
strings with at lesat one dot so just wondering if it is fixed or known 
or even a normal behaviour...


thanks for answering

it was tested (among athers) on a debian with bash 3.1-5(release)



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bash-3.1 Official patch 10

[Jeff Chua]

On Wed, 22 Feb 2006, Greg Schafer wrote:


status=`echo '-'| { ${GREP} -E -e 'a\' >/dev/null 2>&1 ; echo $?; }`


You're having one additional "\" ... change that to ...
status=`echo '-'| { ${GREP} -E -e 'a' >/dev/null 2>&1 ; echo $?; }`


or split to the next line ...

status=`echo '-'| { ${GREP} -E -e 'a\
' >/dev/null 2>&1 ; echo $?; }`

or remove the "\" altogether.


Thanks,
Jeff.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: behavior diff. btw. 3.0 and 3.1 (may be a bug)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to [EMAIL PROTECTED] on 1/23/2006 6:52 AM:
> 
> Description:
>   There is a behavior difference between bash 3.0 and 3.1. This results
> in trouble installing oracle database software. in 3.0 `cmd` can
> span over lines, in 3.1 not.
> 
> Repeat-By:
>   
> a=`echo 'a b c' | sed 's/ /\\
> /g' | grep 'b'`
> echo $a

Or shorter:

bash-3.0 $ echo `echo '\\
> a'`
\ a

bash-3.1.9 $ echo `echo '\\
> a'`
\a

Using 'set -xv' is useful here to seeing what bash is trying to do.  bash
3.0 invokes the subcommand "echo '\[newline]a'" (after IFS splitting, the
outer echo sees two parameters) while bash 3.1.9 invokes the subcommand
"echo '\a" (the outer echo sees only one parameter).

The difference here is the POSIX parsing rules
(http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html).
  Section 2.3 token recognition states that in command substitution, "The
shell shall read sufficient input to determine the end of the unit to be
expanded (as explained in the cited sections). While processing the
characters, if instances of expansions or quoting are found nested within
the substitution, the shell shall recursively process them in the manner
specified for the construct that is found."  And in Section 2.6.3, inside
backticks, backslash is only a quoting character if it is followed by $,
`, or \.

In your example, there is a backslash followed by another backslash, so
the first \ is a quoting character per the rules of command substitution,
but it occurs inside single quotes, where it must be a literal character
per the rules of nested construct parsing.  I think that the strict
reading of POSIX is as follows - the first ` starts a command
substitution, which then recursively parses to the end of the construct.
During that search, backquote parsing does not recursively use single
quoting rules (although unquoted single quotes must appear in matched
pairs, or the results are undefined), but does see that the first \ quotes
the second (and not the second quoting a newline).  All the characters
parsed form the final token, which is "`echo '\\[newline]a'", but which
the command substitution sees as "echo '\[newline]a'.  So I think you did
find a regression - bash 3.0 is correct in preserving the newline between
the quoted backslash and remaining characters, while bash 3.1 (through
patchlevel 9) is incorrect in performing newline joining.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD/cFO84KuGfSFAYARAqLBAJ0Q57l+VEzUMy+RTp50KNcX3QjboACfWfP7
eJ4R7BRNhXl5TJAjCyvnFvA=
=Crns
-END PGP SIGNATURE-


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Bash-3.1 Official patch 10

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Greg Schafer on 2/21/2006 8:20 PM:
> 
> status=`echo '-'| { ${GREP} -E -e 'a\' >/dev/null 2>&1 ; echo $?; }`

Even shorter - from the command line:

bash-3.1.9 $ echo `echo 'a\'`
a\

bash-3.1.10 $ echo `echo 'a\'`
># Oops, bash is still looking for input
> [Ctrl-c]
bash-3.1.10 $ echo `echo 'a\\'`   # Some hint as to what went wrong
a\


> 
> AFAICT, this used to be accepted by older Bash versions.
> 
> Do think problem lies with this Bash patch or with test case?

The bug is in official patch 10.  POSIX parsing rules
(http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html)
state in step 5 of 2.3 token recognition that on the first `, the shell
parses until the end of the command substitution, and in 2.6.3 command
substitution, that when parsing a command substitution the backslash
retains its literal meaning except when followed by $, `, or \.  In this
case, it is followed by ', so the nested command should be "echo 'a\'".

However, patch 10 only affected backticks:

bash-3.1.10 $ echo $(echo 'a\')
a\

So as a workaround, the test can be rewritten:

status=$(echo '-'| { ${GREP} -E -e 'a\' >/dev/null 2>&1 ; echo $?; })

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD/bVV84KuGfSFAYARAiEbAKCeC83Ke7kXKa61wgYt4JUn6hYSEwCdF9iu
wck5gmcvRR8d6u285MLP6To=
=GK+O
-END PGP SIGNATURE-


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: command history

[Chris F.A. Johnson]

On Fri, 17 Feb 2006, [EMAIL PROTECTED] wrote:


hi everybody

this is my first post, and i'm not sure whether it even belongs here...

is it the shell which handles the command history? if so, here my
feature request: it would be very convenient, to be able and narrow down
the search in the command history by typing a few characters, instead of
having to scroll through the whole thing.

or is it already there, without me knowing how to switch it on?


  There are (at least) two methods of narrowing the history search.
  One is on by default: incremental search with Ctrl-R.

  The other, history-search-backward, is not bound to any key. Type
  one or more characters and bash searches for commands beginning
  with the letters you have already typed.

  I use this in my ~/.inputrc file:

"\e[a": history-search-backward  ## shift+up-arrow
"\e[b": history-search-forward   ## shift+down-arrow

  You may need to adjust the bindings for your terminal.

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


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash