Re: Various improvements to tests/run-all

[Vladimir Marek]

> > 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, it seems
> like you enable posix mode via SHELLOPTS.  The tests definitely don't
> expect to be run in posix mode.

Makes sense.


> As for your other suggestions, bash-4.4 doesn't use /tmp/xx; that's a
> remnant from previous versions.  bash-4.4 sets, exports, and uses
> $BASH_TSTOUT.

That's my next goal - remove as many local patches as possible from our
bash build. And I'm happy that this is first one :)



> Also, sh is just used to run each test harness (e.g.,
> run-redir).  All of those scripts run the actual test scripts using
> $THIS_SH, so there's no real gain to using $THIS_SH there.

I _think_ that there was problem with running the actual 'run_*' scripts
using 'real' sh. But I don't see the problem now, so another local
change to loose I think.

Thank you
-- 
Vlad

Re: Strange bash behavior

[Clark Wang]

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 came to this:
>>
>>  - my ~/.bashrc has to contain 'cd /' (any dir works)
>>  - the tests have to first execute run-execscript, namely it has to
>>execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
>>  - the file exec8.sub is reported as not found (I presume because of the
>>'cd /' in .bashrc)
>>  - the tests then have to run read-test, exactly in read2.sub when
>>  'read -t 2 a < /dev/tty' was executed whole thing was stopped
>>
>> When I removed the 'cd' command from my ~/.bashrc, all worked fine.
>>
>> I then tried to make minimal reproducible case and came to this (this
>> time there is no 'cd /' in my ~/.bashrc needed):
>>
>> $ bash -c 'bash -i i; bash -i i'
>> bash -c 'bash -i i; bash -i i'
>> bash: i: No such file or directory
>>
>> [1]+  Stopped bash -c 'bash -i i; bash -i i'
>>
>
> I can reproduce this with bash 4.4.5 on Debian 8.5.
>
>   foo@deb64:~$ bash -c 'bash -i 1; bash -i 2'
>   bash: 1: No such file or directory
>
>   [1]+  Stopped bash -c 'bash -i 1; bash -i 2'
>   foo@deb64:~$ echo $?
>   149
>
> It was stopped by SIGTTIN. According to gdb backtrace it was killed by the
> second "bash -i".
>
>   4099   while ((terminal_pgrp = tcgetpgrp (shell_tty)) != -1)
>   4100 {
>   4101   if (shell_pgrp != terminal_pgrp)
>   4102 {
>   4103   SigHandler *ottin;
>   4104
>   4105   ottin = set_signal_handler (SIGTTIN, SIG_DFL);
>   4106   kill (0, SIGTTIN);
>   4107   set_signal_handler (SIGTTIN, ottin);
>   4108   continue;
>   4109 }
>   4110   break;
>   4111 }
>
> The problem is tcgetpgrp() still returns the pgrp of the first "bash -i"
> when the second "bash -i" is running. This can be shown with following
> example:
>
>   foo@deb64:~$ bash -c 'bash -i 1; sleep '
>   bash: 1: No such file or directory<-- CTRL-C does not work here
>
>   root@deb64:~# ps t pts/10 j
> PPIDPID   PGIDSID TTY   TPGID STAT   UID   TIME COMMAND
>96886  96887  96887  96887 pts/1097073 Ss1001   0:00 -bash
>96887  97072  97072  96887 pts/1097073 S 1001   0:00 bash -c
> bash -i 1; sleep 
>97072  97074  97072  96887 pts/1097073 S 1001   0:00 sleep 
>
> Here the TPGID 97073 must be the first "bash -i" which has already exited.
> Seems like for some reason the "bash -c" does not set the foreground pgrp
> to the second "bash -i".
>

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
@@ -1504,6 +1504,7 @@ open_shell_script (script_name)
 {
   e = errno;
   file_error (filename);
+  end_job_control ();
   sh_exit ((e == ENOENT) ? EX_NOTFOUND : EX_NOINPUT);
 }

Re: problem with redir test

[Vladimir Marek]

