Re: Not a typewriter

Re: Not a typewriter

[Wayne.Brown]

On 05/13/2001 at 08:03:30 PM Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
wrote:

>The old C compiler/old Unix linker guaranteed 6 chars in an external symbol
>name only, and C functions got an underscore prepended: _creat. I guess
>this is the reason for this wart. As to why 6 chars only, I'd guess some
>data structure in the linker was laid out that way. Machines had a few
>dozen Kbs of RAM then, space was precious.

I've always thought it was just an arbitrary decision, based on the general Unix
custom of shortnening names by removing vowels, especially since Ken Thompson
later said he'd spell it "create" if he had it to do over again.  But your
explanation sounds more likely.  I really should have thought of this, since I
used to run into problems with non-unique names under the Minix linker (which,
IIRC, had the same 6 char limit).

RE: Not a typewriter

[Bingner Sam J. Contractor RSIS]

I had an experience pretty close... but I never saw anything wrong with
man... I have ALWAYS LOVED man.... it's the perfect help system IMO, and
info is infuriating to me...  There should be a but more documentation some
places sure, but nothing is going to completely remedy that... because
you'll never get everybody to keep documentation updated correctly.

	Sam Bingner
	PACAF CSS/SCHE
	Contractor RSIS
	DSN	315 449-7889
	COMM	808 449-7889


-----Original Message-----
From: Wayne.Brown@altec.com [mailto:Wayne.Brown@altec.com]
Sent: Friday, May 11, 2001 1:19 PM
To: Hacksaw
Cc: linux-kernel@vger.kernel.org
Subject: Re: Not a typewriter




On 05/11/2001 at 04:43:13 PM Hacksaw <hacksaw@hacksaw.org> wrote:

<snip>

>Well, I can't disagree. Unix's biggest turn off was the stupid command
names.
>It's a big reason why Unixoid systems aren't more commonplace. I only
learned
>it because I was stuck at a desk with a Wyse terminal. Otherwise I probably
>would have played with the Autocad machines more. Once I understood the
>basics, I understood the power of the system.

