Re: Several issues with coprocesses regarding exit status
DJ Mills danielmil...@gmail.com 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; wait $COPROC_PID || echo error2 2 This has nothing to do with if but with ! which doesn't appear to work in this context. 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.
devel branch build failure
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 (bash-20120914 snapshot), the build fails with the above error. Some of the later revisions also add the failure below: ./builtins/libbuiltins.a(help.o): In function `wdispcolumn': builtins/./help.def:409: undefined reference to `wcsnwidth' builtins/./help.def:449: undefined reference to `wcsnwidth' collect2: ld returned 1 exit statu is this expected ? is there something special about building this branch ? thanks
Re: devel branch build failure
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 process used to create the devel tree) makes the mod time of all files in the tree the same, so y.tab.c doesn't get rebuilt from parse.y. You can fix this with rm y.tab.? make Maybe I will remove y.tab.[ch] from the devel tree, but that introduces a dependency on bison. But since f14388d (bash-20120914 snapshot), the build fails with the above error. Some of the later revisions also add the failure below: ./builtins/libbuiltins.a(help.o): In function `wdispcolumn': builtins/./help.def:409: undefined reference to `wcsnwidth' builtins/./help.def:449: undefined reference to `wcsnwidth' collect2: ld returned 1 exit statu I don't see this. wcsnwidth.c is present in the tree and (seemingly) correctly specified in the Makefiles. The definitions and uses all depend on HANDLE_MULTIBYTE. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: devel branch build failure
Chet Ramey chet.ra...@case.edu 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 4ED5 And now for something completely different.
Re: devel branch build failure
Chet Ramey chet.ra...@case.edu 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 version of y.tab.c present for each commit. It's a choice between those two alternatives, not removing y.tab.c and doing nothing. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: devel branch build failure
Chet Ramey chet.ra...@case.edu 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 And now for something completely different.
Re: devel branch build failure
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 see what happened. git (or the process used to create the devel tree) makes the mod time of all files in the tree the same, so y.tab.c doesn't get rebuilt from parse.y. You can fix this with rm y.tab.? make Maybe I will remove y.tab.[ch] from the devel tree, but that introduces a dependency on bison. But since f14388d (bash-20120914 snapshot), the build fails with the above error. Some of the later revisions also add the failure below: ./builtins/libbuiltins.a(help.o): In function `wdispcolumn': builtins/./help.def:409: undefined reference to `wcsnwidth' builtins/./help.def:449: undefined reference to `wcsnwidth' collect2: ld returned 1 exit statu I don't see this. wcsnwidth.c is present in the tree and (seemingly) correctly specified in the Makefiles. The definitions and uses all depend on HANDLE_MULTIBYTE. Chet 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?
Re: devel branch build failure
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 ALL derived files that can be rebuilt but where the rebuild may require tools that aren't required for the normal user building from a tarball. Building from git is different than building from a tarball, and I argue that there are derived files (such as y.tab.[ch]) that must exist in the tarball but can be safe to omit from git, if we are willing to assume that developers building from git can be assumed to have the maintainer tools. Treating git like building from a tarball is not necessarily worth the headache. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: devel branch build failure
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 a past commit. Those files don't exist in the development snapshots I create and use to make the devel tree. Ordinarily it wouldn't matter -- their timestamps would be much older than parse.y and the usual rebuild would occur. However, the git quirk I just noticed that makes all files have a modification date equal to the time of the last checkout defeats this. People using the devel tree can be reasonably expected to have bison installed, so I will just remove the (stale) files and go on. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: devel branch build failure
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' collect2: ld returned 1 exit status I see what happened. git (or the process used to create the devel tree) makes the mod time of all files in the tree the same, so y.tab.c doesn't get rebuilt from parse.y. You can fix this with rm y.tab.? make thanks !
devel/ hangs in globbing
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 initialisation uses this kind of construct ] regards
Requesting an alternate nameref feature
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 time the reference
was created, similar to the way ksh93's nameref works.
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 problem.
$ bash+ -c 'function f { typeset -n y=$1; typeset x=bar; echo $y; }; x=foo;
f x'
bar
$ mksh -c 'function f { typeset -n y=$1; typeset x=bar; echo $y; }; x=foo; f
x'
bar
$ ksh -c 'function f { typeset -n y=$1; typeset x=bar; echo $y; }; x=foo; f
x'
foo
I can't think of a reason this couldn't coexist with dynamic scope in
principle, with some modification. For instance, Bash won't require a check
that forces variable names to be passed through the positional parameters as in
ksh.
This feature would have similarities to declare -g in its ability to
tunnel around overloaded variable names in outer scopes, except would allow
both reading and writing to any scope from any deeper scope (provided the
reference itself hasn't been covered up). This would be extremely useful for
shell libraries.
--
Dan Douglas
Re: Requesting an alternate nameref feature
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 problem. Oh, you tease ... 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? Because, yes, when investigating a recent question of mine as to the status of multi-dimensional arrays, I ran into the fact that indirect parameter expansion would solve most of my needs -- if only it would behave with arrays. typeset -n doesn't exist for my bash-4.2.39... Kind regards, Rene
Re: devel/ hangs in globbing
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 /tmp/!($glob); do echo $i; done Thanks for the report. Luckily it was a quick and easy fix. It will be in the next development snapshot. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Requesting an alternate nameref feature
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: http://git.savannah.gnu.org/cgit/bash.git/?h=devel Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Several issues with coprocesses regarding exit status
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 current documentation doesn't say anything about what the `coproc' command returns. It only talks about what the coprocess -- the asynchronous command -- returns. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Requesting an alternate nameref feature
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://git.savannah.gnu.org/cgit/bash.git/?h=devel Thanks for the reply. I am going to sit tight then until I can try them out using a release and will report back as to whether or not I still think I need multi-dimensional arrays at that time. (unless you'd like me to test them now of course, but I gather they're coming down the pipe anyway...) Rene.