> > 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
> > < ./redir11.sub: line 27: echo: write error: Bad file number
> > ---
> >> ./redir11.sub: line 26: $(a=4 foo): Bad file number
> >> ./redir11.sub: line 27: $(a=4 foo): Bad file number
> 
> I can't reproduce this.  The key is that redir11.sub inherits file
> descriptor 3 as an fd open for read on /etc/passwd, and echo gets a
> write error when trying to write to it.  This might also be affected
> by SHELLOPTS setting posix mode, but I can't reproduce it even when
> setting SHELLOPTS=posix in the environment.
> 
> It's also hard to see why starting bash  without SHELL in the environment
> sould make such a difference, since bash sets SHELL to the current user's
> login shell, as found via getpwent.

Thank you for looking into this, I'll try to find out more.

-- 
Vlad

Re: Strange bash behavior

[Vladimir Marek]

> > 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-execscript, namely it has to
> >execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
> >  - the file exec8.sub is reported as not found (I presume because of the
> >'cd /' in .bashrc)
> 
> Yes, though the line that runs exec8.sub is actually in execscript, and
> exec6.sub doesn't matter at all.  Changing ./ to ${PWD}/ should fix it.

Probably, I thought that having 'cd' in ~/.bashrc is too exotic to make
the tests work with it. But yes, that is workaround.

Still, this stops the bash:

bash -c 'bash -i 1; read -t 2 a < /dev/tty'


> >  - the tests then have to run read-test, exactly in read2.sub when
> >  'read -t 2 a < /dev/tty' was executed whole thing was stopped
> 
> This is strange, since the presence or absence or a controlling terminal
> doesn't have anything to do with whether or not there's a cd in a startup
> script that's not run by a non-interactive shell (that is, since the read
> script isn't run by an interactive shell, your .bashrc isn't run).  Very
> strange.

Sorry :)
-- 
Vlad

Re: Strange bash behavior

[Vladimir Marek]

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 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-execscript, namely it has to
> >execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
> >  - the file exec8.sub is reported as not found (I presume because of the
> >'cd /' in .bashrc)
> >  - the tests then have to run read-test, exactly in read2.sub when
> >  'read -t 2 a < /dev/tty' was executed whole thing was stopped
> >
> > When I removed the 'cd' command from my ~/.bashrc, all worked fine.
> >
> > I then tried to make minimal reproducible case and came to this (this
> > time there is no 'cd /' in my ~/.bashrc needed):
> >
> > $ bash -c 'bash -i i; bash -i i'
> > bash -c 'bash -i i; bash -i i'
> > bash: i: No such file or directory
> >
> > [1]+  Stopped bash -c 'bash -i i; bash -i i'
> >
> 
> I can reproduce this with bash 4.4.5 on Debian 8.5.
> 
>   foo@deb64:~$ bash -c 'bash -i 1; bash -i 2'
>   bash: 1: No such file or directory
> 
>   [1]+  Stopped bash -c 'bash -i 1; bash -i 2'
>   foo@deb64:~$ echo $?
>   149
> 
> It was stopped by SIGTTIN. According to gdb backtrace it was killed by the
> second "bash -i".
> 
>   4099   while ((terminal_pgrp = tcgetpgrp (shell_tty)) != -1)
>   4100 {
>   4101   if (shell_pgrp != terminal_pgrp)
>   4102 {
>   4103   SigHandler *ottin;
>   4104
>   4105   ottin = set_signal_handler (SIGTTIN, SIG_DFL);
>   4106   kill (0, SIGTTIN);
>   4107   set_signal_handler (SIGTTIN, ottin);
>   4108   continue;
>   4109 }
>   4110   break;
>   4111 }
> 
> The problem is tcgetpgrp() still returns the pgrp of the first "bash -i"
> when the second "bash -i" is running. This can be shown with following
> example:
> 
>   foo@deb64:~$ bash -c 'bash -i 1; sleep '
>   bash: 1: No such file or directory<-- CTRL-C does not work here
> 
>   root@deb64:~# ps t pts/10 j
> PPIDPID   PGIDSID TTY   TPGID STAT   UID   TIME COMMAND
>96886  96887  96887  96887 pts/1097073 Ss1001   0:00 -bash
>96887  97072  97072  96887 pts/1097073 S 1001   0:00 bash -c
> bash -i 1; sleep 
>97072  97074  97072  96887 pts/1097073 S 1001   0:00 sleep 
> 
> Here the TPGID 97073 must be the first "bash -i" which has already exited.
> Seems like for some reason the "bash -c" does not set the foreground pgrp
> to the second "bash -i".
> 
> (Still learning the APUE book. Hope my analysis makes sense. :)

