fix the regression introduced by r251544; which was trying to make things
consistent w/respect to ESC versus YES versus NO in the password disable
prompt in "Login Management".
(need stronger coffee; very sorry for the churn)
With this revision, the "YES", "NO", and implied ESC options all work as-
expected. Choosing "YES" allows you to proceed and the password will be
disabled. Choosing "NO" will bring back around to enter a password for the
account. Pressing ESC will drop you out of either user or group input and
back to the usermgmt screen.
would like to disable password management for an account while adding either
a user or group. When being prompted to answer questions while adding a
group or user, two things are trow:
1. You can hit ENTER to blast through all the questions and in the end, the
group or user is created with sensible defaults for all values.
2. You can press ESC during any prompt to cancel the operation as a whole.
This fix is shoring up an inconsistency in the latter (#2).
which choosing to cancel the manual input of expiration time (in seconds
since the UNIX epoch) for either account expiration or password expiration
would see the original value lost.
with diagnosis of kerberized NFS mount problems. When set,
messages are sent to syslog() (or fprintf(stderr,...) if
"-d" is also specified) to indicate activity/results of
kgssapi upcalls.
Reviewed by: jhb
MFC after: 2 weeks
this menu consistent with Console->Repeat, Console->Font, Console->Screenmap
and many others which place the default choice at the top.
NOTE: SVN r249751 changed things so that these menus highlight the active
selection, so the idea that the default choice (now at top) "can be selected
immediately by hitting ENTER" is not possible unless the default choice is
the currently active setting (e.g., on first visit to the menu). However, it
is still warranted to have the default choice at the top of the menu.
PR: bin/169316
replacement comes with a great performance increase (as f_shell_escape()
uses the built-in based f_replaceall() which out-performs forking to
awk(1)). This should also improve readability slightly.
dialog(1) API in dialog.subr responsible for retrieving menu-choice data
(for the --menu widget).
Add f_dialog_menuitem_store()/f_dialog_menuitem_fetch() for storing and
retrieving the menuitem (not the tag) from a --menu widget result.
The dialog --menu widget returns the `tag' from the tag/item pair of choices
for a menu list. Because the menu list is often local to the function that
is displaying it, the ability to dereference this into the item is not
possible unless you use a global. This changes things so the function (upon
successful return of dialog) dereferences the tag into the item and stores
it for later retrieval using these functions.
NOTE: Tags are dereferenced into items using f_dialog_menutag2item().
display a global instead of the passed-argument; however since the global
always has the same value as the passed argument, it made no difference in
the realtime operation.
caused by the standard (and correct) behavior of the shell to discard the
return status of lvalue-operands in a pipe-chain.
The solution is to not pipe the file-acquisition directly into sort(1) but
instead store the output (allowing immediate testing of the return status)
and later sort it.
edge-case. The case was that you have been through the FTP setup once before
and on the second time through, you cancel at the re-selection of a new FTP
server.
The spurious warning was "device_media: not found" and was caused because
the underlying call to f_device_network_down() did not check to see if the
network device existed before attempting to shut it down.
Add checks to make sure we don't forge ahead unless the device exists.
make their purpose more clear by their names:
f_dialog_input_change() and
f_dialog_input_expire()
Are now (respectively):
f_dialog_input_expire_password() and
f_dialog_input_expire_account()
Upon revisit to this portion of code, the former names were too confusing.
behavior(s); e.g., `-Xd' versus `-dX' did not produce the same results.
The libraries common.subr and dialog.subr automatically process the
arguments passed to the program and enable/disable functionality without the
need to process the arguments within your program. For example, if "$@"
contains `-d', common.subr will see this and enable debugging regardless of
whether you process "$@" yourself or not (this automatic processing can
easily be disabled for custom scripts that don't want it; see the afore-
mentioned scripts for additional details).
NOTE: common.subr stores a copy of "$@" in $ARGV for convenient (and
repeated) processing by libraries such as dialog.subr which provide such
transparent functionality for the consuming script(s).
However, the libraries don't know if a program wants to accept `extra'
options. Flags are not really a problem, because the library can be
programmed to silently ignore unknown flags. The trouble comes into play
when the program wants to define an option that takes an argument.
For example:
bsdconfig -D logfile -X
In the above example, the library uses getopts to process $ARGV and if it
doesn't know that `-D' takes an argument, the option processing will
prematurely terminate on `logfile' (this is standard/correct behavior for
getopts but is undesired in our situation where we have partially off-loaded
main argument processing).
The problem is solved by allowing the program to define an extra set of
options to be included in each library's handling of $ARGV. Only options
that require arguments are truly necessary to be pre-specified in this new
manner.
invocation. Specifically, "top-load" your arguments and in the order in-
which they will be displayed. For example, many [if not all] widgets display
information in the following order, top-to-bottom (visually):
+ backtitle (displayed behind the widget at top-left)
+ title (at the top of the `window')
+ prompt text (just below the title and above whatever widget you choose)
+ Depending on widget, _one_ of the following:
- menu list
- radio list
- check list
- text input box with initial text
- [Xdialog(1)] 2x or 3x text input boxes
- [dialog(1)] a multi-part form
- progress bar
- etc. (many more widget choices)
+ buttons (right below the selected widget)
+ [dialog(1)] the hline (displayed at bottom of `window')
NOTE: Xdialog(1) accepts and silently ignores --hline
When building local arguments for your dialog invocation, if the value can't
be cleanly loaded into a local, add "# Calculated below" to the end of the
local declaration while retaining the block order of argument declarations.
Move other local declarations that are not associated with this top-loading
the dialog arguments to right-above where they are first-used.
Also, standardize on the names of the arguments. For example, always use
$prompt (instead of sometimes $msg and sometimes $prompt); use $menu_list
or $shell_list or $radio_list for those respective widgets; ad nauseum.
While we're doing this, flush-out full arguments for many invocations that
were passing NULL strings (making it unapparent if you were staring at this
one invocation what argument that NULL string was supposed to represent).
Last, while we're in startup/rcconf let's remove the unnecessary use of a
GLOBAL (RCCONF_MENU_LIST) for the menu_list.
and f_dialog_default_fetch(). Operating similar to functions introduced by
SVN r251236 and r251242, these functions operate as a pair for helping track
the default-item data (for the --menu, --checklist, and --radiolist
widgets).
This replaces the direct usage of a global to store the data with an
abstract method for readability and to centralize the code.
responsible for retrieving stored input (for the --inputbox and --password
widgets).
When we (Ron McDowell and I) developed the first version of bsdconfig, it
used temporary files to store responses from dialog(1). That hasn't been
true for a very long time, so the need to always execute some clean-up
function is long-deprecated. The function that used to perform these clean-
up routines for these widgets was f_dialog_inputstr().
We really don't need f_dialog_inputstr() for its originally designed purpose
as all dialog invocations no longer require temporary files.
Just as in r251236, redesign f_dialog_inputstr() in the following four ways:
1. Rename f_dialog_inputstr() to f_dialog_inputstr_fetch()
2. Introduce the new first-argument of $var_to_set to reduce forking
3. Create a corresponding f_dialog_inputstr_store() to abstract storage
4. Offload the sanitization to a new function, f_dialog_line_sanitize()
It should be noted that f_dialog_line_sanitize() -- unlike its cousin from
SVN r251236, f_dialog_data_sanitize() -- trims leading/trailing whitespace
from the user's input. This helps prevent errors and common mistakes caused
by the fact that the new cdialog implementation allows the right-arrow
cursor key to go beyond the last byte of realtime input (adding whitespace
at the end of the typed value).
While we're centralizing the sanitization, let's rewrite f_dialog_input()
while we're here to likewise reduce forking. The f_dialog_input() function
now expects the first argument of $var_to_set instead of producing results
on standard-out.
These changes greatly improve readability and also improve performance.
retrieving stored data (for the --menu, --calendar, --timebox, --checklist,
and --radiolist widgets).
When we (Ron McDowell and I) developed the first version of bsdconfig, it
used temporary files to store responses from dialog(1). That hasn't been
true for some very long time, so the need to always store the return status
of dialog(1) and then call some function to clean-up is long-deprecated. The
function that used to do the clean-up was f_dialog_menutag().
We really don't need f_dialog_menutag() for its originally designed purpose,
as all dialog invocations (even when in a sub-shell) do not use temporary
files anymore.
However, we do need to keep f_dialog_menutag() around because it still fills
the need of being able to abstract the procedure for fetching stored data
provided by functions that display the aforementioned widgets.
In re-designing f_dialog_menutag(), four important changes are made:
1. Rename f_dialog_menutag() to f_dialog_menutag_fetch()
2. Introduce the new first-argument of $var_to_set to reduce number of forks
3. Create a corresponding f_dialog_menutag_store() to abstract the storage
4. Offload the sanitization to a new function, f_dialog_data_sanitize()
NOTE: That last one is important. Not all functions need to store their data
for later fetching, meanwhile every invocation of dialog should be sanitized
(as we learned early-on in the i18n-effort -- underlying libraries will spit
warnings to stderr for bad values of $LANG and since dialog outputs its
responses to stderr, we need to sanitize every response of these warnings).
These changes greatly improve readbaility and also improve performance by
reducing unnecessary forking.
calculating widget sizes. Instead of forking a sub-shell to calculate the
optimum size for a widget, use a byRef style call-out to set variables in
the parent namespace. For example, instead of:
size=$( f_dialog_buttonbox_size title btitle msg )
$DIALOG --title title --backtitle btitle --msgbox msg $size
The new API replaces the above with the following:
f_dialog_buttonbox_size height width title btitle msg
$DIALOG --title title --backtitle btitle --msgbox msg $height $width
This reduces the number of forks, improves performance, and makes the code
more readable by revealing the argument-order for widget sizing. It also
makes performing minor adjustments to the calculated values easier as
you no longer have to split-out the response (which required knowledge of
ordering so was counter-intuitive).
get RSDP from loader(8) hint via kenv(2) but the bug nullified the new code
and we always fell back to the previous method, i. e., sysctlbyname(3).
MFC after: 3 days
