On 9/25/06, Glenn Fowler gsf at research.att.com wrote:
would '-R $ORIGIN/../lib/ast' work?
FYI, that's how the CSWksh package (out of date now) was done
(actually, it is $ORIGIN/../lib/ksh which resolved to /opt/csw/lib/ksh).
http://blastwave.org/packages/ksh
http://blastwave.org/filesearch/ksh
Glenn Fowler gsf at research.att.com wrote:
On Sat, 23 Sep 2006 12:21:31 +0200 Joerg.Schilling at fokus.fraunhofer.de
(Joerg Schilling) wrote:
For me there would be an interesting OSS aspect that is a result from the
fact
that Korn/Fowler system is very similar to my sytem and thus is
Glenn Fowler writes:
now, on solaris, is there some compile-time magic that would allow
libcmd.so to be installed in $SOMELIBDIR/ksh/libcmd.so such that
-lcmd imbedded in the a.out would cause ld.so to look for
ksh/libcmd.so while honoring LD_LIBRARY_PATH? if so let
-R $SOMELIBDIR/ksh -- it's
On Mon, 25 Sep 2006 12:37:10 +0200 Joerg.Schilling at fokus.fraunhofer.de
(Joerg Schilling) wrote:
If I understand correctly, then libast does similar things with sfio
as I do in my invisible stdio layer: adding data structures besides
stdio in a way that does not hurt.
sfio is a complete
On Mon, 25 Sep 2006 08:35:08 -0400 James Carlson wrote:
Glenn Fowler writes:
now, on solaris, is there some compile-time magic that would allow
libcmd.so to be installed in $SOMELIBDIR/ksh/libcmd.so such that
-lcmd imbedded in the a.out would cause ld.so to look for
ksh/libcmd.so while
On Mon, Sep 25, 2006 at 10:46:01AM -0400, Glenn Fowler wrote:
On Mon, 25 Sep 2006 08:35:08 -0400 James Carlson wrote:
-R $SOMELIBDIR/ksh -- it's just a makefile thing, and it seems to me
that the makefiles are already being forked due to an insistence on ON
instead of SFW. (That fork
: Re: [ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
To: Joseph Kowalski Joseph.Kowalski at eng.sun.com
Cc: ksh93-integration-discuss at opensolaris.org, PSARC-EXT at
sac.sfbay.sun.com
MIME-version: 1.0
Content-transfer-encoding
On Sat, Sep 23, 2006 at 08:49:02PM -0700, John Plocher wrote:
$BIN/../lib/libcmd.so.x:b_...
The entry points in the above libcmd shared object.
They is used by ksh, ast and a bunch of /usr/bin/cmd
wrappers, and is intended to be used by
the issue is that the ast -lcmd library is used:
(1.a) at compile-link time for the static ksh93 a.out
(static -lshell -lcmd -ldll -last, dynamic otherwise)
ksh93 can be configured to bring in some or all of -lcmd;
the default ast ksh93 static a.out build pulls in only
Nicolas Williams wrote:
So, which is it? If public, then the ARC pretty much has to butt out on
this, no?
No, if it is public then the ARC needs to work with the project team
to determine HOW the library will be delivered without negatively
impacting the existing libcmd that lives in the
From: Mike Kupfer mike.kupfer at sun.com
...
That said, Roland has already written new makefiles for use in the ON
code base. So maybe I'm missing something, but I don't see how makefile
source compatibility would be a concern here.
That said, my statement was based on the assumption that
From: Mike Kupfer mike.kupfer at sun.com
...
Mike So maybe I'm missing something, but I don't see how makefile
Mike source compatibility would be a concern here.
I was missing something (he says after rereading earlier emails).
The issue is that applications that want to use libcmd and
Glenn Fowler gsf at research.att.com wrote:
On Fri, 22 Sep 2006 14:32:08 -1000 (HST) Joseph Kowalski wrote:
Marginal because we are only effecting source portability at a Makefile
level. Yawn.
with sun glasses on source portability may be boring
that was very clear a few messages back
Such a change would break existing scripts and applications and IMO
ATT should reject such an attempt to bypass the decision of the
project leads.
How could this break existing scripts and applications?
There obviously are no existing applications using this library on Solaris.
The library
Mike Kupfer mike.kupfer at sun.com wrote:
...
well said let me add some general remarks:
Also, if we do want Solaris-specific changes, I think we'll be more
likely to reach a mutually acceptable approach if our rationale is more
concrete than such-and-such approach is ugly. Several
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
...
What we should discuss here is _not_ wehther to include the libraries
from ksh93 but how to include them and whether these libraries should be
deemed ksh internal or for general users.
I thought we were. At least that's the
On Sat, 23 Sep 2006 12:21:31 +0200 Joerg.Schilling at fokus.fraunhofer.de
(Joerg Schilling) wrote:
For me there would be an interesting OSS aspect that is a result from the
fact
that Korn/Fowler system is very similar to my sytem and thus is very
different. I would like to know whether an
On Fri, Sep 22, 2006 at 08:45:26PM -0700, Mike Kupfer wrote:
Mike == Mike Kupfer mike.kupfer at sun.com writes:
Mike So maybe I'm missing something, but I don't see how makefile
Mike source compatibility would be a concern here.
I was missing something (he says after rereading earlier
On Fri, Sep 22, 2006 at 11:59:44PM -1000, Joseph Kowalski wrote:
From: Mike Kupfer mike.kupfer at sun.com
...
That said, Roland has already written new makefiles for use in the ON
code base. So maybe I'm missing something, but I don't see how makefile
source compatibility would be a
On Fri, Sep 22, 2006 at 11:59:44PM -1000, Joseph Kowalski wrote:
From: Mike Kupfer mike.kupfer at sun.com
...
That said, Roland has already written new makefiles for use in the ON
code base. So maybe I'm missing something, but I don't see how makefile
source compatibility would be a
Joseph Kowalski wrote:
Tell you what - *if* the concensus is that this library is Consolidation
Private, meaning anybody in the ON consolidation can use it, but no one
else, I'll turn my back on this. Its simply not that important.
Sorry, no can do. *Both* libcmds are effectively
Roland Mainz roland.mainz at nrubsig.org wrote:
To describe it short words (April did some research on this and may be
able to give you more details): Both ksh93 and Solaris have a libcmd. To
ensure backwards-compatibility with both versions we're shipping a
merged version which contains both
Alan Coopersmith alan.coopersmith at sun.com wrote:
Joseph Kowalski wrote:
I *think* all the functions in Solaris's libcmd are Consolidation Private
(or at least Private of some form).
I don't remember if libcmd was officially or just effectively Sun Private, but
since it's used by
Alan Coopersmith alan.coopersmith at sun.com wrote:
Joerg Schilling wrote:
Please check the content of libcmd, there are more entries than the ones
starting with def*
Not in Solaris Nevada - the other old entries were removed. (The ARC case
was 2004/803 which doesn't seem to be on
Alan Coopersmith wrote:
Roland Mainz wrote:
Darren J Moffat wrote:
Are all the new things that are being added to libcmd already in a
library called libcmd when ksh93 is installed on other systems ? If not
please don't put them in our libcmd.
Umpf. Please read last months discussion
On 9/22/06, Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
Thanks for the explanation, but the reason I'm inquiring is to determine
if the name libcmd is significant.
The name libcmd is significant because it is a library which can be
referenced using
builtin -f cmd commandname
to load
I. Szczesniak writes:
On 9/22/06, Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
Thanks for the explanation, but the reason I'm inquiring is to determine
if the name libcmd is significant.
The name libcmd is significant because it is a library which can be
referenced using
James Carlson james.d.carlson at sun.com wrote:
The name libcmd is significant because it is a library which can be
referenced using
builtin -f cmd commandname
to load one of the commands located in libcmd.
The name 'cmd' is a well known location to find those commands for
dynamically
On 9/22/06, Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de wrote:
James Carlson james.d.carlson at sun.com wrote:
The name libcmd is significant because it is a library which can be
referenced using
builtin -f cmd commandname
to load one of the commands located in libcmd.
I. Szczesniak writes:
If it *did* need to be renamed, would there be a barrier to having an
alias? Just have the -f x handler compare the string against
cmd and use an alternate name for that one case. (Not pretty, I
know, but doesn't seem to pose any obvious problems.)
From a
On 9/22/06, James Carlson james.d.carlson at sun.com wrote:
I. Szczesniak writes:
On 9/22/06, Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
Why wouldn't this scan a ksh93-specific location first, such as a
/usr/lib/ksh93/ directory? You could have your own libcmd.so{,.1}
buried in
I. Szczesniak writes:
On 9/22/06, James Carlson james.d.carlson at sun.com wrote:
I. Szczesniak writes:
On 9/22/06, Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
Why wouldn't this scan a ksh93-specific location first, such as a
/usr/lib/ksh93/ directory? You could have your own
I. Szczesniak wrote:
On 9/22/06, James Carlson james.d.carlson at sun.com wrote:
I. Szczesniak writes:
On 9/22/06, Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
Why wouldn't this scan a ksh93-specific location first, such as a
/usr/lib/ksh93/ directory? You could have your own
On Fri, 22 Sep 2006 10:02:54 -0400 James Carlson wrote:
A better alternative might be to look at the places scanned. It
doesn't seem to make sense to me that 'builtin -f' would resolve
against /usr/lib, at least first in the list. I sure don't want
'builtin -f ipmp' to load the IPMP
a bunch of good suggestions on -lcmd *already implemented for years*
there is so much traffic here its hard to keep up
some of it could be allayed by holding off a few miniutes before posting
so that slow readers with technical answers have a chance to post
-- Glenn Fowler -- ATT Research,
I agree that changing the name as seen by users (via 'builtin -f') is
a bad idea, but I don't agree that putting plugins in the top level of
/usr/lib is a good idea, nor do I agree that the user interface must
always map directly into the internal implementation.
So, I don't see how
I think my comments are on the border line between architecture review
and design or code review, the only reason I'm asking is the $PATH issues.
Glenn Fowler wrote:
the upshot is that, on solaris, ksh first looks for plugins for the
ksh application, so the ksh cmd plugin, with solaris
David Korn wrote:
I agree that changing the name as seen by users (via 'builtin -f') is
a bad idea, but I don't agree that putting plugins in the top level of
/usr/lib is a good idea, nor do I agree that the user interface must
always map directly into the internal implementation.
So, I
Date: Fri, 22 Sep 2006 17:10:02 +0100
From: Darren J Moffat Darren.Moffat at sun.com
... ... ...
Most shell plugins should go in .../lib/ksh/plugin.so but libcmd.so
is different since it is not just usable by ksh. We have
nearly 40 other commands that use this library and changing the
Don Cragun writes:
Are any of these 40 other commands similar to ones in Solaris.
Most are similar to utilities in /usr/bin, but there are compatibility
problems. The project team expects to work out these compatibility
issues (by changing the ATT built-in code and/or changing current
Why is changing those utilities to be compatible with the existing
Solaris utilities possible, but changing them to link against a
different path impossible?
It is possible provide that the changes don't violate the POSIX
standard and don't conflict with current extensions.
I suspect
Date: Fri, 22 Sep 2006 12:38:22 -0400
From: James Carlson james.d.carlson at Sun.COM
Don Cragun writes:
Are any of these 40 other commands similar to ones in Solaris.
Most are similar to utilities in /usr/bin, but there are compatibility
problems. The project team expects to work out these
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 1044
URL:
http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20060922/b1f0b073/attachment.nws
jek3 == Joseph Kowalski Joseph.Kowalski at eng.sun.com writes:
jek3 As the thread points out, we have two libraries (both from ATT)
jek3 called libcmd. Their contents are rather unrelated. Rather than
jek3 merging them (which seems very unclean), I'm investigating the
jek3 possibility of
On Fri, 22 Sep 2006 17:05:47 +0100 Darren J Moffat wrote:
I think my comments are on the border line between architecture review
and design or code review, the only reason I'm asking is the $PATH issues.
Glenn Fowler wrote:
the upshot is that, on solaris, ksh first looks for plugins for
From: I. Szczesniak iszczesniak at gmail.com
...
On 9/22/06, Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
Thanks for the explanation, but the reason I'm inquiring is to determine
if the name libcmd is significant.
The name libcmd is significant because it is a library which
Joseph Kowalski writes:
Maybe I'm beating a dead horse, but is there any reason
builtin -f cmd commandname
couldn't open /usr/lib/lib_ksh_builtin_commands.so.1 to find the
entry points? I tend to doubt there is anything special that
ties the cmd in the option to the builtin
From: Mike Kupfer mike.kupfer at Sun.COM
...
jek3 == Joseph Kowalski Joseph.Kowalski at eng.sun.com writes:
jek3 As the thread points out, we have two libraries (both from ATT)
jek3 called libcmd. Their contents are rather unrelated. Rather than
jek3 merging them (which seems very
From: James Carlson james.d.carlson at sun.com
...
If we know that there are no programs outside of the project team's
ken that will want to link to this library (if it really is some
flavor of Private), then that'll work fine.
Unfortunately, we've gotten varying answers on this: that
On Fri, Sep 22, 2006 at 12:03:20PM -1000, Joseph Kowalski wrote:
I *think* if finally figured this out. Those 40 other commands are
the 40 file system equivalents of the builtins.
Commands that live in ON today, no?
IMO ksh93 ought to live in ON also, FWIW, particularly if we would
change
X-Original-To: ksh93-integration-discuss at opensolaris.org
Delivered-To: ksh93-integration-discuss at opensolaris.org
Date: Fri, 22 Sep 2006 12:03:20 -1000 (HST)
From: Joseph Kowalski Joseph.Kowalski at eng.sun.com
Subject: Re: Re: [ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93
On Fri, Sep 22, 2006 at 06:20:22PM -0400, James Carlson wrote:
So, clearly, the project team appears to believe:
- that libcmd.so needs to be in /lib or /usr/lib
- that there will be applications outside of ksh that will link to
this library in order to avoid fork+exec or spawn
jek3 == Joseph Kowalski Joseph.Kowalski at eng.sun.com writes:
jek3 If libcmd and libcmd are both private **and will stay that way**,
jek3 the merge is a viable (if nose holding) alternative.
So would it be okay to undo the merge as part of making libcmd public?
Or are you saying that if
Date: Fri, 22 Sep 2006 18:20:22 -0400
From: James Carlson james.d.carlson at sun.com
Joseph Kowalski writes:
I *think* if finally figured this out. Those 40 other commands are
the 40 file system equivalents of the builtins.
Yes.
Mostly, but not entirely.
Obviously, at the current time,
On Fri, Sep 22, 2006 at 04:06:49PM -0700, Don Cragun wrote:
The long term goal is to make libcmd public (but keep defopen, defread,
and defcntl Sun Private). Joe has already commented that other public
libraries contain private interfaces. Furthermore, as has been stated
before in the case
Date: Fri, 22 Sep 2006 18:22:41 -0500
From: Nicolas Williams Nicolas.Williams at sun.com
... ... ...
5006948 libcmd is not thread safe
was putback before S10 shipped.
So def*() are thread safe now.
Thanks, I missed that.
Doesn't their having been documented in System II and System V and the
From: James Carlson james.d.carlson at sun.com
...
That said, I don't see a reason that *either* libcmd should become
Public.
That's the sticking point. The others commenting on this thread have
said that they expect third parties to join in on the libcmd fun:
Don Cragun said:
From: Mike Kupfer mike.kupfer at sun.com
...
jek3 == Joseph Kowalski Joseph.Kowalski at eng.sun.com writes:
jek3 If libcmd and libcmd are both private **and will stay that way**,
jek3 the merge is a viable (if nose holding) alternative.
So would it be okay to undo the merge as part of
From: Don Cragun don.cragun at sun.com
...
- that some of those applications will be portable across machines
other than Solaris, and thus it'd be bad for us to rename the
library
Yes.
This must be portable at a source level we are discussing.
Even more than that, it must be
From: I. Szczesniak iszczesniak at gmail.com
...
On 9/22/06, Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
Thanks for the explanation, but the reason I'm inquiring is to determine
if the name libcmd is significant.
The name libcmd is significant because it is a library
On Fri, 22 Sep 2006 17:37:33 -0500 Nicolas Williams wrote:
How stable would this be anyways?
(re ast -lcmd)
I checked the old logs
initial release 1992, 28 functions with this prototype:
extern int b_xxx(int, char** void*);
main external change up to today -- 8 more b_xxx() added
same
On Fri, 22 Sep 2006 16:06:49 -0700 (PDT) Don Cragun wrote:
Yes, but there are standards problems, missing options, ... that need
to be fixed first in some of the b_XXX entries in libcmd before we can
replace /usr/bin or /usr/xpg*/bin utilities with libcmd front ends.
Thus, not all of this
Glenn == Glenn Fowler gsf at research.att.com writes:
Glenn On Fri, 22 Sep 2006 14:32:08 -1000 (HST) Joseph Kowalski wrote:
Marginal because we are only effecting source portability at a
Makefile level. Yawn.
Glenn with sun glasses on source portability may be boring
In general I agree
Mike == Mike Kupfer mike.kupfer at sun.com writes:
Mike So maybe I'm missing something, but I don't see how makefile
Mike source compatibility would be a concern here.
I was missing something (he says after rereading earlier emails).
The issue is that applications that want to use libcmd and
Roland Mainz wrote:
Darren J Moffat wrote:
Are all the new things that are being added to libcmd already in a
library called libcmd when ksh93 is installed on other systems ? If not
please don't put them in our libcmd.
Umpf. Please read last months discussion in the ksh93-integration
Joseph Kowalski wrote:
I *think* all the functions in Solaris's libcmd are Consolidation Private
(or at least Private of some form).
I don't remember if libcmd was officially or just effectively Sun Private, but
since it's used by unbundled products such as JES, renaming it would cause
Joerg Schilling wrote:
Please check the content of libcmd, there are more entries than the ones
starting with def*
Not in Solaris Nevada - the other old entries were removed. (The ARC case
was 2004/803 which doesn't seem to be on opensolaris.org yet.)
--
-Alan Coopersmith-
From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
...
AFAIR, libcmd was introduced by ATT with SVr4 (mainly for /etc/default which
was missing on SunOS 4.x). In early days it was a static library living in the
cmd source tree and not installed in /usr/lib. When Sun switched to
On Thu, 21 Sep 2006 14:24:36 -1000 (HST) Joseph Kowalski wrote:
What about ksh98's libcmd. Why is this considered Public? (If it
is Public, where are the man pages?)
save a top level man page that lists the commands foo implemented as
extern int b_foo(int _argc, char* const _argv[]);
From: Glenn Fowler gsf at research.att.com
...
On Thu, 21 Sep 2006 14:24:36 -1000 (HST) Joseph Kowalski wrote:
What about ksh98's libcmd. Why is this considered Public? (If it
is Public, where are the man pages?)
save a top level man page that lists the commands foo implemented as
cc: don.cragun at sun.com PSARC-EXT at sac.sfbay.sun.com
Subject: Re: Re: [ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
From: Glenn Fowler gsf at research.att.com
...
On Thu, 21 Sep 2006 14:24:36 -1000 (HST) Joseph
On Thu, 21 Sep 2006 15:34:45 -1000 (HST) Joseph Kowalski wrote:
From: Glenn Fowler gsf at research.att.com
...
On Thu, 21 Sep 2006 14:24:36 -1000 (HST) Joseph Kowalski wrote:
What about ksh98's libcmd. Why is this considered Public? (If it
is Public, where are the man pages?)
).
- jek3
Date: Thu, 21 Sep 2006 21:47:29 -0400 (EDT)
From: David Korn dgk at research.att.com
Subject: Re: Re: [ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
To: don.cragun at sun.com, ksh93-integration-discuss at opensolaris.org
73 matches
Mail list logo
