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
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
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
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
> 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:
> 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
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
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/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 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'
> >
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
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
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
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/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/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/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
17 matches
Mail list logo
