Richard Rauch skrev:

>> >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.

It probably was in another one, but I can't be arsed to look. =)

>> 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.

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?
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.

>> Have you tried BASH or ZSH?

>Yes. Have you tried an Amiga?

I'm typing this on one. ;-)

>> >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.

>> >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.

I don't really think the internal names are an issue, though. Sounds really
odd, really, though I have only limited C experience.

>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.

>> >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.  (^&

But you know, there's prestige involved in your uptime. =)
Didn't know about that file in /var, though.

>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.

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.

>> 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?

Yes, EtherLink.

>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.

>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*?

--
En ligne avec Thor 2.6a.

JavaScript has been developed to show scrolling messages on your pages. It
should have been named ScrollerScript, but as it came out more or less the
same time when the hype on a programming language called Java (poor man's
SmallTalk raped by C++ which is expected to solve all problems of the world,
including traffic, pollution and AIDS) started, it's creators decided to use
the term ``Java'' in it's name, too.
 -- README for the HTML preprocessor "hsc"