|
Replies:
150
-
Last Post:
Oct 3, 2006 5:42 PM
by: Don Cragun
|
|
|
Don Cragun
don.cragun@sun.com
|
|
|
|
Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 9:41 AM
|
|
Subject: PSARC-EXT FastTrack [09/27/2006]: Korn Shell 93 Integration
Note that this is an open case and the e-mail discussion is being
distributed to addresses outside of Sun...
I am submitting the fast-track case for Roland Mainz (OpenSolaris
contributor) and April Chin (Sun engineer). This case seeks a patch
binding. (The current plan is to integrate into ONNV, but patches to a
Solaris 10 Update and Solaris 9 are possible if there is sufficient
demand.)
This case times out Wednesday, September 27, 2006. Note that if there
is any significant discussion on this case, I will ask for a short
discussion on this case after the ARC business discussion on September
27th. This will allow Roland and the Open Solaris community to
participate in the discussion.
Sincerely,
Don
Template Version: @(#)sac_nextcase %I% %G% SMI
1. Introduction
1.1. Project/Component Working Name:
Korn Shell 93 Integration
1.2. Name of Document Author/Supplier:
Author: April Chin
1.3 Date of This Document:
20 September, 2006
4. Technical Description
1. Introduction
1.1 Project/Component Working Name
Korn Shell 93 Integration
1.2 Name of Document Author/Supplier:
April Chin (april dot chin at sun dot com)
1.3 Date of this Document:
20 September, 2006
1.4 Name of Major Document Customer(s)/Consumer(s)
1.4.1. The community this proposal comes from
ksh93-integration-discussion at opensolaris dot org
1.4.2. The ARC(s) you expect to review your project:
PSARC
1.5. Email Aliases:
1.5.1. Responsible Manager:
tim dot sparlin at sun dot com
1.5.2. Responsible Engineers:
roland dot mainz at nrubsig dot org
april dot chin at sun dot com
1.5.3. Marketing Manager:
jeff dot mcmeekin at sun dot com
1.5.4. Interest List:
ksh93-integration-discussion at opensolaris dot org
2. Project Summary
2.1 Project Description
This project seeks approval to introduce the latest version of
the open source ksh93, maintained by korn shell creator David Korn
and others at AT&T, into the Solaris system as a new set of binaries.
Supporting AT&T libraries will also be introduced as private shared libraries.
2.2 Risks and Assumptions:
This project is based on an external open source product and may
have dependencies on the development of or the inclusion of
required fixes by the korn shell owners at AT&T.
It is the goal of the project team to keep ksh93 in the Solaris operating
system updated with AT&T's latest version of ksh93 and its supporting
libraries. Thus it will be important to keep Solaris ksh93 source in sync,
including contributing Solaris-specific changes back to the
AT&T source.
There are cases of Solaris-specific functionality, covered under
the CDDL (Common Development and Distribution License), which should
be merged upstream to AT&T source for Solaris-specific builds.
AT&T allows contributions under the condition that only a copyright
may be added to AT&T source. At this time it is unknown if a blanket
licensing agreement will be reached which allows contribution of such
source to AT&T without requiring the addition of the CDDL.
Although this project will introduce ksh93 as binaries separate from
the existing /usr/bin/ksh and /usr/xpg4/bin/sh (the standard shell),
which are both based on ksh88, the eventual goal in one or more future
projects will be to replace both /usr/bin/ksh and the
standard-compliant /usr/xpg4/bin/sh with ksh93. Thus this project
needs to be aware of potential compatibility problems. See COMPAT file
for a list of known incompatibilities between ksh93 and Solaris ksh.
This project will also introduce built-in commands in ksh93, which have
a superset of the functionality of the corresponding Solaris /usr/bin
commands (see Section 4.3 Description). These ksh93 built-in commands
may lead to the future replacement of the source of some existing /usr/bin
commands with the corresponding AT&T code used by the ksh93 built-ins.
Some functionality available in the current Solaris /usr/bin/ksh
or /usr/xpg4/bin/sh is either not fully verified or not fully
implemented in ksh93, including standards conformance.
Although the intention is for ksh93 to be POSIX compliant, it does
not yet meet UNIX98 or UNIX03 standards conformance, that is, ksh93
does not pass the latest OpenGroup Shell and Utilities Verification
Suite, VSC version 5.2.8. This issue will be revisited before
ksh93 replaces /usr/xpg4/bin/sh.
3. Business Summary
3.1 Problem Area
Since at least 1998 (CR 4113420), and especially after AT&T's ksh93 was
open sourced, circa 2000, users have been requesting that Solaris
systems include the latest version of the Korn shell, ksh93, as a
replacement for or alternative to the existing /usr/bin/ksh and
/usr/xpg4/bin/sh, which are both derived from ksh88i.
ksh93s- is under the Common Public License which allows Sun to
freely redistribute a derived verison of ksh93, provided Sun includes
the license terms and does not encumber it with any proprietary changes.
The derived ksh88 we currently ship in /usr/bin/ksh and /usr/xpg4/bin/sh
is encumbered by copyrights which do not allow us to ship
the source through the Open Source Solaris product.
3.2 Market Requester
In addition to Open Solaris users, there have been multiple Change Requests
(CRs):
4113420 *ksh* request for ksh93 integration
many CRs have been closed as duplicates of this CR.
4113420 has many Customer Call records, including those from
Nokia, Lockheed Martin, Lexis Nexis, Bell South, and AT&T.
6332421 Solaris Kornshell outdated
involves a customer trying to port their application from
SUSE Linux to Solaris 10 and running into problems with
existing ksh93 scripts.
3.3 Justification
ksh88 is out dated and considered obsolete by many. The current version
of the Solaris ksh is not even considered ksh88 compatible, since its
behavior has diverged significantly from the original AT&T ksh88.
ksh88 source is closed on the Open Solaris source tree, but ksh93 will
be open source, allowing community members to contribute fixes,
resulting in a better quality Solaris korn shell.
Users with existing ksh93 scripts on other platforms are reluctant to migrate
to the Solaris OS without ksh93 functionality (see CR 6332421, above).
Users on Open Solaris discussion groups and other media, such as
news:comp.unix.solaris, have requested that Sun replace /usr/bin/ksh
with ksh93, to allow default login shells to take advantage of the many
features of ksh93 and to allow interoperability with other operating
systems (see 3.4).
In addition to many new features (see 4.2), many bugs
in the existing /usr/bin/ksh are fixed in ksh93, including:
4500743 *ksh* 'test -w' should exit with zero exit status
4703213 *ksh* ksh can't handle [[ "$s" ]] as manpage claims
4771050 *ksh* test -z "=" should not produce an error
4869545 *ksh* ksh should print error message for "trap - YABBA_DABBA_DOO"
6359008 *ksh* dumps core running command builtin with large argument list
6417347 *ksh* test -nt/-ot doesn't compare all of the timestamp
6435815 *ksh* sometimes chokes when piping output to a shell function
6442036 *ksh* ksh: "export -p" doesn't work as documented
Presumably, a majority of the remaining currently-open ksh RFEs and
defects would be resolved by the use of ksh93 in place of Solaris
/usr/bin/ksh.
3.4 Competitive Analysis
Sun is one of the only major vendors which does not include ksh93.
/usr/dt/bin/dtksh on the Solaris OS is not a viable login shell and is
based on ksh93d alpha, a very early, out-of-date version of ksh93.
ksh93 is included with IBM AIX, HP-UX, Debian, Redhat/Fedora, MacOSX,
Darwin, and SUSE Linux distributions. The absence of ksh93 on the
Solaris OS has been a major complaint by users [5].
HP-UX 11i Version 2, released September 2004 still keeps /usr/bin/ksh
as ksh88 and ksh93 as the binary dtksh.
On Debian, ksh93 is available as /usr/bin/ksh93, and does not
include the AT&T libraries libast and libshell [6].
IBM AIX 5L (released in 2004) introduced ksh93 as /usr/bin/ksh93
/usr/bin/ksh is still an enhanced POSIX-compliant version of ksh88. [7]
4. Technical Description
4.1. Bug/RFE Number
6437624 RFE: Add ksh93 (as /usr/bin/ksh93) and libshell.so to OS/Net
4.2 Features
ksh93 has many enhancements over the Solaris ksh utility, which is based
upon ksh88i, including:
- key binding (trap on KEYBD, to intercept all interactive user input)
- floating point arithmetic
- associative arrays
- complete ANSI-C printf formatting
- name reference variables (variables referring to other variables)
- new parameter expansion operators
- dynamic loading of built-in commands, including
the ability to add user-defined built-in commands
- active variables, allowing users to trap on variable assignments
and references by associating intercept functions
- compound variables
- increased performance, due to the addition of many built-in
commands for AT&T versions of common UNIX commands
- read with timeouts
- command and variable completion, in addition to filename completion
- Various pattern matching facilities, including normal shell pattern,
regular expressions, extended regular expressions and user-defined
expression systems
4.3. Description
The latest version, ksh93r, is available
from AT&T Resarch at http://www.research.att.com/~gsf/download
and was released on 1/24/06, with an updated alpha version (ksh93s-)
on 9/12/06.
See http://www.opensolaris.org/os/project/ksh93-integration/announcements/
ksh93 is available from AT&T under Common Public License [3].
This proposal will introduce a new set of binaries for ksh93.
For the ksh93, pfksh93, and rksh93 binaries, the stability
levels are as follows:
The scripting interface is Uncommitted. The environment
variables, .paths feature, editing modes, and pathname
bindings are Volatile.
Interface Description
--------- -----------
/usr/bin/ksh93 the korn shell
/usr/bin/pfksh93 profile shell
/usr/bin/rksh93 restricted shell
which will be hard links to /usr/lib/isaexec; isaexec will execute
the corresponding 32-bit binary in /usr/bin/{sparcv7,i86} or
the 64-bit binary/usr/bin/{sparcv9,amd64}, depending on the architecture.
The isaexec links will allow the 64-bit version of ksh93
to be executed by default on 64-bit platforms.
Note below that there will also be duplicate 32-bit versions of the
binaries residing in /sbin, on the root filesystem. The necessary
libraries (libshell, libast, libcmd, libdll) will reside on root,
in /lib. Thus the 32-bit version of ksh93 will be available
early in the boot process and during filesystem repair.
This is a desirable feature requested by community users.
isaexec will not be used by ksh93 on the root filesystem.
The 64-bit versions will be available on the /usr filesystem only.
Interface Description
--------- -----------
/usr/bin/sparcv7/ksh93 32-bit sparc korn shell
/usr/bin/sparcv7/pfksh93 hard link to /usr/bin/sparcv7/ksh93
/usr/bin/sparcv7/rksh93 hard link to /usr/bin/sparcv7/ksh93
/usr/bin/sparcv9/ksh93 64-bit sparc korn shell
/usr/bin/sparcv9/pfksh93 hard link to /usr/bin/sparcv9/ksh93
/usr/bin/sparcv9/rksh93 hard link to /usr/bin/sparcv9/ksh93
/usr/bin/i86/ksh93 32-bit x86 korn shell
/usr/bin/i86/pfksh93 hard link to /usr/bin/i86/ksh93
/usr/bin/i86/rksh93 hard link to /usr/bin/i86/ksh93
/usr/bin/amd64/ksh93 64-bit x86 korn shell
/usr/bin/amd64/pfksh93 hard link to /usr/bin/amd64/ksh93
/usr/bin/amd64/rksh93 hard link to /usr/bin/amd64/ksh93
/sbin/ksh93 32-bit korn shell (2nd copy)
/sbin/pfksh93 hard link to /sbin/ksh93
/sbin/rksh93 hard link to /sbin/ksh93
Four new shared libraries from AT&T will be introduced,
and one Sun private shared library (libcmd) will be appended with new
interfaces from AT&T. The new libraries and the new interfaces to
libcmd will initially be used only by ksh93. Although these libraries
and libcmd interfaces will be introduced with the Project Private
stability level, they could have potential use by Solaris applications
and external users if upgraded to public libraries in a future project.
See Section 4.5 Interfaces.
libshell - contains functions used for writing extensions
to ksh93 or for potentially embedding shell command
processing into other commands, such as dbx.
Most of ksh93 is contained in this library; the ksh93
binary itself is primarily a set of calls to libshell interfaces.
libast - AT&T's AST (Advanced Software Technology) library which
contains major components used by ksh93, including
implementations of interfaces for I/O (sfio), memory, strings,
stacks, and queue and list management. It also contains an OS
abstraction layer for portabilty, such as a stdio-compatible
wrapper over sfio for the benefit of plug-in modules (which
need to have sfio underneath for proper integration with ksh93).
libdll - portable runtime plug-in interface; allows "builtin -f foo"
to use high-level dll/so names which are mapped and searched using
local conventions.
libcmd - the AT&T library contains built-in commands and will be merged
with the existing Solaris libcmd Sun private shared library.
The new interfaces are AT&T implementations of common commands
which the Solaris OS implements as binaries under /usr/bin,
/usr/xpg4/bin, and /usr/xpg6/bin. A subset of these AT&T
implementations will be introduced as built-in commands in ksh93
(see below). The existing three Solaris libcmd interfaces (defopen,
defread, and defcntl) which are used by many Sun applications,
including many outside of the ON consolidation, will be left
untouched.
Since they are project private interfaces, for the new
AT&T libraries--libshell, libast, and libdll--the compilation environment
names (libshell.so, libast.so, libdll.so) will not be exposed.
New Ksh93 Built-ins
Below is the set of eight built-in commands in ksh93 which
are not built-ins in Solaris /usr/bin/ksh and which will have
"pathname binding" to /bin (and implicitly to /usr/bin).
These built-ins will also have pathname binding to /usr/ast/bin,
as described below.
cat
chown
head
mkdir
rmdir
tee
uniq
wc
With pathname binding to /bin, if, for example, "cat" is executed in
ksh93 without a pathname prefix, and a $PATH search first finds an
executable cat file on /bin or /usr/bin, the built-in cat
command is executed, not the Solaris /bin/cat binary.
The advantages of using these built-ins are increased performance and
additional functionality provided by the AT&T versions of these
commands (see manpages in case materials).
In addition, the below two upwardly-compatible ksh93 built-ins, which
are not built-ins in Solaris /usr/bin/ksh, will always be invoked when
called without a pathname prefix, instead of the corresponding Solaris
binary in /usr/bin:
sleep
printf
The above ten ksh93 built-ins are designed to conform to the POSIX
standard. They are also expected to be compatible with the Solaris
/usr/bin utilities. Incompatibilities between the above ksh93
built-ins and the Solaris /usr/bin versions shall be fixed or the
built-ins shall be disabled by default or removed from ksh93. See
builtin.bugs in the materials directory for a list of incompatible
behaviors in ksh93 built-ins which are known bugs to be fixed in
ksh93.
Although the above built-ins will be documented in manpages (see case
materials), a number of additional built-in commands, with pathname
binding to /usr/ast/bin, will be made available as an undocumented
feature of ksh93. Note that almost all ksh93 built-ins will print an
internal manpage when invoked with the --man option.
/usr/ast/bin/basename
/usr/ast/bin/cat
/usr/ast/bin/chgrp
/usr/ast/bin/chmod
/usr/ast/bin/chown
/usr/ast/bin/cmp
/usr/ast/bin/comm
/usr/ast/bin/cp
/usr/ast/bin/cut
/usr/ast/bin/date
/usr/ast/bin/dirname
/usr/ast/bin/expr
/usr/ast/bin/fds
/usr/ast/bin/fmt
/usr/ast/bin/fold
/usr/ast/bin/head
/usr/ast/bin/id
/usr/ast/bin/join
/usr/ast/bin/ln
/usr/ast/bin/logname
/usr/ast/bin/mkdir
/usr/ast/bin/mkfifo
/usr/ast/bin/mv
/usr/ast/bin/paste
/usr/ast/bin/pathchk
/usr/ast/bin/rev
/usr/ast/bin/rm
/usr/ast/bin/rmdir
/usr/ast/bin/stty
/usr/ast/bin/tail
/usr/ast/bin/tee
/usr/ast/bin/tty
/usr/ast/bin/uname
/usr/ast/bin/uniq
/usr/ast/bin/wc
Since most of these undocumented built-ins are not currently compatible
with the corresponding Solaris commands in /usr/bin, these built-ins
will be bound to the new pathname /usr/ast/bin. Unlike the /bin
pathname binding, the /usr/ast/bin pathname binding does not require
that the /usr/ast/bin directory exists.
These built-ins are being included to give ksh93 users easy access to
the AT&T implementations of these commands by adding /usr/ast/bin in
the front of their path, without affecting default Solaris commands
behavior for other ksh93 users. The stability of these undocumented
built-in commands is Volatile.
4.4. Interfaces:
See section 4.3 above for ksh93 binary interfaces.
The following new interfaces are introduced from AT&T:
Interface Stability Description
--------- --------- -----------
/lib/libshell.so.1 Project Private versioned 32-bit library
/usr/lib/libshell.so.1 Project Private symlink to /lib/libshell.so.1
/lib/amd64/libshell.so.1 Project Private versioned 64-bit x86 library
/usr/lib/amd64/libshell.so.1 Project Private symlink to
/lib/amd64/libshell.so.1
/lib/sparcv9/libshell.so.1 Project Private versioned 64-bit sparc library
/usr/lib/sparcv9/libshell.so.1 Project Private symlink to
/lib/sparcv9/libshell.so.1
/lib/libast.so.1 Project private versioned 32-bit library
/usr/lib/libast.so.1 Project Private symlink to /lib/libast.so.1
/lib/amd64/libast.so.1 Project Private versioned 64-bit x86 library
/usr/lib/amd64/libast.so.1 Project Private symlink to
/lib/amd64/libast.so.1
/lib/sparcv9/libast.so.1 Project Private versioned 64-bit sparc library
/usr/lib/sparcv9/libast.so.1 Project Private symlink to
/lib/sparcv9/libast.so.1
/lib/libdll.so.1 Project private versioned 32-bit library
/usr/lib/libdll.so.1 Project Private symlink to /lib/libdll.so.1
/lib/amd64/libdll.so.1 Project Private versioned 64-bit x86 library
/usr/lib/amd64/libdll.so.1 Project Private symlink to
/lib/amd64/libdll.so.1
/lib/sparcv9/libdll.so.1 Project Private versioned 64-bit sparc library
/usr/lib/sparcv9/libdll.so.1 Project Private symlink to
/lib/sparcv9/libdll.so.1
Existing libcmd library and its existing interfaces
(listed here for completeness, since they have not been listed in a
previous case):
Interface Stability Description
--------- ------------ ---------------------
/lib/libcmd.so.1 Sun Private versioned 32-bit library
/lib/libcmd.so Sun Private compilation environment name,
symlink to libcmd.so.1
/usr/lib/libcmd.so.1 Sun Private symlink to /lib/libcmd.so.1
/usr/lib/libcmd.so Sun Private symlink to /lib/libcmd.so.1
/lib/amd64/libcmd.so.1 Sun Private versioned 64-bit x86 binary
/lib/amd64/libcmd.so Sun Private compilation environment name,
symlink to libcmd.so.1
/usr/lib/amd64/libcmd.so.1 Sun Private symlink to
/lib/amd64/libcmd.so.1
/usr/lib/amd64/libcmd.so Sun Private symlink to
/lib/amd64/libcmd.so.1
/lib/sparcv9/libcmd.so.1 Sun Private versioned 64-bit sparc binary
/lib/sparcv9/libcmd.so Sun Private compilation environment name,
symlink to libcmd.so.1
/usr/lib/sparcv9/libcmd.so.1 Sun Private symlink to
/lib/sparcv9/libcmd.so.1
/usr/lib/sparcv9/libcmd.so Sun Private symlink to
/lib/sparcv9/libcmd.so.1
defopen Sun Private libcmd interface to files in
/etc/default
defread Sun Private "
defcntl Sun Private "
New interfaces will be added to the existing Sun Private Solaris
library libcmd.so.1:
Interface Stability Description
--------- --------------------- ------------
b_basename Project private AT&T built-in for basename command
b_cat Project private AT&T built-in for cat command
b_chgrp Project private AT&T built-in for chgrp command
b_chmod Project private AT&T built-in for chmod command
b_chown Project private AT&T built-in for chown command
b_cmp Project private AT&T built-in for cmp command
b_comm Project private AT&T built-in for cmp command
b_cp Project private AT&T built-in for cmp command
b_cut Project private AT&T built-in for cmp command
b_date Project private AT&T built-in for date command
b_dirname Project private AT&T built-in for dirname command
b_expr Project private AT&T built-in for expr command
b_fds Project private AT&T built-in for fds command
b_fmt Project private AT&T built-in for fmt command
b_fold Project private AT&T built-in for fold command
b_getconf Project private AT&T built-in for getconf command
b_head Project private AT&T built-in for head command
b_id Project private AT&T built-in for id command
b_join Project private AT&T built-in for join command
b_ln Project private AT&T built-in for ln command
b_logname Project private AT&T built-in for logname command
b_mkdir Project private AT&T built-in for mkdir command
b_mkfifo Project private AT&T built-in for mkfifo command
b_mv Project private AT&T built-in for mv command
b_paste Project private AT&T built-in for paste command
b_pathchk Project private AT&T built-in for pathchk command
b_rev Project private AT&T built-in for rev command
b_rmdir Project private AT&T built-in for rmdir command
b_rm Project private AT&T built-in for rm command
b_stty Project private AT&T built-in for ssty command
b_tail Project private AT&T built-in for tail command
b_tee Project private AT&T built-in for tee command
b_tty Project private AT&T built-in for tty command
b_uname Project private AT&T built-in for uname command
b_uniq Project private AT&T built-in for uniq command
b_wc Project private AT&T built-in for wc command
New directories:
Interface Stability Description
--------- ---------- ----------------------------
/usr/demo/ksh Uncommitted ksh93 function definitions, test suite,
miscellaneous
/usr/include/ast Project private AT&T header files
5. Reference Documents
1. Home page for the KornShell Command and Programming Language
http://www.kornshell.com
2. The Official AT&T release of ksh93
http://www.research.att.com/sw/download/
3. Common Public License
http://www.opensource.org/licenses/cpl
Also, see cpl1.0 file in case materials.
4. The Open Solaris Korn Shell 93 Integration Project
http://www.opensolaris.org/os/project/ksh93-integration/
5. User comments on the absence of ksh93 in Solaris systems
See user.comments file in case materials.
6. Debian ksh packages
http://packages.debian.org/unstable/shells/ksh
7. IBM AIX 5L documentation in Section 2.9.1 ksh93 from 2004:
http://www.redbooks.ibm.com/redbooks/SG245765/wwhelp/wwhimpl/java/html/wwhelp.htm
6. Resources and Schedule
6.1 Projected Availability
A prototype of ksh93 and its libraries has been built on
Open Solaris build 37.
See http://www.opensolaris.org/os/project/ksh93-integration/
for downloads of tarballs of the latest OpenSolaris ksh93.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
Don Cragun
don.cragun@Sun.COM
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 10:20 AM
in response to: Don Cragun
|
|
>Date: Wed, 20 Sep 2006 10:09:21 -0700 (PDT)
>From: Glenn Skinner <glenn at ivrel dot SFBay dot Sun dot COM>
>Subject: Re: Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:
09/27/2006]
>
>Where is the case directory for this case? Does it live outside of the
>normal directory structure because it's community-visible?
Just like the tag on the name of the case is PSARC-EXT/2006/550 rather
than PSARC/2006/550, the case directory is PSARC-EXT/2006/550 rather
than PSARC/2006/550.
I believe John will be joining us during our 4PM PDT PSARC business
meeting this afternoon to enlighten us on details...
- Don
>
> -- Glenn
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joseph Kowalski
Joseph.Kowalski@eng....
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 11:32 AM
in response to: Don Cragun
|
|
Whoot, Whoot! Its about time (even if this isn't currently called ksh).
One minor comment:
/sbin/ksh93 32-bit korn shell (2nd copy)
/sbin/pfksh93 hard link to /sbin/ksh93
/sbin/rksh93 hard link to /sbin/ksh93
Do we need these any more than /sbin/bash, /sbin/zsh, ... ?
I'd rather not get into shell wars (my favorite shell is better than your
favorite shell becasue I'm on root).
I'd like to see a fairly strong justification for these or have them removed
from the proposal.
- thanks,
- jek3
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:16 PM
in response to: Joseph Kowalski
|
|
>
>Whoot, Whoot! Its about time (even if this isn't currently called ksh).
>
>One minor comment:
>
> /sbin/ksh93 32-bit korn shell (2nd copy)
> /sbin/pfksh93 hard link to /sbin/ksh93
> /sbin/rksh93 hard link to /sbin/ksh93
>
>Do we need these any more than /sbin/bash, /sbin/zsh, ... ?
>
>I'd rather not get into shell wars (my favorite shell is better than your
>favorite shell becasue I'm on root).
>
>I'd like to see a fairly strong justification for these or have them removed
>from the proposal.
Seconded.
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:44 PM
in response to: Joseph Kowalski
|
|
Joseph Kowalski wrote:
>
> Whoot, Whoot! Its about time (even if this isn't currently called ksh).
>
> One minor comment:
>
> /sbin/ksh93 32-bit korn shell (2nd copy)
> /sbin/pfksh93 hard link to /sbin/ksh93
> /sbin/rksh93 hard link to /sbin/ksh93
>
> Do we need these any more than /sbin/bash, /sbin/zsh, ... ?
>
> I'd rather not get into shell wars (my favorite shell is better than your
> favorite shell becasue I'm on root).
>
> I'd like to see a fairly strong justification for these or have them removed
> from the proposal.
AFAIK there isn't opne strong justification but lots of smaller ones:
- The term "copy" doesn't really apply to "/sbin/ksh93". The "ksh93"
binary is actually only a ~~5k frontend which immediately calls into
libshell (which is ksh93 made available as shared library).
The actual code looks like this (see
http://polaris.blastwave.org/browser/on/branches/ksh93/gisburn/prototype002/m1_ast_ast_imported/usr/src/lib/libshell/common/sh/pmain.c):
-- snip --
22 #include <shell.h>
23
24 typedef int (*Shnote_f)(int, long, int);
25
26 int main(int argc, char *argv[])
27 {
28 sh_waitnotify((Shnote_f)0);
29 return(sh_main(argc, argv, 0));
30 }
-- snip --
That's all - and this source didn't change for a couple of years.
- "libshell" and all other required libraries already live in /lib (that
applications like SMF etc. can use them in the future) and IMO it is not
very usefull to obmit the frontend in the root filesystem when the
majority of the code already lives in '/' anyway (as I said: we're
talking about a ~~5k penaltity to make things MUCH easier for script
writers, admins and users (see below)).
- Right now Solaris has no POSIX-conformant shell in the root filesystem
- which means applications who need to be started before /usr gets
mounted are stuck with the /sbin/sh monstrosity which means any scripts
which need POSIX features need to be ported first due lack of a
POSIX-conformant shell.
- /sbin/pfksh93 and /sbin/rksh93 are just hardlinks to /sbin/ksh93 (they
are included for completeness reasons)
- Finally: Imagine the picture: The main server of your department fails
and cannot mount /usr anymore. The phone starts to ring (angry users!),
the door operns and your manager/professor appears in front of your desk
and starts yelling around. In this situation you have to deal with a
shell called "/sbin/sh" which treats things like "working editor mode"
and other things as "optional" features (e.g. each typo forces you to
rewrite the line unless you figure out how the editor mode for /sbin/sh
works - and usually you do not have that much time before the person in
front of your desk gets rabies...).
/sbin/sh has a VERY bad reputation of being the worst imagineable
(s)hell in such a case and there is more than one large thread on
news:comp.unix.solaris whether "... /sbin/sh can be replaced by
something less "horrible" ...". We do not want to replace /sbin/sh right
now but I think the extra 5k (compared to 1200kb needed by bash (and I
won't comment here about "bash"'s non-existant POSIX conformance)) may
please many users in such an emergency because they can quickly type
<k><h><9><3> and then get working emacs/gamcs/vi editor modes, a
history and other goodies.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
807
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:20 PM
in response to: gisburn
|
|
On Wed 20 Sep 2006 at 11:44PM, Roland Mainz wrote:
> Joseph Kowalski wrote:
> >
> > Whoot, Whoot! Its about time (even if this isn't currently called ksh).
> >
> > One minor comment:
> >
> > /sbin/ksh93 32-bit korn shell (2nd copy)
> > /sbin/pfksh93 hard link to /sbin/ksh93
> > /sbin/rksh93 hard link to /sbin/ksh93
> >
> > Do we need these any more than /sbin/bash, /sbin/zsh, ... ?
> >
> > I'd rather not get into shell wars (my favorite shell is better than your
> > favorite shell becasue I'm on root).
> >
> > I'd like to see a fairly strong justification for these or have them removed
> > from the proposal.
>
> AFAIK there isn't opne strong justification but lots of smaller ones:
In casual conversation, Stephen Hahn mentioned what is to me a more
architecturally compelling reason to have this in /sbin: we're going to
need to have a transition period where we clean up all of the scripts
delivered into the product by OS/Net (and by other consolidations) which
don't work right in ksh93 if we're ever going to have ksh93 be the default
version of ksh.
This will benefit OpenSolaris distros as well, presumably. If any of
those scripts currently use /sbin/ksh, then it'll be a lot easier to
verify the transition if we can set them to use /sbin/ksh93, and
this provides (to me) a more persuasive rationale about "why ksh93
and not {bash|zsh|tcsh}" than their POSIX-ness.
Maybe such scripts don't exist; if they do, that would be a good
reason to have /sbin/ksh93.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
807
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:25 PM
in response to: dp
|
|
On Wed 20 Sep 2006 at 03:20PM, Dan Price wrote:
> On Wed 20 Sep 2006 at 11:44PM, Roland Mainz wrote:
> > Joseph Kowalski wrote:
> > >
> > > Whoot, Whoot! Its about time (even if this isn't currently called ksh).
> > >
> > > One minor comment:
> > >
> > > /sbin/ksh93 32-bit korn shell (2nd copy)
> > > /sbin/pfksh93 hard link to /sbin/ksh93
> > > /sbin/rksh93 hard link to /sbin/ksh93
> > >
> > > Do we need these any more than /sbin/bash, /sbin/zsh, ... ?
> > >
> > > I'd rather not get into shell wars (my favorite shell is better than your
> > > favorite shell becasue I'm on root).
> > >
> > > I'd like to see a fairly strong justification for these or have them removed
> > > from the proposal.
> >
> > AFAIK there isn't opne strong justification but lots of smaller ones:
>
> In casual conversation, Stephen Hahn mentioned what is to me a more
> architecturally compelling reason to have this in /sbin: we're going to
Please excuse me for being a turkey: there is no /sbin/ksh. I'm
clearly losing my mind.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:34 PM
in response to: dp
|
|
>In casual conversation, Stephen Hahn mentioned what is to me a more
>architecturally compelling reason to have this in /sbin: we're going to
>need to have a transition period where we clean up all of the scripts
>delivered into the product by OS/Net (and by other consolidations) which
>don't work right in ksh93 if we're ever going to have ksh93 be the default
>version of ksh.
>
>This will benefit OpenSolaris distros as well, presumably. If any of
>those scripts currently use /sbin/ksh, then it'll be a lot easier to
>verify the transition if we can set them to use /sbin/ksh93, and
>this provides (to me) a more persuasive rationale about "why ksh93
>and not {bash|zsh|tcsh}" than their POSIX-ness.
There is no /sbin/ksh. If the need for /sbin/ksh93 follows from
the existance of /sbin/ksh then clearly this is not the case.
Is the intention to replace /sbin/sh with ksh93?
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 4:48 PM
in response to: casper
|
|
Casper.***@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.
However any such project would be started after the /usr/bin/ksh
migration to ksh93 is done, e.g. we don't plan this for Solaris
11/Nevada (mainly due lack of resources (time, engineers)).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 3:51 AM
in response to: gisburn
|
|
Roland Mainz <roland dot mainz at nrubsig dot org> wrote:
> Casper.***@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.
If you ever do this, what name would you like to use for the old sh then?
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
David Korn
dgk@research.att.com
|
|
|
|
Re: Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:11 AM
in response to: Joerg Schilling
|
|
> The item numbers in the COMPAT file that are part of the PSARC case
> are slightly different than those in the ksh88 vs. ksh93 COMPATIBILITY file
> from AT&T that David may be referencing. The COMPAT file in the case
> is based on the AT&T one but is specific to Solaris ksh (based
> on ksh88 but has diverged) versus ksh93.
>
> I've attached the COMPAT file from the ARC case with item #1 corrected
> per Mike Oliver's comments; I had reversed the description of
> the POSIX and non-POSIX function behavior.
>
> Sorry for the confusion.
>
> Thanks,
> April
>
Most of the compatibilities that you list could at least by flagged
with warning messages with ksh -n which could make it easy to
fix non-conforming scripts.
Another option would be a ksh88 conformance mode. However, it is unlikely
that ksh93 would ever be 100% ksh88 compatible but it would eliminate
most of the items on your list.
There has been recent discussion about item 13, octal constants in
arithmetic expressions. Currently ksh93 only recognizes explicit
octal constants in scripts; not those that originate from either
using the variable name or $varname.
This appears to be a conformance issue. On the other hand,
in the past a number of scripts broke with this change.
I was considering modifying the behavior so that leading zeros
would get dropped only for fields defined as zero-filled and
those that have a .get discipline function. This would then
eliminte the conformance problem. Is this likely to resolve
most of the ksh88 backward compatibily issues?
David Korn
dgk at research dot att dot com
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
ksh88 compatibility mode in ksh93 ? / was: Re:
Re: Korn Shell 93
Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 4:51 PM
in response to: David Korn
|
|
David Korn wrote:
[snip]
> Most of the compatibilities that you list could at least by flagged
> with warning messages with ksh -n which could make it easy to
> fix non-conforming scripts.
>
> Another option would be a ksh88 conformance mode. However, it is unlikely
> that ksh93 would ever be 100% ksh88 compatible but it would eliminate
> most of the items on your list.
I don't think such a compatibility mode would make sense. ksh93 was
explicitly designed that way to get rid of some old design issues (and I
am very happy with this decision :-) ) and "turning the time back" with
such a compatibilty option (which can never be fully compatible) is IMO
just wasted engineering time.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
New name for /sbin/sh ?! / was: Re: [osol-arc] Re:
Re: Korn Shell 93Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:45 PM
in response to: Joerg Schilling
|
|
Joerg Schilling wrote:
> Roland Mainz <roland dot mainz at nrubsig dot org> wrote:
> > Casper.***@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.
>
> If you ever do this, what name would you like to use for the old sh then?
What about following the AIX example and name it either "osh" (old
shell) or "bsh" (bourne shell) ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: New name for /sbin/sh ?! / was: Re: [osol-arc] Re:
Re: Korn Shell 93Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:48 PM
in response to: gisburn
|
|
Roland Mainz <roland dot mainz at nrubsig dot org> wrote:
> Joerg Schilling wrote:
> > Roland Mainz <roland dot mainz at nrubsig dot org> wrote:
> > > Casper.***@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.
> >
> > If you ever do this, what name would you like to use for the old sh then?
>
> What about following the AIX example and name it either "osh" (old
> shell) or "bsh" (bourne shell) ?
The name "bsh" is used by my shell for a long time.... "osh" would be OK.
*) Developed when I was working at Berthold AG (the second largest Sun OEM in
the 1980s).
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 1:21 PM
in response to: Don Cragun
|
|
Don Cragun writes:
> It is the goal of the project team to keep ksh93 in the Solaris operating
> system updated with AT&T's latest version of ksh93 and its supporting
> libraries. Thus it will be important to keep Solaris ksh93 source in sync,
> including contributing Solaris-specific changes back to the
> AT&T source.
With an Uncommitted stability level, you won't be able to make
incompatible patches for the ksh93 scripting interface once Nevada
ships. Is that the intended solution? Is a snapshot once per minor
release enough of an update frequency?
Will at least some parts of the scripting interface eventually be
Committed? It seems that they will need to be, if ksh replacement is
one of the goals.
> standard-compliant /usr/xpg4/bin/sh with ksh93. Thus this project
> needs to be aware of potential compatibility problems. See COMPAT file
> for a list of known incompatibilities between ksh93 and Solaris ksh.
What's the plan here? Some of those incompatibilities seem rather
stark to me. Will incompatible changes be made to the open source
version in order to keep compatibility with the old ksh? Or will the
Solaris-integrated ksh93 be made incompatible with the open source
version? Or do we intend to break compatibility in our own
/usr/bin/ksh in the future?
I realize that the complete set of answers might not yet be known, but
is there a plan of some sort?
> This project will also introduce built-in commands in ksh93, which have
> a superset of the functionality of the corresponding Solaris /usr/bin
> commands (see Section 4.3 Description). These ksh93 built-in commands
> may lead to the future replacement of the source of some existing /usr/bin
> commands with the corresponding AT&T code used by the ksh93 built-ins.
When does this happen? The duplication of code here seems rather
extensive. Unless there's a good plan to eliminate that duplication,
I think this might be a reason to have a written opinion.
> ksh93s- is under the Common Public License which allows Sun to
> freely redistribute a derived verison of ksh93, provided Sun includes
> the license terms and does not encumber it with any proprietary changes.
What does that mean? Does it mean that we're not able to maintain our
own code, or is it a licensing issue?
(I would have expected to see "any additional licensing terms" or some
such. Seeing the word "changes" here is jarring, and seems to imply
that we're not able to maintain our own code because the changes would
be "proprietary.")
> /sbin/ksh93 32-bit korn shell (2nd copy)
> /sbin/pfksh93 hard link to /sbin/ksh93
> /sbin/rksh93 hard link to /sbin/ksh93
Why is ksh93 needed before /usr is mounted?
This seems wasteful to me. If anything, we should be doing away with
cases where /usr isn't mounted rather than engorging the root file
system.
> libshell - contains functions used for writing extensions
> to ksh93 or for potentially embedding shell command
> processing into other commands, such as dbx.
> Most of ksh93 is contained in this library; the ksh93
> binary itself is primarily a set of calls to libshell interfaces.
How does this square with the existing libtecla? Should we remove
libtecla?
> Since most of these undocumented built-ins are not currently compatible
> with the corresponding Solaris commands in /usr/bin, these built-ins
> will be bound to the new pathname /usr/ast/bin. Unlike the /bin
> pathname binding, the /usr/ast/bin pathname binding does not require
> that the /usr/ast/bin directory exists.
It looks like we're building a parallel universe under /usr/ast.
Is there any chance that this goes away in a future version, or are we
stuck carrying the /usr/ast baggage forever? (In other words: is this
part of the intentional design here, or is it just a temporary
work-around?)
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 1:56 PM
in response to: carlsonj
|
|
On Wed, Sep 20, 2006 at 04:23:57PM -0400, James Carlson wrote:
> Don Cragun writes:
> > standard-compliant /usr/xpg4/bin/sh with ksh93. Thus this project
> > needs to be aware of potential compatibility problems. See COMPAT file
> > for a list of known incompatibilities between ksh93 and Solaris ksh.
>
> What's the plan here? Some of those incompatibilities seem rather
> stark to me. Will incompatible changes be made to the open source
> version in order to keep compatibility with the old ksh? Or will the
> Solaris-integrated ksh93 be made incompatible with the open source
> version? Or do we intend to break compatibility in our own
> /usr/bin/ksh in the future?
>
> I realize that the complete set of answers might not yet be known, but
> is there a plan of some sort?
Incompatibility (1) seems likely to break a lot of scripts (I am fond of
function() function-declaration syntax, so my scripts would break).
Incompatibility (9)... Does this mean pattern matching in the same
statement/command? Or subsequently for the rest of the script? Sounds
like a bug.
I don't understand (6).
(10) will almost certainly break scripts.
(12) could be finnessed (one signal per-line if stdout is a pipe, say).
I'm guessing most of these could be finessed so that when invoked as
"ksh" they go away.
Nico
--
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Mike Oliver
Mike.Oliver@Sun.COM
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:15 PM
in response to: carlsonj
|
|
James Carlson wrote:
> Don Cragun writes:
>> [...] the eventual goal in one or more future
>> projects will be to replace both /usr/bin/ksh and the
>> standard-compliant /usr/xpg4/bin/sh with ksh93. Thus this project
>> needs to be aware of potential compatibility problems. See COMPAT file
>> for a list of known incompatibilities between ksh93 and Solaris ksh.
>
> What's the plan here? Some of those incompatibilities seem rather
> stark to me. Will incompatible changes be made to the open source
> version in order to keep compatibility with the old ksh? Or will the
> Solaris-integrated ksh93 be made incompatible with the open source
> version? Or do we intend to break compatibility in our own
> /usr/bin/ksh in the future?
If we do intend to break backwards compatibility then will we rename
the existing 'ksh' to, say, 'ksh88' or move it to some other pathname
so that scripts that break when 'ksh' becomes ksh93 can have their
interpreter (#!) line rewritten to invoke 'ksh88'? If we're going to
do that then the sooner we do it, the better.
BTW, the second paragraph in item 1 of the COMPAT summary:
In ksh93, local variables only exist for POSIX-style
(func()) functions. In non-POSIX-style functions, variables
declared with "typeset var" remain global in scope, and are shared
between the calling program and the function.
is incorrect. It's the POSIX-style functions that always operate on
global variables. Non-POSIX functions retain the ability to create
local variables via 'typedef'.
<http://
gets this right, although it's wrong about non-POSIX functions
maintaining backwards compatibility. For one thing, the behaviour
of a local variable in ksh93 is incompatible with the existing
Solaris ksh because the semantics of a variable's "readonly"
('typeset -r') attribute are very different.
Mike.
--
mike dot oliver at sun dot com
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Gary Winiger
gww@tundra.sfbay.sun...
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 1:32 PM
in response to: Don Cragun
|
|
> Interface Description
> --------- -----------
> /usr/bin/ksh93 the korn shell
> /usr/bin/pfksh93 profile shell
> /usr/bin/rksh93 restricted shell
Will these be added to getusershell(3C) or will an /etc/shells
be delivered with these and the other "legal user shell"s?
Gary..
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:21 PM
in response to: Gary Winiger
|
|
>> Interface Description
>> --------- -----------
>> /usr/bin/ksh93 the korn shell
>> /usr/bin/pfksh93 profile shell
>> /usr/bin/rksh93 restricted shell
>
> Will these be added to getusershell(3C) or will an /etc/shells
> be delivered with these and the other "legal user shell"s?
Not rksh :-)
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
April Chin
April.Chin@eng.sun.com
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:08 PM
in response to: Don Cragun
|
|
> Date: Wed, 20 Sep 2006 08:32:07 -1000 (HST)
> From: Joseph Kowalski <Joseph dot Kowalski at eng dot sun dot com>
> Subject: Re: Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:
09/27/2006]
> To: PSARC-EXT at sac dot sfbay dot sun dot com, don dot cragun at sun dot com
> Cc: April dot Chin at eng dot sun dot com, ksh93-integration-discuss at opensolaris dot org,
roland dot mainz at nrubsig dot org
> MIME-Version: 1.0
> Content-MD5: PtcfOtDUrTE/dLldF5Pl9A==
>
>
> Whoot, Whoot! Its about time (even if this isn't currently called ksh).
>
> One minor comment:
>
> /sbin/ksh93 32-bit korn shell (2nd copy)
> /sbin/pfksh93 hard link to /sbin/ksh93
> /sbin/rksh93 hard link to /sbin/ksh93
>
> Do we need these any more than /sbin/bash, /sbin/zsh, ... ?
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 single-user mode, when dealing with filesystem
problems.
I'm sure Roland will be able to elaborate more on this.
April
>
> I'd rather not get into shell wars (my favorite shell is better than your
> favorite shell becasue I'm on root).
>
> I'd like to see a fairly strong justification for these or have them removed
> from the proposal.
>
> - thanks,
>
> - jek3
>
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:26 PM
in response to: April Chin
|
|
>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 single-user mode, when dealing with filesystem
>problems.
I don't think that's a strong enough reason:
- you can already use any shell as root shell; is /usr isn't
mounted /sbin/sh is used instead.
By this reasoning, we should add bash/zsh/tcsh/csh there too.
If you have a separate /usr, well, you pretty much deserve the
barebones system you get.
And I also suggest we move all ksh93 libaries to /usr/lib with
the needed exception of libcmd.
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:35 PM
in response to: casper
|
|
On Wed, Sep 20, 2006 at 11:27:55PM +0200, Casper.***@Sun.COM wrote:
> And I also suggest we move all ksh93 libaries to /usr/lib with
> the needed exception of libcmd.
Why are those functions being thrown into libcmd anyways?
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: Korn Shell 93
Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:06 PM
in response to: casper
|
|
Casper.***@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 single-user mode, when dealing with filesystem
> >problems.
>
> I don't think that's a strong enough reason:
>
> - you can already use any shell as root shell; is /usr isn't
> mounted /sbin/sh is used instead.
Do you mean replacing "root"'s login shell in /etc/passwd with any shell
? Where is this documented (AFAIK the recommentation over all the years
was "... don't do that. Never. Don't touch it or your system will
explode (sooner or later) ...") ?
> By this reasoning, we should add bash/zsh/tcsh/csh there too.
Is any of { bash, zsh, tcsh, csh } POSIX-conformant by default (ksh93
isn't perfect in this case either but at least it is one of the choices
which is very close to the specs) ?
> If you have a separate /usr, well, you pretty much deserve the
> barebones system you get.
It is still the default configuration in the installer to create a
seperate "/usr" filesystem (and still needed for diskless client setups
or when /usr should live on ZFS/QFS or simply another physical disk).
And you forgot the jumpstart case (like I did... and I usually try to
forget this immediately again because it is usually a pain to deal with
/sbin/sh when you write POSIX-like shell scripts most of the time) ...
> And I also suggest we move all ksh93 libaries to /usr/lib with
> the needed exception of libcmd.
<blink><marquee>DEFINATELY NO</marquee></blink>. At some point we will
have followup projects and many of them (like SMF) simply need libshell
in the root filesystem because the consumers live there, too. Moving
libshell or any of the libraries needed by it to /usr/lib would kill
most of the follow-up projects. And this would neither help programmers,
users, admins or writers of jumpstart/startup scripts.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
807
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93
Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:18 PM
in response to: gisburn
|
|
On Thu 21 Sep 2006 at 12:07AM, Roland Mainz wrote:
> Casper.***@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 single-user mode, when dealing with filesystem
> > >problems.
> >
> > I don't think that's a strong enough reason:
> >
> > - you can already use any shell as root shell; is /usr isn't
> > mounted /sbin/sh is used instead.
>
> Do you mean replacing "root"'s login shell in /etc/passwd with any shell
> ? Where is this documented (AFAIK the recommentation over all the years
> was "... don't do that. Never. Don't touch it or your system will
> explode (sooner or later) ...") ?
I improved this in Solaris 9. Here's a reference:
http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/9665233a4976c7fb/dcabfd29073e5795#dcabfd29073e5795
This is PSARC/2001/723 "Fallback Root Login for su(1M)"
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93
Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:29 PM
in response to: gisburn
|
|
>Do you mean replacing "root"'s login shell in /etc/passwd with any shell
>? Where is this documented (AFAIK the recommentation over all the years
>was "... don't do that. Never. Don't touch it or your system will
>explode (sooner or later) ...") ?
No, there was no documentation stipulating that fact.
The only potential problem was for those people stupid enough to
split / & /usr; well, the *real* problem was people changing
/sbin/sh to /sbin/csh which, of course, does not work.
But we've addressed that issue.
This is somewhat of a rehash of the argument against no longer
shipping a statically linked "/sbin/sh", which the external folks
may have missed.
In the end, having /sbin/sh dynamically linked adds about 10 files
to the list of 100s of files needed to successfully boot to single
user mode so the whole statically linked issue was declared moot.
*Nothing* happens when you change root's shell.
>Is any of { bash, zsh, tcsh, csh } POSIX-conformant by default (ksh93
>isn't perfect in this case either but at least it is one of the choices
>which is very close to the specs) ?
This is relevant, how?
Root's shell needs to be POSIX compliant because?
>It is still the default configuration in the installer to create a
>seperate "/usr" filesystem (and still needed for diskless client setups
>or when /usr should live on ZFS/QFS or simply another physical disk).
>And you forgot the jumpstart case (like I did... and I usually try to
>forget this immediately again because it is usually a pain to deal with
>/sbin/sh when you write POSIX-like shell scripts most of the time) ...
If that's the case the installer is broken (and it probably is, I
don't doubt that).
><blink><marquee>DEFINATELY NO</marquee></blink>. At some point we will
>have followup projects and many of them (like SMF) simply need libshell
>in the root filesystem because the consumers live there, too. Moving
>libshell or any of the libraries needed by it to /usr/lib would kill
>most of the follow-up projects. And this would neither help programmers,
>users, admins or writers of jumpstart/startup scripts.
Why? Why do we want to burden these programs with libshell?
All the tools which currently use command line editing use
libtecla; it is installed in /usr/lib so it is clear that replacing
such functionality does not require a library in /lib.
I see no follow-on projects listed in the ARC case so I would
like to know what these are.
The ARC has traditionally resisted "frameworks" which did not
have consumers; I see no concrete examples of such consumers.
And what is preventing these followon projects to move the library?
What is the relevance of jumpstart here?
It's a crying shame that the miniroot is now 155MB and climbing; but
/usr is part of it and putting ksh93 in /sbin is not relevant.
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 5:23 PM
in response to: casper
|
|
Casper.***@sun.com wrote:
> >Do you mean replacing "root"'s login shell in /etc/passwd with any shell
> >? Where is this documented (AFAIK the recommentation over all the years
> >was "... don't do that. Never. Don't touch it or your system will
> >explode (sooner or later) ...") ?
>
> No, there was no documentation stipulating that fact.
I think you will still get that answer when you ask in
news:comp.unix.solaris (e.g. this knowledge doesn't seem to be
well-known outside Sun...) ... ;-(
> The only potential problem was for those people stupid enough to
> split / & /usr; well, the *real* problem was people changing
> /sbin/sh to /sbin/csh which, of course, does not work.
Uhm... I do not think it is "stupid" to split "/" and "/usr" - sometimes
it is usefull to do it for performance or other reasons (like using
seperate physical disks for "/" and "/usr") ...
> But we've addressed that issue.
>
> This is somewhat of a rehash of the argument against no longer
> shipping a statically linked "/sbin/sh", which the external folks
> may have missed.
>
> In the end, having /sbin/sh dynamically linked adds about 10 files
> to the list of 100s of files needed to successfully boot to single
> user mode so the whole statically linked issue was declared moot.
Why doesn't apply the same argumentation to "libshell in the root
filesystem", too ?
[snip]
> This is relevant, how?
> Root's shell needs to be POSIX compliant because?
I was thinking more about having a (near-) POSIX-conformant shell around
at startup time and single-user mode, something which is easy to use,
doesn't have the habit to turn the life of admins into a living hell in
emergencies, can be used in jumpstart, pkgadd/pkgrm
preinstall/postinstall/precheck/preremove/postremove scripts, boot time
scripts and allow a high amount of "portability" between operating
systems.
> >It is still the default configuration in the installer to create a
> >seperate "/usr" filesystem (and still needed for diskless client setups
> >or when /usr should live on ZFS/QFS or simply another physical disk).
> >And you forgot the jumpstart case (like I did... and I usually try to
> >forget this immediately again because it is usually a pain to deal with
> >/sbin/sh when you write POSIX-like shell scripts most of the time) ...
>
> If that's the case the installer is broken (and it probably is, I
> don't doubt that).
Why should the installer be "broken" when it uses this choice by default
? It is a valid choice in Unix to have "/" and "/usr" on seperate
filesystems and it is AFAIK still needed for diskless client support and
zones (please correct me if I am wrong).
> ><blink><marquee>DEFINATELY NO</marquee></blink>. At some point we will
> >have followup projects and many of them (like SMF) simply need libshell
> >in the root filesystem because the consumers live there, too. Moving
> >libshell or any of the libraries needed by it to /usr/lib would kill
> >most of the follow-up projects. And this would neither help programmers,
> >users, admins or writers of jumpstart/startup scripts.
>
> Why? Why do we want to burden these programs with libshell?
Why not ?
> All the tools which currently use command line editing use
> libtecla; it is installed in /usr/lib so it is clear that replacing
> such functionality does not require a library in /lib.
I wasn't only thinking about "command line editing". For zones and SMF I
have some nice ideas in the queue to add features like event-driven
scripting (for example send SMS to the admin when a service goes down)
or simply "conditional execution" (e.g. the usual if...else...fi
machinery would be very usefull, including keeping the current status of
a SMF service in variables maintained by discipline functions (for
example $ echo ${SMF.service.status["svc:/network/telnet:default"]} #
could return "online" (the "trick" is to define a "get" discipline
function for "SMF.service.status"))).
> I see no follow-on projects listed in the ARC case so I would
> like to know what these are.
They are not listed because we have only rougth drafts and some
prototype code for some of them - but it doesn't make sense to spend
more time on such items unless we're sure that the basis - this ARC case
and putback - has a chanche to succeed (and the current resistance makes
me think there isn't much a chanche it will succeed without being
crippled to death).
To satisfy your curiosiy a little bit:
- |libc::wordexp()| currently uses the old Solaris /usr/bin/ksh but
should use "ksh93" in the future. Since libc sits in "/lib" it may be
nice to have a copy of ksh93 in the root filesystem, too - otherwise
|libc::wordexp()| will only work when "/usr" is mounted
- Replace some of the standalone commands with the libshell builtins
(low-hanging fruits include "sleep", "pwd", "test" etc.)
- Think about { SMF, zone adminstration tool } which can be scripted
(and do event-driven+conditional tasks) using shell functions and
scripts (similar how dtksh/tksh can run shell functions as callback
hooks)
> The ARC has traditionally resisted "frameworks" which did not
> have consumers; I see no concrete examples of such consumers.
ksh93 has no "concrete consumers" either right now, too - using this
kind of argumentation we could cancel this effort completely.
> And what is preventing these followon projects to move the library?
It needs to be ARC'ed - again. Based on the current resistance we will
either get libshell in /lib now or simply forget such projects
completely because in a second/third/etc. attempt we will face the same
argumentation+resistance. It's IMO useless to start projects or even
consider them when there is little chanche of success.
> What is the relevance of jumpstart here?
Think about pkg preinstall/postinstall/precheck/preremove/postremove
scripts or custom install scripts which need to be run before "/usr"
gets mounted...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
807
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 5:34 PM
in response to: gisburn
|
|
On Thu 21 Sep 2006 at 02:23AM, Roland Mainz wrote:
> > All the tools which currently use command line editing use
> > libtecla; it is installed in /usr/lib so it is clear that replacing
> > such functionality does not require a library in /lib.
>
> I wasn't only thinking about "command line editing". For zones and SMF I
> have some nice ideas in the queue to add features like event-driven
> scripting (for example send SMS to the admin when a service goes down)
> or simply "conditional execution" (e.g. the usual if...else...fi
> machinery would be very usefull, including keeping the current status of
> a SMF service in variables maintained by discipline functions (for
> example $ echo ${SMF.service.status["svc:/network/telnet:default"]} #
> could return "online" (the "trick" is to define a "get" discipline
> function for "SMF.service.status"))).
As a representative of the Zones team, I'm not aware of these plans.
Since zonecfg(1m) is just basically a document editor, I don't believe
we need anything beyond the kind of tab completion that libtecla gives
us (and indeed we were the team responsible for adding it in the first
place).
As for notifications at state transitions, the team's long term plan is
to rework our service model such that each zone is an SMF service
instance (there are additional reasons for this which are out of the
scope of this discussion), and then to piggyback on planned SMF
functionality in that space, which Liane has called "the transitions
project." It is possible that we will also expose such state
transitions to the command line (i.e. via zoneadm) but I don't need
any new libraries to do so.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
824
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 5:51 PM
in response to: gisburn
|
|
>>>>> "Roland" == Roland Mainz <roland dot mainz at nrubsig dot org> writes:
Casper> Root's shell needs to be POSIX compliant because?
Roland> I was thinking more about having a (near-) POSIX-conformant
Roland> shell around at startup time and single-user mode
This is already available on most (all?) Linux distros, yes?
>> And what is preventing these followon projects to move the library?
Roland> It needs to be ARC'ed - again. Based on the current resistance
Roland> we will either get libshell in /lib now or simply forget such
Roland> projects completely because in a second/third/etc. attempt we
Roland> will face the same argumentation+resistance.
Well, you'll get the same question, but I wouldn't take that as
"resistance". If the follow-on project truly needs the library in /,
you explain why it can't work with the library in /usr, and the ARC says
"oh, okay".
mike
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 6:29 PM
in response to: kupfer
|
|
Mike Kupfer wrote:
>
> >>>>> "Roland" == Roland Mainz <roland dot mainz at nrubsig dot org> writes:
>
> Casper> Root's shell needs to be POSIX compliant because?
>
> Roland> I was thinking more about having a (near-) POSIX-conformant
> Roland> shell around at startup time and single-user mode
>
> This is already available on most (all?) Linux distros, yes?
Yes, on Linux bash is used in "posix" mode and AFAIK on *BSD
> >> And what is preventing these followon projects to move the library?
>
> Roland> It needs to be ARC'ed - again. Based on the current resistance
> Roland> we will either get libshell in /lib now or simply forget such
> Roland> projects completely because in a second/third/etc. attempt we
> Roland> will face the same argumentation+resistance.
>
> Well, you'll get the same question, but I wouldn't take that as
> "resistance". If the follow-on project truly needs the library in /,
> you explain why it can't work with the library in /usr, and the ARC says
> "oh, okay".
The detail that libshell is being used should be an implementation
detail and not something which needs to be explicitly ARC'ed.
IMO most people who want to write a new project which has dependicies to
the boot process would look at the issue, read this discussion and then
would simply avoid the usage of libshell at all costs because it is
restricted to /usr.
Somehow this is really not what we wanted to archive - we wanted a shell
which is feature-rich, (more or less) POSIX-conformant, user-friendly,
i18n/l10n-capable and doesn't have any artificial restrictions on it's
usage. Putting libshell in /usr/lib instead of /lib simply kills the
last item and dramatically reduces the benefits of introducing
ksh93/libshell in Solaris.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 6:31 PM
in response to: gisburn
|
|
Roland Mainz wrote:
> Mike Kupfer wrote:
> > >>>>> "Roland" == Roland Mainz <roland dot mainz at nrubsig dot org> writes:
> >
> > Casper> Root's shell needs to be POSIX compliant because?
> >
> > Roland> I was thinking more about having a (near-) POSIX-conformant
> > Roland> shell around at startup time and single-user mode
> >
> > This is already available on most (all?) Linux distros, yes?
>
> Yes, on Linux bash is used in "posix" mode and AFAIK on *BSD
[that line wasn't finished, I hit "Send" instead "Store email in
drafts"... sorry... ]
... AFAIK on *BSD a POSIX-like shell is used, too.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 5:01 AM
in response to: gisburn
|
|
Roland Mainz writes:
> > Well, you'll get the same question, but I wouldn't take that as
> > "resistance". If the follow-on project truly needs the library in /,
> > you explain why it can't work with the library in /usr, and the ARC says
> > "oh, okay".
>
> The detail that libshell is being used should be an implementation
> detail and not something which needs to be explicitly ARC'ed.
I agree with that in part, but the architecturally relevant parts here
are:
- whether this belongs in the root file system, and
- whether this is intended to end up being used in other projects.
If it were purely an internal implementation detail and following all
of the usual standards (such as those in filesystem(5)), then it
wouldn't be an issue here.
> IMO most people who want to write a new project which has dependicies to
> the boot process would look at the issue, read this discussion and then
> would simply avoid the usage of libshell at all costs because it is
> restricted to /usr.
That's just broken.
We don't move things to root on speculation that someone may someday
like to have it there. There must be a _need_.
Furthermore, if it's really the case that people treat the rest of the
system as immutable, then that it's a real shame that they're led into
poor design as a result of that practice, but that's not a
consideration here.
If it is in fact the case that someone wants to use this shell or one
of its libraries before /usr is mounted, then we can easily move those
libraries to root at that time. The work involved is trivial.
> Somehow this is really not what we wanted to archive - we wanted a shell
> which is feature-rich, (more or less) POSIX-conformant, user-friendly,
> i18n/l10n-capable and doesn't have any artificial restrictions on it's
> usage. Putting libshell in /usr/lib instead of /lib simply kills the
> last item and dramatically reduces the benefits of introducing
> ksh93/libshell in Solaris.
I don't see it at all. No such special shell is needed before /usr is
mounted, so the shell isn't needed in root.
If you still must insist, then I think it's time to derail this case
and have a full review. Placing a new shell (plus a pile of attendant
libraries) into the root file system isn't an "obvious" change, and
thus this case no longer fits the definition of a fast-track.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
20
From:
Registered:
7/22/06
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:21 AM
in response to: carlsonj
|
|
On 9/21/06, James Carlson <james dot d dot carlson at sun dot com> wrote:
> Roland Mainz writes:
> > > Well, you'll get the same question, but I wouldn't take that as
> > > "resistance". If the follow-on project truly needs the library in /,
> > > you explain why it can't work with the library in /usr, and the ARC says
> > > "oh, okay".
> >
> > The detail that libshell is being used should be an implementation
> > detail and not something which needs to be explicitly ARC'ed.
>
> I agree with that in part, but the architecturally relevant parts here
> are:
>
> - whether this belongs in the root file system, and
>
> - whether this is intended to end up being used in other projects.
>
> If it were purely an internal implementation detail and following all
> of the usual standards (such as those in filesystem(5)), then it
> wouldn't be an issue here.
>
> > IMO most people who want to write a new project which has dependicies to
> > the boot process would look at the issue, read this discussion and then
> > would simply avoid the usage of libshell at all costs because it is
> > restricted to /usr.
>
> That's just broken.
>
> We don't move things to root on speculation that someone may someday
> like to have it there. There must be a _need_.
>
> Furthermore, if it's really the case that people treat the rest of the
> system as immutable, then that it's a real shame that they're led into
> poor design as a result of that practice, but that's not a
> consideration here.
>
> If it is in fact the case that someone wants to use this shell or one
> of its libraries before /usr is mounted, then we can easily move those
> libraries to root at that time. The work involved is trivial.
>
> > Somehow this is really not what we wanted to archive - we wanted a shell
> > which is feature-rich, (more or less) POSIX-conformant, user-friendly,
> > i18n/l10n-capable and doesn't have any artificial restrictions on it's
> > usage. Putting libshell in /usr/lib instead of /lib simply kills the
> > last item and dramatically reduces the benefits of introducing
> > ksh93/libshell in Solaris.
>
> I don't see it at all. No such special shell is needed before /usr is
> mounted, so the shell isn't needed in root.
>
> If you still must insist, then I think it's time to derail this case
> and have a full review. Placing a new shell (plus a pile of attendant
> libraries) into the root file system isn't an "obvious" change, and
> thus this case no longer fits the definition of a fast-track.
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
--
// Martin Schaffstall
// EMail: martin dot schaffstall at googlemail dot com
\\ //
\X/
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:39 AM
in response to: mschafft
|
|
>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
Martin, if you have nothing useful to add, then please butt out.
If you think we're being harsh on the ksh93 project's ARC case, then
that can only be because you've never seen any other ARC cases.
This bickering over details like this in cases of this size is the
norm and not an exception.
In the absence of previous experience, I can see how you can misconstrue
this as "resistance against ksh93" or perhaps even "personal attack
on Roland". And if you've worked long and hard on a project then you
sometimes "become" the project.
The ARC is here to look from a bigger distance at projects and examine
the overall picture.
And the bigger picture is simply this: all shells in Solaris live in
/usr except for /sbin/sh which is used for the very early bootstrap
process. Ergo, we see no reason to make ksh93 live in /sbin.
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 moved around if the need arises.
If not, then this case would open the doors for "but his ksh93 is in /sbin,
I want my bash/zsh/tcsh there too".
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 7:49 AM
in response to: mschafft
|
|
Martin Schaffstall wrote:
> 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
Once again, as in several previous threads, your only contribution
is to attack and discourage the people doing the work - I agree it
is no longer worth your wasting time contributing to this mailing
list and will be happy to see you leave so that we can work with
Roland to get ksh93 in Solaris, which everyone except you still wants
to happen.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 5:09 PM
in response to: mschafft
|
|
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 questions (even unpleasant ones) and to a full
review of the proposal and the design decisions. Almost all projects and
larger companies have such a process (for example mozilla.org has their
reviewers, super-reviewers and module maintainers for similar
purposes).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 1:30 AM
in response to: gisburn
|
|
>I think you will still get that answer when you ask in
>news:comp.unix.solaris (e.g. this knowledge doesn't seem to be
>well-known outside Sun...) ... ;-(
Yes, but that doesn't mean that the answer is basically "wrong" in
the sense that the answer usually includes arguments like:
- root's shell is used during boot (false)
- root's shell is used for certain scripts (false)
- root's shell should be statically linked (false, very much
so in Solaris 10)
Only the last answer was ever appropriate for earlier releases;
the second argument was partially appropriate when our /etc/rc?.d scripts
did not all start with #!.
>Uhm... I do not think it is "stupid" to split "/" and "/usr" - sometimes
>it is usefull to do it for performance or other reasons (like using
>seperate physical disks for "/" and "/usr") ...
For performance reasons? C'mon.
The reason a split "/" and "/usr" is *stupid* is fairly simple; there
are precious few scenarios which you can recover without /usr.
(E.g., you can *always* mount "/" because the kernel boots from it and
knows the boot device; but there are many scenarios where the /usr cannot
be mounted and where recovery is not possible, e.g., when the devices
pointing to the disk are not in the filesystem)
>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.
>I was thinking more about having a (near-) POSIX-conformant shell around
>at startup time and single-user mode, something which is easy to use,
>doesn't have the habit to turn the life of admins into a living hell in
>emergencies, can be used in jumpstart, pkgadd/pkgrm
>preinstall/postinstall/precheck/preremove/postremove scripts, boot time
>scripts and allow a high amount of "portability" between operating
>systems.
All of these need /usr present.
Also, you won't be able to use ksh93 for pkg* install scripts for a while
to come. At least not for scripts which are shipped as part of Solaris.
The reason is "liveupgrade" and other modes of operation where packages
are added while the tools are running on older revisions of the OS
(upto two or three releases back). So when ksh93 comes a standard item
in S11, you can not depend on it in pkg* tools until Solaris 13.
>Why should the installer be "broken" when it uses this choice by default
>? It is a valid choice in Unix to have "/" and "/usr" on seperate
>filesystems and it is AFAIK still needed for diskless client support and
>zones (please correct me if I am wrong).
Because the default is not helpful and leads to all sorts of issues
when space crunch happens.
There is NO good reason for a separate /usr on the root of a non-diskless
system.
There is NO good reason to grow "/" as opposed to "/usr" because there's
nothing you can do with just "/" mounted anyway.
>> Why? Why do we want to burden these programs with libshell?
>
>Why not ?
The onus is on the project team to provide arguments. As Dave said
"this is news to the SMF team".
I'm not saying that we should avoid using libshell in SMF at all costs,
but I have yet to see a reason, let alone a compelling reason, for it
to use libshell.
>- |libc::wordexp()| currently uses the old Solaris /usr/bin/ksh but
>should use "ksh93" in the future. Since libc sits in "/lib" it may be
>nice to have a copy of ksh93 in the root filesystem, too - otherwise
>|libc::wordexp()| will only work when "/usr" is mounted
So this currently doesn't work when /usr isn't mounted.
>- Replace some of the standalone commands with the libshell builtins
>(low-hanging fruits include "sleep", "pwd", "test" etc.)
All programs living in /usr
>- Think about { SMF, zone adminstration tool } which can be scripted
>(and do event-driven+conditional tasks) using shell functions and
>scripts (similar how dtksh/tksh can run shell functions as callback
>hooks)
All tools living in /usr.
>> The ARC has traditionally resisted "frameworks" which did not
>> have consumers; I see no concrete examples of such consumers.
>
>ksh93 has no "concrete consumers" either right now, too - using this
>kind of argumentation we could cancel this effort completely.
No, that's not true. "ksh93" is the project in itself and it is
clearly a usable and long-overdue addition to Solaris.
It is not a "framework" so it does not need consumers; but all the other
bits of ksh which are dumped all over the place are a framework
and I am still wondering why they need to be in /lib and /sbin.
>> And what is preventing these followon projects to move the library?
>
>It needs to be ARC'ed - again. Based on the current resistance we will
>either get libshell in /lib now or simply forget such projects
>completely because in a second/third/etc. attempt we will face the same
>argumentation+resistance. It's IMO useless to start projects or even
>consider them when there is little chanche of success.
I think you are taking the resistance entirely too personal; the
resistance against stuff in "/" is simply because there are no
arguments to do so. Once a project is submitted which requires
libshell to be moved to /lib then approval is a no-brainer.
>Think about pkg preinstall/postinstall/precheck/preremove/postremove
>scripts or custom install scripts which need to be run before "/usr"
>gets mounted...
There is no such situation. In the install situation, "/usr" is always
present. (And none of the install tools work when /usr is absent)
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 4:35 AM
in response to: casper
|
|
Casper.***@sun.com wrote:
> The reason a split "/" and "/usr" is *stupid* is fairly simple; there
> are precious few scenarios which you can recover without /usr.
>
> (E.g., you can *always* mount "/" because the kernel boots from it and
> knows the boot device; but there are many scenarios where the /usr cannot
> be mounted and where recovery is not possible, e.g., when the devices
> pointing to the disk are not in the filesystem)
This has been true in former times. Since we have the devfs on /devices, this
is most unlikely and would lead to a broken kernel.
> >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.
This is my impression too:
Let us have the smalles possible shell as /usr/bin/sh & /sbin/sh
> >- |libc::wordexp()| currently uses the old Solaris /usr/bin/ksh but
> >should use "ksh93" in the future. Since libc sits in "/lib" it may be
> >nice to have a copy of ksh93 in the root filesystem, too - otherwise
> >|libc::wordexp()| will only work when "/usr" is mounted
>
> So this currently doesn't work when /usr isn't mounted.
Correct.
> >- Replace some of the standalone commands with the libshell builtins
> >(low-hanging fruits include "sleep", "pwd", "test" etc.)
>
> All programs living in /usr
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 of trouble in the 1980s with SunOS when the machine
was unresponsive but my login shell did still work. I did type sync; sync
and then powercled.
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 4:41 AM
in response to: Joerg Schilling
|
|
>This has been true in former times. Since we have the devfs on /devices, this
>is most unlikely and would lead to a broken kernel.
"devfs" isn't really relevant; I think that it may now work since b48.
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 4:49 AM
in response to: casper
|
|
Casper.***@sun.com wrote:
>
>
> >This has been true in former times. Since we have the devfs on /devices, this
> >is most unlikely and would lead to a broken kernel.
>
> "devfs" isn't really relevant; I think that it may now work since b48.
What should this mean?
Does Solaris now correctly show /devices/ramdisk instead of /ramdisk
after the kernel has come up?
If defvs would be unusable for mounting existing devices; I would not be
able to mount the CD-ROM from Schillix since 16 months.
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
"sync" builtin in ksh93 ? / was: Re: [osol-arc] Re:
Re: Korn
Shell93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:44 PM
in response to: Joerg Schilling
|
|
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 of trouble in the 1980s with SunOS when the machine
> was unresponsive but my login shell did still work. I did type sync; sync
> and then powercled.
That's easy... :-)
... feel free to file an RFE at
http://bugs.grommit.com/enter_bug.cgi?product=ksh93-integration ... :-)
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
20
From:
Registered:
7/22/06
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:20 AM
in response to: casper
|
|
On 9/21/06, Casper.***@sun.com <Casper.***@sun.com> wrote:
>
> >I think you will still get that answer when you ask in
> >news:comp.unix.solaris (e.g. this knowledge doesn't seem to be
> >well-known outside Sun...) ... ;-(
>
>
> Yes, but that doesn't mean that the answer is basically "wrong" in
> the sense that the answer usually includes arguments like:
>
> - root's shell is used during boot (false)
> - root's shell is used for certain scripts (false)
> - root's shell should be statically linked (false, very much
> so in Solaris 10)
>
> Only the last answer was ever appropriate for earlier releases;
> the second argument was partially appropriate when our /etc/rc?.d scripts
> did not all start with #!.
>
> >Uhm... I do not think it is "stupid" to split "/" and "/usr" - sometimes
> >it is usefull to do it for performance or other reasons (like using
> >seperate physical disks for "/" and "/usr") ...
>
> For performance reasons? C'mon.
>
> The reason a split "/" and "/usr" is *stupid* is fairly simple; there
> are precious few scenarios which you can recover without /usr.
>
> (E.g., you can *always* mount "/" because the kernel boots from it and
> knows the boot device; but there are many scenarios where the /usr cannot
> be mounted and where recovery is not possible, e.g., when the devices
> pointing to the disk are not in the filesystem)
>
>
> >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 users with /sbin/sh.
Casper, could you elaborate why Sun is not willing to address the
problems with /sbin/sh and isn't even willing to support an
alternative, pls?
--
// Martin Schaffstall
// EMail: martin dot schaffstall at googlemail dot com
\\ //
\X/
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:24 AM
in response to: mschafft
|
|
>Sounds you like being a little sadist and punish users with /sbin/sh.
>Casper, could you elaborate why Sun is not willing to address the
>problems with /sbin/sh and isn't even willing to support an
>alternative, pls?
The current ARC case is about ksh93 integration; it is not about
replacing /sbin/sh with ksh93 or changing root's default shell.
In the context of the ARC case, your question does not make sense.
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
20
From:
Registered:
7/22/06
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:55 AM
in response to: casper
|
|
On 9/21/06, Casper.***@sun.com <Casper.***@sun.com> wrote:
>
>
> >Sounds you like being a little sadist and punish users with /sbin/sh.
> >Casper, could you elaborate why Sun is not willing to address the
> >problems with /sbin/sh and isn't even willing to sup***t an
> >alternative, pls?
>
> The current ARC case is about ksh93 integration; it is not about
> replacing /sbin/sh with ksh93 or changing root's default shell.
>
> In the context of the ARC case, your question does not make sense.
No, it makes sense in the context of this ARC case. /sbin/ksh93 would
be an alternative for boot scripts. /sbin/sh is a pain in the *** and
I am wondering why an alternative is not even considered
--
// Martin Schaffstall
// EMail: martin dot schaffstall at googlemail dot com
\\ //
\X/
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 7:46 AM
in response to: mschafft
|
|
Martin Schaffstall w***es:
> On 9/21/06, Casper.***@sun.com <Casper.***@sun.com> wrote:
> >
> >
> > >Sounds you like being a little sadist and punish users with /sbin/sh.
> > >Casper, could you elaborate why Sun is not willing to address the
> > >problems with /sbin/sh and isn't even willing to support an
> > >alternative, pls?
> >
> > The current ARC case is about ksh93 integration; it is not about
> > replacing /sbin/sh with ksh93 or changing root's default shell.
> >
> > In the context of the ARC case, your question does not make sense.
>
> No, it makes sense in the context of this ARC case. /sbin/ksh93 would
> be an alternative for boot scripts. /sbin/sh is a pain in the *** and
> I am wondering why an alternative is not even considered
Note that we're talking here _only_ about boot scripts that execute
before /usr is mounted read-only. That's really not very many.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 8:24 AM
in response to: mschafft
|
|
Martin Schaffstall w***e:
> On 9/21/06, Casper.***@sun.com <Casper.***@sun.com> wrote:
>>
>>
>> >Sounds you like being a little sadist and punish users with /sbin/sh.
>> >Casper, could you elaborate why Sun is not willing to address the
>> >problems with /sbin/sh and isn't even willing to support an
>> >alternative, pls?
>>
>> The current ARC case is about ksh93 integration; it is not about
>> replacing /sbin/sh with ksh93 or changing root's default shell.
>>
>> In the context of the ARC case, your question does not make sense.
>
> No, it makes sense in the context of this ARC case. /sbin/ksh93 would
> be an alternative for boot scripts. /sbin/sh is a pain in the *** and
> I am wondering why an alternative is not even considered
They *YOU* should convince the *project team* that they should add this
to the scope of *this* project. There are ARC members who have already
said they don't see it necessary for *this* case and it is better
addressed in the future. I don't see that anyone has said never, it is
more that we are trying to *help* get ksh93 into OpenSolaris and Solaris
as soon as possible - and that often means keeping the scope smaller
that some people might like.
--
Darren J Moffat
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:30 AM
in response to: mschafft
|
|
Martin Schaffstall wrote:
>> Because we need one shell and /sbin/sh suffices for now.
^^^^^^^^^^^^^^^^^
> Sounds you like being a little sadist and punish users with /sbin/sh.
> Casper, could you elaborate why Sun is not willing to address the
> problems with /sbin/sh and isn't even willing to support an
> alternative, pls?
Well I'm not Casper but here is my take on this.
*This* ARC case is just about adding ksh93 under that basename, it is
*NOT* addressing the replacement of the current /usr/bin/ksh or the
/usr/xpg4/bin/ksh (but does imply that it will happen at some time in
the future). When the project team brings that case forward then is the
time to talk about /sbin/sh being the ksh93 code (and I hope the project
team will actually propose that). At this time lets not burden the
project team with more work they have enough to do.
--
Darren J Moffat
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: Korn
Shell93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 4:56 PM
in response to: mschafft
|
|
Martin Schaffstall w***e:
> On 9/21/06, Casper.***@sun.com <Casper.***@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 users with /sbin/sh.
It would be nice to avoid attacking people at the personal level.
I agree with the opinion that /sbin/sh is a pain and we may be able to
address this issue somewhere in the future but this is not the subject
of this ARC case - and for now /sbin/sh is more or less sufficient to
get the system up and running. After this point it is no longer really
needed (except in emergencies in which case I was hoping for a
/sbin/ksh93 as an alternative - but the current objections from ARC made
this idea simply impossible).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: [osol-arc] Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 8:17 PM
in response to: mschafft
|
|
Martin Schaffstall w***e:
> On 9/21/06, Casper.***@sun.com <Casper.***@sun.com> wrote:
>> Because we need one shell and /sbin/sh suffices for now.
>
>
> Sounds you like being a little sadist and punish users with /sbin/sh.
> Casper, could you elaborate why Sun is not willing to address the
> problems with /sbin/sh and isn't even willing to support an
> alternative, pls?
Martin and others,
Please try and make a distinction between the various roles that
people are playing in this conversation, and don't jump to misinformed
conclusions about conspiracies...
Casper is involved in this discussion in his roles as a PSARC
Licensee, a Sun employed engineer, and as a member of the
opensolaris-arc community. In particular, he is not participating in
his role as a CAB member, nor does he even *have* a role as "policy
maker and spokesperson for Sun".
You should read his (and mine, and others) email as being one person's
opinion. Granted, Casper has considerable experience, but, like
anyone of us, he can be wrong, misinformed or even outvoted.
ARC Review is a discussion among senior engineers about the impact of
a project on OpenSolaris. The views expressed by the participants
certainly aren't set by Sun management, don't necessarily reflect
those of our sponsors, and probably won't even be understood by them.
In general, they are opinions based on past experience, and many
times reflect deep understandings of problems in areas that others
didn't even realize existed. As the ARC Review discussion progresses,
the participants on all sides are expected to learn and adapt so that,
over time, they converge on a mutually agreeable outcome. That
outcome isn't set in stone, and certainly isn't set by any single person.
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
evolution of both ksh93 *and* OpenSolaris with the minimum of disruption.
We now return to your regularly scheduled debate...
-John
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: [osol-arc] Re: Re: Korn
Shell93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 24, 2006 5:08 PM
in response to: plocher
|
|
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
> evolution of both ksh93 *and* OpenSolaris with the minimum of disruption.
What exactly is the problem with the idea to ship a merged libcmd with
Solaris Nevada ? The design is compatible to BOTH existing versions of
libcmd and in the not so distant future - maybe even before the Nevada
gates closes - all consumers of the |def*()| functions have been
switched over to the new API and then libcmd would be for AST (which
includes ksh93) and the Solaris commands only again.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Korn
Shell 93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 8:09 AM
in response to: casper
|
|
Casper.***@Sun.COM wrote:
> The reason a split "/" and "/usr" is *stupid* is fairly simple; there
> are precious few scenarios which you can recover without /usr.
I've tried to do this before, on an x86 machine which had a hardware
failure so we moved the disk to another machine, but the device paths
changed so only / could mount. It would have been very nice to have
a shell with builtins for the commands from /usr/bin working - while
"echo *" works for ls, it's not the same.
Having learned from that, I rarely make /usr a separate partition anymore,
though I also have the advantage of not having as high a security burden
as when I was setting up internet-exposed machines and making /usr read-only
for a small bit of protection against script kiddies with canned exploits
that tried to write there.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 9:03 AM
in response to: alanc
|
|
Alan Coopersmith <alan dot coopersmith at sun dot com> wrote:
> Casper.***@Sun.COM wrote:
> > The reason a split "/" and "/usr" is *stupid* is fairly simple; there
> > are precious few scenarios which you can recover without /usr.
>
> I've tried to do this before, on an x86 machine which had a hardware
> failure so we moved the disk to another machine, but the device paths
> changed so only / could mount. It would have been very nice to have
> a shell with builtins for the commands from /usr/bin working - while
> "echo *" works for ls, it's not the same.
Which OS release was this?
BTW: I would like to see find in /sbin as it helps to find nodes in /devices ;-)
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: [osol-arc] Re: Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 10:23 AM
in response to: casper
|
|
Casper.***@Sun.COM wrote:
> I'm not saying that we should avoid using libshell in SMF at all costs,
> but I have yet to see a reason, let alone a compelling reason, for it
> to use libshell.
[Intentionally not stepping into the / -vs /usr debate here...]
[The whole issue of SMF/libshell is out of scope for this project:
2006/550 - ksh93 integration]
Roland has given (IMHO) a very valid reason to do so - the SMF
community (which includes Roland and other non-"Sun internal SMF team"
people as well) is considering some interesting ways to innovate with
SMF and libshell. Now, it may be that the community isn't of one mind
in this particular issue or it may be that this discussion is more
about alternative visions of potential futures, but those are problems
that the community gets to deal with, not the ARCs
In the "governance" conversation, if a community wishes to go down a
path of discovery and experimentation to see if they can come up with
interesting features, they are free to do so; nobody outside that
community is empowered to make the "do we want to do this?" decisions
for them.
Even the ARC process can't counteract that resolve; all it can do as
it addresses the related question of "is this the best way to do it?"
is to require the community to better articulate its desires (NEED
SPEC or "REJECTED - go back and start over") or have it change the
architecture/design of their proposed implementation (TCR/TCA).
Just because Sun engineers aren't playing in that particular part of
the sandbox doesn't mean that nobody else will; nor does it imply that
those other parts of the sandbox are inherently bad (always excepting
cats, of course :-)
-John
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
370
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93
Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:40 PM
in response to: gisburn
|
|
On Thu, Sep 21, 2006 at 12:07:36AM +0200, Roland Mainz wrote:
> > And I also suggest we move all ksh93 libaries to /usr/lib with
> > the needed exception of libcmd.
>
> <blink><marquee>DEFINATELY NO</marquee></blink>. At some point we will
> have followup projects and many of them (like SMF) simply need libshell
> in the root filesystem because the consumers live there, too.
That's an interesting assertion. Could you elaborate?
I know little about libshell, but I'll admit the possibility that it
offers truly compelling functionality. That said, as a member of the
SMF team, the fact that SMF "simply needs" libshell is news to me.
Dave
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
libshell&&SMF / was: Re: Re: Korn Shell
93 Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 6:01 PM
in response to: dep
|
|
David Powell wrote:
> On Thu, Sep 21, 2006 at 12:07:36AM +0200, Roland Mainz wrote:
> > > And I also suggest we move all ksh93 libaries to /usr/lib with
> > > the needed exception of libcmd.
> >
> > <blink><marquee>DEFINATELY NO</marquee></blink>. At some point we will
> > have followup projects and many of them (like SMF) simply need libshell
> > in the root filesystem because the consumers live there, too.
>
> That's an interesting assertion. Could you elaborate?
Yes, but it would be nice to start a seperate thread for this because
this is IMO hightly offtopic for this ARC case...
> I know little about libshell, but I'll admit the possibility that it
> offers truly compelling functionality. That said, as a member of the
> SMF team, the fact that SMF "simply needs" libshell is news to me.
We've been experimenting with some ideas to add things like event-driven
actions and scripting functionlity to SMF. The idea is to have a
dbx/dtksh/tksh-like "shell" interface which contains a couple of
additional things on top of ksh93/libshell, including:
- New builtin commands to control SMF services (like "enable",
"disable", "restart", "refresh", "mark", "clear", "milestone",
"setcurrentservice", "getcurrentservice", "catch", "commit" etc.) and
it's processes (including a way to set the process "projectid", "renice"
all processes belonging to a service (AFAIK these features are missing
in SMF) etc.)
- New variables (maintained by discipline functions) which can be used
to get/set the status (and other attributes) of services (where setting
a variable can either have an immediate effect or execute the changes
when the "commit" command is used)
- The ability to register "callback" functions for specific events (for
example: service started/start completed/terminated/failed (or better:
pre-,poststart/pre-,postshutdown/pre-,postenable/pre-,postdisable/pre-,postma rk/failed/error/manifest_loaded/DOM-events
for manifest changes etc.) etc.)
- The ability to read/modify/write+override SMF manifests (somewhere we
have a SAX+DOM implementation for ksh93 floating around which may be
usefull)
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
370
From:
Registered:
3/9/05
|
|
|
|
Re: libshell&&SMF / was: Re: Re: Korn
Shell 93 Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 1:00 PM
in response to: gisburn
|
|
On Thu, Sep 21, 2006 at 03:02:35AM +0200, Roland Mainz wrote:
> David Powell wrote:
> > On Thu, Sep 21, 2006 at 12:07:36AM +0200, Roland Mainz wrote:
> > > > And I also suggest we move all ksh93 libaries to /usr/lib with
> > > > the needed exception of libcmd.
> > >
> > > <blink><marquee>DEFINATELY NO</marquee></blink>. At some point we will
> > > have followup projects and many of them (like SMF) simply need libshell
> > > in the root filesystem because the consumers live there, too.
> >
> > That's an interesting assertion. Could you elaborate?
>
> Yes, but it would be nice to start a seperate thread for this because
> this is IMO hightly offtopic for this ARC case...
Quite the contrary: this appears to be an important part of your
justification for including libshell in /lib, and your justification
for including libshell in /lib is an important part of an ARC case
that proposes putting it there.
> > I know little about libshell, but I'll admit the possibility that it
> > offers truly compelling functionality. That said, as a member of the
> > SMF team, the fact that SMF "simply needs" libshell is news to me.
>
> We've been experimenting with some ideas to add things like event-driven
> actions and scripting functionlity to SMF. The idea is to have a
> dbx/dtksh/tksh-like "shell" interface which contains a couple of
> additional things on top of ksh93/libshell, including:
This all sounds fascinating, but these projects don't exist yet.
They are neither defined by this proposal, nor any other formal
proposal submitted to the ARC. We don't know when such changes will
happen, or if they will happen at all.
There might be good reasons for shipping libshell in /lib (to
millions of OpenSolaris users), but the anticipation of possible
projects that might someday happen isn't one.
Dave
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: Re: Korn Shell 93
Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 3:42 AM
in response to: gisburn
|
|
Roland Mainz <roland dot mainz at nrubsig dot org> wrote:
> Casper.***@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 single-user mode, when dealing with filesystem
> > >problems.
> >
> > I don't think that's a strong enough reason:
> >
> > - you can already use any shell as root shell; is /usr isn't
> > mounted /sbin/sh is used instead.
>
> Do you mean replacing "root"'s login shell in /etc/passwd with any shell
> ? Where is this documented (AFAIK the recommentation over all the years
> was "... don't do that. Never. Don't touch it or your system will
> explode (sooner or later) ...") ?
If you really like to put ksh93 into / you would need to have extra hooks for
all needed shared libs in /lib. Dou you really like to do this?
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Extra hooks for ksh93 libraries ? / was: Re: [osol-arc] Re:
Re: Korn Shell
93Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 6:46 PM
in response to: Joerg Schilling
|
|
Joerg Schilling wrote:
> Roland Mainz <roland dot mainz at nrubsig dot org> wrote:
> > Casper.***@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 single-user mode, when dealing with filesystem
> > > >problems.
> > >
> > > I don't think that's a strong enough reason:
> > >
> > > - you can already use any shell as root shell; is /usr isn't
> > > mounted /sbin/sh is used instead.
> >
> > Do you mean replacing "root"'s login shell in /etc/passwd with any shell
> > ? Where is this documented (AFAIK the recommentation over all the years
> > was "... don't do that. Never. Don't touch it or your system will
> > explode (sooner or later) ...") ?
>
> If you really like to put ksh93 into / you would need to have extra hooks for
> all needed shared libs in /lib. Dou you really like to do this?
What do you mean with "extra hooks" ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 5:21 AM
in response to: casper
|
|
Casper.***@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 single-user mode, when dealing with filesystem
>> problems.
>
> I don't think that's a strong enough reason:
>
> - you can already use any shell as root shell; is /usr isn't
> mounted /sbin/sh is used instead.
>
> By this reasoning, we should add bash/zsh/tcsh/csh there too.
>
> If you have a separate /usr, well, you pretty much deserve the
> barebones system you get.
... and when we have ZFS boot it is very unlikely that you would be able
to have a / and /usr out of the same pool where / is available but /usr
is not.
IMO /usr as a separate file system is a dead concept and is no longer
relevant, however the / /usr packaging split is not (it is an important
distinction).
--
Darren J Moffat
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
ZFS and '/'+'/usr' split / was: Re: Re:
Korn Shell 93 Integration[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 4:23 PM
in response to: darrenm
|
|
Darren J Moffat wrote:
> Casper.***@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 single-user mode, when dealing with filesystem
> >> problems.
> >
> > I don't think that's a strong enough reason:
> >
> > - you can already use any shell as root shell; is /usr isn't
> > mounted /sbin/sh is used instead.
> >
> > By this reasoning, we should add bash/zsh/tcsh/csh there too.
> >
> > If you have a separate /usr, well, you pretty much deserve the
> > barebones system you get.
>
> .. and when we have ZFS boot it is very unlikely that you would be able
> to have a / and /usr out of the same pool where / is available but /usr
> is not.
>
> IMO /usr as a separate file system is a dead concept and is no longer
> relevant, however the / /usr packaging split is not (it is an important
> distinction).
I do not agree. ZFS is really not the solution for all problems.
ZFS has great problems with performace, resource usage (the memory usage
is excessive compared to both QFS and UFS) and lacks even basic features
needed for HPC applications (like guranteed bandwith or moving the inode
data on a seperate physical disk (for example QFS can do that)) - and
baased on the discussions on zfs-discuss I think we will not see such
features in the forseeable future. AFAIK Holger Berger and his team
evaluated ZFS a while ago and their results were not promising (compared
to XFS, QFS, VxFS, ReiserFS and a bunch of other filesystems on various
operating systems).
IMO the design and requirements should not depend on a specific
filesystem.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:48 PM
in response to: April Chin
|
|
April Chin wrote:
> > Whoot, Whoot! Its about time (even if this isn't currently called ksh).
> >
> > One minor comment:
> >
> > /sbin/ksh93 32-bit korn shell (2nd copy)
> > /sbin/pfksh93 hard link to /sbin/ksh93
> > /sbin/rksh93 hard link to /sbin/ksh93
> >
> > Do we need these any more than /sbin/bash, /sbin/zsh, ... ?
>
> 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 single-user mode, when dealing with filesystem
> problems.
And I forgot about the "jumpstart" thing. The lack of a decent shell
during jumpstart runtime is annoying, too.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:16 PM
in response to: gisburn
|
|
>And I forgot about the "jumpstart" thing. The lack of a decent shell
>during jumpstart runtime is annoying, too.
/usr is there during jumpstart.
Casper
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
April Chin
April.Chin@eng.sun.com
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 2:23 PM
in response to: Don Cragun
|
|
Yes, ksh93 and pfksh93 will be added to getusershell(3c).
The manpage changes in the case include getusershell.3c changes,
including the addition of /usr/bin/{ksh93,pfksh93}, /bin/{ksh93,pfksh93},
and /sbin/{ksh93,pfksh93), but not rksh93, as Casper points out.
The restricted shells should not be included.
April
> Date: Wed, 20 Sep 2006 13:32:11 -0700 (PDT)
> From: Gary Winiger <gww at tundra dot sfbay dot sun dot com>
> To: PSARC-EXT at sac dot sfbay dot sun dot com, don dot cragun at sun dot com
> Cc: April dot Chin at eng dot sun dot com, ksh93-integration-discuss at opensolaris dot org,
roland dot mainz at nrubsig dot org
> Subject: Re: Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:
09/27/2006]
>
> > Interface Description
> > --------- -----------
> > /usr/bin/ksh93 the korn shell
> > /usr/bin/pfksh93 profile shell
> > /usr/bin/rksh93 restricted shell
>
> Will these be added to getusershell(3C) or will an /etc/shells
> be delivered with these and the other "legal user shell"s?
>
> Gary..
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Tim Marsland
tpm@eng.sun.com
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 3:57 PM
in response to: April Chin
|
|
Though I don't think this is part of this proposal ... as for
changing the default root shell (which we should, because the existing
choice is awful) wouldn't we change it to bash so as to be finger
compatible with the rest of the world?
As for the compatibility issues in this case, I'd prefer to see a
proposal that splits what we'd do "looking backwards" to S9 and S10
where compatibility expectations are extremely high, and what
we'd do "looking forwards" in Nevada, where minor-release compatibility
expectations (and the resulting complexity) are intrinsically lower.
tim
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
April Chin
April.Chin@eng.sun.com
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 4:36 PM
in response to: Don Cragun
|
|
> Date: Wed, 20 Sep 2006 14:15:02 -0700
> From: Mike Oliver <Mike dot Oliver at Sun dot COM>
>
> BTW, the second paragraph in item 1 of the COMPAT summary:
>
> In ksh93, local variables only exist for POSIX-style
> (func()) functions. In non-POSIX-style functions, variables
> declared with "typeset var" remain global in scope, and are shared
> between the calling program and the function.
>
> is incorrect. It's the POSIX-style functions that always operate on
> global variables. Non-POSIX functions retain the ability to create
> local variables via 'typedef'.
Thanks for the correction. Yes, what it should say is:
In ksh93, local variables only exist for non-POSIX-style
(function func) functions. In POSIX-style functions (func()),
variables declared with "typeset var" remain global in scope,
and are shared between the calling program and the function.
Sorry about that.
>
<http://
> gets this right, although it's wrong about non-POSIX functions
> maintaining backwards compatibility. For one thing, the behaviour
> of a local variable in ksh93 is incompatible with the existing
> Solaris ksh because the semantics of a variable's "readonly"
> ('typeset -r') attribute are very different.
Can you elaborate, please? It sounds like something else to be
added to the compatibility list.
Thanks,
April
>
> Mike.
> --
> mike dot oliver at sun dot com
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
David Korn
dgk@research.att.com
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 7:29 PM
in response to: April Chin
|
|
> On Wed, Sep 20, 2006 at 04:23:57PM -0400, James Carlson wrote:
> > Don Cragun writes:
> > > standard-compliant /usr/xpg4/bin/sh with ksh93. Thus this project
> > > needs to be aware of potential compatibility problems. See COMPAT file
> > > for a list of known incompatibilities between ksh93 and Solaris ksh.
> >
> > What's the plan here? Some of those incompatibilities seem rather
> > stark to me. Will incompatible changes be made to the open source
> > version in order to keep compatibility with the old ksh? Or will the
> > Solaris-integrated ksh93 be made incompatible with the open source
> > version? Or do we intend to break compatibility in our own
> > /usr/bin/ksh in the future?
> >
> > I realize that the complete set of answers might not yet be known, but
> > is there a plan of some sort?
>
> Incompatibility (1) seems likely to break a lot of scripts (I am fond of
> function() function-declaration syntax, so my scripts would break).
This is the imcompatibility that is most likely to effect existing
scripts. There are a few ways to minimize this.
1. Add local variables to name() functions.
2. Detect name() functions with local variables when reading the script
and treat these as if the user had entered function name.
3. Detect name() functions with local variables when reading the script
and exec ksh88
on this script.
It would be easy to implement #2 but it could break some existing ksh93
scripts that assume that you can use typeset to declare global
variables with attributes.
>
> Incompatibility (9)... Does this mean pattern matching in the same
> statement/command? Or subsequently for the rest of the script? Sounds
> like a bug.
I don't get what your concern is? Some changes were consequenses
of the posix standard. For example, the 126 and 127 exit codes
are not compatible with earlier shells. I can't say that I have ever
gotten an e-mail about a script that broke becasue of (9).
>
> I don't understand (6).
In earlier version of ksh.
echo $'foo'
would output
$foo
not the value will be
foo
Also echo $'foo\nbar'
will not output
foo
bar
not
$foo\nbar
>
> (10) will almost certainly break scripts.
This is not accurate. This only applies to new builtins. Builtins that were
builtins in earlier versions are still executed first. Only new builtins
not necessarily executed first.
>
> (12) could be finnessed (one signal per-line if stdout is a pipe, say).
I don't know what this ahs to do with (12).
>
> I'm guessing most of these could be finessed so that when invoked as
> "ksh" they go away.
>
> Nico
> --
> _______________________________________________
> ksh93-integration-discuss mailing list
> ksh93-integration-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
>
David Korn
dgk at research dot att dot com
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,422
From:
Austin, TX, USA
Registered:
6/15/05
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 7:05 AM
in response to: David Korn
|
|
On Wed, Sep 20, 2006 at 10:29:17PM -0400, David Korn wrote:
> > Incompatibility (1) seems likely to break a lot of scripts (I am fond of
> > function() function-declaration syntax, so my scripts would break).
> This is the imcompatibility that is most likely to effect existing
> scripts. There are a few ways to minimize this.
> 1. Add local variables to name() functions.
> 2. Detect name() functions with local variables when reading the script
> and treat these as if the user had entered function name.
> 3. Detect name() functions with local variables when reading the script
> and exec ksh88
> on this script.
> It would be easy to implement #2 but it could break some existing ksh93
> scripts that assume that you can use typeset to declare global
> variables with attributes.
#1 sounds like the way to go.
#3... needs to deal with source of scripts as well.
> > I don't understand (6).
> In earlier version of ksh.
As April replied, we're not looking at the same list!
Nico
--
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
April Chin
April.Chin@eng.sun.com
|
|
|
|
Re: Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 20, 2006 11:12 PM
in response to: April Chin
|
|
The item numbers in the COMPAT file that are part of the PSARC case
are slightly different than those in the ksh88 vs. ksh93 COMPATIBILITY file
from AT&T that David may be referencing. The COMPAT file in the case
is based on the AT&T one but is specific to Solaris ksh (based
on ksh88 but has diverged) versus ksh93.
I've attached the COMPAT file from the ARC case with item #1 corrected
per Mike Oliver's comments; I had reversed the description of
the POSIX and non-POSIX function behavior.
Sorry for the confusion.
Thanks,
April
> X-Original-To: ksh93-integration-discuss at opensolaris dot org
> Delivered-To: ksh93-integration-discuss at opensolaris dot org
> Date: Wed, 20 Sep 2006 22:29:17 -0400 (EDT)
> From: David Korn <dgk at research dot att dot com>
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> To: ksh93-integration-discuss at opensolaris dot org
> Subject: Re: [ksh93-integration-discuss] Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
> Cc: don dot cragun at Sun dot COM, PSARC-EXT at sac dot sfbay dot sun dot com, Nicolas dot Williams at Sun dot COM
> X-BeenThere: ksh93-integration-discuss at opensolaris dot org
> X-Mailman-Version: 2.1.4
> List-Id: Korn Shell 93 integration/migration project discussion
<ksh93-integration-discuss.opensolaris.org>
> List-Unsubscribe:
<http://,
<mailto:ksh93-integration-discuss-request at opensolaris dot org?subject=unsubscribe>
> List-Archive:
<http://
> List-Post: <mailto:ksh93-integration-discuss at opensolaris dot org>
> List-Help:
<mailto:ksh93-integration-discuss-request at opensolaris dot org?subject=help>
> List-Subscribe:
<http://,
<mailto:ksh93-integration-discuss-request at opensolaris dot org?subject=subscribe>
>
>
> > On Wed, Sep 20, 2006 at 04:23:57PM -0400, James Carlson wrote:
> > > Don Cragun writes:
> > > > standard-compliant /usr/xpg4/bin/sh with ksh93. Thus this project
> > > > needs to be aware of potential compatibility problems. See COMPAT file
> > > > for a list of known incompatibilities between ksh93 and Solaris ksh.
> > >
> > > What's the plan here? Some of those incompatibilities seem rather
> > > stark to me. Will incompatible changes be made to the open source
> > > version in order to keep compatibility with the old ksh? Or will the
> > > Solaris-integrated ksh93 be made incompatible with the open source
> > > version? Or do we intend to break compatibility in our own
> > > /usr/bin/ksh in the future?
> > >
> > > I realize that the complete set of answers might not yet be known, but
> > > is there a plan of some sort?
> >
> > Incompatibility (1) seems likely to break a lot of scripts (I am fond of
> > function() function-declaration syntax, so my scripts would break).
> This is the imcompatibility that is most likely to effect existing
> scripts. There are a few ways to minimize this.
> 1. Add local variables to name() functions.
> 2. Detect name() functions with local variables when reading the script
> and treat these as if the user had entered function name.
> 3. Detect name() functions with local variables when reading the script
> and exec ksh88
> on this script.
> It would be easy to implement #2 but it could break some existing ksh93
> scripts that assume that you can use typeset to declare global
> variables with attributes.
> >
> > Incompatibility (9)... Does this mean pattern matching in the same
> > statement/command? Or subsequently for the rest of the script? Sounds
> > like a bug.
> I don't get what your concern is? Some changes were consequenses
> of the posix standard. For example, the 126 and 127 exit codes
> are not compatible with earlier shells. I can't say that I have ever
> gotten an e-mail about a script that broke becasue of (9).
> >
> > I don't understand (6).
> In earlier version of ksh.
> echo $'foo'
> would output
> $foo
> not the value will be
> foo
> Also echo $'foo\nbar'
> will not output
> foo
> bar
> not
> $foo\nbar
> >
>
> > (10) will almost certainly break scripts.
> This is not accurate. This only applies to new builtins. Builtins that were
> builtins in earlier versions are still executed first. Only new builtins
> not necessarily executed first.
> >
> > (12) could be finnessed (one signal per-line if stdout is a pipe, say).
> I don't know what this ahs to do with (12).
> >
> > I'm guessing most of these could be finessed so that when invoked as
> > "ksh" they go away.
> >
> > Nico
> > --
> > _______________________________________________
> > ksh93-integration-discuss mailing list
> > ksh93-integration-discuss at opensolaris dot org
> > http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
> >
>
> David Korn
> dgk at research dot att dot com
> _______________________________________________
> ksh93-integration-discuss mailing list
> ksh93-integration-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
INCOMPATIBLITIES BETWEEN ksh93s- and Solaris /usr/bin/ksh
Of these incompatibilities, the more serious are:
#1, #4, #5, #8, #9, #10, #13, and possibly #6.
1) In Solaris ksh, in both POSIX-style functions, declared as "func()"
and in non-POSIX-style functions, declared as "function func",
variables can be declared local to that function and all functions
it calls using the typeset special command, e.g., "typeset var".
In ksh93, local variables only exist for non-POSIX-style
(function func) functions. In POSIX-style functions (func()),
variables declared with "typeset var" remain global in scope,
and are shared between the calling program and the function.
2) In Solaris ksh, "alias -x" lists the exported aliases. In ksh93,
alias -x exits 0 and outputs nothing. However in Solaris ksh, exported
aliases do not work any differently than non-exported aliases.
3) In Solaris ksh, a dollar sign ($') followed by a single quote
is interpreted literally. In ksh93, you must escape the dollar
sign to get the previous behavior. Similarly, the dollar
sign ($") preceding a double quote in Solaris ksh must be escaped.
In ksh93, a $"..." string indicates a string to be translated
for locales other than C or POSIX.
Example:
In Solaris ksh: In ksh93:
% echo $'foo' % echo $'foo'
$foo foo
% echo $"foo" % echo $"foo"
$foo foo
% echo \$'foo' % echo \$'foo'
$foo $foo
% echo \$"foo" % echo \$"foo"
$foo $foo
4) In Solaris ksh, the exit status of a command that terminated because
it received a signal is 128+<signal #>. In ksh93, it is 256+<signal #>.
Users should therefore not be relying on specific exit values,
other than 0 for success or non-zero otherwise.
5) New built-ins in ksh93.
ksh93 will include several built-ins which are not built-ins in Solaris ksh,
and, if executed without a pathname prefix, may be run in place of the
corresponding Solaris /usr/bin binaries on the path:
printf
sleep
and these built-ins, which are executed if the corresponding /bin executable
is found on the path before any other:
cat
chown
head
mkdir
rmdir
tee
uniq
wc
Three known incompatibilities exist in the printf, mkdir, and uniq
built-ins ksh93, which are based upon POSIX requirements.
They are considered bugs, and it is expected that AT&T will
fix these shortly before or after ksh93 integrates into Solaris.
See builtin.bugs file for details.
6) Some built-ins don't allow options to be passed in any order as they
did previously. One known case is "typeset -8i <variable>", which
no longer works the same as "typeset -i8 <variable>" to set
an integer variable that is base 8.
7) The ENV variable in ksh93 is now evaluated for arithmetic expansions
$((<arithmetic value>)) and command substitution `<command>`
In Solaris ksh, it is not. Previous uses of ` and $( as
literal values in the ENV variable must be escaped with \.
This won't be an issue for scripts, which do not execute the
file pointed to by ENV. No problems are anticipated for this case.
8) The ERRNO variable has been dropped in ksh93.
9) In ksh93, pattern matching following a redirection symbol works only
in interactive shell, not in scripts.
10) In ksh93, the original arguments ($1, $2, $3, etc.) to a script
are restored after a dot script (. <script> <arg1> <arg2> ...)
is executed. In Solaris ksh, the original arguments are cleared
and replaced by any dot script arguments.
11) In ksh93, tracked aliases are only listed with "alias -t", not
with "alias" alone. Solaris ksh lists tracked aliases with both
"alias" and "alias -t".
12) "kill -l" in Solaris ksh lists all the signal names on a single line
"kill -l" in ksh93 lists each signal name on a separate line.
13) In arithmetic expansions, e.g., $((<arithmetic expr>)),
Solaris /usr/bin/ksh will interpret numbers starting with 0 (and not
starting with 0x or 0X) as decimal, not octal.
For example: $((010)) is a decimal 10, not an 8.
In /usr/xpg4/bin/sh and ksh93, $((010)) is interpreted as an octal,
so it is 8.
This behavior is the one difference between Solaris /usr/bin/ksh
and /usr/xpg4/bin/sh.
ksh93 additionally differs from the standard Solaris ksh (/usr/xpg4/bin/sh)
in one other way with respect to this feature, in that, although ksh93
recognizes octal *constants* in an arithmetic expansion, it does not
interpret *variables* containing numbers starting with 0, as octal
in an arithmetic expansion.
That is:
a=010
$(($a)) or $((a)) in ksh93 is a decimal 10
$(($a)) or $((a)) in /usr/xpg4/bin/sh is an octal number, so it is 8
For UNIX03 standards conformance, the above needs to be interpreted
as an octal.
14) In ksh93, the behavior of Ctrl-T in emacs mode is slightly different
than in Solaris ksh. In ksh93, in emacs mode, Ctrl-T transposes
the current and one previous character and moves the cursor
to the next character. In Solaris ksh, in emacs mode, Ctrl-T
transposes the current and *next* character and moves
the cursor position over one (to the old current character).
This is feature is only available for interactive korn shell.
15) In Solaris ksh, if /usr/ucb/echo is found first on the path,
the built-in echo command will try to emulate /usr/ucb/echo:
it supports the -n option to eliminate the newline at the
end of the string, and it will NOT understand the backslash escapes,
such as \t, \n, \a, etc.
ksh93 built-in echo does not try to emulate /usr/ucb/echo.
16) In emacs mode, Ctrl-V no longer prints the shell version number.
Instead, Ctrl-V is now a general escape character, which allows
one to enter any character using Ctrl-V<character>.
17) In ksh93, for all interactive shells, if there exists an
/etc/ksh.kshrc file, it will be executed before the file named by
the ENV environment variable ($HOME/.kshrc, by default).
Solaris ksh does not execute /etc/ksh.kshrc.
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 3:56 AM
in response to: April Chin
|
|
April Chin writes:
> Thanks for the correction. Yes, what it should say is:
>
> In ksh93, local variables only exist for non-POSIX-style
> (function func) functions. In POSIX-style functions (func()),
> variables declared with "typeset var" remain global in scope,
> and are shared between the calling program and the function.
I've updated the 'COMPAT' file.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
April Chin
April.Chin@eng.sun.com
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 1:37 AM
in response to: Don Cragun
|
|
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Wed, 20 Sep 2006 16:23:57 -0400
> From: James Carlson <james dot d dot carlson at sun dot com>
> To: Don Cragun <don dot cragun at sun dot com>
> Cc: PSARC-EXT at sac dot sfbay dot sun dot com, April dot Chin at eng dot sun dot com,
ksh93-integration-discuss at opensolaris dot org, roland dot mainz at nrubsig dot org
> Subject: Re: Korn Shell 93 Integration [PSARC-EXT/2006/550 Timeout:
09/27/2006]
>
> Don Cragun writes:
> > It is the goal of the project team to keep ksh93 in the Solaris operating
> > system updated with AT&T's latest version of ksh93 and its supporting
> > libraries. Thus it will be important to keep Solaris ksh93 source in sync,
> > including contributing Solaris-specific changes back to the
> > AT&T source.
>
> With an Uncommitted stability level, you won't be able to make
> incompatible patches for the ksh93 scripting interface once Nevada
> ships. Is that the intended solution? Is a snapshot once per minor
> release enough of an update frequency?
My understanding is that David Korn is very committed to compatibility, so
we should be able to update more frequently than once per minor release.
>
> Will at least some parts of the scripting interface eventually be
> Committed? It seems that they will need to be, if ksh replacement is
> one of the goals.
Yes, we intend to move toward a Committed interface for ksh93
before it replaces /usr/bin/ksh.
>
> > standard-compliant /usr/xpg4/bin/sh with ksh93. Thus this project
> > needs to be aware of potential compatibility problems. See COMPAT file
> > for a list of known incompatibilities between ksh93 and Solaris ksh.
>
> What's the plan here? Some of those incompatibilities seem rather
> stark to me. Will incompatible changes be made to the open source
> version in order to keep compatibility with the old ksh?
Most of these incompatibilities originated from the AT&T ksh88 vs. ksh93
document. I don't think we'd be able to break ksh93 compatibility
for Solaris ksh compatibility, but it sounds like David Korn
is willing to consider some solutions.
> Or will the
> Solaris-integrated ksh93 be made incompatible with the open source
> version?
We want to keep Solaris ksh93 & the open source version
the same as much as possible. There may be uncommon cases, however, where we
will need to add #ifdef Solaris code to the open source version.
> Or do we intend to break compatibility in our own
> /usr/bin/ksh in the future?
This will likely be the case, and we will need to manage this.
>
> I realize that the complete set of answers might not yet be known, but
> is there a plan of some sort?
We've discussed various things--having incompatibilities handled
or reported dynamically, migration scripts to fix or report on
incompatibilities, keeping the old ksh binary around--but further research
is needed before we can say what the right approach to this is.
>
> > This project will also introduce built-in commands in ksh93, which have
> > a superset of the functionality of the corresponding Solaris /usr/bin
> > commands (see Section 4.3 Description). These ksh93 built-in commands
> > may lead to the future replacement of the source of some existing /usr/bin
> > commands with the corresponding AT&T code used by the ksh93 built-ins.
>
> When does this happen? The duplication of code here seems rather
> extensive. Unless there's a good plan to eliminate that duplication,
> I think this might be a reason to have a written opinion.
>
> > ksh93s- is under the Common Public License which allows Sun to
> > freely redistribute a derived verison of ksh93, provided Sun includes
> > the license terms and does not encumber it with any proprietary changes.
>
> What does that mean? Does it mean that we're not able to maintain our
> own code, or is it a licensing issue?
It's a licensing issue, but I believe the requirement is mis-paraphrased.
Any changes we make to ksh93 must allow us to grant the copyright
licenses in the CPL. It's probably better worded as follows:
ksh93s- is under the Common Public License, which allows Sun to
freely redistribute a derived version of ksh93, provided Sun includes
the license terms and any changes we make allow us to grant the
copyright licenses in the CPL.
>
> (I would have expected to see "any additional licensing terms" or some
> such. Seeing the word "changes" here is jarring, and seems to imply
> that we're not able to maintain our own code because the changes would
> be "proprietary.")
>
> > /sbin/ksh93 32-bit korn shell (2nd copy)
> > /sbin/pfksh93 hard link to /sbin/ksh93
> > /sbin/rksh93 hard link to /sbin/ksh93
>
> Why is ksh93 needed before /usr is mounted?
>
> This seems wasteful to me. If anything, we should be doing away with
> cases where /usr isn't mounted rather than engorging the root file
> system.
>
> > libshell - contains functions used for writing extensions
> > to ksh93 or for potentially embedding shell command
> > processing into other commands, such as dbx.
> > Most of ksh93 is contained in this library; the ksh93
> > binary itself is primarily a set of calls to libshell interfaces.
>
> How does this square with the existing libtecla? Should we remove
> libtecla?
>
> > Since most of these undocumented built-ins are not currently compatible
> > with the corresponding Solaris commands in /usr/bin, these built-ins
> > will be bound to the new pathname /usr/ast/bin. Unlike the /bin
> > pathname binding, the /usr/ast/bin pathname binding does not require
> > that the /usr/ast/bin directory exists.
>
> It looks like we're building a parallel universe under /usr/ast.
>
> Is there any chance that this goes away in a future version, or are we
> stuck carrying the /usr/ast baggage forever? (In other words: is this
> part of the intentional design here, or is it just a temporary
> work-around?)
I believe Roland intends for this to be temporary. There will not
actually be any /usr/ast files or binaries.
April
>
> --
> James Carlson, KISS Network <james dot d dot carlson at sun dot com>
> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Korn Shell 93 Integration
[PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 4:51 AM
in response to: April Chin
|
|
April Chin writes:
> > I realize that the complete set of answers might not yet be known, but
> > is there a plan of some sort?
>
> We've discussed various things--having incompatibilities handled
> or reported dynamically, migration scripts to fix or report on
> incompatibilities, keeping the old ksh binary around--but further research
> is needed before we can say what the right approach to this is.
OK. I think it'd be good to have more details on this, as it seems
that a large part of this project team's overall plan is to do that
replacement.
> > Is there any chance that this goes away in a future version, or are we
> > stuck carrying the /usr/ast baggage forever? (In other words: is this
> > part of the intentional design here, or is it just a temporary
> > work-around?)
>
> I believe Roland intends for this to be temporary. There will not
> actually be any /usr/ast files or binaries.
In that case, adding the modifier "Obsolete" to the stability level
would probably be the right thing to do.
(It seems a bit strange to me to have a magic non-existent path that
triggers internal state changes, but I guess I can't quite see a
reason to say that it's actually wrong.)
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout: 09/27/2006]
Posted:
Sep 21, 2006 5:40 AM
in response to: Don Cragun
|
|
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 think libdll
falls into that category.
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.
I'm very concerned about the built-in behaviour and the interactions
with pfksh93.
The spec says:
> With pathname binding to /bin, if, for example, "cat" is executed in
> ksh93 without a pathname prefix, and a $PATH search first finds an
> executable cat file on /bin or /usr/bin, the built-in cat
> command is executed, not the Solaris /bin/cat binary.
> The advantages of using these built-ins are increased performance and
> additional functionality provided by the AT&T versions of these
> commands (see manpages in case materials).
So if I understand this correctly the "File System Management" and "
File System Management" RBAC profiles would not work under pfksh93
because ksh93's builtin mkdir/chown/etc will be used instead of
executing the /usr/bin variant via pfexec.
We already have this confusion with some other builtins (kill is the one
that catches most people out) in the existing shells but overriding
chown(1) is going to make this worse.
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 (ie chown can't be a builtin when
running as pfksh93) and ideally that the code to do the pfexec execution
is implement in such away that it *always* executes the external
binary rather than the shell builtin if there is a profile entry for
that command for the euid of the shell.
Yes I'm asking for this project to fix errors introduced by others in
the past but this is the perfect time to at least get the ksh part of
the world fixed with respect to builtins and RBAC [ pftcsh, pfzsh,
pfbash don't exist and personally I don't care about pfcsh :-) ].
--
Darren J Moffat
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
Posted:
Sep 21, 2006 4:31 PM
in response to: darrenm
|
|
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 think libdll
> falls into that category.
>
> Are all the new things that are being added to libcmd already in a
> library called libcmd when ksh93 is installed on other systems ? If not
> please don't put them in our libcmd.
Umpf. Please read last months discussion in the ksh93-integration
archive. We had a flamewar (which nearly caused the destruction of this
project (and I am unhappy that we revisit this horror again... ;-( )), a
long discussion and even a phone conference about the libcmd issue.
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 should be the
most painless solution for both sides and doesn't cause any problems for
it's consumers since all functions from the ksh93 version of libcmd
start with |b_*()| (for builtin command, see the builtin(1) manual page)
while the Solaris libcmd functions start with |def*()|.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
Posted:
Sep 21, 2006 4:36 PM
in response to: gisburn
|
|
Roland Mainz wrote:
> Darren J Moffat wrote:
>> Are all the new things that are being added to libcmd already in a
>> library called libcmd when ksh93 is installed on other systems ? If not
>> please don't put them in our libcmd.
>
> Umpf. Please read last months discussion in the ksh93-integration
> archive. We had a flamewar (which nearly caused the destruction of this
> project (and I am unhappy that we revisit this horror again... ;-( )), a
> long discussion and even a phone conference about the libcmd issue.
>
> 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 should be the
> most painless solution for both sides and doesn't cause any problems for
> it's consumers since all functions from the ksh93 version of libcmd
> start with |b_*()| (for builtin command, see the builtin(1) manual page)
> while the Solaris libcmd functions start with |def*()|.
In other words, the answer to Darren's question is "Yes". You can't
expect everyone on the ARC to know the full history of the project, so
it's a reasonable question, with a reasonable answer.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Re: Re: [osol-arc] Korn Shell 93
Integration[PSARC-EXT/2006/550 Timeout:09/27/2006]
Posted:
Sep 21, 2006 7:36 PM
in response to: alanc
|
|
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 in the ksh93-integration
> > archive. We had a flamewar (which nearly caused the destruction of this
> > project (and I am unhappy that we revisit this horror again... ;-( )), a
> > long discussion and even a phone conference about the libcmd issue.
> >
> > 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 should be the
> > most painless solution for both sides and doesn't cause any problems for
> > it's consumers since all functions from the ksh93 version of libcmd
> > start with |b_*()| (for builtin command, see the builtin(1) manual page)
> > while the Solaris libcmd functions start with |def*()|.
>
> In other words, the answer to Darren's question is "Yes". You can't
> expect everyone on the ARC to know the full history of the project, so
> it's a reasonable question, with a reasonable answer.
Ok... right... but please excuse me... I am simply trying to forget
about the libcmd debate. It was very very ugly and I really do not want
to revisit this horror again... ;-(
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
Posted:
Sep 21, 2006 5:51 PM
in response to: gisburn
|
|
Roland Mainz <roland dot mainz at nrubsig dot 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 functionalities. This should be the
> most painless solution for both sides and doesn't cause any problems for
> it's consumers since all functions from the ksh93 version of libcmd
> start with |b_*()| (for builtin command, see the builtin(1) manual page)
> while the Solaris libcmd functions start with |def*()|.
Please check the content of libcmd, there are more entries than the ones
starting with def*
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
About pfksh93 and builtins... / was:
Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
Posted:
Sep 21, 2006 4:46 PM
in response to: darrenm
|
|
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 IMO better than the old ksh since there are now
multiple ways to handle the "builtin vs. pfexec" issue in a clean and
predictable way, see below.
> (ie chown can't be a builtin when
> running as pfksh93) and ideally that the code to do the pfexec execution
> is implement in such away that it *always* executes the external
> binary rather than the shell builtin if there is a profile entry for
> that command for the euid of the shell.
IMO there is no need for such a change (and it would IMO very tricky to
do it without blowing some existing ksh93 scripts up). There are at
least three solutions for this problem:
1. Scripts can always load/enable/disable all builtin commands via the
"builtin" command, e.g. "builtin -d chown" will remove the builtin
"chown" and from this point the external command is used (you can use
this in subshells, too (which only affects subshells)). This is part of
the ksh93 language since a long time.
2. You can always specify the full path to the command (e.g.
/usr/bin/chown) to execute the external command. The builtin commands
are only used when you use the plain filename, e.g. "chown" which is
then searched in ${PATH}.
3. You can combine [2] with "alias", e.g. "alias chown=/usr/bin/chown"
will redict all calls of "chown" to "/usr/bin/chown", bypassing the
builtin version of "chown" until the alias entry is undone.
I hope this is acceptable for the ARC since playing around with the
builtins just because the shell is currently in "profile shell" mode is
the least desireable option (and both POSIX and the ksh93 lanuguage
itself provide a solution which is IMO sufficient).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: About pfksh93 and builtins... /
was: Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
Posted:
Sep 21, 2006 5:11 PM
in response to: gisburn
|
|
Roland Mainz writes:
> > (ie chown can't be a builtin when
> > running as pfksh93) and ideally that the code to do the pfexec execution
> > is implement in such away that it *always* executes the external
> > binary rather than the shell builtin if there is a profile entry for
> > that command for the euid of the shell.
>
> IMO there is no need for such a change (and it would IMO very tricky to
> do it without blowing some existing ksh93 scripts up). There are at
> least three solutions for this problem:
> 1. Scripts can always load/enable/disable all builtin commands via the
> "builtin" command, e.g. "builtin -d chown" will remove the builtin
> "chown" and from this point the external command is used (you can use
> this in subshells, too (which only affects subshells)). This is part of
> the ksh93 language since a long time.
> 2. You can always specify the full path to the command (e.g.
> /usr/bin/chown) to execute the external command. The builtin commands
> are only used when you use the plain filename, e.g. "chown" which is
> then searched in ${PATH}.
> 3. You can combine [2] with "alias", e.g. "alias chown=/usr/bin/chown"
> will redict all calls of "chown" to "/usr/bin/chown", bypassing the
> builtin version of "chown" until the alias entry is undone.
I don't see how any of those are usable answers here.
The point of the "profile shell" is that the commands executed there
are automatically granted privileges according to what's configured
for the user. The script writer doesn't need to know anything about
RBAC to make it work.
Having to work around it with 'builtin -d xxx' or other changes
defeats that capability.
Answers that seem useful to me are:
- when invoked as pfksh93, the shell automatically disables all
built-ins other than the intrinsically required ones (such as
'cd').
- 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.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: Re: About pfksh93 and builtins... /
was: Re: [osol-arc] Korn Shell 93 Integration [PSARC-EXT/2006/550
Timeout:09/27/2006]
Posted:
Sep 21, 2006 5:57 PM
in response to: carlsonj
|
|
James Carlson <james dot d dot carlson at Sun dot 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 to me.
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
|
|
|
|
|
Posts:
3,657
From:
DE
Registered:
6/16/05
|
|
|
|
Issues with pfksh93 and builtin commands... / was: Re:
Re: About pfksh93 and builtins... /was: Re:
[osol-arc] Korn Shell 93 Integration
[PSARC-EXT/2006/550Timeout:09/27/2006]
Posted:
Sep 21, 2006 6:56 PM
in response to: Joerg Schilling
|
|
Joerg Schilling wrote:
> James Carlson <james dot d dot carlson at Sun dot 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 to me.
Question to David+Glenn: Is it possible to implement this somehow ?
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 with deal with the problem since the intial putback
commits ksh93s-_alpha to OS/Net anyway - which means there will be a
couple of putbacks between now and the final version of ksh93s where we
can revisit this issue and hack a working solution together...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland dot mainz at nrubsig dot org
\__\/\/__/ MPEG | | | |
