Skip to Content.
Sympa Menu

sm-users - Re: [SM-Users] menuconfig for casts

sm-users AT lists.ibiblio.org

Subject: Sourcemage Users List

List archive

Chronological Thread  
  • From: Vladimír Marek <vlmarek AT volny.cz>
  • To: sm-users AT lists.ibiblio.org
  • Subject: Re: [SM-Users] menuconfig for casts
  • Date: Fri, 16 Dec 2005 19:56:01 +0100

Hi,

[...]
> and there are these answers that are remembered in a way that I cannot
> change them (question and answer appearing in []brackets without a
> prompt) - The rule behind them is not so clear to me. Of course, I
> could look at the code to find it...

Well, the answers in [ ] are remembered since you allready answered
them. To force sorcery to re-ask you use cast -r (man cast)


> > I'll point out that backing up after you answer a question isnt really
> > a trivial thing to do in a robust and efficient way. Theres a lot more
>
> I didn't say that it is trivial... just that it seems desirable for
> error-prone humans;-)

Yes, I understand that, it happened to me more than dozen times also :)


> > going on then whats just presented to the end user. All relavent spell
> > files are shell scripts in a turing complete language, theres not really
>
> Wait. Yes, I already noted that spells consist of shell scripts...
> but are they really allowed to do everything? Could a spell config
> script do `rm -f /boot/*` ?

Yes. Even 'nohup rm -rf /'

> I'd think that spell scripts (apart from install) should only (be able
> to) access system information in a read-only way and store their
> config/do their compilation in a confined place. And besides what is
> allowed for them to do, what is possible in reality? Can one guarantee
> a certain set of commands to be available to the scripts (sed, perl,
> ...) even on a very, very minimal system? How far does the turing
> completeness go in reality?

Hmm. If you allow to run perl, you can do perl -e 'system "rm -rf /"'.
Those are scripts that are running with root privilegues. I don't think
that the situation is different for rpm or deb, you just have to trust
your package provider :)


> > any way to predict what they'll do without doing it or jump back in the
> > middle again.
>
> Ok, but - for a start - what's with not jumping back in the middle but
> just have a hot-key to restart CONFIGURE for the current spell in a
> multi-spell cast?

Well, hot-key itself would be a problem, it's a bash script. The only
way I can think of doing that, is to limit CONFIGURE ( not execute it,
rather parse ). Which means doing sorcery less powerfull, imo. And I'm
sure that afrayedknot will know why even that wouldn't be possible :) So
much effort for the user answerring rubbish ?

> It should be possible to restore the state the spell's CONFIGURE
> started in

What makes you believe in that ?


> unless the script created - or worse: modified - some random files in
> the system... I think spells should be at most allowed to write to a
> temporary directory (subdir of cast/xxxx ?) and the unpacked source
> directory, of course.

Well, spell should behave as you described, if it does not, it's
probably bug (unless there's reason ofcourse). But why limit ourselves ?


[...]

> > [much more about problem complexity, dynamic structure, weird places...]
>
> OK, you have quite some points there... I still think that in
> principle the configuration could be done in a menuconfig-like way (on
> the look-and-feel side, not internally) for a whole cast together, but
> I see that the spell design would have to take care of being able to
> go back and forth, support enabling and disabling of things. So even
> if this could be done, it won't be done in the near future.

I would say that this is feature creeping, sorry ...


> What I think is possible, then, is to drop the whole-cast approach and
> to provide sorcery functions for the spells that do what some spells
> (glibc with locales) do now with self-coded dialog scripting, I guess.
> Extending the API so that spells can easily let their configuratuion
> step appear as (nested) menus.
>
> Instead of
>
> config_query VAR "Question?" y
>
> for every option, I'd like to specify the list of options/questions somehow
> (with some means to indicate relationships between options) and execute
>
> config_menu
>
> to get my variables set by the user working in a menu. I have to think a
> bit about the DEPENDS file since I'd like to have it integrated, too.
>
> This approach leaves existing spells unharmed (would they get an error if
> they define a config_menu function themselves?) and would give me the
> non-linearity that I want for the more complex spells.
>
> Is there opposition against that API extension (supposed that probably I'll
> do the work and manage to write such a menu function / its helpers to
> specify the structure)?

Well generally no ( you can create whatever you want in your local
grimoire, after all ). The only think I can think off is that the cast
is supposed to work even unattended, there are timeouts for each
question. I'm not sure how would you do that with menuconfig style ui.

> Thomas.

--
Vladimir

Attachment: pgpkzpRsEnReQ.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page