On 12/12/2012 10:25 PM, Chet Ramey wrote:
That is, mind a bash-newbie question as to what this "bash+" is?
And specifically, is this nameref implementation that you speak of
something that's in the pipeline for "regular bash"?
It's the development branch of bash in the savannah git tree:
http
On 12/11/12 2:49 PM, Greg Wooledge wrote:
> So, I'd just call it a documentation flaw. Most likely "coproc" is
> indicating whether it successfully created the coprocess (bg job), and
> you'll have to use "wait" to fetch its exit status once it becomes
> available.
More like an omission. The cu
On 12/12/12 2:47 PM, Rene Herman wrote:
> That is, mind a bash-newbie question as to what this "bash+" is? And
> specifically, is this nameref implementation that you speak of something
> that's in the pipeline for "regular bash"?
It's the development branch of bash in the savannah git tree:
ht
On 12/12/12 12:58 PM, Raphaël Droz wrote:
> Using the devel/ branch, with default options (simple ./configure), I
> found that *sourcing* such a script would cause bash to hang using 100%
> CPU. This does not happen using 4.2_p39.
>
>> #!/bin/bash
>> shopt -s extglob
>> glob='@(|))'
>> for i in /t
On 12/12/2012 07:04 PM, Dan Douglas wrote:
While the current nameref implementation is tremendously valuable in
writing functions that manipulate non-local arrays, it does very
little else that couldn't already be done with Bash's indirect
parameter expansion, or to solve the encapsulation probl
Hello. Could we possibly modify or create an additional variant of "typeset -n"
which produces "real" references rather than just dynamic references by name?
In other words, I'd like to be able to create reference variables that always
point to the instance of a variable that was visible at the tim
Using the devel/ branch, with default options (simple ./configure), I
found that *sourcing* such a script would cause bash to hang using 100%
CPU. This does not happen using 4.2_p39.
> #!/bin/bash
> shopt -s extglob
> glob='@(|))'
> for i in /tmp/!($glob); do echo $i; done
[ bash-completion initi
On Wed, Dec 12, 2012 at 09:40:29AM -0500, Chet Ramey wrote:
> On 12/12/12 8:56 AM, Raphaël Droz wrote:
> > Hi,
> >
> > using the devel/ branch, linking fails with:
> >> bashline.o: In function `attempt_shell_completion':
> >> bashline.c:1406: undefined reference to `parser_in_command_position'
> >
On 12/12/12 10:57 AM, Steven W. Orr wrote:
>>
>
> Hold on! A make clean should delete all derived files. y.tab.[ch] are
> derived and should be present in a clean sandbox.
>
> Am I missing something?
We're overthinking this. The y.tab.[ch] in the git tree now were
inadvertently left over from
On 12/12/2012 08:57 AM, Steven W. Orr wrote:
>>
>
> Hold on! A make clean should delete all derived files. y.tab.[ch] are
> derived and should be present in a clean sandbox.
Rather, 'make clean' should delete all derived files not present in a
tarball, and 'make maintainer-clean' should delete A
On 12/12/2012 9:40 AM, Chet Ramey wrote:
On 12/12/12 8:56 AM, Raphaël Droz wrote:
Hi,
using the devel/ branch, linking fails with:
bashline.o: In function `attempt_shell_completion':
bashline.c:1406: undefined reference to `parser_in_command_position'
collect2: ld returned 1 exit status
I se
Chet Ramey writes:
> It's a choice between those two alternatives, not removing y.tab.c and
> doing nothing.
It doesn't make any sense to check in an outdated y.tab.c.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"A
> Chet Ramey writes:
>
> > Maybe I will remove y.tab.[ch] from the devel tree, but that introduces a
> > dependency on bison.
>
> ??? Since y.tab.c isn't uptodate you have that anyway.
Correct. The alternative is changing the script that updates the git tree
to make sure there's an up-to-date
Chet Ramey writes:
> Maybe I will remove y.tab.[ch] from the devel tree, but that introduces a
> dependency on bison.
??? Since y.tab.c isn't uptodate you have that anyway.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4E
On 12/12/12 8:56 AM, Raphaël Droz wrote:
> Hi,
>
> using the devel/ branch, linking fails with:
>> bashline.o: In function `attempt_shell_completion':
>> bashline.c:1406: undefined reference to `parser_in_command_position'
>> collect2: ld returned 1 exit status
I see what happened. git (or the p
Hi,
using the devel/ branch, linking fails with:
> bashline.o: In function `attempt_shell_completion':
> bashline.c:1406: undefined reference to `parser_in_command_position'
> collect2: ld returned 1 exit status
I tried a bissection and c84e5202 was the last one to build fine.
But since f14388d
DJ Mills writes:
> 2)
> However, the exception to #1 is my second issue, with is that coproc
> always
> seems to fail when called within the test portion of an if statement. I
> have
> absolutely no idea why this happens.
>
> To reproduce:
> if ! coproc false; then echo error1 >&2; fi
17 matches
Mail list logo
