Function/alias recursion
What is the intended behaviour for this sort of thing?:
$ cat <<"EOF" >trouble
hello ()
{
pwd
}
alias pwd="hello"
EOF
$ source trouble
$ source trouble
$ pwd
The behaviour I've observed with bash-3.2 and several earlier releases
is that bash consumes all available memory and then crashes.
Tim.
*/
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: Function/alias recursion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Tim Waugh on 1/16/2007 5:45 AM:
> What is the intended behaviour for this sort of thing?:
Infinite recursion, within the limits of your stack.
>
> $ cat <<"EOF" >trouble
> hello ()
> {
> pwd
> }
> alias pwd="hello"
> EOF
> The behaviour I've observed with bash-3.2 and several earlier releases
> is that bash consumes all available memory and then crashes.
And why not? It's the same as doing this in C:
int foo()
{
return foo();
}
Bash can't protect you from yourself (or put differently, the halting
problem is undecidable).
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFrNRQ84KuGfSFAYARAsIxAJ9isSE1++l/vXvEzM0WBN0AbvkU2wCfWuPP
k7aE8j9sBQWzNZsqhD9mfRc=
=6ioK
-END PGP SIGNATURE-
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Unexpected behavior observed when using [EMAIL PROTECTED]/pattern/string} construct
> > Note that the goal in the examples below is to prepend "-iname '" (portion > > within double quotes only) to each of the 2 elements in the original array, > > without changing the number of words. i.e., the new array should contain the > > following 2 words: > > -iname 'abc > > -iname 'def Thanks for your careful analysis and detailed description of the problem. With that information, I have been able to fix the bugs reported in your message. In the meantime, you can use eval a2="[EMAIL PROTECTED]/#/"-iname '"}" to get the behavior you want. I apologize for the delay; the demands on my time are such that I do not generally respond to bug reports until I have had a chance to investigate them. [...] > The posix section on "double-quotes" requires that both single and double > quotes be balanced within the rhs of the parameter construct. This at least > implies that something akin to single and double quoted strings are permitted > within the parameter replacement. However, both the examples I have tried and > inspection of param_brace_expand_rhs indicate that if the entire parameter is > within double quotes, nested quotes don't really begin a nested string. The > rhs is parsed as a double quoted string in which unquoted double quotes are > simply discarded, and single quotes are retained literally. The only reason I > can see for using double quotes within the replacement is to allow an > unbalanced single quote to appear in the rhs. Single quotes themselves are not > treated specially at all. This begs the question: If single quotes are not > special within the rhs of a double quoted parameter construct, why are they > required to be balanced? Perhaps it is to allow the same rule to be applied to > the case of double-quoted and non-double-quoted parameter constructs? It's much simpler (and more complicated) than that. The Posix rule is intended to allow the historical Bourne shell double-quoted string parsing, which, to a great extent, is maintained in the Korn shell. The Bourne shell has a single quoting context, regardless of whether or not it's parsing a parameter expansion within braces. A double quote within the braces terminates a double-quoted string begun outside the braces. Bash, on the other hand, begins a new quoting context inside braces. Single- and double-quoted strings are recursively parsed according to the appropriate rules. However, there is a catch: we have to deal with the sh parsing artifact. That is the reason for the `stripdq' argument to string_extract_double_quoted and the immediate call to that function in parameter_brace_expand_rhs. It took a long time and lot of experimenting to get that "right enough". Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bugs pertaining to pathname expansion and field splitting (when IFS is null), caused by use of literal space to separate words generated by "dollar at" expansions
Stahlman Family wrote: > > I believe that multiple issues may be caused by the implementation's use > of a > literal space character to separate words created by various forms of > "dollar > at" expansions. My previous email describes two such issues in detail, but > there may well be others. The two issues I noticed may be summarized as > follows: You are correct that there are issues, but using your detailed description and examples, I have fixed the problems. Thanks for your report. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Function/alias recursion
Tim Waugh wrote: > What is the intended behaviour for this sort of thing?: Bash does not attempt to trap infinite recursion, so whatever your system does with it is what will happen. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[Fwd: [Fwd: Extrange behavior]]
Hi all!
I've done a simple patch for this unexpected behavior.
I don't know if the previous message has arribed to the list because I
wasn't subcribed.
I hope this will be useful :)
--
..
__
/ / Jordi Prats Català
C E / S / C A Departament de Sistemes
/_/Centre de Supercomputació de Catalunya
Gran Capità, 2-4 (Edifici Nexus) · 08034 Barcelona
T. 93 205 6464 · F. 93 205 6979 · [EMAIL PROTECTED]
..
pgp:0x5D0D1321
..
diff -Naur old/builtins/cd.def new/builtins/cd.def
--- old/builtins/cd.def 2006-07-28 03:35:36.0 +0200
+++ new/builtins/cd.def 2007-01-16 22:33:10.0 +0100
@@ -418,7 +418,12 @@
(nolinks != 0). */
tdir = nolinks ? sh_physpath (t, 0)
: sh_canonpath (t, PATH_CHECKDOTDOT|PATH_CHECKEXISTS);
-
+
+ if ((strlen(tdir)==2)&&(*tdir=='/')&&(*(tdir+1)=='/'))
+{
+ *(tdir+1)=(char)0;
+}
+
ndlen = strlen (newdir);
dlen = strlen (t);
--- Begin Message ---
Sorry, I didn't include the configuration information:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-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. -I./include -I./lib -march=k8 -pipe -O2
uname output: Linux a64 2.6.13-gentoo-r5 #2 Wed Feb 8 14:02:44 CET 2006
x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 3.0
Patch Level: 16
Release Status: release
This is one bash, do you need all of them?
--
..
__
/ / Jordi Prats Català
C E / S / C A Departament de Sistemes
/_/Centre de Supercomputació de Catalunya
Gran Capità, 2-4 (Edifici Nexus) · 08034 Barcelona
T. 93 205 6464 · F. 93 205 6979 · [EMAIL PROTECTED]
..
pgp:0x5D0D1321
..
--- Begin Message ---
Hi all,
I found a extrange behavior on bash in several machines:
[EMAIL PROTECTED] ~ $
[EMAIL PROTECTED] ~ $ cd //
[EMAIL PROTECTED] // $ pwd
//
[EMAIL PROTECTED] // $ echo $PWD
//
[EMAIL PROTECTED] // $ /bin/pwd
/
[EMAIL PROTECTED] // $ bash --version
GNU bash, version 3.00.16(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
This also happens on a 3.00.15, 3.1.14, 2.05b.0 on Linux and on 2.05b.0
on MacOSX.
I supose pwd it's a builtin command (as it's cd), so it just prints
$PWD. Is this a bug or a feature? I just found this because of a
misstyping, I'm asking this just for curiosity.
Thank you!
--
..
__
/ / Jordi Prats Català
C E / S / C A Systems Department
/_/Centre de Supercomputació de Catalunya
Gran Capità, 2-4 (Edifici Nexus) · 08034 Barcelona
T. 93 205 6464 · F. 93 205 6979 · [EMAIL PROTECTED]
..
pgp:0x5D0D1321
..
--- End Message ---
--- End Message ---
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Fwd: [Fwd: Extrange behavior]]
> I've done a simple patch for this unexpected behavior. > > I don't know if the previous message has arribed to the list because I > wasn't subcribed. > > I hope this will be useful :) Please read the Bash FAQ, question E10. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Fwd: [Fwd: Extrange behavior]]
Oops! Sorry... I didn't know about this... I found it extrange because csh ,ksh and tcsh don't do this. Sorry for the inconveniences... Chet Ramey wrote: >> I've done a simple patch for this unexpected behavior. >> >> I don't know if the previous message has arribed to the list because I >> wasn't subcribed. >> >> I hope this will be useful :) > > Please read the Bash FAQ, question E10. > > Chet > -- .. __ / / Jordi Prats Català C E / S / C A Departament de Sistemes /_/Centre de Supercomputació de Catalunya Gran Capità, 2-4 (Edifici Nexus) · 08034 Barcelona T. 93 205 6464 · F. 93 205 6979 · [EMAIL PROTECTED] .. pgp:0x5D0D1321 .. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
