Greg A. Woods wrote:
> "Ed" is in fact a very fine and _very_ useful utility, as ascetic as it
> may be.  I think learning to use "ed" well can still teach most people
> more about Unix than any other single utility could ever do.  Except
> maybe sh.  :-)

I think you're exagerating a bit. ed isn't only an obscure program, it's 
also an obsolete piece of code (right around the corner, I have a 
supermarket called "Ed". it's like its unix friend, low quality low 
price, which is ok, but that's only good for those who don't want or 
can't afford better). The only thing I can say about ed is "remove it 
from the tree" (or should I sing "Ed B good tonight?")

Also I don't see anything you can learn by using ed, except learning the 
patience and resistance not to destroy the keyboard (the monitor is more 
expensive so resistance is easy) The last time I used ed, I f+-=ed down 
my disklabel multiple times before getting it right [of course, french 
keyboard (or should I say "freedom keyboard"?) on a US kernel wasn't 
helping, but heh...].

and anyway, the right way to learn about unix is certainly not the ed 
manpage... (that said, isn't unix obsolete ;-p or is it "unix is the 
past, windows the present, and bsd the future"?).

> Of course if one had 'sed' one could easily use commands the likes of:
> 
> 	dmesg | sed -n -e 1,24p
> 	dmesg | sed -n -e 25,50p

I don't like digits, so I prefer:
	gcc -c more.c -o more ; dmesg | more
thus: make more or less, or patch and copy cat.

> and so on to view portions of the output of something like "dmesg"
> without using any temporary files.

The problem isn't caused by temporary files. It's actually caused by 
absent files.

> Unfortunately 'sed' doesn't seem to be in /rescue, nor is 'awk' or
> much of anything else which could easily do similar tricks....

I'd say fortunately they don't. Also, I think that one doesn't 
necessarily need tricks, when one only wants things that work clearly, 
simply and without needing to install a winXP to print the manual.

> 
> Howerver there is still 'sh'!  :-)
> 
> 	i=1
> 	dmesg | while read line ; do
> 		echo $line
> 		if [ $((i++ % 24) -eq 0 ]; then
> 			read ret < /dev/tty
> 		fi
> 	done
> 
> It doesn't handle counting of wrapped lines of course, but it's better
> than trying to use <CTRL-S>!  :-)
> 

ahem. Is the game an "obfuscated more context" or what? If more is too 
much (which would imply that less is yet much more), then a solution is 
to get a dumber prog that doesn't know about all term things but can 
print N lines step by step, and this can be done with not much more 
lines than the prev sh code in safe and fast compiled C. even the number 
of lines ands columns can be passed as args.


cheers,
mouss