Joseph Kowalski Joseph.Kowalski at eng.sun.com wrote:
I just don't see this in the thread. I see a lot of debate (which I
started) as to it the /sbin version is justified, but as I said that
is a discussion about more than one shell in /sbin and not specifically
targetted at ksh93. Thinking
Alan Coopersmith alan.coopersmith at sun.com wrote:
What we _really_ should discuss is whether there is a program in / (not
/usr)
that needs wordexp() as wordexp() is currently in /lib/libs but calls
/usr/bin/ksh
That would be an excellent argument for adding a copy in the root
Darren J Moffat wrote:
Casper.Dik at Sun.COM wrote:
I don't know that I can argue for ksh93 versus any other shell,
but adding /sbin/ksh93 at least gives us one modern, more feature-rich
alternative to the bourne shell (/sbin/sh), for use as the root shell,
in JumpStart scripts, or in
Darren J Moffat wrote:
For all the libraries that are Project Private why are they in /lib or
in /usr/lib rather than in /usr/lib/ksh [ or /usr/lib/ksh93 ] ? I
understand that some of them might be raised in stability later but what
about the ones that are true implementation artifacts, I
Darren J Moffat wrote:
[snip]
The only way I think I can accept the creation of pfksh93 (and by the
implications of this case this code base will be come that for
/usr/bin/pfksh at some point) is if this case at least makes the current
situation no worse than it already is
The situnation is
Martin Schaffstall wrote:
On 9/21/06, Casper.Dik at sun.com Casper.Dik at sun.com wrote:
[snip]
Why doesn't apply the same argumentation to libshell in the root
filesystem, too ?
Because we need one shell and /sbin/sh suffices for now.
Sounds you like being a little sadist and punish
Martin Schaffstall wrote:
[snip]
Roland,
I think it is time to face the truth that Sun doesn't want ksh93 in
Solaris. Please cancel this project. It is no longer worth wasting
time here
Erm, no.
I think you are misunderstaning the ARC process here: It is part of ARC
member's job to ask
James Carlson wrote:
Martin Schaffstall writes:
On 9/21/06, Casper.Dik at sun.com Casper.Dik at sun.com wrote:
None of the arguments have swayed us so far and James explained that
arguments prefixed with in the future we may are best dealt with
in future ARC cases when things may be
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
James Carlson wrote:
[snip]
Moreover, a future project that actually has a need for /sbin/ksh93
(or a replaced /sbin/sh) could do so without causing trouble for the
system. Adding in /sbin/ksh93 doesn't cause trouble for any
applications. It's binary-compatible. Moving the libraries from
James Carlson james.d.carlson at Sun.COM wrote:
- when invoked as pfksh93, the shell becomes aware of RBAC and
checks whether there's a profile for a given command before
attempting to use the built-in; if there is, it execs the external
version instead.
This sounds reasonable
Josh Hurst wrote:
[snip]
These are all needed for ksh93.
No. You can link them statically. There would be no need for any of
these libraries. There is no need for ksh93 in ON either. You could
put it into sfw. Or you could download it from blastwave. They have a
ksh93 package. But you want
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
Darren J Moffat wrote:
For all the libraries that are Project Private why are they in /lib or
in /usr/lib rather than in /usr/lib/ksh [ or /usr/lib/ksh93 ] ? I
understand that some of them might be raised in stability later but what
about the ones that are true implementation artifacts, I
Joerg Schilling wrote:
[snip]
If we talk about thiese functions, I still do not understand why ksh still
not includes sync as builtin while my bsh (where I did start with
a cursor editable history between 1982 and 1984) includes the sync command
as builtin since 1982.
This did save me a lot
Joerg Schilling wrote:
Roland Mainz roland.mainz at nrubsig.org wrote:
Casper.Dik at sun.com wrote:
[snip]
Is the intention to replace /sbin/sh with ksh93?
It has been requested some time ago and it may make sense to replace the
non-standard /sbin/sh with a POSIX-conformant shell.
Joerg Schilling wrote:
Roland Mainz roland.mainz at nrubsig.org wrote:
Casper.Dik at sun.com wrote:
I don't know that I can argue for ksh93 versus any other shell,
but adding /sbin/ksh93 at least gives us one modern, more feature-rich
alternative to the bourne shell (/sbin/sh), for
Roland Mainz roland.mainz at nrubsig.org wrote:
Joerg Schilling wrote:
Roland Mainz roland.mainz at nrubsig.org wrote:
Casper.Dik at sun.com wrote:
[snip]
Is the intention to replace /sbin/sh with ksh93?
It has been requested some time ago and it may make sense to replace the
Joerg Schilling wrote:
James Carlson james.d.carlson at Sun.COM wrote:
- when invoked as pfksh93, the shell becomes aware of RBAC and
checks whether there's a profile for a given command before
attempting to use the built-in; if there is, it execs the external
version
James Carlson wrote:
Roland Mainz writes:
Or libshell? Or libast? I seems that there is no compelling reason to
accept ksh93 at all
None of this justifies putting ksh into root.
What about |libc::wordexp()| ?
Yes, I'd like to see it fixed. I filed CR 4771992 four years ago
Joerg Schilling wrote:
[snip]
Please check the content of libcmd, there are more entries than the ones
starting with def*
Grumpf...
... the libcmd mapfile-spec contains the following entries for the
Solaris libcmd:
-- snip --
# functions exported by Solaris version of libcmd
SUNWprivate_1.1 {
Joseph Kowalski wrote:
From: Roland Mainz roland.mainz at nrubsig.org
[snip]
We all know there are some thorny issues around kshXX because we've
looked for simple answers in the past.
Based on the stories I heared so far Sun let this issue slip far too
long (and the term damn angry is an
Joseph Kowalski wrote:
From: April Chin April.Chin at eng.sun.com
There were many programs found linking to libcmd in other consolidations
and unbundled products...coordinating the changes for
these consumers with the ksh93 project made it very difficult
to change the name of the Solaris
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
April Chin wrote:
Darren J Moffat wrote:
For all the libraries that are Project Private why are they in /lib or
in /usr/lib rather than in /usr/lib/ksh [ or /usr/lib/ksh93 ] ? I
understand that some of them might be raised in stability later but what
about the ones that are true
On Thu, 21 Sep 2006 22:46:49 -0400 James Carlson wrote:
Roland Mainz writes:
I consider it more or less public (note that I am always getting the
official Sun stabilty terminology wrong - April may correct me if I am
causing havic again... :-) ) because the API is stable since many many
On Thu, 21 Sep 2006 23:46:31 -0400 Richard Lowe wrote:
Does this mean that rather than merging the symbols of the two libcmds,
the ksh93 libcmd could go by another name (or location), without
affecting either ksh93 nor consumers of libshell?
the current ast library names live peacfully
Darren J Moffat wrote:
[snip]
The only way I think I can accept the creation of pfksh93 (and by the
implications of this case this code base will be come that for
/usr/bin/pfksh at some point) is if this case at least makes the current
situation no worse than it already is
The situnation is
Joseph Kowalski wrote:
Thanks for the explanation, but the reason I'm inquiring is to determine
if the name libcmd is significant.
As the thread points out, we have two libraries (both from ATT) called
libcmd. Their contents are rather unrelated. Rather than merging them
(which seems
What version? In
http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libcmd/common/deflt.c
I don't see any non-static (global) functions that are other than def*; and if
I'm reading the Makefiles correctly, that's the only source file left for that
library.
ISTR some prior discussion
An additional problem, and one which deeply muddied the debate, is that
some stuff in OS/Net probably should be elsewhere (says I), and those
things are themselves grandfathered in. We should consider moving them
out to SFW. A hopefully uncontroversial example of this is libtecla.
And if
In general I am requesting the ARC people to burry this issue and let
the project team come up with a solution in peace - which means don't
rip out pfksh93 from this ARC case - there are at least three existing
ways to deal with the problem (see my other email) and IMO we have
plenty of time
I'm glad to hear you thought about it.
Care to share those thoughts?
- jek3
Date: Fri, 22 Sep 2006 08:45:52 +0200
From: Roland Mainz roland.mainz at nrubsig.org
X-Accept-Language: en
MIME-Version: 1.0
To: Joseph Kowalski Joseph.Kowalski at eng.sun.com, Korn Shell 93
integration/migration
Roland Mainz roland.mainz at nrubsig.org wrote:
Actually, considering the nature of the routines I don't find it at
all a surprize that others have latched on to these. As a matter of
fact I recall a discussion about making these routies Public, but
that was decided against because we
Casper.Dik at Sun.COM wrote:
Darren J Moffat wrote:
[snip]
The only way I think I can accept the creation of pfksh93 (and by the
implications of this case this code base will be come that for
/usr/bin/pfksh at some point) is if this case at least makes the current
situation no worse
Casper.Dik at sun.com wrote:
The pf*sh issue is somewhat broader than just the builtins.
In the ideal world the pf*sh would just have a flag bit set and the
kernel would take care of most of the rest. (So a pf*sh would not
involve changing the code in the shell).
So it looks like you are
Glenn Fowler writes:
On Thu, 21 Sep 2006 22:46:49 -0400 James Carlson wrote:
Roland Mainz writes:
I consider it more or less public (note that I am always getting the
official Sun stabilty terminology wrong - April may correct me if I am
causing havic again... :-) ) because the API is
Roland Mainz writes:
Joseph Kowalski wrote:
Thanks for the explanation, but the reason I'm inquiring is to determine
if the name libcmd is significant.
As the thread points out, we have two libraries (both from ATT) called
libcmd. Their contents are rather unrelated. Rather than
Darren J Moffat writes:
Now personally I recommend to people when writing scripts that use a
profile never to depend on $PATH and always fully specify the paths.
A bit off-topic, but I disagree with that. For trivial scripts,
littering the code with /foo/bar/baz isn't too horrible, but for
Darren J Moffat Darren.Moffat at Sun.COM wrote:
All of the three that you listed may require changes to the script,
that seems wrong because it is introducing incompatibility between pfksh
and pfksh93 when the longer term goal is that ksh93 become the default.
Now personally I recommend to
Joerg Schilling wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
All of the three that you listed may require changes to the script,
that seems wrong because it is introducing incompatibility between pfksh
and pfksh93 when the longer term goal is that ksh93 become the default.
Now
Joseph Kowalski wrote:
I'm glad to hear you thought about it.
Care to share those thoughts?
Another procedural note about ARC discussions like this:
The right answer to Joe's question is probably closer to
here is a URL link to the archived forum discussion
or maybe
a link +
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
One note for those new to Sun's ARC processes - I've noticed the
e-mail thread subjects wandering a bit - while that's okay, you
need to continue to include the case number (2006/550) in the
subject line for the ARC case archiving scripts to record the
mail in the directory for this case (which
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
John == John Plocher John.Plocher at Sun.COM writes:
John Understood. An alternative to the current, simplistic must be on
John the alias to post spam handler could be along the lines of
John vectoring all the OS.o mailing lists thru Sun's spam firewall
Can you explain in more detail how
David Morano writes:
+ the latest KSH appear as /sbin/sh (statically linked if desired)
No, completely static linking isn't possible on Solaris nor would it
be desirable if it were possible. But having /sbin/sh updated at some
point in time would be.
/sbin doesn't mean static.
+ no
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
Roland Mainz writes:
PPS.: Note that my understanding of the Sun/Solaris interface taxonomity
is a little bit weak. The exact details are described by April in the
ARC case and with public I was thinking about that projects within
OS/Net (like commands like sleep, pwd, test, expr etc.) can use
Roland Mainz wrote:
P.S.: And yes: I am very very angry about that the libcmd issue comes
up again. We had a fully-featured flamewar and a phone conference hosted
by Sun with the result that we get the merged libcmd and I am going to
add a replacement API to libcmdutils.so.1 and aid all
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: James Carlson james.d.carlson at sun.com
...
Roland Mainz writes:
PPS.: Note that my understanding of the Sun/Solaris interface taxonomity
is a little bit weak. The exact details are described by April in the
ARC case and with public I was thinking about that projects within
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: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
...
There is another important issue to discuss:
mkisofs and star (both part of OpenSolaris - mkisofs in reality, star
virtually
by PSARC 2004/480 but comming in reality in a few weeks) both use my libfind
for implementing a
From: Roland Mainz roland.mainz at nrubsig.org
...
Joseph Kowalski wrote:
[snip]
Hence, we should just rename the libcmd associated with ksh on Solaris.
A fork from the reference community (ie: David Korn)? Yes, but an
exceptionally minor one.
Definately NOT. NEVER.
There will not
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
How do I start such an ARC case for depending on libfind?
I'm going to take this off-line with Jorg.
- jek3
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
91 matches
Mail list logo
