Searched hist:251236 (Results 1 - 25 of 41) sorted by relevance

12

/freebsd-10.2-release/usr.sbin/bsdconfig/share/media/
H A Dany.subrdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Doptions.subrdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dtcpip.subrdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/console/
H A Dconsolediff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dfontdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dkeymapdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Drepeatdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dscreenmapdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/mouse/
H A Dmousediff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dportdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dtypediff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/networking/
H A Ddevicesdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dnetworkingdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/networking/share/
H A Dmedia.subrdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/security/
H A Dkern_secureleveldiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dsecuritydiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/share/
H A Dmustberoot.subrdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/startup/
H A Drcadddiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Drcconfdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dstartupdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/timezone/
H A Dtimezonediff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
/freebsd-10.2-release/usr.sbin/bsdconfig/usermgmt/
H A Dgroupdeldiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dgroupeditdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Duserdeldiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.
H A Dusereditdiff 251236 Sat Jun 01 23:58:48 MDT 2013 dteske Improve portion of the dialog(1) API in dialog.subr responsible for
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.

Completed in 224 milliseconds

12