"I. Szczesniak" wrote:
> On 6/2/07, Roland Mainz <[EMAIL PROTECTED]> wrote:
> > Grumpf... no... do you want to see my list of "major" items still open
> > in ast-ksh.2007-04-18 (which is the basis for this putback (disclaimer:
> > None of these bugs are "critical" and ksh93 passes the testsuite and
>With or without using ksh93 (if I can use ksh93 the "POUND_SIGN:sh= echo
>\\043" in usr/src/Makefile.master will die, too... :-) (saving one shell
>call per Makefile)) ?
>
When run from the nightly script, POUND_SIGN is imported from the
environment and never executed. (So it won't help your
> Just curious... if I recall the nawk(1) manual page correctly both
> /usr/bin/nawk and /usr/xpg4/bin/awk should be identical...
Hmm, I don't see a statement to that effect.
In any case, it seems like the source is quite distinct -- one is in
cmd/awk and the other in cmd/awk_xpg4 (sigh). (T
Hi!
Just curious... if I recall the nawk(1) manual page correctly both
/usr/bin/nawk and /usr/xpg4/bin/awk should be identical... but looking
at the file size there seems to be a huge difference in Solaris 11/B61:
-- snip --
$ ls -l /usr/xpg4/bin/awk /usr/bin/nawk
-r-xr-xr-x 1 root b
Roland Mainz wrote:
Garrett D'Amore wrote:
Roland Mainz wrote:
[EMAIL PROTECTED] wrote:
I dunno. I can only theorize at this point, since I've not actually
tried the alternate approach on ON. But the kernel, at least, takes
quite a while to build. I'd think even a small impro
Garrett D'Amore wrote:
> Roland Mainz wrote:
> > [EMAIL PROTECTED] wrote:
> >>> I dunno. I can only theorize at this point, since I've not actually
> >>> tried the alternate approach on ON. But the kernel, at least, takes
> >>> quite a while to build. I'd think even a small improvement would be
Roland Mainz wrote:
[EMAIL PROTECTED] wrote:
I dunno. I can only theorize at this point, since I've not actually
tried the alternate approach on ON. But the kernel, at least, takes
quite a while to build. I'd think even a small improvement would be
appreciated.
I'm not sure; an inc
[EMAIL PROTECTED] wrote:
>
> >I dunno. I can only theorize at this point, since I've not actually
> >tried the alternate approach on ON. But the kernel, at least, takes
> >quite a while to build. I'd think even a small improvement would be
> >appreciated.
>
> I'm not sure; an incremental build
Murali wrote:
>
> syslogd : line 45 warning: localhost could not be resolved.
>
> solaris-devx sendmail[510] My unqualified hostname( localhost
> unknown) sleeping for retry
> solaris-devx sendmail[511] My unqualified hostname( localhost
> unknown) sleeping for retry
>
> Ou
Mike Kupfer wrote:
>
> > "GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
[snip]
> I keep hoping that someone will redo (prototype) the makefiles for a
> portion of the source tree, to avoid recursive makes. It would be
> interesting to compare that approach with the one you described.
It
On 06/26/07 00:42, Danek Duvall wrote:
I thought Sasha would jump in at some point, but
http://opensolaris.org/os/project/onnv/onnv_build/faster_builds/
Sasha is offsite in a class at AMD this week and I'm not on the
opensolaris-code email alias (yet).
I notice that in the build res
[EMAIL PROTECTED] wrote:
Okay, turns out I need to come clean. The stat() optimization is
_really_ just looking for justification for what I really want, which is
a simpler set of Makefiles to maintain. The kernel Makefiles are
mess adding a common module still means you have to touch:
[Once again removing ksh93 list from the cc, since tar still has nothing
to do with the ksh93 project.]
Joerg Schilling wrote:
Well, in order to be able to suggest a different implementation, we would need
a documentation of the implementation in question. Such a documentation is not
available
Doug stated:
< I am trying to troubleshoot an existing script and have located the point of
failure. Before I make any changes I need to know what the bolded entry is
doing/for:
<
< mount /dev/dsk/$disk /mnt [b]2>/dev/null[/b]
<
< I know that if I leave it off everything will work, but does any
I am trying to troubleshoot an existing script and have located the point of
failure. Before I make any changes I need to know what the bolded entry is
doing/for:
mount /dev/dsk/$disk /mnt [b]2>/dev/null[/b]
I know that if I leave it off everything will work, but does anyone have an
idea what
syslogd : line 45 warning: localhost could not be resolved.
solaris-devx sendmail[510] My unqualified hostname( localhost
unknown) sleeping for retry
solaris-devx sendmail[511] My unqualified hostname( localhost
unknown) sleeping for retry
Our computer host name is mit-1
On 06/26/07 00:42, Danek Duvall wrote:
I thought Sasha would jump in at some point, but
http://opensolaris.org/os/project/onnv/onnv_build/faster_builds/
I notice that in the build results there, eg,
http://opensolaris.org/os/project/onnv/onnv_build/faster_builds/times/x86/
the DMAKE_MAX
"Garrett D'Amore" <[EMAIL PROTECTED]> wrote:
> If the extensions have escaped, then it is probably too late to do
> anything about it, and we just need to figure out a way to improve
> cooperation in the future.
>
> If they have _not_ escaped into Solaris 10, then can I suggest that
> Joerg, wh
>Okay, turns out I need to come clean. The stat() optimization is
>_really_ just looking for justification for what I really want, which is
>a simpler set of Makefiles to maintain. The kernel Makefiles are
>mess adding a common module still means you have to touch:
>
>* uts/sparc/Mak
[EMAIL PROTECTED] wrote:
I dunno. I can only theorize at this point, since I've not actually
tried the alternate approach on ON. But the kernel, at least, takes
quite a while to build. I'd think even a small improvement would be
appreciated.
I'm not sure; an incremental build takes me
>I dunno. I can only theorize at this point, since I've not actually
>tried the alternate approach on ON. But the kernel, at least, takes
>quite a while to build. I'd think even a small improvement would be
>appreciated.
I'm not sure; an incremental build takes mere minutes and shaving seco
21 matches
Mail list logo
