Thank you.
ginnie
On 09/ 7/11 09:56 AM, Dave Miner wrote:
OK, I'm satisfied. Approved.
Dave
On 09/07/11 11:31, William Schumann wrote:
On 9/7/2011 4:18 PM, Dave Miner wrote:
On 09/07/11 09:58, William Schumann wrote:
Per Darren's and Dave's suggestions, improved message for leading
zeros.
Allows empty DNS search list per Dave's suggestion.
Also, tested popular terminal emulator PuTTY interoperability.
Discovered that F2 and F3 PuTTY sequences were not recognized and
added
actions for them (next page, previous page). The PuTTY keyboard can be
set for VT100, but these changes will support the default PuTTY
keyboard
as well.
Are we reasonably sure that these escape sequences aren't going to
collide with something else on one of the other supported terminals?
Yes, it is reasonably certain that it will not conflict with other
*supported* terminals.
Can you make it conditional on whether we're actually using a PuTTY
terminal?
'putty' is valid for the TERM environment variable, and Python curses
correctly interprets the F2/F3 escape sequences, so terminalui doesn't
need the extra code to support F2/F3 if TERM=putty. What I observed is
that for PuTTY, TERM=xterm by default when SSH is used, so the added
code to support F2/F3 will save the user from explicitly setting set
TERM=putty. For users that SSH to the console, explicitly setting
TERM=putty (or whatever terminal or keyboard emulation being used) will
yield better results.
So to answer your question, we can look at TERM, but we don't have to
for PuTTY. At this stage, we probably should not attempt a low-level
interrogation of the terminal by sending it a standard identification
escape sequence and reading the response.
William
Otherwise changes look OK.
Dave
Regarding the original CR, 7073565 snv_169 text installer: edited
numeric fields eat the Escape sequence, the problem was not that the
escape sequence was being eaten, but rather that the escape character
was being eaten, and the remainder of the escape sequence was being
dumped into the user's text field. The fix for 7010292 "Esc-# doesn't
work when editing a text field" similarly leaves the last character of
an invalid (i.e., unrecognized) escape sequence in the user's input
field. Although helpful for debugging, leaving the escape sequence
terminator character of unsupported escape sequences is certainly not
what the text installing user wants.
Changed terminalui: __init__.py to not leave the terminator
character of
unsupported escape sequences in the user's input field.
Retested sysconfig create-profile NIC IP,netmask,router; DNS, NIS,
LDAP;
empty DNS search list, unit tests. pep8
Updated webrev.
https://cr.opensolaris.org/action/browse/caiman/wmsch/7073565/webrev/
Please re-review. Other reviewers welcome.
Thank you,
William
On 9/6/2011 6:02 PM, Dave Miner wrote:
On 09/06/11 04:22, William Schumann wrote:
Dermot,
On 9/5/2011 2:38 PM, Darren Kenny wrote:
Hi William,
Looks good, only one comment about the error in ip_address.py:
148 + raise ValueError("No leading zeros")
I think this can be misinterpreted, and probably would probably
read
better as
something like:
"Leading zeros are not permitted in address segments: %s" % segment
All of the validation messages from this module are overridden by a
more
generic message - the user never sees them, only the pyunit
tests. If
these messages ever do go live, they should be reevaluated at once.
What is the generic message that is reported, then? Is it sufficient
for the user to actually understand what is wrong with the input? I'd
rather not leave error messages for re-evaluation later if they
can be
easily fixed now.
Dave
Thanks,
William
Thanks,
Darren.
On 05/09/2011 12:58, William Schumann wrote:
7073565 snv_169 text installer: edited numeric fields eat the
Escape sequences
<http://monaco.us.oracle.com/detail.jsf?cr=7073565>
The original bug has been fixed - the bug report also mentions
that
leading
zeros, accepted as valid by TI, cause problems with some
applicaitions.
Modified validator to reject leading zeros. Added unit test for
leading zeros,
modified another unit test to check for non-numeric characters
only.
Also encountered bug during testing - the DNS domain should be
required (occurs
since DNS and NIS domain screens were separated). At least one DNS
domain is
required in the fix.
https://cr.opensolaris.org/action/browse/caiman/wmsch/7073565/webrev/
Thank you,
William
//<http://monaco.us.oracle.com/detail.jsf?cr=7073565>
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
