On Thu, Sep 20, 2007 at 11:31:59PM -0700, UNIX admin wrote:
> I can well understand that. Although, you are aware of the fact that,
> the more packages set perms explicitly, the higher the chance that one of
> those will set them incorrectly? That's just statistics. Or do all your
> developers, b
> Please don't. It'll break the packaging consistency
> checks.
BTW, that reminded me: the organization where I work at, the "experts" wanted
to strictly forbid dashes in the package names because their check tools were
broken/incorrectly written and couldn't handle something like SUNWgnome-lib
> UNIX admin writes:
> > In "new/usr/src/pkgdefs/SUNWdmfe/prototype_com",
> I'd set:
> >
> > d none kernel/drv/amd64 ? ? ?
> > ...
> > d none kernel/drv/sparcv9 ? ? ?
>
> For unbundled items (stuff that ships separately from
> an OpenSolaris
> distribution), that's good advice.
>
> However, for
mspaper wrote:
> What can cause the child to receive SIGHUP? Once the
> system command fails due to this error, it cannot recover
> till the application is restarted
Depending on the shell (e.g. I only tried this with ksh93) you may try
to use...
-- snip --
trap '' SIGHUP
-- snip --
... to let the
UNIX admin writes:
> In "new/usr/src/pkgdefs/SUNWdmfe/prototype_com", I'd set:
>
> d none kernel/drv/amd64 ? ? ?
> ...
> d none kernel/drv/sparcv9 ? ? ?
For unbundled items (stuff that ships separately from an OpenSolaris
distribution), that's good advice.
However, for stuff that's integrated in
mspaper writes:
> What can cause the child to receive SIGHUP?
A process normally receives SIGHUP when a "modem disconnect" is
detected on the controlling tty. See termio(7I).
It's possible for other processes to send SIGHUP using the kill(2)
system call. You can diagnose what's going on using t
Hi
What can cause the child to receive SIGHUP? Once the system command fails due
to this error, it cannot recover till the application is restarted
This message posted from opensolaris.org
___
opensolaris-code mailing list
opensolaris-code@opensolari
