> >Actually, NetBSD *does* ship with *3* shells that support command-line
> >history.  Try any of sh, csh, or ksh.  They also support aliases and
> >scripts, providing other ways to reduce one's typing.  (^&
>
> Oh, but I said /in a useful way/. It's either not activated by default, or

Sorry, then, it must have been another message of yours.  All that I saw
was in http://mail-index.netbsd.org/netbsd-users/2002/04/20/0004.html .
Perhaps when I ``reply'' to a message that I see in the archives, I should
include the URL.


> over-complicated and user-unfriendly. !25 really isn't as nice as arrow-up.

Prefix-matching and substitution are more common.  But I'll admit that I
prefer ksh/sh history handling to csh.

The best history/line-editing that I've used was what the AmigaDOS NewCON:
handler provided.  But, even there, it's subjective.  I knew an Amiga user
who hated a feature that I loved: If you type a character, output is
blocked until you finish the line you are typing or clear it.  I miss that
in UNIX shells.  Typing ^R to review what you've typed (and which has been
spammed by output) is a very poor substitute.


> Have you tried BASH or ZSH?

Yes. Have you tried an Amiga?


> >But, also bear in mind that, e.g., the tlp (Tulip chipset & clones) driver
> >is in a source file with a tlp prefix, and a lot of internal
> >structures/functions have a tlp_ prefix.  (Actually, the file I was
> >looking at had tlp_pci_ as the file- and structure-prefix.)
>
> OTOH, UNIX has a lot of complex commands for manipulating text.

Perhaps I misunderstand what you have in mind here, but I think that this
basically boils down to: Either the developers use the same internal names
as external names, or they don't.  I'm not sure exactly what tools you
would suggest using to get both (or neither).


> >Perhaps someone who knows more about the way that the system works from
> >source can say how functionally necessary this is.  But certainly, it
> >makes it easy to *find* the files and structures.  So to change the names
> >would implicitly suggest/require changing the files.  And from there, you
> >have left the realm of what a history-buffer in your shell can help you
> >with.  If developers use #define macros to type ``tlp'' in the source,
> >that would defeat the value of matching names.  If they have to type Tulip
> >everywhere, it would make it appreciably harder to read and write sources.
>
> What the sources look like internally is of no interest to the end user. The
> programmer may call all their includes and procedure foo, bar and joe for all
> I'm concerned. I don't mind at all.

I value the fact that NetBSD works well.  If having a 2- or 3-letter name
for my ethernet card helps even in a small way towards that, by making
development quicker or more pleasant (or easier for pieceworkers to pick
up) then it's more than justified for me.  I *do* care about this.

What I don't care about is whether, the first time I turn on my computer
after putting in a new ethernet card, I have to learn a 2- or 3-letter
name (e.g., tlp) for the card, or a 5-letter name (e.g., elink).


> >If your sole concern is to identify the hardware readily, I suggest
> >perusing dmesg (or /var/log/messages).  If the information there is still
> >too terse, turn up the verbosity of your kernel.  Of course, it still may
> >not be too helpful.  The kernel can't read the stickers on the card...
>
> I've got an OpenBSD machine whose dmesg gets filled with "de0: parity error"
> or something like that, which in turn causes the boot-up messages to roll off
> the history. ;-)

That's why I added, ``(or /var/log/messages)''.  If your uptime is long
enough that the rotating logs are all filled with such messages, you could
do the unthinkable and reboot.  (^&

Besides, you probably will want to find out things like ``my brand new
ethernet card that I just put in is de'' shortly after the first time that
you boot with the new card, so your logs shouldn't be overfull when you
need this information.


> Besides, dmesg is only a workaround. But hey, why couldn't NetBSD use an alias
> system, so that lamers like me could type elink, whereas programmers and
> people who use ifconfig a lot type ep?

Is ``elink'' an abbreviation of the name on the box that the card came in?
If so, consider that the name on the box isn't really tied to the chipset
used (hence to the driver required).

But, perhaps every ethernet card could be given a generic ``ether*''
interface name, in addition to the driver-specific name.  I don't know
what sort of technical barriers would be involved, or how much resistance
such an idea would receive...


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu