More ksh93 builtins
[Removed the case id, since this is off-topic for the case which isn't currently on the table for discussion anyway.] Garrett D'Amore wrote: > I'm also of the opinion that it is a mistake to sacrifice familiarity > for our paying Solaris 10 customers in favor of familiarity for people > coming from Linux. But clearly all our paying Solaris 10 customers already have dotfiles to set $PATH, given how useless the default Solaris 10 $PATH is. They get familiarity by continuing to use those - the default PATH with /usr/gnu/bin first only affects those setting up new accounts who don't have existing Solaris .dotfiles, which seems like a very reasonable compromise. Also rememeber the PATH default is set only in text files which are trivially editable by users with experience from previous Solaris releases - it's not baked into the kernel. > Which group do you think contributes more towards > the $$ that pay our salaries? Sounds like an invalid question for PSARC-ext & shell-discuss at opensolaris.org. -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On Fri, Mar 19, 2010 at 04:08:09PM -0700, Garrett D'Amore wrote: > I'd rather see us modernize our own tools. I resent abdication of > our own engineering, and the necessity of abandoning all good > innovations (like shell builtins) because some people feel its > critical that the only way to achieve these goals is to provide > these 3rd party tools. Its more offensive to me specifically > because there is no good reason why we can't use tools from the > ksh93 community (who seems to be a lot more willing to work with us > on key engineering issues than the GNU folks who are mostly fixated > on Linux) to achieve this. Instead of re-inventing the wheel at every opportunity, it makes more sense to take the open source projects that have wide acceptance and incorporate them into our product. I think that both ksh93 and gnu fall into this category. It's much better for us to focus our engineering efforts on areas where we can actually differentiate our product from our competitors. I don't have a problem with ksh93 or the builtins, nor am I advocating an entirely GNU userland. What I am suggesting, however, is that the folks who decided to put /usr/gnu in the default path did talk to our customers, and also took note of the fact that Linux is widely adoped across the industry. > I'm also of the opinion that it is a mistake to sacrifice > familiarity for our paying Solaris 10 customers in favor of > familiarity for people coming from Linux. This is a false dilemma. It should be entirely possible for customers to configure whatever default path they desire and deploy that in their enterprise via AI. > Which group do you think contributes more towards the $$ that pay our > salaries? I would love to argue this point with you, but it's not appropriate to discuss it on a public mailing list. -j
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On 03/19/10 03:52 PM, johansen at sun.com wrote: > On Fri, Mar 19, 2010 at 08:13:48AM -0700, Garrett D'Amore wrote: > >> The fact that we have to put /usr/gnu at the head of $PATH of new >> users is a bit of a travesty, and I'm of the opinion that we should >> reexamine *that* particular decision... >> > This is merely one opinion. There are compelling business and > architecture cases for having the default userland be approachable by > the majority of users of other popular unix-like operating systems. The > /usr/gnu isn't the default in my path either, but it makes a lot of > sense to present a userland that's familiar to users of Linux, and > similar environments. > Approachable (and even familiar) does not necessarily == /usr/gnu. It does mean having the main command flags work the same way that people coming from foreign environments (and not just Linux, but also *BSD and maybe other platforms like AIX or HPUX) are used to. > Anyone is free to create a distro with a different default shell, or > default path. Anyone is free to change their path as well as their > shell. Your fixation on /usr/gnu's presence in the default path isn't > productive. Why make it harder to get users from Linux and elsewhere to > adopt Solaris? > I'm not proposing that it should be. I'm proposing that putting /usr/gnu first is not necessarily the only way to achieve that goal. I'd rather see us modernize our own tools. I resent abdication of our own engineering, and the necessity of abandoning all good innovations (like shell builtins) because some people feel its critical that the only way to achieve these goals is to provide these 3rd party tools. Its more offensive to me specifically because there is no good reason why we can't use tools from the ksh93 community (who seems to be a lot more willing to work with us on key engineering issues than the GNU folks who are mostly fixated on Linux) to achieve this. I'm also of the opinion that it is a mistake to sacrifice familiarity for our paying Solaris 10 customers in favor of familiarity for people coming from Linux. Which group do you think contributes more towards the $$ that pay our salaries? > >> ... in which case much of the motivation behind *this* case comes into >> question. (If /usr/gnu isn't the default for most users, then there >> is little motivation to provide builtin wrappers for them.) >> > I disagree. Modulo the issues about the profile shell, I see no reason > why it matters that the ARC delve into the minutia of shell builtins. > In general, that's an implementation or configuration detail of the shell. > I guess reasonable people can disagree here. The points have been made that these drop ins are not 100% compatible drop ins... they have ever so slightly differing interfaces. While normal folks should not care about the differences (they are so tiny, like the format of --version's output), there are situations where it can matter. That makes it a matter of concern for ARC. > I would recommend against derailing this case in favor of one about a > grand shell [re-]architecture. We should be making it easier add > different shells for Solaris. Using this case as an opportunity to rail > about Gnu is just divisive. > The case isn't derailed. Its waiting need spec. At the (more or less) request of the upstream technology supplier. - Garrett
libgdata [PSARC/2010/092 timeout 03/24/2010]
On 03/18/10 02:34 AM, Danek Duvall wrote: > Jerry Tan wrote: > > >> I will list "Desktop/library/libgdata" as its ips name in interface table. >> > Please follow the pattern of the rest of the libraries: > > pkg:/library/libgdata > > This library is in no way useful only in a desktop context. > > Thanks, > Danek > Thanks, I will change it to pkg:/library/libgdata -- next part -- An embedded and charset-unspecified text was scrubbed... Name: libgdata.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20100319/c101356d/attachment.txt>
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On Fri, Mar 19, 2010 at 08:13:48AM -0700, Garrett D'Amore wrote: > The fact that we have to put /usr/gnu at the head of $PATH of new > users is a bit of a travesty, and I'm of the opinion that we should > reexamine *that* particular decision... This is merely one opinion. There are compelling business and architecture cases for having the default userland be approachable by the majority of users of other popular unix-like operating systems. The /usr/gnu isn't the default in my path either, but it makes a lot of sense to present a userland that's familiar to users of Linux, and similar environments. Anyone is free to create a distro with a different default shell, or default path. Anyone is free to change their path as well as their shell. Your fixation on /usr/gnu's presence in the default path isn't productive. Why make it harder to get users from Linux and elsewhere to adopt Solaris? > ... in which case much of the motivation behind *this* case comes into > question. (If /usr/gnu isn't the default for most users, then there > is little motivation to provide builtin wrappers for them.) I disagree. Modulo the issues about the profile shell, I see no reason why it matters that the ARC delve into the minutia of shell builtins. In general, that's an implementation or configuration detail of the shell. I would recommend against derailing this case in favor of one about a grand shell [re-]architecture. We should be making it easier add different shells for Solaris. Using this case as an opportunity to rail about Gnu is just divisive. -j
idmap: default unresolvable SID mapping to true [PSARC/2010/097 FastTrack timeout 03/26/2010]
Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: idmap: default unresolvable SID mapping to true 1.2. Name of Document Author/Supplier: Author: Jordan Brown 1.3 Date of This Document: 19 March, 2010 4. Technical Description SUMMARY PSARC 2008/408 introduced config/unresolvable_sid_mapping, a SMF parameter to control treatment of SIDs that cannot be looked up, with a default of false. This case proposes to change the default to true. BACKGROUND Windows Security IDs (SIDs) fill the same role as UIDs and GIDs. Solaris supports them by dynamically mapping them to UNIX IDs using a variety of techniques, including dynamically allocated "ephemeral" IDs. In some cases, it may not be possible to look up a SID during the mapping process. The existing default behavior of idmap is to yield an error in such a case. The unresolvable_sid_mapping flag can be used to change this behavior so that idmap maps unresolvable SIDs to ephemeral IDs. The SunStorage 7000 series of storage appliances, the most visible and widely used platform for Solaris Windows interoperability, sets the unresolvable_sid_mapping flag to true. PROBLEM The same interoperability concerns that drove the SS7000 series to set this flag true apply equally to generic Solaris, and the difference in configuration between the two platforms can lead to confusion and requires duplicated testing. PROPOSAL Interpret a missing config/unresolvable_sid_mapping property as "true" instead of "false". The property remains undocumented, but available if necessary to force the old behavior. DELIVERY VEHICLE Solaris RELEASE Minor (as part of the ongoing OpenSolaris stream) COMMITMENT LEVEL The behavior - supporting unresolvable SIDs - is Committed. The mechanism - config/unresolvable_sid_mapping - is Project Private. REFERENCE DOCUMENTS PSARC 2008/408 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
Removing MySQL 4.0 from OpenSolaris [PSARC/2010/088 FastTrack timeout 03/18/2010]
The timer has passed, there was at least one +1, there are no open issues and nobody derailed, so I am marking this closed approved. On 03/11/10 11:23, Brian Utterback wrote: > I am sponsoring this fasttrack on behalf of Lukas Rovensky. Binding is patch. > Time > out is 03/18/2010. > > Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI > This information is Copyright 2010 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: >Removing MySQL 4.0 from OpenSolaris > 1.2. Name of Document Author/Supplier: >Author: Lukas Rovensky > 1.3 Date of This Document: > 11 March, 2010 > 4. Technical Description > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2010 Sun Microsystems > 1. Introduction > 1.1 Project/Component Working Name: > Removing MySQL 4.0 from OpenSolaris > > 1.2 Name of Document Author/Supplier: > Author: Sunanda Menon (original author) > Lukas Rovensky (current author) > > 1.3 Date of This Document: > 10 March, 2010 > > 1.4 Introduction > > This FastTrack will EOL the MySQL 4.0 from OpenSolaris and obsolete > MySQL 4.0 interfaces in Solaris 10. > > All products and users should migrate to 5.1, as MySQL 4.0 is an end > of life product. > > 1.5 Previous Relevant ARC cases > > LSARC/2004/324 - SIP Proxy Server > LSARC/2009/062 - Including MySQL 5.1 with Solaris > > 2. Technical issues > > 2.1 Changes to existing code > > All references to MySQL 4.0 in the SIP Express Router (SER) will be > updated to reference to the new location at /usr/mysql. See > CR 6799158, [3], which addresses this task. > > 2.2 Upgrade procedure for existing users of SER > > After the new SER packages are installed then the database > upgrade procedure on MySQL pages: > http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-4-0.html > http://dev.mysql.com/doc/refman/5.0/en/upgrade.html > http://dev.mysql.com/doc/refman/5.1/en/upgrade.html > need to be followed on current installations, to ensure that the tables > created with /etc/sfw/ser/ser_mysql.sh will be upgraded to the current > MySQL version. > > New SER users can use the set up procedure described at [2]. > Certainly, the way MySQL 5.1 is installed and run differs from > Solaris 10 and MySQL 5.1 man pages should be referred. > > 2.3 Risks and Assumptions > > All MySQL 4.0 users/products will have been updated to use 5.1 by > the time Solaris Next ships. It is also expected that SER will not > be part of Solaris Next, since in accordance with its project > pages, [4], SER developers joined SIP Router project, [5], and > SER itself is no longer developed. Having a dead open source > product included in Solaris Next does not make sense. Should > a SIP router like product be part of Solaris Next then most likely > SIP Router, [5], shall replace SER, [4]. > > 2.4 SMF > > No changes as MySQL 4.0 does not have any smf support. > > 3. Documentation > > SER documentation on [2] may be upgraded supposing SIP/ser > stays in OpenSolaris / Solaris Next, see section 2.3. Note, > that for Solaris 10 this document is still valid. > > Obsoleting MySQL 4 interfaces in Solaris 10 will be announced > in release notes for Solaris 10. MySQL 4 man page in Solaris 10 > needs to be updated to reflect this change -- Interface Stability > will be set to "External, Obsolete". > > 4. Packaging and Delivery > > SUNWmysqlr, SUNWmysqlu and SUNWmysqlt packages will be removed. > > 5. Interfaces > > All the interfaces described below will be obsoleted in Solaris 10. > > MySQL 4.0 binaries from /usr/sfw/bin will be removed: >mysqladmin >mysqlcheck >mysqlshow >mysqldump >mysqlimport >mysqlbinlog >mysqlmanagerc >mysqlmanager-pwgen >replace >comp_err >perror >resolveip >my_print_defaults >resolve_stack_dump >mysql_install >mysql_waitpid >isamchk >isamlog >pack_isam >myisamchk >myisamlog >myisampack >mysql_install_db >make_win_src_distribution >msql2mysql >mysql_config >mysql_fix_privilege_tables >mysql_fix_extensions >mysql_setpermission >mysql_secure_installation >mysql_zap >mysqlaccess >mysqlbug >mysql_convert_table_format >mysql_find_rows >mysqlhotcopy >mysqldumpslow >mysql_explain_log >mysql_tableinfo >mysqld_multi >mysqlmanager > > MySQL 4.0 libraries from /usr/sfw/lib will be removed: >/usr/sfw/lib/mysql - entire directory >libmysqlclient.so >libmysqlclient.so.12 >libmysqlclient.so.12.0.0 >libmysqlclient
[shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On Fri, 19 Mar 2010 08:13:48 -0700 Garrett D'Amore wrote: > I am coming to agree. While I'm the sponsor on this case, I'm on the > verge of derailing this case and asking that a new case to examine > userland shell architecture be created. The fact that we have to put > /usr/gnu at the head of $PATH of new users is a bit of a travesty, and > I'm of the opinion that we should reexamine *that* particular decision, > in which case much of the motivation behind *this* case comes into > question. (If /usr/gnu isn't the default for most users, then there is > little motivation to provide builtin wrappers for them.) > I'd rather see ksh93 based utilities (or rather libcmd based) with all > the bells and whistles delivered into /usr/bin or perhaps /usr/ksh93/bin > (and put at the head of $PATH) and leave /usr/gnu as a dumping ground > for people who insist that they want GNU warts. dgk are discussing this right now we had somehow missed the detail that the proposed ksh builtin binding dir is "/usr/gnu/bin" just because a libcmd builtin handles some gnu options does not make it gnu there are most likely gnu features that libcmd builtins will never implement e.g., the gnu getopt(3) "feature" that allows options to appear after operands once we solidify the ideas where should we post, and under what subject? -- Glenn Fowler -- at&t Research, Florham Park NJ --
OpenSolaris ARC Agenda - March 24, 2010
http://hub.opensolaris.org/bin/edit/Community+Group+arc/ARCAgenda/ = OpenSolaris ARC Agenda = TELECONFERENCE NUMBERS: (866)545-5223 (Within US) (215)446-3661 (International) ACCESS CODE 939-55-86 Times are US/Pacific Timezone ARC meetings are recorded. 03/24/2010 10 minutes Open ARC Business (use open dial in above) Fast-tracks: Case (Timeout) Title 2010/078 (03/09/10) xgrep 2010/084 (03/17/10) Perl Crypt bindings for OpenSSL 2010/086 (03/17/10) open source sed 2010/087 (03/18/10) EOL of the MySQL 5.0 from OpenSolaris 2010/092 (03/24/10) libgdata 2010/093 (03/24/10) Apache 1.3 removal 2010/094 (03/25/10) Locale Services Library 2010/096 (03/25/10) Public Audio DDI
OpenSolaris ARC Agenda - March 24, 2010
http://hub.opensolaris.org/bin/edit/Community+Group+arc/ARCAgenda/ = OpenSolaris ARC Agenda = TELECONFERENCE NUMBERS: (866)545-5223 (Within US) (215)446-3661 (International) ACCESS CODE 939-55-86 Times are US/Pacific Timezone ARC meetings are recorded. 03/24/2010 10 minutes Open ARC Business (use open dial in above) Fast-tracks: Case (Timeout) Title 2010/078 (03/09/10) xgrep 2010/084 (03/17/10) Perl Crypt bindings for OpenSSL 2010/086 (03/17/10) open source sed 2010/087 (03/18/10) EOL of the MySQL 5.0 from OpenSolaris 2010/092 (03/24/10) libgdata 2010/093 (03/24/10) Apache 1.3 removal 2010/094 (03/25/10) Locale Services Library 2010/096 (03/25/10) Public Audio DDI
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On 03/19/10 07:19 AM, Sebastien Roy wrote: > Norm, > > On 03/19/10 04:34 AM, Norm Jacobs wrote: >> I think that in part, I misread this: >>> Interface Stability Description >>> - - --- >>> ksh93 '/usr/gnu/bin/basename' built in Uncommitted basename utility >>> with GNU extensions > ... >> to mean that >> >> $ ksh93 -c "/usr/gnu/bin/basename" >> >> would use the ksh93 basename built-in, which supports GNU extensions. >> Though that does seem in conflict with the paragraph that precedes the >> table. I gather that it means that >> >> $ PATH=/usr/gnu/bin:/usr/bin /usr/bin/ksh93 -c "basename" >> >> will use the ksh93 basename built-in, which happens to support GNU >> extensions. > > Correct: Fully qualified command names do not use built-ins. This is > specified by 2006/550. > >>> Given that the shell honors compatibility within each of the >>> applicable paths for which it provides built-in bindings, there >>> doesn't seem to be any issue regarding "compatible behavior". >> >> If ksh93 built-ins are really drop-in replacements for the interfaces >> they intend on interposing on under ksh93 (/usr/bin, /usr/xpg4, >> /usr/gnu, ...), then we should be delivering a wrapper/link to the ksh93 >> version so that we have consistency regardless of shell/execution >> environment. It could be the intention of this case and that I just >> missed it in my read through. If they are direct replacements, then they >> should use delivered as such. If they are not direct replacements, then >> they should probably not be used in place of their intended target under >> ksh93 only. >> >> This may also have some added benefit in helping us be able to better >> deal with conflict/divergence down the road. > > Yes, that's a good point, and perhaps that can be looked into in the > future. However, I think this discussion is veering off-topic for > this case, as you're now debating the implementation and architecture > of the shell built-ins in general, which is not being introduced by > this case. That was introduced by PSARC 2006/550. This case is > building upon previously approved architecture. > Perhaps I delve slightly into implementation detail here, but the issue of consistency is something that needs to be addressed here and now, not wait for the future. -Norm
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On 03/19/10 08:13, Garrett D'Amore wrote: > I'd rather see ksh93 based utilities (or rather libcmd based) with all > the bells and whistles delivered into /usr/bin or perhaps /usr/ksh93/bin > (and put at the head of $PATH) and leave /usr/gnu as a dumping ground > for people who insist that they want GNU warts. Perhaps you could leave the pejoratives out next time; it really doesn't add anything to the discussion. Like it or not, a significant number of our customers (and a larger number of those we'd like to have as customers) are familiar and accustomed to the GNU commands; referring to their environment of choice as "warts" and "dumping ground" does nothing useful. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaalders at oracle.comhttp://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
[shell-discuss] More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On 03/19/10 08:27 AM, Glenn Fowler wrote: > On Fri, 19 Mar 2010 08:13:48 -0700 Garrett D'Amore wrote: > >> I am coming to agree. While I'm the sponsor on this case, I'm on the >> verge of derailing this case and asking that a new case to examine >> userland shell architecture be created. The fact that we have to put >> /usr/gnu at the head of $PATH of new users is a bit of a travesty, and >> I'm of the opinion that we should reexamine *that* particular decision, >> in which case much of the motivation behind *this* case comes into >> question. (If /usr/gnu isn't the default for most users, then there is >> little motivation to provide builtin wrappers for them.) >> > >> I'd rather see ksh93 based utilities (or rather libcmd based) with all >> the bells and whistles delivered into /usr/bin or perhaps /usr/ksh93/bin >> (and put at the head of $PATH) and leave /usr/gnu as a dumping ground >> for people who insist that they want GNU warts. >> > dgk are discussing this right now > we had somehow missed the detail that the proposed ksh builtin binding dir > is "/usr/gnu/bin" > > just because a libcmd builtin handles some gnu options does not make it gnu > there are most likely gnu features that libcmd builtins will never implement > e.g., the gnu getopt(3) "feature" that allows options to appear after operands > > once we solidify the ideas where should we post, and under what subject? > Reply to this message. I'm going to put this case on waiting-needs-spec. My guess is that ultimately the thing to do will be to "not" override the GNU builtins, because you're not providing truly 100% compatible drop-ins. (And it sounds like unless you're willing to introduce any bugs that are present in the GNU versions, you never will be.) - Garrett
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
Norm, On 03/19/10 04:34 AM, Norm Jacobs wrote: > I think that in part, I misread this: >> Interface Stability Description >> - - --- >> ksh93 '/usr/gnu/bin/basename' built in Uncommitted basename utility >> with GNU extensions ... > to mean that > > $ ksh93 -c "/usr/gnu/bin/basename" > > would use the ksh93 basename built-in, which supports GNU extensions. > Though that does seem in conflict with the paragraph that precedes the > table. I gather that it means that > > $ PATH=/usr/gnu/bin:/usr/bin /usr/bin/ksh93 -c "basename" > > will use the ksh93 basename built-in, which happens to support GNU > extensions. Correct: Fully qualified command names do not use built-ins. This is specified by 2006/550. >> Given that the shell honors compatibility within each of the >> applicable paths for which it provides built-in bindings, there >> doesn't seem to be any issue regarding "compatible behavior". > > If ksh93 built-ins are really drop-in replacements for the interfaces > they intend on interposing on under ksh93 (/usr/bin, /usr/xpg4, > /usr/gnu, ...), then we should be delivering a wrapper/link to the ksh93 > version so that we have consistency regardless of shell/execution > environment. It could be the intention of this case and that I just > missed it in my read through. If they are direct replacements, then they > should use delivered as such. If they are not direct replacements, then > they should probably not be used in place of their intended target under > ksh93 only. > > This may also have some added benefit in helping us be able to better > deal with conflict/divergence down the road. Yes, that's a good point, and perhaps that can be looked into in the future. However, I think this discussion is veering off-topic for this case, as you're now debating the implementation and architecture of the shell built-ins in general, which is not being introduced by this case. That was introduced by PSARC 2006/550. This case is building upon previously approved architecture. -Seb
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On 03/19/10 07:58 AM, Norm Jacobs wrote: > >> Yes, that's a good point, and perhaps that can be looked into in the >> future. However, I think this discussion is veering off-topic for >> this case, as you're now debating the implementation and architecture >> of the shell built-ins in general, which is not being introduced by >> this case. That was introduced by PSARC 2006/550. This case is >> building upon previously approved architecture. >> > > Perhaps I delve slightly into implementation detail here, but the > issue of consistency is something that needs to be addressed here and > now, not wait for the future. I am coming to agree. While I'm the sponsor on this case, I'm on the verge of derailing this case and asking that a new case to examine userland shell architecture be created. The fact that we have to put /usr/gnu at the head of $PATH of new users is a bit of a travesty, and I'm of the opinion that we should reexamine *that* particular decision, in which case much of the motivation behind *this* case comes into question. (If /usr/gnu isn't the default for most users, then there is little motivation to provide builtin wrappers for them.) I'd rather see ksh93 based utilities (or rather libcmd based) with all the bells and whistles delivered into /usr/bin or perhaps /usr/ksh93/bin (and put at the head of $PATH) and leave /usr/gnu as a dumping ground for people who insist that they want GNU warts. -- Garrett
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On 03/18/10 09:54 PM, Sebastien Roy wrote:
> Norm,
>
> On 03/18/10 07:57 PM, Norm Jacobs wrote:
>> It's not that I don't think that the ksh93 built-ins have a place and
>> that they couldn't be a perfectly reasonable default for most people. In
>> some cases, they seem to provide something that is sorely needed in the
>> Solaris userland, a blend of POSIX conforming and GNUish commands.
>
> I'm afraid I don't understand your initial point. That's not what the
> ksh93 shell built-ins provide. $PATH is still honored, and the
> built-ins are compatible with the commands that are resolved from
> $PATH. You do not suddenly get a blend of POSIX and GNU commands.
I guess I just assumed that there would be one ksh93 built-in here for
something like basename and that it would take the same arguments and
function the same regardless of whether ksh93 were executing it in place
of the /usr/gnu, /usr/xpg4, or /usr/bin version. Perhaps that's not the
case.
> I believe that architecture introduced by PSARC 2006/550 maintains
> the semantics of $PATH by binding a built-in to a pathname, and only
> executing a built-in when a $PATH search matches the binding.
Perhaps I am misunderstanding this part of the current case.
> Part 1: ksh93 built in mappings for /usr/gnu/bin utilities
> --
> The case proposes to enable the following mappings to ksh93 built in
> commands for utilities in /usr/gnu/bin. When the utility is called
> using it's command name, and not the full path, the ksh93 builtin
> will be used instead of executing the /usr/gnu/bin binary.
>
As I understand that statement
$ PATH=/usr/gnu/bin:/usr/bin /usr/bin/ksh93 -c "basename --version"
and
$ PATH=/usr/gnu/bin:/usr/bin
/usr/bin/{your-favorite-non-ksh93-shell} -c "basename --version"
will return different results. Given that I explicitly put /usr/gnu/bin
at the front of the PATH in the examples, I would expect
/usr/gnu/bin/basename warts and all. Though perhaps it's only slightly
different and perhaps slightly better than the shell built-in bits that
are things like test, echo, ...
I think that in part, I misread this:
> Interface StabilityDescription
> - ----
> ksh93 '/usr/gnu/bin/basename' built in Uncommitted basename utility
> with GNU extensions
> ksh93 '/usr/gnu/bin/cksum' built in Uncommitted cksum utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/comm' built in Uncommitted comm utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/cut' built in Uncommitted cut utility with GNU
> extensions
> ksh93 '/usr/gnu/bin/dirname' built in Uncommitted dirname utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/expr' built in Uncommitted expr utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/fold' built in Uncommitted fold utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/join' built in Uncommitted join utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/logname' built in Uncommitted logname utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/mkdir' built in Uncommitted mkdir utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/mkfifo' built inUncommitted mkfifo utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/mktemp' built inUncommitted mktemp utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/pathchk' built in Uncommitted pathchk utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/paste' built in Uncommitted paste utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/sleep' built in Uncommitted sleep utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/sync' built in Uncommitted sync utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/tee' built in Uncommitted tee utility with GNU
> extensions
> ksh93 '/usr/gnu/bin/tty' built in Uncommitted tty utility with GNU
> extensions
> ksh93 '/usr/gnu/bin/uniq' built in Uncommitted uniq utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/rmdir' built in Uncommitted rmdir utility with
> GNU extensions
> ksh93 '/usr/gnu/bin/wc' built inUncommitted wc utility with GNU
> extensions
to mean that
$ ksh93 -c "/usr/gnu/bin/basename"
would use the ksh93 basename built-in, which supports GNU extensions.
Though that does seem in conflict with the paragraph that precedes the
table. I gather that it means that
$ PATH=/usr/gnu/bin:/usr/bin /usr/bin/ksh93 -c "basename"
will use the ksh93 basename built-in, which happens to support GNU
extensions.
>>
>> For several paths on the system, customers expect certain behaviour
>> /usr/xpg4 XPG4 compatible behaviour
>> /usr/xpg6 XPG6 compatible behaviour
>> /usr/gnu GNU/Linux compatible behaviour
>> /usr/ucb SunOS/BSD 4.X behaviour
>> /usr/5bin SVR3 compatible behaviou
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
On 18/03/2010 23:57, Norm Jacobs wrote: > For several paths on the system, customers expect certain behaviour > /usr/xpg4 XPG4 compatible behaviour > /usr/xpg6 XPG6 compatible behaviour > /usr/gnu GNU/Linux compatible behaviour > /usr/ucb SunOS/BSD 4.X behaviour > /usr/5bin SVR3 compatible behaviour standards(5) mandates specific directory paths for different levels of POSIX etc compliance. I'm not clear how this 'hidden override' mechanism impacts that, an explanation would be helpful. And I don't see any mention of /usr/xpg6/bin in there either. -- Alan Burlison --