My first exposure to Unix came in 1987 when I was assigned to write a
datacomm
package in C on a Unix (AIX) workstation the company had just bought.  I was
the
only one in our shop who knew C, and no one else there had ever dealt with
Unix
either.  (I had heard of Unix, but didn't know anything about it.)  My
training
consisted of my boss handing me the manuals and saying, "Figure it out."
For
the first two weeks I absolutely HATED that system; nothing made sense, vi
seemed insane, and I was stumbling blindly through the documentation (I'd
never
seen a permuted index before).  Then suddenly something clicked, it all
started
to make sense, and I fell in love with it.  That's why I think it's so
important
for people to learn the Unix mindset before trying to deal with Unix
systems.
It's also why I have so little patience with people who don't have the
patience
to work through the learning curve.

<snip>

>But first we need a better help system. The absolute most stupid convention
of
>Unix is the man command. The fact that SCCS before, and now Bash usurp the
>keyword "help" is beyond the pale.

I guess we'll just have to agree to disagree, because we have exactly
opposite
opinions on all this.  I love the short, cryptic command names, and I think
man
is the best help system ever devised.  (The GNU Info system, however, is the
spawn of Satan. :-) In case you haven't guessed, I love vi, too, and use it
whenever possible.  If Unix (or Linux) ever gets to the point of losing
things
like this, I'll have no desire to use it.

Wayne


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Not a typewriter

[Wayne.Brown]

On 05/11/2001 at 04:43:13 PM Hacksaw <hacksaw@hacksaw.org> wrote:

<snip>

>Well, I can't disagree. Unix's biggest turn off was the stupid command names.
>It's a big reason why Unixoid systems aren't more commonplace. I only learned
>it because I was stuck at a desk with a Wyse terminal. Otherwise I probably
>would have played with the Autocad machines more. Once I understood the
>basics, I understood the power of the system.

My first exposure to Unix came in 1987 when I was assigned to write a datacomm
package in C on a Unix (AIX) workstation the company had just bought.  I was the
only one in our shop who knew C, and no one else there had ever dealt with Unix
either.  (I had heard of Unix, but didn't know anything about it.)  My training
consisted of my boss handing me the manuals and saying, "Figure it out."  For
the first two weeks I absolutely HATED that system; nothing made sense, vi
seemed insane, and I was stumbling blindly through the documentation (I'd never
seen a permuted index before).  Then suddenly something clicked, it all started
to make sense, and I fell in love with it.  That's why I think it's so important
for people to learn the Unix mindset before trying to deal with Unix systems.
It's also why I have so little patience with people who don't have the patience
to work through the learning curve.

<snip>

>But first we need a better help system. The absolute most stupid convention of
>Unix is the man command. The fact that SCCS before, and now Bash usurp the
>keyword "help" is beyond the pale.

I guess we'll just have to agree to disagree, because we have exactly opposite
opinions on all this.  I love the short, cryptic command names, and I think man
is the best help system ever devised.  (The GNU Info system, however, is the
spawn of Satan. :-) In case you haven't guessed, I love vi, too, and use it
whenever possible.  If Unix (or Linux) ever gets to the point of losing things
like this, I'll have no desire to use it.

Wayne

Re: Not a typewriter

[Kai Henningsen]

Wayne.Brown@altec.com  wrote on 11.05.01 in <86256A49.00800177.00@smtpnotes.altec.com>:

> I think man is the best help system ever devised.  (The GNU Info system,
> however, is the spawn of Satan. :-)

Both have good and bad parts. HTML and PDF are yet other such candidates.

Something better is needed, but no two people seem to agree on what  
exactly it should be.

What I want: search support at least as good as Info (which is not very,  
but better than the other two); structure like man; support for both short  
refcard style and long reference book style treatments; one standard  
format that can be supported on console, X, or via a Web interface ... oh,  
and standard key bindings at least don't force people to play at Emacs.

MfG Kai

Re: Not a typewriter

[Wayne.Brown]

On 05/11/2001 at 12:03:43 PM Joel Jaeggli <joelja@darkwing.uoregon.edu> wrote:

>it's not clear to me that that textsearch is a more  accurate description
>than Get Regular ExPression

It's not more accurate.  But Hacksaw's original point was that a new user would
not know what "not a typewriter" meant.  My point was that a newbie wouldn't be
likely to guess that "grep" means "search for text" either; in both cases he'd
have to look it up if he'd never seen it before.

BTW, grep does not stand for "Get Regular ExPression."  It comes from an
often-used command in the ed (and ex and vi) editor: g/re/p.  The "g" means
"global," the "re" is a regular expression, and the "p" means "print."  So to
search for all lines containing the word "foo" in a file you were editing, you
would type g/foo/p.  This was such a useful function that it was packaged in a
standalone program that could be used to search multiple files.

Wayne

Re: Not a typewriter

[Wayne.Brown]

On 05/10/2001 at 06:20:34 PM Hacksaw <hacksaw@hacksaw.org> wrote:

>Heaven help us when tradition is more important than clarity.
>

If clarity is the most important consideration, then other things should be
changed as well.  For instance, the command we use to search for text strings in
files should be called "textsearch."  That's a lot more clear than "grep."

>Typewriter has always been wrong. I'd agree that "Not a teletypewriter" would
>suffice.
>

But the original message said "typewriter."  (The "wrongness" is part of its
charm.)  If the wording is going to be changed, then it's better to abandon the
tradition altogether and use one of the more descriptive and "correct" messages
you and others have proposed.

>On the other hand "Inappropriate ioctl for device" is also not very clear.
>
>I'd like to see "Not a serial or character device" or "Not a serial device" if
>that's more appropriate. Something like that...

My point is that someone who sees the "typewriter" message and doesn't
understand it will have to dig a bit to find out what it means.  Finding it
almost certainly will involve uncovering some of the history and folklore of
Unix.  In the "Intro to Unix" classes I've taught over the years, I've always
made a point of explaining the background of things like this -- such as the
relation of grep to the g/re/p expression of ed, ex and vi; where biff got its
name; what the letters stand for in awk; why creat doesn't end in an "e;" and so
forth.  I tell the class that Unix has quirky, eccentric, whimsical elements
because many of the things in it were written by quirky, eccentric, or whimsical
people.  The comment at the bottom of some versions of the tunefs man page (such
as the HP-UX version) is an example I like to use:  "You can tune a file system,
but you can't tune a fish."  I tell them they'll understand the Unix way of
thinking faster if they approach it with an inquisitive, playful spirit rather
than as a stuffy business system.  It's supposed to be correct; it's supposed to
be efficient; but it's also supposed to be fun, and sometimes the fun is worth
sacrificing a little of the other qualities in trivial areas.

I guess what I'm trying to say is that "Life With Unix" should be required
reading for anyone who goes near a Unix (or Linux) system.

Wayne

Re: Not a typewriter

[Joel Jaeggli]

On Fri, 11 May 2001 Wayne.Brown@altec.com wrote:

> >Heaven help us when tradition is more important than clarity.
> >
>
> If clarity is the most important consideration, then other things should be
> changed as well.  For instance, the command we use to search for text strings in
> files should be called "textsearch."  That's a lot more clear than "grep."

it's not clear to me that that textsearch is a more  accurate description
than Get Regular ExPression

Re: Not a typewriter

[Hacksaw]

>If clarity is the most important consideration, then other things should be
>changed as well.  For instance, the command we use to search for text strings 
in
>files should be called "textsearch."  That's a lot more clear than "grep."

Well, I can't disagree. Unix's biggest turn off was the stupid command names. 
It's a big reason why Unixoid systems aren't more commonplace. I only learned 
it because I was stuck at a desk with a Wyse terminal. Otherwise I probably 
would have played with the Autocad machines more. Once I understood the 
basics, I understood the power of the system.

However, I was a CS major, smart, and a voracious reader. 

-----

I have often thought of an alternate naming scheme that would apply to the 
most basic utilities. With command completion longer names become less 
annoying.

But first we need a better help system. The absolute most stupid convention of 
Unix is the man command. The fact that SCCS before, and now Bash usurp the 
keyword "help" is beyond the pale.

>If the wording is going to be changed, then it's better to abandon the 
tradition

I say abandon tradition when tradition doesn't serve. Arcane messages prevent 
understanding, arbitrary command names sometimes can't be avoided. The process 
is annoying at best, and painful on Linux systems where the documentation 
isn't unified, and is often incomplete.

A beautiful example that came up on my RedHat 6.2 system:
[From ppd_file_new_from_filep(3)]

       ENOTTY no idea what these errors are. Probably PPD parse errors.

I run into things like this all the time.

"Textsearch" is better than grep, except sometimes you aren't searching 
through text. "Search" is more general. "Find" would be even better.

I wish that find had the functions of grep as well, ala the MacOS "find", 
which can (these days) search for files names and attributes, and also search 
for things inside files.

>My point is that someone who sees the "typewriter" message and doesn't
>understand it will have to dig a bit to find out what it means.

All well and good if you have the time. If you are in a business or academic 
settings, the learning curve is an important part of the total cost of 
ownership.

--------

Ob. LKML: Error messages from the kernel should be examined with this in mind. 
The more clear that error message is, the less likely we'll see a question 
about it here.

Re: Not a typewriter

[Mike A. Harris]

On Fri, 11 May 2001, Hacksaw wrote:

>Well, I can't disagree. Unix's biggest turn off was the stupid command names.

I agree partially with that, but as someone who's used DCL in
VMS, I can say meaningful names are no better.  People don't want
to type SHOW DIRECTORY or CREATE /DIRECTORY /PERMISSIONS=blah
blah.. and when given DCL, once people understand how to create
logical names (the equiv of aliases in unix) they alias the above
verbose garbage down to 2-4 letter cryptic looking names.  I
don't know anyone who has used VMS for more than 3 months who
hasn't done the above.  Problem is that everyone chooses their
own cryptic shortcuts from everyone else.  At least in UNIX, the
short cryptic names are the same everywhere, and you can alias
them to larger names if you like.



------------------------------------------------------------------------
Signature poll:  I'm planning on getting a 12 or 16 port autosensing
10/100 ethernet switch soon for home use, and am interested in hearing
others recommendations on what to buy.  Cost isn't as important as is
functionality and quality.  Any suggestions appreciated.
------------------------------------------------------------------------

Re: Not a typewriter

[John Alvord]

On Fri, 11 May 2001 11:07:45 -0500, Wayne.Brown@altec.com wrote:

>
>
>On 05/10/2001 at 06:20:34 PM Hacksaw <hacksaw@hacksaw.org> wrote:
>

>My point is that someone who sees the "typewriter" message and doesn't
>understand it will have to dig a bit to find out what it means.  Finding it
>almost certainly will involve uncovering some of the history and folklore of
>Unix.  In the "Intro to Unix" classes I've taught over the years, I've always
>made a point of explaining the background of things like this -- such as the
>relation of grep to the g/re/p expression of ed, ex and vi; where biff got its
>name; what the letters stand for in awk; why creat doesn't end in an "e;" and so
>forth.  I tell the class that Unix has quirky, eccentric, whimsical elements
>because many of the things in it were written by quirky, eccentric, or whimsical
>people.  The comment at the bottom of some versions of the tunefs man page (such
>as the HP-UX version) is an example I like to use:  "You can tune a file system,
>but you can't tune a fish."  I tell them they'll understand the Unix way of
>thinking faster if they approach it with an inquisitive, playful spirit rather
>than as a stuffy business system.  It's supposed to be correct; it's supposed to
>be efficient; but it's also supposed to be fun, and sometimes the fun is worth
>sacrificing a little of the other qualities in trivial areas.
>
>I guess what I'm trying to say is that "Life With Unix" should be required
>reading for anyone who goes near a Unix (or Linux) system.

David N. Smith, an IBM researcher, wrote that we should preserve the
past for the criticism of the future.

john alvord

Re: Not a typewriter

[Mike A. Harris]

On Fri, 11 May 2001 Wayne.Brown@altec.com wrote:

>>Heaven help us when tradition is more important than clarity.
>>
>
>If clarity is the most important consideration, then other things should be
>changed as well.  For instance, the command we use to search for text strings in
>files should be called "textsearch."  That's a lot more clear than "grep."

gnuregularexpressionparser?


>why creat doesn't end in an "e;" and so forth.  I tell the

What is the reason for that?  Also wondered why it is resolv.conf
and not resolve.conf or resolver.conf...

Were they afraid that "e" being the most widely used letter in
the English language was going to war out thir xpnsiv kyboards if
thy usd it all th tim?

;o)

>I guess what I'm trying to say is that "Life With Unix" should be required
>reading for anyone who goes near a Unix (or Linux) system.

I agree.  ;o)


