tech-kern archive


Re: Input line editing

der Mouse wrote:
And line editing is much less needed when you have all the nice
command completion in there.

Maybe for typical TOPS-20 command lines.

True. TOPS-20 command lines don't come close to the complex mess a command line can be in Unix.

 Definitely not so for me; I
moderately routinely issue commands like

% ( bzcat */log.bz2 ; cat curlog ) | awk 'NR==1 { base = $1; } { printf("%d %d 
%s\n",$1-base,$7,substr($3,1,6)); }' | sort +1n | sed -e 's@\(.*\) \(.*\) \(.*\)@< 
\3/log | sed -e '\''s/.*[[]//'\'' -e '\''s/[]].*//'\'' -e '\''s/.*/\2 & \1/'\'@ | sh | sort 
| uniq -c | sort -n | tail

Wow. While not exactly TECO, you are almost getting close. :-)
Yes, that kind of stuff can't be handled by any completion. Line editing is nice, but it's kindof no real solution to that kind of headache. :-)

I have some reason to think I'm unusual in this respect, but I daresay
there are plenty of other ways completion doesn't make up for lack of
real editing too.

Well, in Unix I'd agree. Since command line arguments can be programs for instance, which no completion ever can help you out much with. Command lines in some other OSes are far less complex. Admittedly that sometimes means you can't do as much from the command line either, but I'm not totally convinced that's a real problem. :-)

But we're drifting off topic here, so I'll stop now. I agree with you that a common command line editing feature would be nice, though. But I don't know how I'd go about it in a Unix system. In a way, I suspect that the terminal driver might be the place to have it, but it would still be a mess to implement, I think.


Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email:             ||  Reading murder books

Home | Main Index | Thread Index | Old Index