Christian T. Steigies wrote: > Now this is confusing like accounting, everything is inversed. I use INPUT > to OUPUT a note, ok. And I use GET to set a variable to the return value. > Once I stop trying to interprete the meaning of the commands, it actually > makes sense, like accounting...
We decided to use INPUT to, quite naturally, ask the user for input. It was only later overloaded to include displaying a note to the user. GET gets a value from the database. The only sane place to put that value in the current shell library is in a shell variable. (I would have prefered to have the db_get command return the value on stdout, but that was sadly not possible). > Yup. Now just one more newbie question, what does the " || true" do? > It is not setting the default answer (which is probably set in the templates > files), its OR-ing the return value of db_* with true? Do I need to use this? The shell library uses shell return codes to report back debconf return codes. Since not trapping those return codes makes set -e scripts terminate abruptly, the return code is trapped with the || true (or ||:) if you decide to ignore it. > Should I used shared/moon-buggy for this? Or is moon-buggy sufficient? shared/ is only intended for more widely shared values, really. -- see shy jo