------------------------------------------------------------------------
Signature poll:  I'm planning on getting a 12 or 16 port autosensing
10/100 ethernet switch soon for home use, and am interested in hearing
others recommendations on what to buy.  Cost isn't as important as is
functionality and quality.  Any suggestions appreciated.
------------------------------------------------------------------------

Re: Not a typewriter

[Horst von Brand]

"Mike A. Harris" <mharris@opensourceadvocate.org> said:
> On Fri, 11 May 2001 Wayne.Brown@altec.com wrote:

[...]

> >why creat doesn't end in an "e;" and so forth.  I tell the

The old C compiler/old Unix linker guaranteed 6 chars in an external symbol
name only, and C functions got an underscore prepended: _creat. I guess
this is the reason for this wart. As to why 6 chars only, I'd guess some
data structure in the linker was laid out that way. Machines had a few
dozen Kbs of RAM then, space was precious.

> What is the reason for that?  Also wondered why it is resolv.conf
> and not resolve.conf or resolver.conf...

Old FS handled only 14 chars in names, but that clearly isn't the reason
here (11 chars). Some other operating system perhaps?

> Were they afraid that "e" being the most widely used letter in
> the English language was going to war out thir xpnsiv kyboards if
> thy usd it all th tim?

Funny conspiracy suscpicion, that... ;-)
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: Not a typewriter

