[comp.os.minix] MacMinix config.h LINEWRAP option

paul@ukpoit.co.uk (Paul Wood) (12/13/90)

In /usr/include/minix/config.h is the following entry:
    #define LINEWRAP 0             /* console.c - wrap lines at column 80 */

It appears to have no effect when I changed it to a 1 and remade the kernel,
mm, fs, and macboot. It is not used in console.c.

In fact when I executed the following:
    find / -name '*.[ch]' -exec grep LINEWRAP {} \;
                              the only line found was the one listed above.

Does anybody have any information about LINEWRAP?

Paul Wood           | UUCP Mail:  paul@ukpoit.co.uk   |
31 Buttermere Drive | Bang-Style: ...!ukc!ukpoit!paul |
Dronfield Woodhouse | Voice:      +44 246 214256      |
Sheffield           | FAX:        +44 246 214353      |
England S18 5PX     | Postline:   5403 4256           |

webber@csd.uwo.ca (Robert E. Webber) (12/14/90)

In article <1639@ukpoit.co.uk> paul@ukpoit.co.uk (Paul Wood) writes:
.
.In /usr/include/minix/config.h is the following entry:
.    #define LINEWRAP 0             /* console.c - wrap lines at column 80 */

I think this was left there for compatibility with the other versions
under the assumption that if LINEWRAP was ever implemented, it would
read this hook to do it.  Doubtless it is on Pickert's list of things
to do.  Where on the list it is I have no idea.  In theory it
shouldn't be difficult to do if you run 80 char wide terminal windows,
but since the mac console window can have its fonts changed and the
console windows themselves can be resized, a general implementation of
linewrap might be messier than one would like.

.In fact when I executed the following:
.    find / -name '*.[ch]' -exec grep LINEWRAP {} \;
.                              the only line found was the one listed above.

Actually, you probably want to do a search on *.[csh] when trying to track this
sort of thing, since who knows what evil lurks in the .s files.  Also, a -print
on the end of the find is helpful for those times when something is actually
found.

.Does anybody have any information about LINEWRAP?

Just confirm that you are the third person to notice it doesn't work on
MacMinix.

--- BOB (webber@csd.uwo.ca)

awb@uk.ac.ed.aipna (Alan W Black) (12/14/90)

In article <1639@ukpoit.co.uk>, paul@ukpoit.co.uk (Paul Wood) writes:
|>
|>In /usr/include/minix/config.h is the following entry:
|>    #define LINEWRAP 0             /* console.c - wrap lines at column 80 */
|>
|>It appears to have no effect when I changed it to a 1 and remade the kernel,
|>mm, fs, and macboot. It is not used in console.c.
|>
|>In fact when I executed the following:
|>    find / -name '*.[ch]' -exec grep LINEWRAP {} \;
|>                              the only line found was the one listed above.
|>
|>Does anybody have any information about LINEWRAP?
|>
|>Paul Wood           | UUCP Mail:  paul@ukpoit.co.uk   |
|>31 Buttermere Drive | Bang-Style: ...!ukc!ukpoit!paul |
|>Dronfield Woodhouse | Voice:      +44 246 214256      |
|>Sheffield           | FAX:        +44 246 214353      |
|>England S18 5PX     | Postline:   5403 4256           |
                  
Unfortunately LINEWRAP is only used in the PC specific stuff (console.c)
and is not used at all in the 68000 code (at least not in the ST version).

The config file doesn't make this clear and possibly should, or even
better the 68k version could use it (so I don't loose the last bytes
of the line on my ST).  I don't know of a way to get LINEWRAP in the 
68K version.

Alan

Alan W Black                          80 South Bridge, Edinburgh, UK
Dept of Artificial Intelligence       tel: (+44) -31 225 7774 x228 or x223
University of Edinburgh               email: awb@ed.ac.uk

paul@ukpoit.co.uk (Paul Wood) (12/21/90)

In article <1925@ria.ccs.uwo.ca> webber@csd.uwo.ca (Robert E. Webber) writes:
>In article <1639@ukpoit.co.uk> paul@ukpoit.co.uk (Paul Wood) writes:
>
>.In fact when I executed the following:
>.    find / -name '*.[ch]' -exec grep LINEWRAP {} \;
>.                              the only line found was the one listed above.
>
>Actually, you probably want to do a search on *.[csh] when trying to track this
>sort of thing, since who knows what evil lurks in the .s files.  Also, a -print
>on the end of the find is helpful for those times when something is actually
>found.

I think you missed the point, the -print is not necessary. The above command
looked for LINEWRAP in all .c and .h files and only found the config.h entry.
Thats what the command was meant to do, and thats what it does. If I'd found
that LINEWRAP was used in more places, then I would have investigated further.

Adding a -print would cause every .c and .h filename to be printed. If I went
away to cook a meal (which I did), then by the time I got back to the screen
any evidence would have probably scrolled off the top of the screen. This is
not what I wanted. A command should do what you want it to do, no more, no less.

I do take your point however about .s files. I'll remember that for the future.

Paul Wood           | UUCP Mail:  paul@ukpoit.co.uk   |
31 Buttermere Drive | Bang-Style: ...!ukc!ukpoit!paul |
Dronfield Woodhouse | Voice:      +44 246 418031      |
Sheffield           |
England S18 5PX     |

webber@csd.uwo.ca (Robert E. Webber) (12/23/90)

In article <1654@ukpoit.co.uk> paul@ukpoit.co.uk (Paul Wood) writes:
Adding a -print would cause every .c and .h filename to be printed. If I went
away to cook a meal (which I did), then by the time I got back to the screen
any evidence would have probably scrolled off the top of the screen. This is
not what I wanted.A command should do what you want it to do, no more,no less.

  find / -name \*.\[csh\] -exec grep LINEWRAP {} \; -print

will not print the name of all of the files.  It will only print the names
of those files that succeed on the -exec test.  Since grep returns a 
different status code depending on whether the match succeeds or not,
the effect is the -exec is true only when grep finds something.  Thus it
would only scroll off the screen if the find succeeded very many times, in
which case you would probably want to redo the command with output being
redirected.

Find is definitely one of the nicer things in Unix although the Version 7
man pages for it concludes with:
        BUGS
             The syntax is painful


Of course, looking at console.c on page 375 of the MacMinix manual, we
find that LINEWRAP was doing a fairly straightforward test on tty_column
in the function out_char.  Looking at out_char in the MacMinix console.c,
we find that this module has been significantly rewritten.  Now, only
tty.c cares about tty_column, and there is a new structure vduinfo with
a field ccol that looks like the right thing to hang LINEWRAP off of.
The only question being which function(s) to change and whether or not
to try and track window resizing.

--- BOB (webber@csd.uwo.ca)