alias - there are experts
there that would certainly be able to evaluate this idea.
cheers,
tim
Original Message
Subject: Re: [osol-discuss] Re: OpenSolaris Standards Base
Date: Sat, 12 Aug 2006 21:01:29 +0200
From: Joerg Schilling <[EMAIL PROTECTED]>
To:
hi hugh,
Thanks for the feedback,
Hugh McIntyre wrote:
A more elegant solution might be to
teach intp.c about a proposed $OS_PERSONALITY environment variable.
Based on this variable, while executing an interpreter, we'd go
digging for the right personality.conf file, which would in turn alias
Tim Foster wrote:
Now, as to the problem of #!/bin/sh being bash or sh, or #!/bin/ksh being
ksh88, 93, etc. I had initially been thinking about a 'personality zone' (in
the same ilk as we now have branded zones) - but that's pretty heavyweight. A
more elegant solution might be to teach intp.c
Hi Joerg,
Joerg Schilling wrote:
Tim Foster <[EMAIL PROTECTED]> wrote:
TimiX scripts that need run on those different distributions could avail
of the #! aliasing feature I was mentioning previously (thanks for the
hint Casper!) where during execution, we lookup the personality.conf
file for t
Yep, just forwarding this to the relevant alias - there are experts
there that would certainly be able to evaluate this idea.
cheers,
tim
Original Message
Subject: Re: [osol-discuss] Re: OpenSolaris Standards Base
Date: Sat, 12 Aug 2006 21:01:29
Tim Foster <[EMAIL PROTECTED]> wrote:
> TimiX scripts that need run on those different distributions could avail
> of the #! aliasing feature I was mentioning previously (thanks for the
> hint Casper!) where during execution, we lookup the personality.conf
> file for their OS to work out what they
[EMAIL PROTECTED] wrote:
>
> >[btw. my idea of hacking intp.c to check for $OS_PERSONALITY isn't as
> >easy as I'd thought - we're in kernel space at that stage I thnk (still
> >reading my new copy of the 2nd ed. of the internals book ;-)]
>
> Might be easier to make it into a syscall then.
There
On Fri, 11 Aug 2006, Tim Foster wrote:
Hi Eric,
On Thu, 2006-08-10 at 16:42 -0500, Eric Boutilier wrote:
I'm not sure I agree completely with the way you've scoped
the problem.
Ok - unless I'm misunderstanding you, we're talking about different
problems I think.
You're talking about the prob
On Friday 11 August 2006 08:07 am, Tim Foster wrote:
> Ok - unless I'm misunderstanding you, we're talking about different
> problems I think.
I 'spose this is true...there could be two distinct problems being described.
> As I say, perhaps I'm over-complicating the problem, and if so, I'll
> hap
Hi Eric,
On Thu, 2006-08-10 at 16:42 -0500, Eric Boutilier wrote:
> I'm not sure I agree completely with the way you've scoped
> the problem.
Ok - unless I'm misunderstanding you, we're talking about different
problems I think.
You're talking about the problem of /usr/sfw/ containing material th
Darren J Moffat wrote:
That restriction has been removed now. I can't at the moment find the
ARC reference for the removal, but if John Plocher is reading this
thread I'm sure he will be able to find it and post it here.
PSARC/2005/185 Enabling serendipitous discovery - by Bart Smaalders,
c
Eric Boutilier wrote:
I'm not sure I agree completely with the way you've scoped
the problem. Reason being, the new rule (pending ARC
approval) is basically that all GNU/FOSS stuff goes in
/usr/bin.
The license was NEVER the issue.
The original issue that caused the creation of /usr/sfw/ was
On Thu, 10 Aug 2006, Tim Foster wrote:
...
It strikes me that the delivery of software, and the location it's
expected to be found on across distributions is like herding cats. Even on
Solaris, it's been hard enough to standardise (cf. /usr/ucb /usr/xpg4,
/usr/xpg6, /usr/sfw/, /usr/gnu, etc.)
...
>[btw. my idea of hacking intp.c to check for $OS_PERSONALITY isn't as
>easy as I'd thought - we're in kernel space at that stage I thnk (still
>reading my new copy of the 2nd ed. of the internals book ;-)]
Might be easier to make it into a syscall then.
At exec time we've copied the new environ
On Thu, 2006-08-10 at 14:28 -0700, Alan DuBoff wrote:
> What is /usr/bin was always a symlink, to point to the respective personality?
Mm, I'd say you shouldn't do that, because it'll ruin things for
everyone on your system (not to mention your system shell scripts)
The idea of a separate dedicat
On Thursday 10 August 2006 12:37 pm, Tim Foster wrote:
> It strikes me that the delivery of software, and the location it's expected
> to be found on across distributions is like herding cats. Even on Solaris,
> it's been hard enough to standardise (cf. /usr/ucb /usr/xpg4, /usr/xpg6,
> /usr/sfw/, /
Hi All,
It strikes me that the delivery of software, and the location it's expected to
be found on across distributions is like herding cats. Even on Solaris, it's
been hard enough to standardise (cf. /usr/ucb /usr/xpg4, /usr/xpg6, /usr/sfw/,
/usr/gnu, etc.)
I mentioned this on Eric's recent b
17 matches
Mail list logo