[John Kodis]

On Sun, May 13, 2001 at 09:03:30PM -0400, Horst von Brand wrote:

> The old C compiler/old Unix linker guaranteed 6 chars in an external symbol
> name only, and C functions got an underscore prepended: _creat. I guess
> this is the reason for this wart. As to why 6 chars only, I'd guess some
> data structure in the linker was laid out that way. Machines had a few
> dozen Kbs of RAM then, space was precious.

I recall that RSX-11 and a few other series of early DEC operating
systems stored linker symbols in a "RAD50" encoding scheme which
allowed 6 chararacters to be crammed into a 32-bit "long word".  I
suspect that this is where the limitation originated.

-- 
John Kodis <kodis@acm.org>
Phone: 301-286-7376

Re: Not a typewriter

[Michael Meissner]

On Sun, May 13, 2001 at 09:03:30PM -0400, Horst von Brand wrote:
> "Mike A. Harris" <mharris@opensourceadvocate.org> said:
> > On Fri, 11 May 2001 Wayne.Brown@altec.com wrote:
> 
> [...]
> 
> > >why creat doesn't end in an "e;" and so forth.  I tell the
> 
> The old C compiler/old Unix linker guaranteed 6 chars in an external symbol
> name only, and C functions got an underscore prepended: _creat. I guess
> this is the reason for this wart. As to why 6 chars only, I'd guess some
> data structure in the linker was laid out that way. Machines had a few
> dozen Kbs of RAM then, space was precious.

IIRC, the 6 character linker requirement came from when the Bell Labs folk
ported the C compiler the IBM mainframe world, not from the early UNIX (tm)
world.  During the original ANSI C meetings, I got the sense from the IBM rep,
that part of the problem was the linker was owned by the OS folk, and not the
language group, and it was hard to make a business case why the linker should
be extended to handle newer languages (since it was a different office that was
responsible).  The 6 character limit came from the fact that the linker
actually supported 8 characters, but the first 2 characters were used to denote
different products (I recall IBM stuff all tended to be IE....).  The VMS folk
also had a similar problem (but there they had a 31 character, one case limit),
though by the end of the process, the linker had been moved into the languages
group in that case.

