Re: Possible bug Bash v5.22.6/5.1.16

On 2/17/24 6:40 AM, John Larew wrote: This is a portion of a script that appears to be problematic. Each of these attempts appear to be valid; none of them work. The issue is apparent with bash in both termux v0.118.0/5.22.6 and Ubuntu v22.04.3 LTS/5.1.16  (see attached). The clue is in the

Re: A possible bug?

On 12/27/23 4:33 PM, George R Goffe wrote: Chet, Thanks for your response. Is this clone NOT a dev branch? I'm thinking you're saying that it is not. It is not. The default (master) branch is for releases. My objective in using the clone is to get as close to a "release" as possible... a

Re: A possible bug?

Chet, Thanks for your response. Is this clone NOT a dev branch? I'm thinking you're saying that it is not. My objective in using the clone is to get as close to a "release" as possible... a beta branch(?) for daily use to identify possible bugs (experimental GCC, bash itself, other software

Re: A possible bug?

On 12/26/23 1:06 PM, George R Goffe wrote: Hi, I'm building bash with the bash at " git clone https://git.savannah.gnu.org/git/bash.git; and am seeing the following messages: make depend bash ./support/mkdep -c gcc --  -DPROGRAM='"bash"' The make depend support is only intended for the

Re: A possible bug?

On Tue, 26 Dec 2023, at 6:06 PM, George R Goffe wrote: > Hi, > > I'm building bash with the bash at " git clone > https://git.savannah.gnu.org/git/bash.git; and am seeing the following > messages: > > make depend > bash ./support/mkdep -c gcc --  -DPROGRAM='"bash"' > -DCONF_HOSTTYPE='"x86_64"'

A possible bug?

Hi, I'm building bash with the bash at " git clone https://git.savannah.gnu.org/git/bash.git; and am seeing the following messages: make depend bash ./support/mkdep -c gcc --  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"' -DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-pc-linux-gnu"'

Re: Possible bug in bash

Greg Wooledge writes: > On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote: >> Reading your message, I believe that the rule can be stated as follows, >> and I'd thank you to check it: && and || have the same precedence, and >> they both "associate left". So for example >> x &&

Re: 回复: Possible bug in bash

On 1/17/23 2:21 AM, anonymous4feedb...@outlook.com wrote: I am sorry I made a mistake in the first email. Bash printed foo= bar=v and all other shells printed foo=v bar=. It turns out I am using --posix to enable alias in bash, and that’s what makes the difference. Thanks for the update; I

回复: Possible bug in bash

u.org> 抄送: chet.ra...@case.edu<mailto:chet.ra...@case.edu> 主题: Re: Possible bug in bash On 1/15/23 7:42 AM, anonymous4feedb...@outlook.com wrote: > For the follow script > alias al=' ' > alias foo=bar > al for foo in v > do echo foo=$foo bar=$bar > done > bash (version 5.1

Re: Possible bug in bash

On 1/15/23 7:42 AM, anonymous4feedb...@outlook.com wrote: For the follow script alias al=' ' alias foo=bar al for foo in v do echo foo=$foo bar=$bar done bash (version 5.1.16) prints foo=v bar=, while all other shells I tested (dash, ksh, zsh, and yash) all prints foo= bar=v. That's strange.

Re: Possible bug in bash

On 5/13/22 10:36 PM, Dale R. Worley wrote: Robert Elz writes: Note particularly that there is no operator precedence between && and || - they are the same (unlike in C for example) Reading your message, I believe that the rule can be stated as follows, and I'd thank you to check it: && and

Re: Possible bug in bash

Date:Fri, 13 May 2022 23:27:50 -0400 From:Greg Wooledge Message-ID: | Not really. What's the difference? | Let's say you have a bunch of commands strung together like this: | | a && b || c && d || e && f || g | | We start with the shell's command

Re: Possible bug in bash

Date:Fri, 13 May 2022 22:36:56 -0400 From:"Dale R. Worley" Message-ID: <87ilq8hmbb@hobgoblin.ariadne.com> | Reading your message, I believe that the rule can be stated as follows, | and I'd thank you to check it: OK | && and || have the same precedence,

Re: Possible bug in bash

On Fri, May 13, 2022 at 10:36:56PM -0400, Dale R. Worley wrote: > Reading your message, I believe that the rule can be stated as follows, > and I'd thank you to check it: && and || have the same precedence, and > they both "associate left". So for example > x && yy || zz > is equivalent (as

Re: Possible bug in bash

Robert Elz writes: > Note particularly that there is no operator precedence between > && and || - they are the same (unlike in C for example) Reading your message, I believe that the rule can be stated as follows, and I'd thank you to check it: && and || have the same precedence, and they both

Re: Possible bug in bash

> > Have a thorough look around at: > http://mywiki.wooledge.org/BashPitfalls > http://mywiki.wooledge.org/BashFAQ > http://mywiki.wooledge.org/BashGuide > > and you will find a lot of useful knowledge that is > explained with considerable effort by many people. Pity I didn't find this page

Re: Possible bug in bash

On Fri, 13 May 2022 at 18:18, flyingrhino wrote: > Before opening the bug I looked online for if-then-else vs [[ and no > proper information was available, definitely not to the extent you explain > here. Have a look here: http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3

Re: Possible bug in bash

Thanks Lawrence for the response. Between you and Robert I now have a clear understanding on this and I'll go back and fix the bug in my code which used this construct. Ken. On Fri, 13 May 2022 00:51:49 -0400 Lawrence Velázquez wrote: > On Thu, May 12, 2022, at 11:34 PM, flyingrhino wrote: >

Re: Possible bug in bash

Hi, Thank you very much for the detailed description of this scenario. Before opening the bug I looked online for if-then-else vs [[ and no proper information was available, definitely not to the extent you explain here. This is very useful and rare knowledge and the effort you took to explain

Re: Possible bug in bash

Not a bug. Do not use && || as if they were a replacement for if then else fi they aren't. In some simple cases it all works out OK, but not in general, as you discovered. If you mean if x; then y; else z; fi then write that, not x && y || z The way and-or lists work, is that the first

Re: Possible bug in bash

On Thu, May 12, 2022, at 11:34 PM, flyingrhino wrote: > Should the "else" condition after the: || run if the last command in > the: && section exits non zero? Yes. This behavior is not a bug; ''A && B || C'' is simply not equivalent to ''if A then B; else C; fi''.

Re: Possible bug with redirect.

On Tue, 2 Nov 2021 at 02:37, Rikke Rendtorff wrote: > > I'm very new to linux [...] > I went to the https://linuxmint.com community website and joined their IRC > chat to see if they had an explanation and they told me it may be a bug, > since they couldn't reproduce it for other commands. > >

Re: Possible bug with redirect.

On Mon, Nov 01, 2021 at 04:23:32PM +0100, Rikke Rendtorff wrote: > I'm very new to linux, so I apologize if I'm reporting a non-bug. > > I wanted to do this: date > `date +"%Y-%m-%d"`.txt to put the date into a > file called 2021-10-16.txt > > But I accidentally forgot the backticks, so it

Re: possible bug in Bash 5.0

On 12/25/19 5:41 PM, Xin Wu wrote: > Hi, > > I found the single-bracket [ ... ] and double-bracket [[ ... ]] behave > differently for string comparison in the follow simple Bash-script. > > # comma (,) is before two (2) in ASCII > a=,rst > b=2rst > if [ "$a" \> "$b" ]; then >   echo

Re: Possible bug in bash... or maybe UFU?

On 6/4/19 3:09 AM, George R Goffe wrote: > Hi, > I'm trying to build the latest bash from ftp.gnu.org and am having some > problems. Are these a bug or am I doing something wrong? This is what happens when the bash configure can't find a working termcap or curses library. What does the Makefile

Re: Possible bug in Bash Reference Manual - lists of commands

On Wed, May 22, 2019 at 02:38:29PM +0800, Ralph Jensen wrote: > The Bash Reference Manual, Edition 5 and earlier versions define lists of > commands as follows: > > "A list is a sequence of one or more pipelines separated by one of the > operators ..." (Bash Reference Manual 3.2.3). > >

Re: Possible Bug in command and type posix compliance

That sound like a good solution to me as having a program in your hash table that isn't executable isn't much of an advantage anyway and it's desirable to search the whole PATH again to find a command that is executable. I found where it's adding to the hash table in findcmd.c and I'll add some

Re: Possible Bug in command and type posix compliance

On 4/5/19 2:28 AM, Michael S wrote: > Hello, > > I believe I have found a bug when using the posix compliant bash. From this > page point 53 > https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html it > states that type and command should not return a binary that is non >

Re: A possible bug on autocompletion after setting FUNCNEST level

On Mon, Oct 08, 2018 at 02:06:39PM +0200, Valentin Bajrami wrote: > This is how I could reproduce this: > > f3d0r4:~/FOO# FUNCNEST=4 4 is ridiculously low. Set it higher.

Re: A possible bug on autocompletion after setting FUNCNEST level

On 10/8/18 8:06 AM, Valentin Bajrami wrote: > This is some kind of a follow up on "Segfault on recursive trap/kill" > reported by Mike Grewitz. > > After setting FUNCNEST and the listing a file or using 'vi filname[TAB]' a > bug is triggered. It's not a bug. FUNCNEST is working as designed. As

Re: A possible bug on autocompletion after setting FUNCNEST level

On Okt 08 2018, Valentin Bajrami wrote: > This is some kind of a follow up on "Segfault on recursive trap/kill" > reported by Mike Grewitz. > > After setting FUNCNEST and the listing a file or using 'vi filname[TAB]' a > bug is triggered. > > This is how I could reproduce this: > >

A possible bug on autocompletion after setting FUNCNEST level

This is some kind of a follow up on "Segfault on recursive trap/kill" reported by Mike Grewitz. After setting FUNCNEST and the listing a file or using 'vi filname[TAB]' a bug is triggered. This is how I could reproduce this: f3d0r4:~/FOO# FUNCNEST=4 f3d0r4:~/FOO# ls

Re: Possible Bug in Auto-Complete

On 8/6/16 8:53 PM, hungry.ra...@gmail.com wrote: > Running Fedora Core, tried 3 different versions of Bash. > > bash-4.3.42-3.fc23.x86_64 > bash-4.3.42-5.fc25.x86_64 > bash-4.3.43-1.fc25.x86_64 > > Created a directory with the C equivalent "test\n\t\\ this" > > typing > > cd test gives me a

Re: Possible Bug in Auto-Complete

On Sa, Aug 06 2016, hungry.ra...@gmail.com wrote: > Created a directory with the C equivalent "test\n\t\\ this" > > typing > > cd test gives me a list of a single file > > test ^I\ this > > but will not autocomplete. Worksforme. Make sure you are not using external completion scripts.

Re: Possible bug in getopts when required argument is not supplied

On Fri, November 13, 2015 12:56 pm, Greg Wooledge wrote: > On Fri, Nov 13, 2015 at 10:13:15AM -0600, Griff Miller II wrote: > >> % ./myscript -a -b b >> >> >> Note that in the last run, getopts does not detect that nothing was >> passed via -a, even though -a requires it. Instead, it thinks the

Re: Possible bug in getopts when required argument is not supplied

On Fri, Nov 13, 2015 at 10:13:15AM -0600, Griff Miller II wrote: > % ./myscript -a -b b > > Note that in the last run, getopts does not detect that nothing was passed > via -a, even though -a requires it. Instead, it thinks the next switch > (-b) is the value of -a. Perhaps this was a conscious

Re: Possible bug in getopts when required argument is not supplied

On Fri, Nov 13, 2015 at 10:13 AM, Griff Miller II wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: cygwin > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='cygwin'

Re: Possible bug in getopts when required argument is not supplied

On Fri, November 13, 2015 1:02 pm, Dennis Williamson wrote: > Your opts string needs to begin with a colon to enable silent error > reporting and you need to handle the colon in your case statement as the > condition where a required argument is missing. Hi, Dennis - thanks for replying. I get

Re: Possible bug in getopts when required argument is not supplied

On 11/13/15 11:13 AM, Griff Miller II wrote: > Note that in the last run, getopts does not detect that nothing was passed > via -a, even though -a requires it. Instead, it thinks the next switch > (-b) is the value of -a. Perhaps this was a conscious decision, so that > values starting with '-'

Re: Possible bug in 4.3.11: Nameconflict when when passing an array to a function

On Wed, Oct 28, 2015 at 11:35:42AM +0100, Oskar Maier wrote: > http://stackoverflow.com/questions/33371309/change-in-behaviour-of-declare-local-from-bash-4-2-to-4-3 Here is the text: == I've recently updated my system and got a new bash version. Since then I've

Re: Possible bug in 4.3.11: Nameconflict when when passing an array to a function

Dear Greg, thank you for the extensive reply, I've already learned something new. The code I've posted was just intended as a minimal working example without giving it to much thought, therefore please excuse the unquoted "arr[@]". Furthermore, the original source is a small collection of

Re: Possible bug in 'unset' builtin

[19:24] dualbus for every fix that Chet does, he introduces like 2 bugs. Nice way of keeping himself busy That points to the importance of having a good, comprehensive test suite. It's difficult to test the interaction between features otherwise. I apologize for my comment :-) I

Re: Possible bug in 'unset' builtin

On 5/1/15 2:26 PM, Dreamcat4 wrote: Hello. If you unset a function, then a variable argument (argv) specified after that function will not be unset. Thanks for the report. Yes, once you unset a function, it's as if you supplied the `-f' option. This came in as the result of a fix for the

Re: Possible bug when combining Bash's process substitution with HERE-document?

On Fri, Jun 20, 2014 at 12:00:02AM +0200, Tim Friske wrote: While searching for an alternative I came up with the following code which does not work when I have the shopt -os errexit command line at the top of my script: read -d '' -r foobar BARFOO bla bla BARFOO read returns failure

Re: Possible bug when combining Bash's process substitution with HERE-document?

On 6/19/14, 6:00 PM, Tim Friske wrote: When I try to explicitly return success in case read fails because of EOF the script indefinitely waits: read -d '' -r foobar || true BARFOO bla bla BARFOO You have constructed a command where `read' will wait forever for terminal input and `true'

Re: Possible bug when combining Bash's process substitution with HERE-document?

Hi, first I want to thank you for your help. While searching for an alternative I came up with the following code which does not work when I have the shopt -os errexit command line at the top of my script: read -d '' -r foobar BARFOO bla bla BARFOO When I try to explicitly return success in

Re: Possible bug when combining Bash's process substitution with HERE-document?

On Jun 19, 2014 5:00 PM, Tim Friske m...@timfriske.com wrote: Hi, first I want to thank you for your help. While searching for an alternative I came up with the following code which does not work when I have the shopt -os errexit command line at the top of my script: read -d '' -r foobar

Re: Possible bug when combining Bash's process substitution with HERE-document?

I've heard process substitutions considerably complicate parsing. zsh and ksh93 are the only others that have process substitutions that I know of, and zsh can't handle unbalanced parentheses in that situation either. $ zsh -c $'cat (cat EOF\n(test)(foo\nEOF\n)' zsh:4: parse error near `(cat

Re: Possible bug when combining Bash's process substitution with HERE-document?

On 6/17/14, 5:54 PM, Tim Friske wrote: Hi, see my question http://unix.stackexchange.com/questions/137506/how-to-combine-bashs-process-substitution-with-here-document for a description. Could the described behavior be a bug? Yes, since bash can parse the same construct without any

Re: Possible bug when combining Bash's process substitution with HERE-document?

On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey chet.ra...@case.edu wrote: Yes, since bash can parse the same construct without any problems if you use command substitution, it looks like a bug. I'll take a look. It brings to mind all those unbalanced paren case..esac bugs that affected every

Re: Possible bug when combining Bash's process substitution with HERE-document?

On 6/18/14, 4:27 PM, Dan Douglas wrote: On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey chet.ra...@case.edu wrote: Yes, since bash can parse the same construct without any problems if you use command substitution, it looks like a bug. I'll take a look. It brings to mind all those unbalanced

Re: Possible bug in kill builtin

On 10/1/13 7:04 AM, Job Noorman wrote: Hi all, I just noticed some strange behavior with the kill builtin and was wondering whether this is a bug or not. The following applies to using kill on stopped processes (I didn't test it on running processes). When using 'kill jobspec', the

RE: Possible bug with BASH V4: The $!

, April 11, 2013 2:03 PM To: Lenga, Yair [ICG-MKTS] Cc: 'chet.ra...@case.edu'; 'Dan Douglas'; 'bug-bash@gnu.org' Subject: Re: Possible bug with BASH V4: The $! On 4/11/13 12:15 PM, Lenga, Yair wrote: Dan, Chet: Many thanks for the info about BASHPID. I've checked BASHPID on RH6, and it looks

Re: Possible bug with BASH V4: The $!

On Thu, Apr 11, 2013 at 01:05:43PM +, Lenga, Yair wrote: Is it possible to add back the functionality to allow the child process to somehow retrieve it's OWN PID. You are looking for the BASHPID variable, which expands to the process ID of the current bash process (even in a subshell).

Re: Possible bug with BASH V4: The $!

On Thursday, April 11, 2013 01:05:43 PM Lenga, Yair wrote: With BASH 3.0, the backgrounded task could access the PID of the parent using $$, and the PID Of itself as $!. With BASH 4.0, the script fail, the $! is not available to the child process. Is it possible to add back the

Re: Possible bug with BASH V4: The $!

On 4/11/13 9:24 AM, Dan Douglas wrote: On Thursday, April 11, 2013 01:05:43 PM Lenga, Yair wrote: With BASH 3.0, the backgrounded task could access the PID of the parent using $$, and the PID Of itself as $!. With BASH 4.0, the script fail, the $! is not available to the child process. Is

RE: Possible bug with BASH V4: The $!

Ramey [mailto:chet.ra...@case.edu] Sent: Thursday, April 11, 2013 10:14 AM To: Lenga, Yair [ICG-MKTS] Cc: Dan Douglas; bug-bash@gnu.org; chet.ra...@case.edu Subject: Re: Possible bug with BASH V4: The $! On 4/11/13 9:24 AM, Dan Douglas wrote: On Thursday, April 11, 2013 01:05:43 PM Lenga, Yair

Re: Possible bug with BASH V4: The $!

On Thu, Apr 11, 2013 at 04:15:45PM +, Lenga, Yair wrote: + The man page list BASH_VERSION, etc., but no indication of BASHPID. It's probably a good idea to put a note next to '$!' about BASHPID. It is certainly in the man page: BASHPID Expands to the process ID of the

Re: Possible bug with BASH V4: The $!

On Thursday, April 11, 2013 04:15:45 PM Lenga, Yair wrote: ( echo $!) ( echo $!) According to POSIX, both calls should print (nothing). As the background command does not come from the current shell. With BASH4, The first call will print (nothing), second call will print the PID of

Re: Possible bug with BASH V4: The $!

On 4/11/13 12:15 PM, Lenga, Yair wrote: Dan, Chet: Many thanks for the info about BASHPID. I've checked BASHPID on RH6, and it looks OK. Few comments related to making the change visible, and POSIX compliance. + The 'set' command, does not print the BASHPID, this make it very hard to

Re: Possible bug: Race condition when calling external commands during trap handling

A trap is not a signal. It doesn't come in. A trap handler is executed because some condition is true at a command boundary. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.

Re: Possible bug: Race condition when calling external commands during trap handling

Andreas Schwab wrote: A trap is not a signal. It doesn't come in. A trap handler is executed because some condition is true at a command boundary. Andreas. That still begs the question... If you are in your trap handler, and you don't reset the signal -- how can you guarantee that your

Re: Possible bug: Race condition when calling external commands during trap handling

On Tue, May 22, 2012 at 04:47:01AM -0700, Linda Walsh wrote: If you are in your trap handler, and you don't reset the signal -- how can you guarantee that your signal handler will be reset before another even that would cause a trap occurs You are using the wrong words for everything. A

Re: Possible bug: Race condition when calling external commands during trap handling

On 05/22/2012 02:28 PM, Greg Wooledge wrote: I do not know the answers to How does bash implement traps? Is there a guarantee that no signals will be lost? Hopefully someone else does. I can just imagine a situation when the bash is reading trap from the source (is going through the script

Re: Possible bug: Race condition when calling external commands during trap handling

On 5/22/12 8:41 AM, Roman Rakus wrote: Another situation: You had previous trap handler and you are installing new one. The received signals are paused for a while and are processed right after the installation of new trap handler. There was a bug report against this, I'm not sure if it is

Re: Possible bug: Race condition when calling external commands during trap handling

On 05/22/2012 03:01 PM, Chet Ramey wrote: On 5/22/12 8:41 AM, Roman Rakus wrote: Another situation: You had previous trap handler and you are installing new one. The received signals are paused for a while and are processed right after the installation of new trap handler. There was a bug

Re: Possible bug: Race condition when calling external commands during trap handling

On 5/22/12 9:16 AM, Roman Rakus wrote: On 05/22/2012 03:01 PM, Chet Ramey wrote: On 5/22/12 8:41 AM, Roman Rakus wrote: Another situation: You had previous trap handler and you are installing new one. The received signals are paused for a while and are processed right after the installation

Re: Possible bug: Race condition when calling external commands during trap handling

Andreas Schwab wrote: Bob Proulx b...@proulx.com writes: And lastly I will comment that you are doing quite a bit inside of an interrupt routine. Typically in a C program it is not safe to perform any operation that may call malloc() within an interupt service routine since malloc isn't

Re: Possible bug: Race condition when calling external commands during trap handling

tillmann.crue...@telekom.de wrote: I have produced the following script as a small example: A good small example! I do not understand the problem but I do have a question about one of the lines in it and a comment about another. trap kill $?; exit 0 INT TERM What did you intend with kill $?;

Re: Possible bug: Race condition when calling external commands during trap handling

Bob Proulx b...@proulx.com writes: And lastly I will comment that you are doing quite a bit inside of an interrupt routine. Typically in a C program it is not safe to perform any operation that may call malloc() within an interupt service routine since malloc isn't reentrant. Bash is a C

A possible bug with 4.2 (latest)

Howdy, I am experiencing a problem with sourcing a file. It's really my bashrc but I want to keep the corporate version separate. What I'm seeing: 1) make a change to .grgrc 2) enter . .grgrc 3) usually use the changed code. This change is not appearing. My .grgrc is almost 3000 lines of

Re: A possible bug with 4.2 (latest)

On 3/29/11 2:09 PM, George Goffe wrote: Howdy, I am experiencing a problem with sourcing a file. It's really my bashrc but I want to keep the corporate version separate. What I'm seeing: 1) make a change to .grgrc 2) enter . .grgrc 3) usually use the changed code. This change is

Re: A possible bug with 4.2 (latest)

Chet, I'll do that right now. Thanks for the QUICK response. George... On Tue, Mar 29, 2011 at 11:19 AM, Chet Ramey chet.ra...@case.edu wrote: On 3/29/11 2:09 PM, George Goffe wrote: Howdy, I am experiencing a problem with sourcing a file. It's really my bashrc but I want to keep

Re: A possible bug during build.

On 10/1/10 2:52 PM, George R Goffe wrote: Howdy, I have a script that I use to build bash and other open source software. When I unzip/tar the bash distribution file and run the script in the directory that pops out, bash builds correctly (no make install yet). When I run the script with

A possible bug during build.

Howdy, I have a script that I use to build bash and other open source software. When I unzip/tar the bash distribution file and run the script in the directory that pops out, bash builds correctly (no make install yet). When I run the script with NO changes, the build fails. Below is the tail

Re: Possible Bug in BASH

Matthew Strax-Haber strax-habe...@neu.edu writes: Perhaps it is not a bug, but if it is not then the documentation is inconsistent with the behavior. There is no inconsistency. In the first example you define a function with the name `clear', in the second example you define a function with

Re: Possible Bug in BASH

On 2/25/10 2:05 AM, Matthew Strax-Haber wrote: Below is a simple demonstration of the unexpected behavior: SHELL 1: mattsh$ alias c=clear mattsh$ c () { echo foo; } mattsh$ clear foo Here c is the first word. So it is replaced by the alias. (I didn't know this behavior before. This

Re: possible bug on readline

On Jan 17, 11:40 pm, Samus_ mail2sa...@gmail.com wrote: to reproduce simply try to glob-expand the following code: $( * You can reproduce that without the asterisk. I doubt that that's a bug in readline. The errors you're getting are from tab-completion which is done in a script. It's not

Re: possible bug on readline

On 1/18/10 12:40 AM, Samus_ wrote: hello, I had this on my shell: fgrep $(nl_join templates/ advertiser/campaign* and when tried to perform readline's glob-expand- word I got some parse errors, I'm not sure if it is a bug or the expected behaviour because the line isn't functional code

Re: possible bug on readline

On Jan 18, 11:01 am, Chet Ramey chet.ra...@case.edu wrote: On 1/18/10 12:40 AM, Samus_ wrote: hello,  I had this on my shell: fgrep $(nl_join templates/ advertiser/campaign* and when tried to perform readline's glob-expand- word I got some parse errors, I'm not sure if it is a bug or the

Re: possible bug with $@ and and non-standard IFS

If you use nd=${dh}$* before resetting IFS, you'll get the output you in bash-3.0 through bash-4.0. But I don't in Bourne shell, I get smith0.0. So neither construct works in a portable manner. :( JR

Re: possible bug with $@ and and non-standard IFS

Apparently, I have run into an area of some controversy (or at least some disagreement) On my Solaris 10 box, ksh thinks that the expected output should be smith::0.0 sh - smith:0.0 (an old version of bash) - smith: 0.0 dtksh- smith: 0.0 I don't think this will get solved anytime soon. :)

Re: fc command substitution behavior, possible bug

smallnow wrote: $ echo $BASH_VERSION 3.2.48(1)-release $ echo $(fc -nl -1) echo $BASH_VERSION $ echo $BASH_VERSION 4.0.10(2)-release $ echo $(fc -nl -1) echo $(fc -nl -1) I see there were a lot of changes to fc, is this intended or a bug? The off-by-one errors that occurred when

fc command substitution behavior, possible bug

$ echo $BASH_VERSION 3.2.48(1)-release $ echo $(fc -nl -1) echo $BASH_VERSION $ echo $BASH_VERSION 4.0.10(2)-release $ echo $(fc -nl -1) echo $(fc -nl -1) I see there were a lot of changes to fc, is this intended or a bug? It seems there is another way to get the last history entry that works

Re: Possible bug with respect to global variable within block of code when piping the output of later

Thiemo Kellner [EMAIL PROTECTED] wrote: Maybe the piping converts the block implicitly to a subshell. Yes, it does. This is documented in the man page, under Pipelines in the SHELL GRAMMAR section, and in the FAQ, entry E4. paul