[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On 9/25/06, Glenn Fowler 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 http://blastwave.org/m

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

Glenn Fowler 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 very > > diff

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 fo

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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.s

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

From: John Plocher > Subject: Re: [ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006] > To: Joseph Kowalski > Cc: ksh93-integration-discuss at opensolaris.org, PSARC-EXT at > sac.sfbay.sun.com > MIME-version: 1.0 > Content

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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"

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 som

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 s

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 use

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On Fri, Sep 22, 2006 at 11:59:44PM -1000, Joseph Kowalski wrote: > > From: Mike Kupfer > ... > > 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. > >

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On Fri, Sep 22, 2006 at 11:59:44PM -1000, Joseph Kowalski wrote: > > From: Mike Kupfer > ... > > 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. > >

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On Fri, Sep 22, 2006 at 08:45:26PM -0700, Mike Kupfer wrote: > > "Mike" == Mike Kupfer 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). >

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 Public/Co

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

Mike Kupfer 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 messages in the There

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

Glenn Fowler 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 which suggested i

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On 9/23/06, Joseph Kowalski wrote: > > > From: Mike Kupfer > ... > > 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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> 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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> Such a change would break existing scripts and applications and IMO > AT&T 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 librar

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: Mike Kupfer ... > 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 be portable > w

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: Mike Kupfer ... > 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 libcmd is simply lin

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 which suggested introducing a sun only name for a s

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> > From: "I. Szczesniak" > ... > > On 9/22/06, Joseph Kowalski 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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> "Mike" == Mike Kupfer 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 be portable wou

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> "Glenn" == Glenn Fowler 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 with Glenn. I

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

ol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006] > Cc: PSARC-EXT at sac.sfbay.sun.com > x_sac_archived: PSARC-EXT/2006/550 > x_sac_loop: April.Chin at eng.sun.com roland.mainz at nrubsig.org > x_sac_info: auto-forwarded by the SAC mail system > > >

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 cas

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

Joseph Kowalski writes: > I *think* if finally figured this out. Those 40 other commands are > the 40 file system equivalents of the builtins. Yes. > Obviously, at the current time, our file system equivalents don't do > this. Indeed. > They probably should. This is a nice architecture which

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 builti

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 spaw

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 th

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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. >> >>

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

>Date: Fri, 22 Sep 2006 18:22:41 -0500 >From: Nicolas Williams ... ... ... > >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 >lack of incompat

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 fo

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On 9/22/06, James Carlson wrote: > I. Szczesniak writes: > > On 9/22/06, Joseph Kowalski 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 there, encourage others to deliver plugin libraries

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On 9/22/06, Joerg Schilling wrote: > James Carlson 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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

>Date: Fri, 22 Sep 2006 18:20:22 -0400 >From: James Carlson > >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, our file system

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

James Carlson 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 linked version

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On 9/22/06, Joseph Kowalski 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 one of the commands located

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> "jek3" == Joseph Kowalski 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 there are any plans to mak

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> 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 > Subject: Re: Re: [ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integra

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

I. Szczesniak wrote: > On 9/22/06, James Carlson wrote: >> I. Szczesniak writes: >> > On 9/22/06, Joseph Kowalski 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 there, encourage others

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: Don Cragun ... > > - 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 portable at a Ma

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: Mike Kupfer ... > > "jek3" == Joseph Kowalski 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 s

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: James Carlson ... > > 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: > > > Not in this PSAR

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> 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 suspec

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 AT&T built-in code and/or changing current

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: James Carlson ... > 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 there aren't > any, that

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: Mike Kupfer ... > > "jek3" == Joseph Kowalski writes: > > jek3> As the thread points out, we have two libraries (both from AT&T) > jek3> called libcmd. Their contents are rather unrelated. Rather than > jek3> merging them (which seems very unclean), I'm investigating the > jek3> p

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> "jek3" == Joseph Kowalski writes: jek3> As the thread points out, we have two libraries (both from AT&T) jek3> called libcmd. Their contents are rather unrelated. Rather than jek3> merging them (which seems very unclean), I'm investigating the jek3> possibility of renaming one. If we ren

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> 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 r

fwd: [ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 1044 URL:

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: "I. Szczesniak" ... > On 9/22/06, Joseph Kowalski 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 co

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 -- AT&T Research, Florh

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 lib

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

I. Szczesniak writes: > On 9/22/06, James Carlson wrote: > > I. Szczesniak writes: > > > On 9/22/06, Joseph Kowalski 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 there, encourage o

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

I. Szczesniak writes: > > > If it *did* need to be renamed, would there be a barrier to having an > > > alias? Just have the "-f " 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.)

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

I. Szczesniak writes: > On 9/22/06, Joseph Kowalski 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 commandnam

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

>Date: Fri, 22 Sep 2006 12:38:22 -0400 >From: James Carlson > >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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

>Date: Fri, 22 Sep 2006 17:10:02 +0100 >From: Darren J Moffat > ... ... ... >> >> 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 >> location would

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration[PSARC-EXT/2006/550 Timeout:09/27/2006]

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 mon

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

Alan Coopersmith 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 opensolaris.org yet.) T

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

Alan Coopersmith 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 unbundled products such as

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

Roland Mainz 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 functionalities. This

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

On Thu, 21 Sep 2006 15:34:45 -1000 (HST) Joseph Kowalski wrote: > > From: Glenn Fowler > ... > > 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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 > ... > > On Thu, 21 Sep 2006 14:24:36 -1000 (HST) Joseph

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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[])

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

haven't made this error before). - jek3 > Date: Thu, 21 Sep 2006 21:47:29 -0400 (EDT) > From: David Korn > 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-

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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-

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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 coordin

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

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-integrati

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: Glenn Fowler ... > 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

[ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]

> From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) ... > AFAIR, libcmd was introduced by AT&T 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