The mainframe linker is also why the 1989 C standard required there to be only
one definition of a global variable (ie, only one module can say "int x;" while
others must say "extern int x"), even though the UNIX compilers have
traditionally used the common model (ie, "int x" creates a common relocation,
so that if there is no other non-common definition, the linker will create
one).  Evidently, the mainframe linker decided to put each unique common
variable on its own page.

I vaguelly recall that somebody went back to Ritchie & Thompson and asked if
they could go back in time and make one change, what would it be.  Ritchie's
answer was to make default chars be unsigned instead of signed (since it really
messes up internation character support), and Thompson's answer was to spell
"create" with an trailing e.


> > What is the reason for that?  Also wondered why it is resolv.conf
> > and not resolve.conf or resolver.conf...
> 
> Old FS handled only 14 chars in names, but that clearly isn't the reason
> here (11 chars). Some other operating system perhaps?

I would imagine you should ask the Berkely folks, since the TCP/IP support all
came from there, and not Bell Labs.

> > Were they afraid that "e" being the most widely used letter in
> > the English language was going to war out thir xpnsiv kyboards if
> > thy usd it all th tim?
> 
> Funny conspiracy suscpicion, that... ;-)

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Not a typewriter

[Alan Cox]

> IIRC, the 6 character linker requirement came from when the Bell Labs folk
> ported the C compiler the IBM mainframe world, not from the early UNIX (tm)
> world.  During the original ANSI C meetings, I got the sense from the IBM rep,

6 character linker name limits are very old. Honeywell L66 GCOS3/TSS which I
had the dubious pleasure of experiencing and which is a direct derivative of
GECOS and thus relevant to the era like many 36bit boxes uses 6 char link names

Why - well because 6 BCD characters fit in a 36bit word and its a single compare
to check symbol matches

Re: Not a typewriter

[Michael Meissner]

On Mon, May 14, 2001 at 06:01:42PM +0100, Alan Cox wrote:
> > IIRC, the 6 character linker requirement came from when the Bell Labs folk
> > ported the C compiler the IBM mainframe world, not from the early UNIX (tm)
> > world.  During the original ANSI C meetings, I got the sense from the IBM rep,
> 
> 6 character linker name limits are very old. Honeywell L66 GCOS3/TSS which I
> had the dubious pleasure of experiencing and which is a direct derivative of
> GECOS and thus relevant to the era like many 36bit boxes uses 6 char link names
> 
> Why - well because 6 BCD characters fit in a 36bit word and its a single compare
> to check symbol matches

Another old system that I recall was the CDC Cyber systems, which when I
encountered them used 6-bit 'bytes' (the null byte meaning ':' in some cases,
and null in others).  The linker resolved names to 7 characters, so it could
fit the name (42 bits) + an 18 bit address into a single 60 bit word.

One of the most useful rules of the GNU coding standards is that it asks people
to avoid putting arbitrary limits in their code:

	For example, Unix utilities were generally optimized to minimize memory
	use; if you go for speed instead, your program will be very different.
	You could keep the entire input file in core and scan it there instead
	of using stdio.  Use a smarter algorithm discovered more recently than
	the Unix program.  Eliminate use of temporary files.  Do it in one pass
	instead of two (we did this in the assembler).

	Or, on the contrary, emphasize simplicity instead of speed.  For some
	applications, the speed of today's computers makes simpler algorithms
	adequate.

	Or go for generality.  For example, Unix programs often have static
	tables or fixed-size strings, which make for arbitrary limits; use
	dynamic allocation instead.  Make sure your program handles NULs and
	other funny characters in the input files.  Add a programming language
	for extensibility and write part of the program in that language.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Not a typewriter

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> > IIRC, the 6 character linker requirement came from when the Bell Labs folk
> > ported the C compiler the IBM mainframe world, not from the early UNIX (tm)
> > world.  During the original ANSI C meetings, I got the sense from the IBM rep,
> 
> 6 character linker name limits are very old. Honeywell L66 GCOS3/TSS which I
> had the dubious pleasure of experiencing and which is a direct derivative of
> GECOS and thus relevant to the era like many 36bit boxes uses 6 char link names
> 
> Why - well because 6 BCD characters fit in a 36bit word and its a single compare
> to check symbol matches

well... actually it was 6 bit "ascii" computed from: (char - ' '). Depends
entirely on architecture, and implementation. EBCD/6Bit/7Bit and EBCDIC were
supported on the Honeywell systems.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Not a typewriter

