> > 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 message
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. Trying to find
>> minimal set of conditions it cam
> > 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
> > < ./redi
> > 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 run-exec
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 sure what is going on, but t
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 it cannot read from the tty.
> > 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
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
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 t
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
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 Bel
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
> @@ -150
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 R
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
>
>
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 thi
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 thi
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
17 matches
Mail list logo
