It appears to me that with the exception of one item, this case has
converged.
That one item is of course the "style issue".
The question I feel that needs to be asked at this point is:
Is this really an issue for the ARCs, or is this an
implementation detail?
If it's an implem
Quoth Eric Lowe on Tue, Oct 17, 2006 at 09:28:05AM -0500:
> NAME
> strfnum, strfunum - format a number as a scaled string
...
> Conversion Specification
> The string determines how will be formatted to
> the output in a fashion similar to sprintf(). Each conversion
>
On Thu 19 Oct 2006 at 04:54AM, Roland Mainz wrote:
> Dan Price wrote:
> [snip]
> > My thought is that we should revamp all of the interactive shell defaults
> > to have consistent (across the shells) and excellent default interactive
> > settings, with useful prompts and default behaviors whereever
This case was approved during this afternoon's PSARC meeting. The
proposal.final file in the case's materials directory has been added
to reflect changes made during the discussions surrounding this case.
Cheers,
Don
>Date: Wed, 18 Oct 2006 15:21:31 -1000 (HST)
>From: Joseph Kowalski
>
>> From: Richard Lowe
>...
>> (I do still harbour some concern regarding any future ksh(1) or sh(1)
>> migration, however, but that's another case).
>
>Very interesting question.
>
>Don (as in Cragun), would having a default e
This morning, Dan Price wrote:
> We should offer customers both *choice* and *wonderful defaults*.
> Choosing "none" has no impact on the former and fails the latter.
I seem to have lost that choice ;-) - well at least in the ksh93
tarball I've got installed...
$ env -i /usr/bin/ksh93 -o vi
> This case was approved during this afternoon's PSARC meeting. The
> proposal.final file in the case's materials directory has been added
> to reflect changes made during the discussions surrounding this case.
No fair! I had no connection!
Actually, I'm fine with this. I'd figured out that m
> From: Don Cragun
...
> C.If (or when) a case comes forward to replace one or more of
> /sbin/sh, /usr/bin/sh, /usr/bin/ksh, and /usr/xpg4/bin/sh with
> ksh93 we will need to discuss this again as a compatibility
> issue. That discussion should not sidetrack this c
> From: Richard Lowe
...
> (I do still harbour some concern regarding any future ksh(1) or sh(1)
> migration, however, but that's another case).
Very interesting question.
Don (as in Cragun), would having a default edit mode for ksh93 prevent
it from eventually becoming the SUS conforming ksh?
> On 10/18/06, James Carlson wrote:
> > Josh Hurst writes:
> > > Unfortunately I have to add a general note here:
> >
> > Please direct the flames at /dev/null. They are of no use here.
> Please understand that I am trying to start a generalised discussion
> whether all this bureaucracy is REQUI
John Plocher wrote:
> Nit: With this proposal, we will have the following shell config files
> living in /etc:
>
> /etc/profile
> /etc/suid_profile
Where do you get this one from ? I don't see in on my snv_50 Solaris
system.
> /etc/.login
> /etc/ksh.kshrc
> /etc/default/su
Joseph Kowalski wrote:
> Look, I'm not going to lie down on the tracks over this. Do any other
> PSARC members feel uncomfortable over shipping a stylistic choice? If
> not, I'll just go away and sulk. 8^)
In ksh and zsh my CLI edit mode of choice is 'vi' however I think that
this case is goo
> From: Alan Hargreaves
...
> It appears to me that with the exception of one item, this case has
> converged.
>
> That one item is of course the "style issue".
>
> The question I feel that needs to be asked at this point is:
>
> Is this really an issue for the ARCs, or is this an
>
>I am more and more shocked that such trivial items need to be debated
>at all. I am observing the ksh93 integration project nearly since the
>beginning and I have to question whether or not really all the
>bureaucracy is needed. I think Sun and the Open Solaris team should
>discuss options to str
On 10/18/06, James Carlson wrote:
> Josh Hurst writes:
> > Unfortunately I have to add a general note here:
>
> Please direct the flames at /dev/null. They are of no use here.
Please understand that I am trying to start a generalised discussion
whether all this bureaucracy is REQUIRED. No other O
On 10/18/06, Bernd Finger wrote:
> Casper,
>
> Casper.Dik at Sun.COM wrote:
> > I think I have to side with Roland; I use "vi" to edit but use
> > "emacs" mode exclusively for command lined editing.
> >
> > The only intuitive editing I can think of is the use of the arrow keys;
> > gmacs/emacs edi
All,
This is a status report on this case from the case owner...
1. login.1 and su.1 man pages have been added to the materials
directory. Diffmarks in login.1 show changes made since PSARC case
2006/550 was approved. Diffmarks in su.1 show changes from the
current man page
On Wed, 18 Oct 2006 14:34:36 +0200 Josh Hurst wrote:
> Unfortunately I have to add a general note here:
> I am more and more shocked that such trivial items need to be debated
> at all. I am observing the ksh93 integration project nearly since the
> beginning and I have to question whether or not
On Wed, Oct 18, 2006 at 03:05:42PM +0100, Darren J Moffat wrote:
> In ksh and zsh my CLI edit mode of choice is 'vi' however I think that
> this case is goodness over all for OpenSolaris distributions and Solaris
> in particular.
>
> I support it even though it is not my personal choice of edit
On Tue 17 Oct 2006 at 03:45PM, Joseph Kowalski wrote:
>
> > From: Dan Price
> ...
> > > So, insted we send these beginners off believing that gmacs is the way
> > > it is. I don't think this is better.
> >
> > To me it sounds like you are saying that beginners must be forced
> > through a steep l
>Date: Wed, 18 Oct 2006 18:37:28 +0100
>From: Rhodri Davies - Sun UK
>
>This morning, Dan Price wrote:
>> We should offer customers both *choice* and *wonderful defaults*.
>> Choosing "none" has no impact on the former and fails the latter.
>
>I seem to have lost that choice ;-) - well at least in
Darren J Moffat wrote:
> Joseph Kowalski wrote:
>> Look, I'm not going to lie down on the tracks over this. Do any other
>> PSARC members feel uncomfortable over shipping a stylistic choice? If
>> not, I'll just go away and sulk. 8^)
>
> In ksh and zsh my CLI edit mode of choice is 'vi' howeve
Casper,
Casper.Dik at Sun.COM wrote:
> I think I have to side with Roland; I use "vi" to edit but use
> "emacs" mode exclusively for command lined editing.
>
> The only intuitive editing I can think of is the use of the arrow keys;
> gmacs/emacs editing supports that; vi does not.
In ksh93 r+ an
Joseph Kowalski wrote:
> I was prepaired to "go with the flow", until I saw Richard Lowe's mail.
> It appears that defaults of "gmacs", "vi" and "none" are equally prevalent
> in other systems. If we want to help the newbee, being consistant across
> systems is the best way to accomplish that. Si
>Date: Wed, 18 Oct 2006 11:12:45 -0400 (EDT)
>From: Glenn Fowler
... ... ...
>
>for newbie guidance why not provide a time honored, commented default .profile
>"# this sets the default edit mode to emacs ..."
>"ENV=$HOME/feel-like-bash-and-linux.sh # ..."
>
Hi Glenn,
One reason for not changing
>
>> From: Roland Mainz
>...
>> > And, for me, usability is "vi" mode.
>>
>> If you want to make this the default for Solaris then I suggest to teach
>> our students how to use "vi". First batch Tuesday 9.30am-11:30am, second
>> batch 13:30h-15:30h (1st semester) ... I think these four hours sho
>Gnome/GTK default to win32-style C-v, C-x, C-c these days, where C-a is
>"select all", not the almost-emacs readline-like editing keys.
Yes; very annoying; you have to change a (not well documented
setting) to get your Emacs bindings.
gtk-key-theme-name = "Emacs"
>Mozilla and friends, as far
Josh Hurst writes:
> Unfortunately I have to add a general note here:
Please direct the flames at /dev/null. They are of no use here.
This is a review. The point of a review is to avoid mistakes that can
be costly or impossible to correct once made. If you want to ship
without review, there ar
Alan Hargreaves writes:
> That one item is of course the "style issue".
[...]
> Is this really an issue for the ARCs, or is this an
> implementation detail?
The issue of style is architectural because of these concerns:
- conformance to applicable standards
- consistency with othe
Joseph Kowalski wrote:
[snip]
> I was prepaired to "go with the flow", until I saw Richard Lowe's mail.
> It appears that defaults of "gmacs", "vi" and "none" are equally prevalent
> in other systems. If we want to help the newbee, being consistant across
> systems is the best way to accomplish th
Richard Lowe wrote:
> Joseph Kowalski wrote:
> >> gmacs is considered an intuitive beginner's editing mode. It is the
> >> default editing mode in bash and more or less matches the common input
> >> mode of various GUI toolkits and desktops, including Gnome/GTK+,
> >> KDE/Qt, CDE/Motif, Mozilla/XU
Joseph Kowalski wrote:
>
> > From: Roland Mainz
> ...
> > Umpf... because the ksh93 "default" is that no editor mode is enabled,
> > leaving beginners completely puzzled how to proceed.
>
> So, insted we send these beginners off believing that gmacs is the way
> it is. I don't think this is bet
Roland Mainz wrote:
> Uhm... there is no "fixed" format - /etc/ksh.kshrc is a shell script
> (fragment) which gets sourced before ~/.kshrc ...
Make that 'sourced before $ENV'. Note that ENV has
to be set before the shell is invoked.
ENVIf this variable is set, then parameter
ex
Joseph Kowalski wrote:
>
> > From: Joseph Kowalski
> ..
> > > gmacs is considered an intuitive beginner's editing mode. It is the
> > > default editing mode in bash and more or less matches the common input
> > > mode of various GUI toolkits and desktops, including Gnome/GTK+,
> > > KDE/Qt, CDE/
On Wed, 18 Oct 2006 01:26:36 -0400 Richard Lowe wrote:
> Glenn Fowler wrote:
> > On Tue, 17 Oct 2006 21:38:53 -0400 Richard Lowe wrote:
> >> Don Cragun wrote:
> >
> >> [heavy snipping]
> >
> >>> ksh93 itself does not set a default editing mode; it would be a
> >>> standards violation to do so.
[...]
> IMO "vi" is not an
> > option (unless you want to punish beginners to
> learn "vi" before they
> > can use something in the shell... =:-) ), leaving
> only "emacs" and
> > "gmacs" as options (unless you want to drive more
> users into "bash"'s
> > direction...).
>
> You failed to list one
Joseph Kowalski wrote:
>
> > gmacs is considered an intuitive beginner's editing mode. It is the
> > default editing mode in bash and more or less matches the common input
> > mode of various GUI toolkits and desktops, including Gnome/GTK+,
> > KDE/Qt, CDE/Motif, Mozilla/XULRunner/Gecko, JAVA, an
Glenn Fowler wrote:
> On Tue, 17 Oct 2006 21:38:53 -0400 Richard Lowe wrote:
>> Don Cragun wrote:
>
>> [heavy snipping]
>
>>> ksh93 itself does not set a default editing mode; it would be a
>>> standards violation to do so. In an interactive shell, in-line editing
>>> will be disabled, unless an
Alan Coopersmith wrote:
> Don Cragun wrote:
> > This case proposes to introduce the new file /etc/ksh.kshrc to the
> > system, as a per-system configuration file for interactive ksh93 (Korn
> > Shell).
>
> Will this file be used by the existing ksh88-based shells in Solaris?
> (/usr/bin/ksh, /usr/
John Plocher wrote:
>
> Nit: With this proposal, we will have the following shell config files
> living in /etc:
>
> /etc/profile
> /etc/suid_profile
> /etc/.login
> /etc/ksh.kshrc
> /etc/default/su
>
> Where does the name "ksh.kshrc" come from? I'm worr
>Nit: With this proposal, we will have the following shell config files
>living in /etc:
>
> /etc/profile
> /etc/suid_profile
> /etc/.login
> /etc/ksh.kshrc
> /etc/default/su
And /etc/.cshrc (which seems to be particular to tcsh?)
>Where does the name "ksh.kshrc" c
41 matches
Mail list logo