[H. Peter Anvin]

Followup to:  <200105141729.MAA28295@tomcat.admin.navo.hpc.mil>
By author:    Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
In newsgroup: linux.dev.kernel
> 
> well... actually it was 6 bit "ascii" computed from: (char - ' '). Depends
> entirely on architecture, and implementation. EBCD/6Bit/7Bit and EBCDIC were
> supported on the Honeywell systems.
> 

There was also a genuine ASCII-6 encoding.  It didn't look much like
ASCII-7 as far as I remember.

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Not a typewriter

[Jonathan Lundell]

>why creat doesn't end in an "e;" and so forth.  I tell the

Some time back, Ken Thompson was asked, if he had it to do over 
again, what changes he would make to Unix. The only thing he could 
think of: spell it "create()".
-- 
/Jonathan Lundell.

Re: Not a typewriter

[Wayne.Brown]

On 05/10/2001 at 05:38:32 PM hpa@transmeta.com (H. Peter Anvin) wrote:

>Sounds like someone has just clarified what the heck it means.  "tty"
>and "typewriter" aren't exactly the same thing (even though "tty"
>stands for "teletypewriter" it has come to mean something completely
>different in a Unix context)... "not a typewriter" is just a
>completely confusing error message for the uninitiated.


I disagree.  "Not a typewriter" is part of Unix tradition, and ought to be
retained as a historical reference.  It's also an opportunity for "the
uninitiated" to learn a little more and move a little closer to becoming "the
initiated."

Wayne

Re: Not a typewriter

[Hacksaw]

>I disagree.  "Not a typewriter" is part of Unix tradition, and ought to be
>retained as a historical reference.  It's also an opportunity for "the
>uninitiated" to learn a little more and move a little closer to becoming "the
>initiated."

Heaven help us when tradition is more important than clarity.

Typewriter has always been wrong. I'd agree that "Not a teletypewriter" would 
suffice.

On the other hand "Inappropriate ioctl for device" is also not very clear.

I'd like to see "Not a serial or character device" or "Not a serial device" if 
that's more appropriate. Something like that...

Re: Not a typewriter

[Jonathan Lundell]

At 7:20 PM -0400 2001-05-10, Hacksaw wrote:
>  >I disagree.  "Not a typewriter" is part of Unix tradition, and ought to be
>>retained as a historical reference.  It's also an opportunity for "the
>>uninitiated" to learn a little more and move a little closer to becoming "the
>>initiated."
>
>Heaven help us when tradition is more important than clarity.
>
>Typewriter has always been wrong. I'd agree that "Not a teletypewriter" would
>suffice.
>
>On the other hand "Inappropriate ioctl for device" is also not very clear.
>
>I'd like to see "Not a serial or character device" or "Not a serial device" if
>that's more appropriate. Something like that...

ENOTTY is used by several non-serial devices (or file systems) to 
object to an unrecognized ioctl command. There's also ENOIOCTLCMD 
(apparently supposed to be a non-user errno, but i don't see where it 
gets changed to something else) and EINVAL. I'm not sure what the 
rationale is for choosing among them; perhaps someone would elucidate?
-- 
/Jonathan Lundell.

Re: Not a typewriter

[Alexander Viro]

On Thu, 10 May 2001, Jonathan Lundell wrote:

> ENOTTY is used by several non-serial devices (or file systems) to 
> object to an unrecognized ioctl command. There's also ENOIOCTLCMD 
> (apparently supposed to be a non-user errno, but i don't see where it 
> gets changed to something else) and EINVAL. I'm not sure what the 
> rationale is for choosing among them; perhaps someone would elucidate?

ENOIOCTLCMD is something I've never met in the kernel. Normal reaction
to unrecognized ioctl() is ENOTTY, for a lot of reasons, starting with
the fact that ioctls are last-ditch API to be used when you just can't
think of better one and historically TTY had the earliest (and largest)
infestation. IOW, "not a tty" used to mean "WTF are you using ioctls here?"
OTOH, EINVAL is a catch-all thing for "something is wrong with arguments".

Re: Not a typewriter

[Jonathan Lundell]

