Re: Could bash do what make does?

Robert- I wanted to craft a witty retort with a veneer of encouragement that might push your towards trying your proposed endeavor. I could not bring myself to do it after realizing that you are quite serious. I understand your motivations. Build systems are often complicated, opaque pieces of

command substitution bug

GNU bash, version 4.3.46(1)-release (x86_64-unknown-linux-gnu) GCC: (GNU) 6.1.1 On archlinux 4.4.27-1-lts Hello, today i tried something simple but it leads to what seems to be a bug. $ var="$(for ((i=0;i<$#;i++));do echo line;done)" leads to: "unexpected EOF while looking for matching `)' I

command substition bug 2

GNU bash, version 4.3.46(1)-release (x86_64-unknown-linux-gnu) GCC: (GNU) 6.1.1 On archlinux 4.4.27-1-lts Hello, today i tried something simple but it leads to what seems to be a bug. $ var="$(for ((i=0;i<$#;i++));do echo line;done)" leads to: "unexpected EOF while looking for matching `)' I

Re: Testsuite problem when HOME is not defined

On 12/1/16 2:38 PM, Vladimir Marek wrote: > In spirit similar problem to the previous one, when the tests are > executed with $HOME undefined, I was getting this error: > > 26d25 > < ./comsub-posix.tests: line 103: cd: HOME not set > 28d26 > < ./comsub-posix.tests: line 106: cd: HOME not set > >

Re: Strange bash behavior

On 12/2/16 2:31 AM, Vladimir Marek wrote: > Still, this stops the bash: > > bash -c 'bash -i 1; read -t 2 a < /dev/tty' Yes, Clark found and fixed this problem. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet

Re: Strange bash behavior

On 12/2/16 1:20 AM, Clark Wang wrote: > Found the problem. The first "bash -i" changed the foreground pgrp to its > own pgrp at startup but did not restore the original foreground pgrp when > it exited. The following patch (not a real fix) works for me: > > --- a/shell.c > +++ b/shell.c > @@

Re: Could bash do what make does?

On Fri, Dec 02, 2016 at 10:53:30PM +1100, Robert Durkacz wrote: > really I am asking why should not program builds have been scripted with > bash all along For starters, make is *older* than bash, by over a decade. https://en.wikipedia.org/wiki/Make_%28software%29 says that make originated at

Re: Could bash do what make does?

On 29/11/16 Charles Daffern replied to my question about bash and make as if I was proposing that bash might beneficially reimplement make, but really I am asking why should not program builds have been scripted with bash all along and make never invented. So if Charles or someone else could point

Re: Could bash do what make does?

I agree that is the first step to take, but I am supposing that, since build systems are a big business, some extensions to bash would be worth doing to take on that market. E.g. I think we would need a concept of lists of files so as to skip executing a command if all files in the list are older

Re: bash tests failing when compiled with --enable-xpg-echo-default=yes

And second patch we use because of xpg-echo. Would it have sense to have it included, or maybe stop the tests completely instead? Thank you -- Vlad On Thu, Dec 01, 2016 at 10:44:02PM +, Vladimir Marek wrote: > Hi, > > On Solaris bash is compiled with --enable-xpg-echo-default=yes

Re: Strange bash behavior

> > Nice analysis, does the second example look similar? > > > > bash -c 'bash -i 1; read -t 2 a < /dev/tty' > > > > I think it's the same problem. After "bash -i" exited, "bash -c" is not the > controlling process any more so it cannot read from the tty. Ah, I see. Thanks! -- Vlad

Re: Strange bash behavior

On Fri, Dec 2, 2016 at 6:34 PM, Vladimir Marek wrote: > Nice analysis, does the second example look similar? > > bash -c 'bash -i 1; read -t 2 a < /dev/tty' > I think it's the same problem. After "bash -i" exited, "bash -c" is not the controlling process any more so

Re: Strange bash behavior

Nice analysis, does the second example look similar? bash -c 'bash -i 1; read -t 2 a < /dev/tty' Thanks! -- Vlad On Fri, Dec 02, 2016 at 12:59:37PM +0800, Clark Wang wrote: > On Fri, Dec 2, 2016 at 6:28 AM, Vladimir Marek > wrote: > > > Hi, > > > > I'm not

Re: Strange bash behavior

> > I'm not sure what is going on, but the bash test suite was getting > > stopped (as if SIGSTOP was received) in the middle. Trying to find > > minimal set of conditions it came to this: > > > > - my ~/.bashrc has to contain 'cd /' (any dir works) > > - the tests have to first execute

Re: problem with redir test

> > during testing of latest bash on Solaris I found strange behavior. We > > run the tests with clear environment (env -). It seems to be caused by > > undefined SHELL variable. The test reported > > > > 150,151c150,151 > > < ./redir11.sub: line 26: echo: write error: Bad file number > > <

Re: Strange bash behavior

On Fri, Dec 2, 2016 at 12:59 PM, Clark Wang wrote: > On Fri, Dec 2, 2016 at 6:28 AM, Vladimir Marek > wrote: > >> Hi, >> >> I'm not sure what is going on, but the bash test suite was getting >> stopped (as if SIGSTOP was received) in the middle.

Re: Various improvements to tests/run-all

> > I am attaching patch against tests/run-all with the hope that the > > changes can be accepted upstream. The patch should be self explanatory. > > For completeness here are the errors I saw before I erased SHELLOPTS > > variable > > I can see doing this. From the error messages in your