Blake Jones wrote:
[snip]
To elaborate on this: part of the idea behind mmapfd() is that it gives
the kernel the flexibility to make global-scope decisions about where
and how a file should be mapped. This includes the appropriate page
size to use (which might vary depending on what platform
Edward Pilatowicz wrote:
On Mon, Mar 31, 2008 at 11:46:34AM -0700, Michael Corcoran wrote:
On Mon, 2008-03-31 at 10:30 +0100, Darren J Moffat wrote:
I find the function name a bit strange. So strange in fact it made me
look at the mmap(2) man page to check that it wasn't taking a char*
Nicolas Williams wrote:
On Mon, Mar 31, 2008 at 01:37:42PM +0200, Roland Mainz wrote:
Rod Evans wrote:
mmapfd(int fd, uint_t flags, mmapfd_result_t *storage,
uint_t *elements, void *arg)
Uhm... how do I unmap the mapping done by |mmapfd()| ?
I thought that was clear (each
Bart Smaalders wrote:
John Zolnowsky x69422/408-404-5064 wrote:
The general nature of mmapfd() mapping represents a possible solution
to a concern being discussed in 2008/195. The issue is that
interpreters other than rtld often have the equivalent of libraries,
for example, perl's .pm
Yan Xue Yang wrote:
Roland Mainz:
Yan Xue Yang wrote:
Roland Mainz :
Yan Xue Yang wrote:
Roland Mainz :
Yan Xue Yang wrote:
Roland Mainz :
Which locale did you use (my main interest is whether non-UTF-8
multibyte encodings as used for zh_CN.GB18030 will work or not...) ?
I used
Bart Smaalders wrote:
Garrett D'Amore wrote:
Hang on a sec. I think what I'm hearing is that it is now OK to accept
architecturally inferior software into Solaris if it already exists on
Linux.
...
Are we just abdicating all engineering responsibility here, so that
Solaris will
Rod Evans wrote:
I'm sponsoring the following case for Mike Corcoran. Time out 04/07/08.
The case introduces a new system call, mmapfd(2). This call is primarily
targeted for use by ld.so.1(1), and provides for the efficient mapping of
ELF files (and 4.x AOUT files).
Release Binding:
Danek Duvall wrote:
I'm sponsoring this case for Henry Jiang. The release binding is Minor,
and the interfaces are Uncommitted.
There is a man page for the library in the materials directory. It shows
(but should probably do so more clearly) that the library is compiled with
g++, not
Joseph Kowalski wrote:
Garrett D'Amore wrote:
4.3.4 Unison does not understand hard links.
That's pretty unfortunate. I guess the necessary consequence of this
is that Unison my dramatically increase the bandwidth needs and
storage needs on the remote side. Imagine synchronizing a 4G
Danek Duvall wrote:
On Fri, Mar 28, 2008 at 12:21:50AM +0100, Roland Mainz wrote:
Can the software be compiled with Sun Studio ?
Read the rest of the mail in the case.
I did it in the meantime (I'm weeks behind my email from ARC... ;-( )
... sorry...
/usr/lib/libIlmImf.so.6.0.0
Roland Mainz wrote:
Danek Duvall wrote:
On Fri, Mar 28, 2008 at 12:21:50AM +0100, Roland Mainz wrote:
[snip]
/usr/lib/libIlmImf.so.6.0.0 Uncommitted openexr library
/usr/lib/libHalf.so.6.0.0Uncommitted Ilmbase library
/usr/lib/libIex.so.6.0.0
Sheng-qi Jiang wrote:
Casper.Dik at Sun.COM wrote:
[snip]
/usr/lib/amd64/libIlmImf.so.6.0.0 Uncommitted openexr
library
/usr/lib/amd64/libHalf.so.6.0.0 Uncommitted Ilmbase
library
/usr/lib/amd64/libIex.so.6.0.0Uncommitted Ilmbase
library
Yan Xue Yang wrote:
Roland Mainz :
Yan Xue Yang wrote:
Roland Mainz :
[snip]
What about filenames with multibyte characters (e.g. chinese characters
using the zh_CN.GB18030 locale or japanese using the ja_JP.PCK locale) ?
How does Unison handle such things ?
It's not documented
Yan Xue Yang wrote:
Roland Mainz :
Yan Xue Yang wrote:
Roland Mainz :
Yan Xue Yang wrote:
Roland Mainz :
[snip]
Which locale did you use (my main interest is whether non-UTF-8
multibyte encodings as used for zh_CN.GB18030 will work or not...) ?
I used zh_CN.UTF-8 for yesterday's testing
Yan Xue Yang wrote:
Alan Coopersmith ?:
Yan Xue Yang wrote:
Alan Coopersmith ?:
Frank Che wrote:
[snip]
It's not documented in the manual. After testing, I confirm unison
doesn't support both ACL's and extended attributes. I think we need to
add this to man page.
What about
Yan Xue Yang wrote:
Roland Mainz :
[snip]
It's not documented in the manual. After testing, I confirm unison
doesn't support both ACL's and extended attributes. I think we need to
add this to man page.
What about filenames with multibyte characters (e.g. chinese characters
using
Frank Che wrote:
Nicolas Williams wrote:
[snip]
I probably shouldn't repeat this, but I am again concerned about
Committed for an application that seems to have a somewhat limited
audience and may itself no longer be actively developed or maintained.
(See
Joep Vesseur wrote:
As Unison is written in Occam, does this case propose to include some
form of Occam compiler as well?
Occam (I'm a bit suprised since I thought most of the legacy of the
Transputer stuff is long long gone (unfortunately)) ?
The occaml compiler normally advertised to
James Carlson wrote:
Roland Mainz writes:
According to the message from the community web site, there is no active
development on this product any more. While bug fixes, small
improvements and contributed patches may come. So I suggested to use
Committed level. If members think
Joep Vesseur wrote:
On 03/25/08 12:44, Roland Mainz wrote:
The occaml compiler normally advertised to
compile Unison with is distributed under the Q-license which might be
a novum for OpenSolaris.
What's the exact problem ? Occam may have some use for Niagara-class
machines...
I
Joerg Schilling wrote:
[snip]
Star's correctness has been tested with various methods. This includes the
Zwicky backup test and self written code to test POSIX compliance and correct
extended dump/restore behavior. The changes that resulted in a directory
/usr/include/schily/ have been
James Carlson wrote:
Roland Mainz writes:
Sarcastic comment of the day: Yeah... I remember how it was done right
([1]) in the case of /usr/bin/ksh ... =:-)
You'll need to try harder to get a plonk. :-/
Erm... for the log: It wasn't my intention to offend anyone... I just
tried to wave
Rod Evans wrote:
Roland Mainz wrote:
Rod Evans wrote:
[snip]
SYNOPSIS
elfdump [-64] [-o relobj-file] [-z target=sparc | x86]
data-file...
Shouldn't this be elfwrap instead of elfdump ? :-)
Yes. Mr. Plocher already beat you to it. Guess what man page template
I used
Rod Evans wrote:
Roland Mainz wrote:
What about adding an option to override basename with a different
string ?
Anything is possible. Initially, I strived for simplicity.
Ok... but a basename option may be usefull to avoid ugly filenames
in the filesystem, e.g. mangled C++ names may
Rod Evans wrote:
I'm sponsoring the following case for myself. This case qualifies for
Architectural self-review, but I wish to record the following
information.
[snip]
User Commands elfwrap(1)
NAME
elfwrap - wrap data in an ELF file
Darren J Moffat wrote:
Roland Mainz wrote:
Darren:
1. Are the changes Ok for you ? If yes I'll post a diff for the ARC
case+manpages...
Yes that is fine.
Ok...
... I've attached the diff as PSARC_2008_094_sum_uses_libmd.diff.txt
and commited the change to my master copies
Glenn Fowler wrote:
On Wed, 13 Feb 2008 05:55:25 +0100 Roland Mainz wrote:
Joseph Kowalski wrote:
Roland Mainz wrote:
The short answer is No. This isn't the way OpenSolaris integration
works.
You did see the comment that I said ... yes, we will do it... ?
We could probably
Darren J Moffat wrote:
Joseph Kowalski wrote:
## Part 1.8: Enable default prompt (PS1) for interactive shells
The 1.8 portion of this project specifies to define a default prompt
(PS1) in /etc/ksh.kshrc for interactive ksh93 shell sessions to
improve end-user usabilty if the user did
John Plocher wrote:
Roland Mainz wrote:
Plocher/jek3:
Is there a way to get the CC: thing fixed for an ARC case which is
already running ?
Done. All mail sent to PSARC-ext@ from now on will automatically
be Bcc'd to ksh93-integration-discuss at opensolaris.org (unless, of
course
Darren J Moffat wrote:
Joseph Kowalski wrote:
[snip]
Part 5: Enhancement of /usr/bin/sum
The 5th part of this project specifies an enhancement to
/usr/bin/sum and a new ksh93 built-in with the same name based on
the ATT AST sum command. The ATT version of the sum utility
provides
Roland Mainz wrote:
Darren J Moffat wrote:
Joseph Kowalski wrote:
[snip]
I had access to a T2000 machine and several Ultra40+45 machines (thanks
to Jesse Silver) at the OpenSolaris Summit 2007 and did some
benchmarking. It seems that the code for the sum builtin (e.g. calling
sum has
Darren J Moffat wrote:
Joseph Kowalski wrote:
[snip]
Part 5: Enhancement of /usr/bin/sum
The 5th part of this project specifies an enhancement to
/usr/bin/sum and a new ksh93 built-in with the same name based on
the ATT AST sum command. The ATT version of the sum utility
provides
Joseph Kowalski wrote:
Roland Mainz wrote:
Please use libmd(3lib) unless there is a very compelling reason not to
do so - if there I would like to see that documented here.
There is no compelling reason, however I would prefer to defer this to
the putback following the one we've
Joseph Kowalski wrote:
Roland Mainz wrote:
Joseph Kowalski wrote:
The short answer is No. This isn't the way OpenSolaris integration
works.
You did see the comment that I said ... yes, we will do it... ?
Yes I did.
We don't integrate what is determined to be the less optional
:
Author: Roland Mainz
1.3 Date of This Document:
08 February, 2008
4. Technical Description
I'm sponsoring this fast-track request on behalf of XXX.
XXX. Hmm. Now is that the father of , or did you
actually mean to specify Roland?
Mea culpa... ;-(
... I forgot to replace
Joseph Kowalski wrote:
James C. McPherson wrote:
I'm sponsoring this fast-track request on behalf of XXX.
XXX. Hmm. Now is that the father of , or did you
actually mean to specify Roland?
Sigh,... third person to note this, all with a somewhat different pun.
Plocher! I need to
[Repost with jek3 at train1.eng.sun.com (seems to be unreachable outside
Sun) replaced with Joseph.Kowalski at eng.sun.com]
Joseph Kowalski wrote:
James C. McPherson wrote:
I'm sponsoring this fast-track request on behalf of XXX.
XXX. Hmm. Now is that the father of , or did you
Danek Duvall wrote:
I'm sponsoring the following fast-track for myself. I'm setting the
time-out to one week from today: November 9, 2007. Release binding is
Patch due to the desire to include this in the S10 updates.
Thanks,
Danek
[snip]
3. Exported Interfaces
SUNWp7zip
Bart Smaalders wrote:
I'm sponsoring the attached arc case (libevent-arc.txt) for
Prakash Sangappa. The requested release binding is patch/micro,
and the case times out next Wednesday.
I will place these materials in the case directory if it is
chgrp'd to sac.
[snip]
4.3 Deliverables
Chris Gerhard wrote:
Roland Mainz wrote:
Darren J Moffat wrote:
[snip]
2. I have great concerns about the abuse of the global environment
variable namespace - sooner or later this will backfire _badly_ if cron
and other applications have slightly different ways to interpret the
values
Chris Gerhard wrote:
Roland Mainz wrote:
Chris Gerhard wrote:
Roland Mainz wrote:
Darren J Moffat wrote:
[snip]
Two issues:
1. You basically assign a double-functionality to the variables - they
affect both cron internal behaviour and they are exported into the
environment
Darren J Moffat wrote:
I'm sponsoring this OpenSolaris case for Chris Gerhard. It has some possible
standards impact but I believe based on previous discussions this should
be acceptable, if it wasn't for the standards impact this would likely have
been self-review.
Template Version:
Ienup Sung wrote:
[snip]
There is no notable imported interfaces. The following are the exported
interfaces:
Interface Stability Reference
uconv_u16tou32(), Consolidation Private [1]
uconv_u16tou8(),
uconv_u32tou16(),
Vladimir Kotal wrote:
James Carlson wrote:
Roland Mainz writes:
4. SuSE Linux 10.0 installs netcat as /usr/bin/netcat
The rest of the issues I think are red herrings, but that one I agree
with.
Vladimir, can you investigate how this is installed on other
platforms? I took
James Carlson wrote:
[snip]
Interfaces
--
This case delivers the following interfaces:
Exported Interfaces:
+-+-+-+
|Interfaces: | Classification: | Comments: |
Nicolas Williams wrote:
On Thu, Jun 28, 2007 at 12:00:07AM +0200, Roland Mainz wrote:
2. IMO the name /usr/bin/netcat would be more descriptive, avoid
namespace collisions (see [1]) and would avoid that the two-letter
namespace in /usr/bin/ gets even more spammed by specialist tools (e.g
James Carlson wrote:
Roland Mainz writes:
4. SuSE Linux 10.0 installs netcat as /usr/bin/netcat
The rest of the issues I think are red herrings, but that one I agree
with.
Erm... I would not be happy if the introduction of netcat as nc
ruins nedit...
... and IMO it is better to use long
Roland Mainz wrote:
Stephen Hahn wrote:
[snip]
3.1. Non-conflicting commands.
/usr/bin/
[
base64
dir
dircolors
| ginstall
| md5sum
pinky
printenv
ptx
readlink
Erm... I missed
Glenn Fowler wrote:
On Thu, 28 Jun 2007 03:54:46 +0200 Roland Mainz wrote:
readlink
Erm... I missed this part... GNU readlink collides with the AST
readlink command and the ksh93 builtin version... is there still a way
to move this to /usr/gnu/ ?
ast doesn't have a readlink
Gary Winiger wrote:
(Getting used to new sac_nextcase...)
I'm sponsoring the nano case for myself. It seeks Patch binding.
The spec never made it to the mail file. I'm including it here.
Gary..
PSARC/2007/366
Include GNU nano 2.0.6
Stephen Hahn (sch
Erik Nordmark wrote:
Nicolas Williams wrote:
I understand that the original customer for this never used it and that
parts of Solaris' Mobile IP support are broken. But, are there really
no real or potential users of / uses for mobile IP in Solaris?
It isn't just that it is untested
James Carlson wrote:
Joseph Kowalski writes:
April Chin wrote:
[snip]
I'm more than willing to leave the metacluster assignments (if any)
out of the case, and work with the team (and the gate staff) offline
to make sure the right thing happens.
Is that acceptable?
Yes...
... note that
Joseph Kowalski wrote:
[snip]
James Carlson wrote:
The stability of the getconf built-in command-line interface and the
system variables documented in getconf(1) is Committed; its pathname
binding to /bin is Volatile. The getconf built-in supports additional
system variables not
James Carlson wrote:
Joseph Kowalski writes:
[snip]
A new package for AST (Advanced Software Technology) developer tools,
SUNWastdev, will be created, which includes all of the above
message-building components. These tools have a dependency on ksh93
and its libraries, as listed in
April Chin wrote:
[snip]
Aside: For those who don't know, I personally view the FSH document to
be one of the
worst specifications ever created, but there are zelots out there who
think it was
written on stone tablets. Sigh,...
If the interface stability level of the shared libraries
Joseph Kowalski wrote:
Roland Mainz wrote:
[snip]
Maybe I'm just confused, but this seems to be a good explanation why
/usr/bin/getconf
can't be a tiny wrapper linking with the library which implements the
builtins for ksh93
(I forgot name of said library - probably blocking
Darren J Moffat wrote:
Template Version: @(#)sac_nextcase %I% %G% SMI
1. Introduction
1.1. Project/Component Working Name:
lofi(7d) crypto support
1.2. Name of Document Author/Supplier:
Author: Darren Moffat
1.3 Date of This Document:
02
Joseph Kowalski wrote:
From: Richard Lowe richlowe at richlowe.net
...
(I do still harbour some concern regarding any future ksh(1) or sh(1)
migration, however, but that's another case).
Very interesting question.
Don (as in Cragun), would having a default edit mode for ksh93
Josh Hurst wrote:
On 10/18/06, Bernd Finger Bernd.Finger at sun.com wrote:
Casper,
Casper.Dik at Sun.COM wrote:
I think I have to side with Roland; I use vi to edit but use
emacs mode exclusively for command lined editing.
The only intuitive editing I can think of is the use of
Josh Hurst wrote:
On 10/18/06, James Carlson james.d.carlson at sun.com wrote:
Josh Hurst writes:
Unfortunately I have to add a general note here:
Please direct the flames at /dev/null. They are of no use here.
Please understand that I am trying to start a generalised discussion
Casper.Dik at Sun.COM wrote:
[snip]
In the particular case of /etc/ksh.kshrc, we have several reasons for these
discussions:
- we introduce a file which is always read by ksh
Minor correction: Is is read by all interactive ksh93 shell sessions.
- nice for system
Dan Price wrote:
[snip]
My thought is that we should revamp all of the interactive shell defaults
to have consistent (across the shells) and excellent default interactive
settings, with useful prompts and default behaviors whereever possible.
And yes, we should do so judiciously, with all due
John Plocher wrote:
Nit: With this proposal, we will have the following shell config files
living in /etc:
/etc/profile
/etc/suid_profile
/etc/.login
/etc/ksh.kshrc
/etc/default/su
Where does the name ksh.kshrc come from? I'm worried that we
Alan Coopersmith wrote:
Don Cragun wrote:
This case proposes to introduce the new file /etc/ksh.kshrc to the
system, as a per-system configuration file for interactive ksh93 (Korn
Shell).
Will this file be used by the existing ksh88-based shells in Solaris?
(/usr/bin/ksh,
Joseph Kowalski wrote:
gmacs is considered an intuitive beginner's editing mode. It is the
default editing mode in bash and more or less matches the common input
mode of various GUI toolkits and desktops, including Gnome/GTK+,
KDE/Qt, CDE/Motif, Mozilla/XULRunner/Gecko, JAVA, and
Joseph Kowalski wrote:
From: Joseph Kowalski Joseph.Kowalski at eng.sun.com
..
gmacs is considered an intuitive beginner's editing mode. It is the
default editing mode in bash and more or less matches the common input
mode of various GUI toolkits and desktops, including Gnome/GTK+,
Joseph Kowalski wrote:
From: Roland Mainz roland.mainz at nrubsig.org
...
Umpf... because the ksh93 default is that no editor mode is enabled,
leaving beginners completely puzzled how to proceed.
So, insted we send these beginners off believing that gmacs is the way
it is. I don't
Richard Lowe wrote:
Joseph Kowalski wrote:
gmacs is considered an intuitive beginner's editing mode. It is the
default editing mode in bash and more or less matches the common input
mode of various GUI toolkits and desktops, including Gnome/GTK+,
KDE/Qt, CDE/Motif,
Joseph Kowalski wrote:
[snip]
I was prepaired to go with the flow, until I saw Richard Lowe's mail.
It appears that defaults of gmacs, vi and none are equally prevalent
in other systems. If we want to help the newbee, being consistant across
systems is the best way to accomplish that. Since
Joseph Kowalski wrote:
From: Roland Mainz roland.mainz at nrubsig.org
...
Well, I hoped that it is somehow possible to have more than one ARC case
for the ksh93-integration, e.g. put this version back, collect user
feedback and then implementARC the necessary suggestions/changes
Darren J Moffat wrote:
Roland Mainz wrote:
Darren J Moffat wrote:
I did agree (and put it in email) that ksh93 is actually better in this
case since there is a way to turn off the builtins. Where I don't agree
is that the writer of the script should have to know to do that when
ksh93
Joseph Kowalski wrote:
From: Roland Mainz roland.mainz at nrubsig.org
Joseph Kowalski wrote:
...
From: Roland Mainz roland.mainz at nrubsig.org
...
No argument here, except the IMHO dtksh is more than half-broken. 8^)
Well, I offered to fix it. The solution
Alan Coopersmith wrote:
Roland Mainz wrote:
Well, I offered to fix it. The solution to almost all of the problems is
to rip-out the ksh93d- alpha basis of ksh93 and replace it with a more
recent version (that was at least the cure for HP/UX). And I am still
wondering why it is so
Darren J Moffat wrote:
Roland Mainz wrote:
Darren J Moffat wrote:
[snip]
On the other hand given that you already have to modify the code to have
pfexec used it doesn't seem unreasonable to make it work as the user
expects. I'd be happy to work with you offline to investigate how
Darren J Moffat wrote:
Roland Mainz wrote:
However there are multiple workarounds (already described in other
postings here (e.g. use fully qualified path, an alias to the full path
etc.)) and AFAIK at least the following solutions:
1. pfksh93 checks whether there is a RBAC entry
Joseph Kowalski wrote:
From: Roland Mainz roland.mainz at nrubsig.org
...
No argument here, except the IMHO dtksh is more than half-broken. 8^)
Well, I offered to fix it. The solution to almost all of the problems is
to rip-out the ksh93d- alpha basis of ksh93 and replace
Glenn Fowler wrote:
On Mon, 25 Sep 2006 15:41:07 -0400 James Carlson wrote:
April Chin writes:
[snip]
Whatever bit of text documents this path (the original case proposed
Volatile stability for the /usr/ast/bin mechanism, which means it's
a public interface) should note that it may cause
James Carlson wrote:
[snip]
maybe for now pf should trump all builtins but the ones already allowed
whether by /usr/ast/bin or not
That'd be the least problematic answer.
But IMO it is the wrong solution (see my other emails for details, the
builtin thing is something coming from the POSIX
Felix Schulte wrote:
On 9/26/06, Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
April Chin wrote:
An update from the project team on the pfksh93 issue...
Although some ideas on disabling built-ins for pfksh93
has
Casper.Dik at Sun.COM wrote:
The updated proposal lists the files that will be in root.
Yes, the root files are only libcmd and libast:
/lib/libcmd*, /lib/{amd64,sparcv9}/libcmd*
/lib/libast*, and /lib/{amd64,sparcv9/libast*.
And please make sure it is lazyloaded (libcmd is pulled in by
Nicolas Williams wrote:
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
James Carlson wrote:
Roland Mainz writes:
[snip]
Moreover we will have a bunch of follow-up projects which will quickly
make use of these builtin commands in libshelllibcmd (e.g. we will
likely see the matching ARC case attack your mailinglist within one or
two weeks after the ksh93
John Plocher wrote:
[snip]
Rest assured that everyone I know who is involved in this ksh93
discussion wants the project to succeed. They just want it to succeed
in a way that does the least damage to the existing Open- and
Closed-Solaris systems, and in a way that best provides for the future
Richard Lowe wrote:
[snip]
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?
No, this will not work. The resulting ksh93 binary would no longer be
compatible
Joseph Kowalski wrote:
From: Roland Mainz roland.mainz at nrubsig.org
...
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
Casper.Dik at sun.com wrote:
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
Darren J Moffat wrote:
[snip]
On the other hand given that you already have to modify the code to have
pfexec used it doesn't seem unreasonable to make it work as the user
expects. I'd be happy to work with you offline to investigate how much
code change it would be to have the appropriate
James Carlson wrote:
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
James Carlson wrote:
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
Joerg Schilling 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.
The name 'cmd' is a well known location to find
James Carlson wrote:
[snip]
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 to that
separate directory, and there'd be no conflict.
libcmd is not
I. Szczesniak wrote:
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
James Carlson wrote:
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/
James Carlson wrote:
[snip]
... which brings me back to my original unanswered question: is
-lcmd and the set of functions therein something that will be
documented as an interface via man pages for third parties to use?
Yes, we're planning to make these interfaces public (with the usual
James Carlson wrote:
[snip]
So, clearly, the project team appears to believe:
- that libcmd.so needs to be in /lib or /usr/lib
Correct.
- that there will be applications outside of ksh that will link to
this library in order to avoid fork+exec or spawn overhead
Correct.
- that
Nicolas Williams wrote:
[snip]
None of that sounds like Private to me, though I'd still very much
like to see this library *be* Private.
How stable would this be anyways?
The |b_*()| functions and their C prototypes are AFAIK stable since at
least ten years and there is no need to change
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 be a rename of libcmd nor a move of it's location (e.g.
moving
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
101 - 200 of 224 matches
Mail list logo
