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