At 8:07 PM -0400 2001-05-10, Alexander Viro wrote:
>On Thu, 10 May 2001, Jonathan Lundell wrote:
>
>>  ENOTTY is used by several non-serial devices (or file systems) to
>>  object to an unrecognized ioctl command. There's also ENOIOCTLCMD
>>  (apparently supposed to be a non-user errno, but i don't see where it
>>  gets changed to something else) and EINVAL. I'm not sure what the
>>  rationale is for choosing among them; perhaps someone would elucidate?
>
>ENOIOCTLCMD is something I've never met in the kernel. Normal reaction
>to unrecognized ioctl() is ENOTTY, for a lot of reasons, starting with
>the fact that ioctls are last-ditch API to be used when you just can't
>think of better one and historically TTY had the earliest (and largest)
>infestation. IOW, "not a tty" used to mean "WTF are you using ioctls here?"
>OTOH, EINVAL is a catch-all thing for "something is wrong with arguments".

That's pretty much what I would have said a couple of hours ago 
before grepping the kernel. Try it, though. ENOTTY is rarely used. 
ENOIOCTLCMD is all over the damned place, though its comment in 
errno.h warns that a user shouldn't see it. And if you browse a bunch 
of random ioctl handlers, you'll see EINVAL used for a bad command 
much more often than ENOTTY.

FWIW, the comment in errno.h under Solaris 2.6 is "Inappropriate 
ioctl for device". I believe that's the POSIX interpretation.
-- 
/Jonathan Lundell.

Re: Not a typewriter

[Malcolm Beattie]

Jonathan Lundell writes:
> FWIW, the comment in errno.h under Solaris 2.6 is "Inappropriate 
> ioctl for device". I believe that's the POSIX interpretation.

POSIX has

  [ENOTTY]  Inappropriate I/O control operation
            A control function was attempted for a file or special file
            for which the operation was inappropriate.

which is quite a nice way of putting it.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

Re: Not a typewriter

[H. Peter Anvin]

Wayne.Brown@altec.com wrote:
> 
> On 05/10/2001 at 05:38:32 PM hpa@transmeta.com (H. Peter Anvin) wrote:
> 
> >Sounds like someone has just clarified what the heck it means.  "tty"
> >and "typewriter" aren't exactly the same thing (even though "tty"
> >stands for "teletypewriter" it has come to mean something completely
> >different in a Unix context)... "not a typewriter" is just a
> >completely confusing error message for the uninitiated.
> 
> I disagree.  "Not a typewriter" is part of Unix tradition, and ought to be
> retained as a historical reference.  It's also an opportunity for "the
> uninitiated" to learn a little more and move a little closer to becoming "the
> initiated."
> 

Nowhere else in Unix is a "tty" referred to as a "typewriter".  "Not a
tty" is one thing; "Not a typewriter" is just plain misleading.

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Not a typewriter

[Richard B. Johnson]

On Thu, 10 May 2001, H. Peter Anvin wrote:

> Wayne.Brown@altec.com wrote:
> > 
> > On 05/10/2001 at 05:38:32 PM hpa@transmeta.com (H. Peter Anvin) wrote:
> > 
> > >Sounds like someone has just clarified what the heck it means.  "tty"
> > >and "typewriter" aren't exactly the same thing (even though "tty"
> > >stands for "teletypewriter" it has come to mean something completely
> > >different in a Unix context)... "not a typewriter" is just a
> > >completely confusing error message for the uninitiated.
> > 
> > I disagree.  "Not a typewriter" is part of Unix tradition, and ought to be
> > retained as a historical reference.  It's also an opportunity for "the
> > uninitiated" to learn a little more and move a little closer to becoming "the
> > initiated."
> > 
> 
> Nowhere else in Unix is a "tty" referred to as a "typewriter".  "Not a
> tty" is one thing; "Not a typewriter" is just plain misleading.
> 

I was told that "Not a typewriter" was a catch-all for a screw-up.
It was to advise that it wasn't a typewriter keyboard you were
hacking at, where you could enter anything.

Over the years, I have used ENOTTY as a temporary return-code from
drivers and library procedures so I could tell what procedure
was returning an error. For instance, if you have a number of
calls that return ETIME, during testing it would be nice to see
what routine timed out. I was quite surprised to find out that
perror() was printing an error string that none of my procedures
were thought to have generated. Then I wrote:

#include <stdio.h>
#include <errno.h>
main() {
    errno = ENOTTY;
    perror("");
}

So "Not a typewriter" has been depreciated (deprecated?). The text
in the header file probably should be changed to show this.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Not a typewriter

[David S. Miller]

H. Peter Anvin writes:
 > Nowhere else in Unix is a "tty" referred to as a "typewriter".  "Not a
 > tty" is one thing; "Not a typewriter" is just plain misleading.

If anything it should be "Not a teletype"

Later,
David S. Miller
davem@redhat.com

Re: Not a typewriter

[Blue Lang]

On Thu, 10 May 2001, David S. Miller wrote:

