On Thu, 23 Aug 2012 00:30:02 +0200, Jilles Tjoelker writes:
>I think the most important reason is to reduce special cases. The POSIX
>developers did not want to create a second subset of utilities that are
>not available via execve() (the first subset is the special builtins).
>The burden on implementations is very low (see src/usr.bin/alias), and
>there are some possible use cases:

The burden may be low, but so is the functionality ;-)
'cd' makes little sense in a child process.

>'cd' will fail if the directory does not exist.

so will 'test -d', and without giving the false impression that
something useful will result if the directory does exist.

>If it avoids the need to add semicolons for mysterious reasons, that may
>be enough reason.

I think everyone agrees that re-writing the target to remove the
spurious 'cd' would have been better.

That aside, I would disagree, at least for the case of 'cd'.
It is only the fact that there is probably no way to construct a harmful
example that did not involve a shell meta char (hence rendering the
existance of /usr/bin/cd irrelevant).  'cd /tmp/dir && rm -rf *'
would be rather dangerous if the && (or ;) didn't trigger use of a
shell, and since as previously noted just 'cd /tmp/dir' is pretty
pointless,  the functionality is very low.

In over 25 years of writing makefiles, I don't recall seeing this before.

>I think make's optimization of executing certain commands directly
>instead of passing them to sh should be rather invisible to the user,
>particularly if the optimization may be activated or deactivated by
>something seemingly innocuous like toggling -j.

Changing the way the dependency graph is processed is probably more
often the cause of surprises.
But yes, makefiles which need work for -j (heck even separate objdirs)
are common enough.

>It seems not entirely possible to hide the optimization completely as
>that would require deeper knowledge of the shell in make. Shell builtins
>are usually found before a PATH search and there may be non-standard
>shell builtins.

True, which is a good argument for having a standard shell as part of
the build environment.


_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to