[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: FAI patches and feedback

From: David Allouche
Subject: Re: [Gnu-arch-users] Re: FAI patches and feedback
Date: Tue, 07 Sep 2004 10:23:00 +0200

On Mon, 2004-09-06 at 21:15 -0400, Aaron Bentley wrote:
> There was nothing I could find in the Python libraries that made 
> colorization simpler than hand-crufting it, so that's what I did. 
> Guidance on how to do it The Right Way without using ncurses would be 
> appreciated.

>From what I gathered, the right way is to query the terminfo database
for the capabilities of the current terminal (as specified by the TERM
environment variable) using the setupterm, tiget* and tparm functions in
Python's curses module. In particular tigetstr seems to yield template
strings to process with tparam to actually produce terminal control

You can get information about the terminfo  database with "man
terminfo" (which gives the documentation of the curses terminfo parsing
functions) and "man 5 terminfo" (which documents the properties defined
in the terminfo database).

Generally, it seems that all control codes should be retrieved from the
terminfo database. A notable exception seems to be the apparently non-
standard "set title" escape sequence which is documented in some HOWTOs
on the web:

> > It has no summary because I was bitten by a pretty annoying failure
> > mode:
> > Apparently the first commit creates the log file and then fail without
> > removing it,
> I've fixed Fai so
> - we test for the editor first
> - we remove new-logs if editing them fails for any reason
>   and the second commit does no check that the log file has a
> > non-empty summary. I think commit should ask for a changelog if the
> > changelog summary is empty or whitespace only.
> Okay, I've done that too.  (It prompts to see if you really want a blank 
> summary.)


> Unfortunately, \export will not behave like you want it to, because it's 
> executed in a shell, then returns.  Perhaps it will have to become a 
> builtin.

How would you call it? There is already a "fai export" command.

There are other annoying behaviours caused by not-quite-sh behaviour.
For example "help | grep foo" is not correctly parsed as a pipe, and you
cannot no longer use the kind of ugly one-liners you could use in tlash,
for example:

        mirrorv `upstream` ; library-add `upstream` ; missing-from
        $(latest-revision `upstream`)

where "upstream" read the contents of the `tree-root`/{arch}/+upstream
file used by the pqm submission script. That one line was useful to
monitor the application of a merge request.

Probably the policy is that in fai you should not have to write one-
liners... I'm not convinced that is a good policy. Some kind of non-
trivial command language is useful. And please, not something with
bracketitis :)

I will look more at the internal design and FAI and RAW before making my

> The Doxygen documentation is obsolete.  Epydoc is the replacement.  For 
> user-level stuff, there's the README and the web site:

I also tried to generate the epydoc documentation but had trouble with
that too. It refused to import most python files in the local directory
complaining they were not python modules. I'll write the makefile if I
manage better the next time.

                                                            -- ddaa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]