coproc not flushing all output?

2009-07-26 Thread clemens fischer
I have a script going through ELF files and finding which of them refer to non-existing shared libraries. After finding the files, it proceeds by checking which package they belong to, which is an expensive operation, so it is done in a "coproc" co-process. The main loop knows when all the files

Re: bash: echoing octal, disagreement between man page and behaviour

2009-07-26 Thread Chet Ramey
Giles Orr wrote: > Hi Chet, Bob. > > I see what the problem is, and yes, it appears to be documentation > rather than a "bug." My apologies. However, in the copy I have of > the man page (I run Debian testing, whatever is default with that and > possibly not up-to-date with the latest version of

Re: bash: echoing octal, disagreement between man page and behaviour

2009-07-26 Thread Giles Orr
Hi Chet, Bob. I see what the problem is, and yes, it appears to be documentation rather than a "bug." My apologies. However, in the copy I have of the man page (I run Debian testing, whatever is default with that and possibly not up-to-date with the latest version of Bash ... The octal thing is

Re: bash: echoing octal, disagreement between man page and behaviour

2009-07-26 Thread Bob Proulx
Chet Ramey wrote: > Giles Orr wrote: > > Not sure if this a bug or a documentation problem: it's certainly a > > change from previous behaviour, and a disagreement between current > > behaviour and the documentation. > > > > The man page says that: > > $ echo -e "\173" > > should produce a "{" b

Re: bash: echoing octal, disagreement between man page and behaviour

2009-07-26 Thread Chet Ramey
Giles Orr wrote: > Hello. > > Not sure if this a bug or a documentation problem: it's certainly a > change from previous behaviour, and a disagreement between current > behaviour and the documentation. > > The man page says that: > > $ echo -e "\173" > > should produce a "{" but instead it pr

Re: bash upgrade 3.2_048 -> 4.0_028 breaks the source command

2009-07-26 Thread Chet Ramey
Miklos Vajna wrote: > Bash Version: 4.0 > Patch Level: 28 > Release Status: release > > Description: > In the current directory create an empty file 'foo'. Then the > following will fail: > > $ sh -c 'ls foo;. foo' > foo > sh: line 0: .: foo: file not foun

bash: echoing octal, disagreement between man page and behaviour

2009-07-26 Thread Giles Orr
Hello. Not sure if this a bug or a documentation problem: it's certainly a change from previous behaviour, and a disagreement between current behaviour and the documentation. The man page says that: $ echo -e "\173" should produce a "{" but instead it produces a "\173". Since $ echo -e "\

Re: bash upgrade 3.2_048 -> 4.0_028 breaks the source command

2009-07-26 Thread Miklos Vajna
On Sun, Jul 26, 2009 at 07:25:50AM -0600, Eric Blake wrote: > > $ sh -c 'ls foo;. foo' > > foo > > sh: line 0: .: foo: file not found > > Not a bug. POSIX requires this. > http://lists.gnu.org/archive/html/bug-bash/2009-07/msg00069.html Ah, OK. Sorry for the noise and t

Re: bash upgrade 3.2_048 -> 4.0_028 breaks the source command

2009-07-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Miklos Vajna on 7/26/2009 4:50 AM: > Description: > In the current directory create an empty file 'foo'. Then the > following will fail: > > $ sh -c 'ls foo;. foo' > foo > sh: line 0: .: foo: file n

bash upgrade 3.2_048 -> 4.0_028 breaks the source command

2009-07-26 Thread Miklos Vajna
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-frugalware-linux-gnu' -DCONF_VENDOR='frugalware' -DLOCALEDIR='/usr/share/locale'