that for form subwindow, which may be NULL (or is always, even?).
This fixes SIGSEGV when one goes to
Network related configuration -> Modify the hosts file -> Delete host entries
and presses F1 (Help).
process_{pre,}form(): g/c unnecessary malloc, plug memory leak
gen_list(): only check ftp->list after realloc()
handle_{pre,}form(): allocate F[] via calloc(3), so that the memory is
properly zeroed
to get amount of fields on the form instead.
This fixes a SIGSEGV problem I encountered, and possibly also the crash part
of bin/17718 by Grant Beattie.
policy and the data dependent initialization is very fragile. I.e.
the code assumes because the data entry is of type foo, it has
initialized certain fields and others not.
- make sure list is not NULL before you use it.
- don't realloc on every loop iteration!
- don't increment i when there are short lines; leads to uninitialized
list[i] entries [fixes bills' core-dump, hi bill!]
function does not exist a little better, rather than dying later in fgetln.
Also fix up a wierd corner case in escript where the programmer forgets
to put in the scriptname.
to do with very large fields being cut off by the end of the screen.
Also.. change the max-width of an onscreen field to 19 from 21.. I don't
know where I got 21 from.. but it was definately wrong.
Add new form keyword, iscript, which allows script generated integer fields.
This uncovered a whole host of bugs, which uncovered a whole host of memory
leaks, which hopefully I've fixed most of now (in this file at least).
built-in functions. This allows users to change F1 to say, ^X, in the case
where a function key might not be available, or perhaps is bound to a window
manager.
problem noted by Nathan Williams
Sushi is an interactive, menu-based program that is designed to aid
the user or administrator with administrative and complex tasks on thier
machines.
Sushi provides a menu of various functions that the user can perform on
his or her machine. Once the user selects a desired function, the
function is either performed outright, or in most cases, the user is
asked to fill in a simple form with required and option information,
which is then processed by sushi, and the action occurs.
The programming interface for sushi is very simple. There are
directories containing various files, such as menu indexes, or forms for
the user to fill out. These files are interpreted by sushi to generate
the menus the user sees on his/her screen. When the form is filled out
by the user, the entries are passed as command-line arguments to a
program, or script contained in one of the subdirectories. In this way,
it is possible to add new entries to the sushi menu structure, by simply
adding a new menu item, form and script, the binary does not need to be
recompiled to take advantage of this new menu.
fvdl