Re: Strange bash behavior

[Clark Wang]

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.

Re: Strange bash behavior

[Vladimir Marek]

> > 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: bash tests failing when compiled with --enable-xpg-echo-default=yes

[Vladimir Marek]

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 (and
> --enable-usg-echo-default=yes if that makes difference). I have no idea
> why, but since it was shipped like this for a long time, I am afraid of
> changing that :)
> 
> Because of this setting the tests are failing. I am attaching a patch we
> are using for workaround to show where the problems are seen. I used
> 'echo -E' when investigating, but "printf '%s\n'" seems to be more
> appropriate. If there is interest I'm more than happy to rework the
> attached patch.
> 
> Thanks!
> -- 
>   Vlad

> solaris is compiled with  --enable-xpg-echo-default=yes which makes some
> tests fail. Should we use printf '%s\n' "..." instead?
> 
> --- tests/comsub2.sub 2016-11-28 01:04:23.177652643 -0800
> +++ tests/comsub2.sub 2016-11-28 01:01:49.330747645 -0800
> @@ -4,5 +4,5 @@ echo "$qpath"
>  
>  # it's crazy that all three of these produce the same result
>  echo ${qpath//\\/}
> -echo ${qpath//"`echo \\`"/}
> -echo ${qpath//`echo ""`/}
> +echo ${qpath//"`echo -E \\`"/}
> +echo ${qpath//`echo -E ""`/}
> --- tests/exp5.sub2016-11-28 02:38:32.148794257 -0800
> +++ tests/exp5.sub2016-11-28 02:33:12.133199473 -0800
> @@ -1,18 +1,18 @@
>  # expansions involving patterns
>  
>  var='[hello'
> -echo "${var//[/}"
> +echo -E "${var//[/}"
>  
>  red='\[\e[0;31m\]'
> -echo "${red//\\[\\e/}"
> +echo -E "${red//\\[\\e/}"
>  
>  foo="${red//\\[\\e/}"
>  
>  # foo == [0;31m\]
> -echo "${foo//[0;31m\\/}"
> +echo -E "${foo//[0;31m\\/}"
>  
> -echo "${var//[]/}"
> -echo "${red//[]/}"
> +echo -E "${var//[]/}"
> +echo -E "${red//[]/}"
>  
>  v=hello
>  foo='[:alpha:]'
> --- tests/exp8.sub2016-11-28 03:44:56.875686938 -0800
> +++ tests/exp8.sub2016-11-28 03:39:21.761054928 -0800
> @@ -10,11 +10,11 @@ declare -p var | sed -n l
>  
>  recho ${var@Q}
>  recho ${var@P}
> -echo ${var@A}
> +echo -E ${var@A}
>  
>  unset array
>  array=( [$'x\001y\177z']=foo )   # should be error
> -echo ${array[@]@A}
> +echo -E ${array[@]@A}
>  
>  unset array
>  declare -a array=([0]=$'x\001y\177z')
> @@ -23,9 +23,9 @@ declare -p array
>  unset array
>  array=( "$var" )
>  recho ${array[@]}
> -echo ${array[@]@A}
> +echo -E ${array[@]@A}
>  
>  unset array
>  declare -A array
>  array=( [$'x\001y\177z']=$'a\242b\002c' )
> -echo ${array[@]@A}
> +echo -E ${array[@]@A}
> --- tests/heredoc3.sub2016-11-28 03:58:47.587299575 -0800
> +++ tests/heredoc3.sub2016-11-28 03:55:11.935894965 -0800
> @@ -69,7 +69,7 @@ cat <  hello
>  \END
>  END
> -echo end 'hello\END'
> +echo -E end 'hello\END'
>  
>  # this has to be last -- results in a syntax error
>  # doesn't currently parse because EOF is not on a line by itself -- should 
> it?
> --- tests/quote1.sub  2016-11-28 04:11:46.210688369 -0800
> +++ tests/quote1.sub  2016-11-28 04:08:49.101872596 -0800
> @@ -14,7 +14,7 @@ echo "'${test//"'"/}'"
>  
>  echo "'${test//"'"/"'\\''"}'"
>  
> -echo "'${test//"'"/\'\\'\'}'"
> +echo -E "'${test//"'"/\'\\'\'}'"
>  
>  #echo "'${test//'/}'"   # hangs waiting for '
>  #echo "'${test//"'"/'\\''}'" # hangs waiting for '

# Unset xpg_echo when running the posix2 regexp tests.
--- tests/posixexp2.tests   2010-11-11 17:50:47.0 -0800
+++ tests/posixexp2.tests   2012-07-12 13:15:14.818468328 -0700
@@ -2,6 +2,11 @@
 
 set -o posix
 
+xpg=`shopt | grep xpg_echo | awk '{ print $2 }'`
+if [ ${xpg} = "on" ] ; then
+shopt -u xpg_echo
+fi
+
 (echo 1 ${IFS+'}'z}) 2>&- || echo failed in 1
 (echo 2 "${IFS+'}'z}") 2>&- || echo failed in 2
 (echo 3 "foo ${IFS+'bar} baz") 2>&- || echo failed in 3

Re: Could bash do what make does?

[Robert Durkacz]

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 than some file that is required.

On 29 November 2016 at 02:21, Dennis Williamson  wrote:

>
>
> On Sun, Nov 27, 2016 at 7:25 PM, Robert Durkacz 
> wrote:
>
>> Has thought been given, over the years, to extending bash to do
>> what make does, in the obvious way that I am about to describe?
>>
>> It would be a matter of having chosen build commands do nothing if their
>> outputs are newer than their inputs. For example that is, cc file.c -o
>> file.o should execute normally if file.c is the newer file but do nothing
>> if file.o is newer.
>>
>> Then you would have a deterministic script to build a system that simply
>> skipped steps determined to be unnecessary.
>>
>> It is possible to achieve this without changing bash but it seems like
>> there would be leverage in having bash deliberately support this mode.
>>
>
>
> Use the newer-than test:
>
> source=file.c
> object=file.o
> [[ $source -nt $object ]] && cc "$source" -o "$object"
>
>
> --
> Visit serverfault.com to get your system administration questions
> answered.
>

Re: Could bash do what make does?

[Robert Durkacz]

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 out the fallacy in the following simplistic approach, I would be
grateful:
1. Script exhaustively the commands to build a unit of software.
2. Using facilities already in bash or, as appropriate, extensions, have
the commands bypass actual execution when all input files are older than
all output files.
It seems that this gives the same effects and benefits of make but in a
more straightforward way.

Re: Could bash do what make does?

[Greg Wooledge]

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 Bell Labs in April 1976.

https://en.wikipedia.org/wiki/Bash_%28Unix_shell%29 says that the first
beta version of bash was released by Brian Fox in June 1989.

Re: Strange bash behavior

[Chet Ramey]

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
> @@ -1504,6 +1504,7 @@ open_shell_script (script_name)
>  {
>e = errno;
>file_error (filename);
> +  end_job_control ();
>sh_exit ((e == ENOENT) ? EX_NOTFOUND : EX_NOINPUT);
>  }

Nice catch and fix.  There are a couple of other places you need to make
this change, but it's the right fix.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Strange bash behavior

[Chet Ramey]

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 Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Testsuite problem when HOME is not defined

[Chet Ramey]

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
> 
> I am attaching the patch I am using for workaround, maybe it's worth
> adding something similar officially?

Yes, I will add something along these lines.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

command substitution bug

[parasite parasite]

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 think it's because bash interprets "^#" as "#" which means that what
follow is commented.

It works, when $# is replaced by any number:
$ var="$(for ((i=0;i<5;i++));do echo line;done)"

It works with backticks:
$ var=`$(for ((i=0;i<$#;i++));do echo line;done)`

This works also:
$ var="$(bash -c 'for ((i=0;i<$#;i++));do echo line; done')"

As well than this one:
$ var="$(for ((i=0;i<${#};i++));do echo line;done)"

Than this one:
$ var="$(for ((i=0;i<"$#";i++));do echo line;done)"


IRC #bash on freenode

02/12/2016 11:13:19  then i guess the math context is not parsed
correctly. that seems odd.

02/12/2016 11:27:57  If you reassign $# to a different variable
beforehand it works as well.

02/12/2016 11:36:42  looks to me like a parser failure that reads
it as a comment start.
 doesn't matter what you write after it. it always misses the
closing parenthesis.

parasite.

command substition bug 2

[parasite parasite]

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 think it's because bash interprets "^#" as "#" which means that what
follow is commented.

It works, when $# is replaced by any number:
$ var="$(for ((i=0;i<5;i++));do echo line;done)"

It works with backticks:
$ var=`for ((i=0;i<$#;i++));do echo line;done`

This works also:
$ var="$(bash -c 'for ((i=0;i<$#;i++));do echo line; done')"

As well than this one:
$ var="$(for ((i=0;i<${#};i++));do echo line;done)"

Than this one:
$ var="$(for ((i=0;i<"$#";i++));do echo line;done)"


IRC #bash on freenode

02/12/2016 11:13:19  then i guess the math context is not parsed
correctly. that seems odd.

02/12/2016 11:27:57  If you reassign $# to a different variable
beforehand it works as well.

02/12/2016 11:36:42  looks to me like a parser failure that reads
it as a comment start.
 doesn't matter what you write after it. it always misses the
closing parenthesis.

parasite.

Re: Could bash do what make does?

[Dave Finlay]

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
software with many bespoke elements, like syntax, configuration, and macro
systems.  They often become that way because software projects of any large
size start to take on their own arbitrary conventions and requirements that
must be handled.  We just love to shoot ourselves in the foot.

I feel like these are self evident, but perhaps there is a grok gap I'm not
seeing. Bash is a shell, a language and an old friend. It is not a build
system. Narrowing and/or expanding a piece of software's scope to address
problems it isn't concerned with is almost always going to end in tears.
See the Unix Philosophy
:
do one thing and do it well.

I recommend you attempt this endeavor independently, as a learning
experience. Try writing a script and a function library that will allow you
to build the Bash project (or something simpler) without Make or Autotools.
You will come to understand why the world is as it is.  You will come to
truly comprehend the dark side of dealing with compilation caches, diverse
compiler output, job control, dependency management, packaging, and all the
other painful things.

After that exercise, take a look at some of approaches people have taken.
CMake, Maven, Gradle, and SCons are good projects to look at. Just take a
look at how much thought went into Maven's Dependency Version Requirement
Specification
.
There is no magic that will lead to the 'Perfect Build System'.  It takes
well thought out architecture, obsession with details, and a gobs of
effort.  Even with all that, it will never be perfect or universal.  There
is always a use case or edge case you didn't deal with.

I hope this response was of benefit to you.



Dave Finlay

On Fri, Dec 2, 2016 at 2:29 AM, Robert Durkacz 
wrote:

> 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 than some file that is required.
>
> On 29 November 2016 at 02:21, Dennis Williamson <
> dennistwilliam...@gmail.com> wrote:
>
>>
>>
>> On Sun, Nov 27, 2016 at 7:25 PM, Robert Durkacz > > wrote:
>>
>>> Has thought been given, over the years, to extending bash to do
>>> what make does, in the obvious way that I am about to describe?
>>>
>>> It would be a matter of having chosen build commands do nothing if their
>>> outputs are newer than their inputs. For example that is, cc file.c -o
>>> file.o should execute normally if file.c is the newer file but do nothing
>>> if file.o is newer.
>>>
>>> Then you would have a deterministic script to build a system that simply
>>> skipped steps determined to be unnecessary.
>>>
>>> It is possible to achieve this without changing bash but it seems like
>>> there would be leverage in having bash deliberately support this mode.
>>>
>>
>>
>> Use the newer-than test:
>>
>> source=file.c
>> object=file.o
>> [[ $source -nt $object ]] && cc "$source" -o "$object"
>>
>>
>> --
>> Visit serverfault.com to get your system administration questions
>> answered.
>>
>
>