> >Prefix-matching and substitution are more common.  But I'll admit that I
> >prefer ksh/sh history handling to csh.
>
> Bash-style editing is very straight-forward, you don't have to read any man
> pages in order to get the basics.
>
> >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.
>
> NewCON:? You haven't tried KingCON then?

Probably not.  When my last Amiga was showing signs of flakieness (about 5
years ago), I hurried up to get something else.  The Amgia's future looked
dim, so I caved in and bought a PC.  (And after the obligatory playing of
games that came bundled, I eventually installed NetBSD so that the PC
would be useful.  (^&)


> I find the blocking "feature" (it's rather a bug, really) useful, since it's
> easier to press space than ^S, but it's not optimal, since it becomes really
> easy to block a program unintentionally.

^S isn't an alternative, because then *you* can't type anything either.
The point is, when I'm typing, I want the computer to shut up and listen,
not spam me.  I had never heard that this was a bug in the console
handling; but if it is, it's a very fortuitous one, and I'm glad that CBM
recognized its positive value and replicated it from CON: to NewCON:.


> >> >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).
>
> I'm not into that, but I hear that awk and grep can do wonders in that regard.

grep's fine if you're just looking for something and know what it looks
like.  It won't help so much if you're just trying to read the sources.
I don't see how one would use awk in normal programming.  (Certainly, I
*hope* that none of the developers are routinely transforming sources to
and fro under off-the-cuff awk scripts!)


> >> >Perhaps someone who knows more about the way that the system works from
> >> >source can say how functionally necessary this is.  But certainly, it
 [...]
> >> 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.
>
> I don't really think the internal names are an issue, though. Sounds really
> odd, really, though I have only limited C experience.

Since I haven't ever worked on (or spent much time looking at) driver
sources in NetBSD, I will only say that my impression is that a verbose
name would damage code readability.  Others who actually work on the code
may or may not agree, however.


> >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).
>
> I tend to value clarity, but perhaps I'd be more suited as a VMS user than a
> UNIX user, then.

I value clarity, too.  But there's more than just the end-user's immediate
perspective to bear in mind.  Or, put another way, some ``end-users'' are
developers or professional administrators, and they (to varying degrees)
need to be able to make changes; clean code is an end-user plus for them.
And, there's the indirect benefit that even you and I get from having code
that's more easily maintained.


 [...]
> >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.  (^&
>
> But you know, there's prestige involved in your uptime. =)

Yeah, I know.  (^&


> Didn't know about that file in /var, though.

Someone also suggested /var/run/dmesg.boot, which is even better for this.


> >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
 [...]
> Not really, no, but once you re-config it, you'd have to think about whether
> it was el, ef or ep. As we all can see, this isn't a big issue, but I still
> wonder why the names can't be a bit more verbose.

Hm.  This doesn't cause any trouble for me.  I rather have trouble
remembering the names that were on the boxes for the cards that I have.


 [...]
> >If so, consider that the name on the box isn't really tied to the chipset
> >used (hence to the driver required).
>
> I appreciate this in the case of the NS8390 (NE2000 and clones, as well as
> non-clones) or the LANCE, but the EtherLink III chipset is AFAIK only used on
> EtherLink III cards.

So this is something that would only affect a single driver?  You're not
after a general change to make driver names more verbose?  Well, if you
want to go through and rename the driver (and fix up all of the sources
and docs to match), and if the changes are accepted by the developers,
it's no skin off my nose either way.  After all, I don't use that
interface, so I wouldn't have to rename my /etc/ifconfig.* files, or
relearn anything.  (^&

If you're waiting for someone else to do that work for you, though, my
impression is that it's not going to happen.


> >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...
>
> You mean something like Linux, which calls all Ethernet adaptors just eth*?

As aliases for the real names, yes.  That would meet your request for not
having to think about the driver name.  I'm not sure if it's a good idea
to do such a thing, or how difficult it would be.  And, being quite
content with names such as tlp0, I have no real interest in this.  (^&


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