>  > Nowhere else in Unix is a "tty" referred to as a "typewriter".  "Not a
>  > tty" is one thing; "Not a typewriter" is just plain misleading.
>
> If anything it should be "Not a teletype"

fork it and see which code base the users support! ;) (would support the
one that doesn't mention !#@$%#$ typewriters. that irritated me for months
when i used DYNIX and my terms never worked properly.)

-- 
   Blue Lang                                    http://www.gator.net/~blue
   Unix Administrator                                     Veritas Software
   2315 McMullan Circle, Raleigh, North Carolina, USA         919 835 1540

Re: Not a typewriter

[Alan Cox]

> > If anything it should be "Not a teletype"
> 
> fork it and see which code base the users support! ;) (would support the
> one that doesn't mention !#@$%#$ typewriters. that irritated me for months
> when i used DYNIX and my terms never worked properly.)

You can internationalise the error string in glibc to something else if you 
wish. Confining 'not a teletyte' to bell-prehistoric language tables wouldnt
be that bad a thing. 

Re: Not a typewriter

[Alan Cox]

> I disagree.  "Not a typewriter" is part of Unix tradition, and ought to be
> retained as a historical reference.  It's also an opportunity for "the
> uninitiated" to learn a little more and move a little closer to becoming "the
> initiated."

Thats fine. Keep it for the

	'Install seriously weird prehistoric stuff'

option that most users really don't want

Alan [who hacked on a GCOS3 box, used DDT on a DEC10 and VTECO and quite frankly
      thinks Gnome and KDE are probably the future not them]

Re: Not a typewriter

[Anuradha Ratnaweera]

On Thu, 10 May 2001 Wayne.Brown@altec.com wrote:

> I disagree.  "Not a typewriter" is part of Unix tradition, and ought
> to be retained as a historical reference.  It's also an opportunity
> for "the uninitiated" to learn a little more and move a little closer
> to becoming "the initiated."

We should maintain the Unix tradition. I would feel very unhappy if I
happen to use a system call "create" to make a file.

Anuradha


----------------------------------------------------------
<a href="http://www.bee.lk/people/anuradha/">home page</a>

Not a typewriter

[Richard B. Johnson]

I noticed that my favorite "errno" has now gotten trashed by
the newer 'C' runtime libraries.

ENOTTY has been for ages, "Not a typewriter".
It's now been changed to "Inappropriate ioctl for device".

Methinks that this means that ../linux/include/asm/errno.h now needs
to be updated:


-#define	ENOTTY		25	/* Not a typewriter */
+#define	ENOTTY		25	/* Inappropriate ioctl for device 
*/

None of these strings are in the kernel, but the headers probably should
show the "latest standard".


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Not a typewriter

[H. Peter Anvin]

Followup to:  <Pine.LNX.3.95.1010510173138.29690A-100000@chaos.analogic.com>
By author:    "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
> 
> I noticed that my favorite "errno" has now gotten trashed by
> the newer 'C' runtime libraries.
> 
> ENOTTY has been for ages, "Not a typewriter".
> It's now been changed to "Inappropriate ioctl for device".
> 
> Methinks that this means that ../linux/include/asm/errno.h now needs
> to be updated:
> 
> 
> -#define	ENOTTY		25	/* Not a typewriter */
> +#define	ENOTTY		25	/* Inappropriate ioctl for device 
> */
> 
> None of these strings are in the kernel, but the headers probably should
> show the "latest standard".
> 

Sounds like someone has just clarified what the heck it means.  "tty"
and "typewriter" aren't exactly the same thing (even though "tty"
stands for "teletypewriter" it has come to mean something completely
different in a Unix context)... "not a typewriter" is just a
completely confusing error message for the uninitiated.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Not a typewriter

[Tom Leete]

"Richard B. Johnson" wrote:
> 
> I noticed that my favorite "errno" has now gotten trashed by
> the newer 'C' runtime libraries.
> 
> ENOTTY has been for ages, "Not a typewriter".
> It's now been changed to "Inappropriate ioctl for device".
> 
> Methinks that this means that ../linux/include/asm/errno.h now needs
> to be updated:
> 
> -#define        ENOTTY          25      /* Not a typewriter */
> +#define        ENOTTY          25      /* Inappropriate ioctl for device
> */
> 
> None of these strings are in the kernel, but the headers probably should
> show the "latest standard".
> 
> Cheers,
> Dick Johnson

Probably so, but I think:

character device => typewriter
block => sheet of paper
block device => stack of paper

is not a bad analogy.

Cheers
Tom

PS. I didn't dare call it a ream of paper ;-)

-- 
The Daemons lurk and are dumb. -- Emerson