UNIX questions should be considered Semi-On Topic on clc

[Wolfgang Draxinger]

I'm currently browsing though my copy of K&R "The C Programming
Language", preparing a undergraduate course "Introduction to
numerical C programming for physicists".

Well, chapter 8 (p. 169 ff.) is captioned "The UNIX System
Interface".

Now I ask you: How which newsgroup will it be, that (new) readers
are asking UNIX questions in? Hint: They're reading a book about
the C programming language.

I think this NG should adhere to the fact, that in the standard
textbook about the language it covers (C), the UNIX API is
outlined. And that will readers will have questions on that,
which they reasonably - it's covered in a textbook on C - will
ask here.

Wolfgang

 

[vippstar]

I'm currently browsing though my copy of K&R "The C Programming
Language", preparing a undergraduate course "Introduction to
numerical C programming for physicists".

Well, chapter 8 (p. 169 ff.) is captioned "The UNIX System
Interface".

Now I ask you: How which newsgroup will it be, that (new) readers
are asking UNIX questions in? Hint: They're reading a book about
the C programming language.

I think this NG should adhere to the fact, that in the standard
textbook about the language it covers (C), the UNIX API is
outlined. And that will readers will have questions on that,
which they reasonably - it's covered in a textbook on C - will
ask here.

Well I was reading deitel & deitel 5th ed, and it also mentions C++
and the Allegro library. Therefore, those should be considered semi-on
topic as well.

 

[Antoninus Twink]

Well I was reading deitel & deitel 5th ed, and it also mentions C++
and the Allegro library. Therefore, those should be considered semi-on
topic as well.

Excellent point - I completely agree.

 

[Wolfgang Draxinger]

Well I was reading deitel & deitel 5th ed, and it also mentions C++
and the Allegro library. Therefore, those should be considered semi-on
topic as well.

Unlike the Deitel & Deitel books, which are part of a series to all kinds of
programming languages, "The C Programming Language" has been written by the
creators of the C language and is thus the canonical textbook on that
topic.

This is similair to say, the "Official OpenGL Programming Guide" (aka the
Red Book), there are plenty of other books on the OpenGL topic, covering
things that are better discussed in comp.graphics.algorithms. But as long
as such topics are also discussed in the Red Book they are well accepted
for discussion in comp.graphics.opengl, and this is, because people have
seen those examples in the canonical textbook and naturally will go to ask
the people most closely associated with that certain book.

And in the case of "The C Programming Language", which is the canonical text
on C, this would be clc. I'm not saying, UNIX topics should be broadly
discussed here, but basic questions and their explanation should be allowed
here. Of course advanced stuff like file descriptor redirection, socket
programming and such belog into the proper NGs. But questions on open,
close, read, write (and maybe fork and exec) should be well accepted here.

Those are topics touched in the canonical C textbook and thus such questions
on that, if asked here, should not be bluntly redirected into other NGs.

Wolfgang

 

[Ben Bacarisse]

Unlike the Deitel & Deitel books, which are part of a series to all kinds of
programming languages, "The C Programming Language" has been written by the
creators of the C language and is thus the canonical textbook on that
topic.

That's a red herring. My K&R discusses 9 system calls, and the
interface it describes is obsolete. If you want to add those 9 calls
to what is topical and limit the discussion to systems where a
directory is read as plain file of struct direct { ino_t i; char
name[14]; } entries then I doubt there will be any takers.

fork (which stared this thread, I think) is not included.

The advice -- to ask elsewhere -- is simply a matter of practicality.
A "unixy" question here will often be badly answered and these answers
will not be corrected.

 

[Wolfgang Draxinger]

That's a red herring. My K&R discusses 9 system calls, and the
interface it describes is obsolete. If you want to add those 9 calls
to what is topical and limit the discussion to systems where a
directory is read as plain file of struct direct { ino_t i; char
name[14]; } entries then I doubt there will be any takers.

It's not about focusing on that set of syscalls. It's about the fact, that
the UNIX API is touched in K&R. Every now and then somebody asks about
simple syscalls and gets bluntly slapped in the face here, merely
suggesting "ask in comp.unix.programmer". A little bit of explanation would
be nice.

There's that guy (I won't give names) who was in the development team of a
popular Linux Distribution and coded a leaner alternative to the original
package manager. This guy gave answers in that cold, formal tune only, too.
A lot of people were put off by that. They asked "how do I..?" and all they
in response litteraly was barely more than "RTFM". This behaviour got that
guy kicked from the development team (i.e. his status was revoked).

Now you can't kick people from clc, but it has a major influence on the
weighting whom newbies tend attention. And there are some guys on clc (I
won't name them, too), which give explanation, but their knowledge of C is
inferior, or they are too pragmatic in addressing certain problems.

True, clc is not the place to ask advanced questions on UNIX, but people new
to the trade should be well treated. Especially as the UNIX API has been
designed with mostly C in mind as such is quite close to it. Thus Semi-OnT:
Give a compact answer if still somewhat related to C and F'up2 c.u.p for
details.

Wolfgang

 

[Ben Bacarisse]

True, clc is not the place to ask advanced questions on UNIX, but people new
to the trade should be well treated. Especially as the UNIX API has been
designed with mostly C in mind as such is quite close to it. Thus Semi-OnT:
Give a compact answer if still somewhat related to C and F'up2 c.u.p for
details.

We would be in complete agreement if (a) Followup-to worked (too many
people ignore it when replying and the effect is often to promote a
huge cross-posted thread) and (b) there were not people here who post
misleading information on system specific topics. I think they do it
deliberately. They, of course, don't set Followup-to.

I might try your suggestion a couple of times, but a simple, polite,
redirection still look to me to be the best answer.

 

[Rui Maciel]

Now I ask you: How which newsgroup will it be, that (new) readers
are asking UNIX questions in? Hint: They're reading a book about
the C programming language.

I do believe you already answered your question. If it's an UNIX question then why
wouldn't it be posted to a UNIX newsgroup?


Rui Maciel

 

[jameskuyper]

That's a red herring. My K&R discusses 9 system calls, and the
interface it describes is obsolete. If you want to add those 9 calls
to what is topical and limit the discussion to systems where a
directory is read as plain file of struct direct { ino_t i; char
name[14]; } entries then I doubt there will be any takers.

It's not about focusing on that set of syscalls. It's about the fact, that
the UNIX API is touched in K&R. Every now and then somebody asks about
simple syscalls and gets bluntly slapped in the face here, merely
suggesting "ask in comp.unix.programmer".

I would say that the fundamental problem is misinterpretation of that
suggestion as a rude "slap in the face", rather than as what it is, a
perfectly polite re-direction. Add the word "please", as sometimes
happens, and it's even a friendly redirection.

A little bit of explanation would be nice.

Oddly enough, a little bit of explanation is, in fact, usually
provided. Providing a lot of explanation is not a good idea, because
it might spark further off-topic discussions in this newsgroup. The re-
directed forum is, in any case, a better place to get a more complete
explanation.

 

[dj3vande]

[K&R2 chapter 8 refers to the Unix system call API]

I think this NG should adhere to the fact, that in the standard
textbook about the language it covers (C), the UNIX API is
outlined. And that will readers will have questions on that,
which they reasonably - it's covered in a textbook on C - will
ask here.

If they were reading carefully enough to get anything useful out of it,
they would have noticed that it says (third paragraph of the chapter):
Chapter 7 was concerned with an input/output interface that is
uniform across operating systems. On any particular system the
routines of the standard library have to be written in terms of the
facilities provided by the host system. In the next few sections we
will describe the UNIX system calls for input and output, and show
how parts of the standard library can be implemented with them.
i.e. K himself points out that he's going beyond C in chapter 8.

So how is it inappropriate to point out that the unix system interface
is not part of C and therefore outside the scope of CLC, and redirect
posters to comp.unix.programmer?


dave

 

[Keith Thompson]

And in the case of "The C Programming Language", which is the canonical text
on C, this would be clc. I'm not saying, UNIX topics should be broadly
discussed here, but basic questions and their explanation should be allowed
here. Of course advanced stuff like file descriptor redirection, socket
programming and such belog into the proper NGs. But questions on open,
close, read, write (and maybe fork and exec) should be well accepted here.

Those are topics touched in the canonical C textbook and thus such questions
on that, if asked here, should not be bluntly redirected into other NGs.

I think you're assuming that a redirection will be taken as a
criticism of the person asking the question. If so, I disagree. The
point of a redirection isn't to insult the questioner by telling him
he posted in the wrong place; it's to let him know that there's
another place where he can get *better* answers to his question. (I'm
inferring this from your use of the word "bluntly"; perhaps I'm
reading too much into it.)

You're right, K&R does include material on the Unix system interface,
and for that and other reasons it's not at all surprising that we get
Unix-specific questions here. It doesn't even bother me very much.
But as long as comp.unix.programmer exists as an active newsgroup, I
see no point in *not* redirecting such questions there.

 

[Kenny McCormack]

Those are topics touched in the canonical C textbook and thus such questions
on that, if asked here, should not be bluntly redirected into other NGs.

The problem with this conversation is that the two sides are using
different terminology/frame-of-reference.

In their fantasy world, "bluntly redirecting the OP into other NGs" [*]
is doing them a favor. It's not really possible to have a sensible
conversation with people with that twisted world view.

[*] Aka, telling them to **** off.

 

[Kenny McCormack]

I think you're assuming that a redirection will be taken as a
criticism of the person asking the question. If so, I disagree. The

You lie. You don't disagree. You think they shouldn't feel this way
(which is a valid [but stupid] opinion to hold), but you don't for a
second think they don't take it as "**** off".

Nor do you not intend it as "**** off".

 

[Antoninus Twink]

[snip same old same old]

As you can see Wolfgang, there is simply no point in trying to persuade
these people by rational argument. They are fanatics, fundamentalists,
and as such they are simply not susceptible to reasoning.

The only thing to do is simply to act in accordance with your own
carefully-considered opinion, and provide useful help on Unix questions
to posters who ask them, ignoring the pointless polemics of the
"regulars".

 

[CBFalconer]

I'm currently browsing though my copy of K&R "The C Programming
Language", preparing a undergraduate course "Introduction to
numerical C programming for physicists".

Well, chapter 8 (p. 169 ff.) is captioned "The UNIX System
Interface".

Now I ask you: How which newsgroup will it be, that (new) readers
are asking UNIX questions in? Hint: They're reading a book about
the C programming language.

However, if you bother to read the book, you will find that K&R
specify that this addition is for convenience, and has nothing to
do with the C language.

 

[user923005]

I'm currently browsing though my copy of K&R "The C Programming
Language", preparing a undergraduate course "Introduction to
numerical C programming for physicists".

Well, chapter 8 (p. 169 ff.) is captioned "The UNIX System
Interface".

Now I ask you: How which newsgroup will it be, that (new) readers
are asking UNIX questions in? Hint: They're reading a book about
the C programming language.

I think this NG should adhere to the fact, that in the standard
textbook about the language it covers (C), the UNIX API is
outlined. And that will readers will have questions on that,
which they reasonably - it's covered in a textbook on C - will
ask here.

Have you read Petzold's C books?
Chock full O' C stuff, but even more full of Windows API stuff.

I have a book on my desk called "Algorithms in C" by Sedgewick. It
also has C in the name and Algorithms too! So algorithms are on
topic.
I have Crenshaw's "Math Toolkit for Real-Time Programming" with CD-Rom
included. Guess what, C again!
Not to mention Weiss' "Data Strucutes and Algorithm Analysis in C" so
we have a double witness that Algorithms are spot on.
I have within 10 feet, "C Mathematical Function Handbook" by Baker.
So math is topical as well.
Right here, in my hot little hands at this moment sits "Number Theory
-- A Programmer's Guide" by Mark Herkommer. You guessed it -- all the
algorithms are written in C so Cryptography is also a go!
Wait a minute -- Here's "Game physics" by David Eberly. Now, I admit
it is in C++ rather than C, but *Some* of the code snippets will
compile as either C or C++ with very little effort!
So let's add both games *and* physics.

I suspect that very little effort along this path will lead us to one
of two conclusions:
1. Literally everything is topical here because there are C books on
that topic or the application is written in C or something along those
lines...
Or:
2. We can restrict the topicality to C (and related subjects when
there is not another group that *better* covers the topic).

If everything is topical, then we can just go on about whatever. If
we apply rule 2, then let us examine your notion about Unix....
Unix is largely written in C. The K&R2 book has a section on C. It
sounds rather topical here. But wait a minute...
There are some other sensible places to find Unix information:
From:
ftp://rtfm.mit.edu/pub/Index-byname

We have this:
pub/usenet-by-group/alt.answers/unix-faq/bbs-software/faq
....
{383 entries containing the string "UNIX" snipped...}
....
pub/usenet-by-hierarchy/de/answers/de-pub-unix

 

[Kaz Kylheku]

Unlike the Deitel & Deitel books, which are part of a series to all kinds of
programming languages, "The C Programming Language" has been written by the
creators of the C language and is thus the canonical textbook on that
topic.

The canonical textbook is the ISO C standard, sorry. The K&R1 was a based
document for C89. The second edition, K&R2, was not a base document.

And in the case of "The C Programming Language", which is the canonical text
on C, this would be clc. I'm not saying, UNIX topics should be broadly
discussed here, but basic questions and their explanation should be allowed

Chapter 8 of the K&R2 has an introduction which makes it perfectly clear that
an example implementation of the library is being presented, and that
that exact interface may not necessarily be found on the student's system, only
something similar to it.

The book does not suggest in any way that The Unix System Interface (or
even the tiny portion of it that is exposed) is part of C.

The chapter is useful because students learning C should be interested in
systems programming, not just calling blackbox functions. It's good to
``whitebox'' some functions for the student to answer the question of how
malloc might work, etc. The students who will become programmers are the
curious ones who want to know how malloc works, etc.

So although I don't disagree with a relaxed attitude toward the topic,
you are not making the right argument for that. What's included in the
book isn't necessarily C.

A better argument is that since Kernighan and Ritchie had a relaxed attitude
about presenting implementation stuff, maybe the C newsgroup ought to chill out
similarly. The inclusion of Chapter 8 does not spoil either edition of the
book, or detract from its value as a textbook on C.

here. Of course advanced stuff like file descriptor redirection, socket
programming and such belog into the proper NGs. But questions on open,
close, read, write (and maybe fork and exec) should be well accepted here.

Why maybe fork and exec? I don't see for and exec in the ``canonical
textbook'', and the inclusion or exclusion of material in that book is the
linchpin of your argument.

Why couldn't we also discuss Win32 CreateFile, CloseHandle, ReadFile and
WriteFile? The K&R2 Chapter 8 could easily be rewritten as ``The Windows System
Interface''. Showing how standard I/O functions can be implemented in Windows
would be equally educational.

 

[James Kuyper]

Kaz Kylheku wrote:
....

The canonical textbook is the ISO C standard, sorry. The K&R1 was a based
document for C89. The second edition, K&R2, was not a base document.

The ISO C standard is certainly canonical, but it is not a textbook, and
serves very poorly when used as one. K&R2 is not canonical, but it is a
textbook, and serves that purpose very well. The standard is a
reference work detailing the requirements specifications for
implementations of C and for programs that will be compiled by them.
It's written in standardese, a dialect of English that will be
unfamiliar to most C programmers.

 

[Wolfgang Draxinger]

K&R isn't THE standard text, thats been published by ISO.

Textbook != standard specification.

Textbook, that is what students use to learn something.

Wolfgang

 

[Wolfgang Draxinger]

You might want to bear in mind that K&R was originally written before
the Standard was agreed, and was last fully updated in 1990 or
thereabouts.

Would you regard a 20-year old map of Europe as canonical? Does your
school still teach the existence of East Germany, Yugoslavia and Soviet
communism?

You know what: I've got some 25 year old Shell Road Atlas of Europe lying in
my car's trunk. It still serves me well today, though it is has
it's "flaws" ;-) when traveling between West and East Germany (the roads
through the former border are all newer), but within that bounds it still
quite accurate.

Why do you think its bad, to send people to the best place to learn? Why
would you rather that they were potentially misinformed by less expert
people here?

Because I often see it here, that posts that contain a tiny little bit of OS
specifics are regarded Off Topic here, even if the question itself may well
be a C one like why does my code compile, but program crashes if reaching
$OS_SPECIFIC_FUNCTION. It's simply assumed, that the function is used
wrongly. But sometimes the error may lie in a wrong typecast, passing the
value of a pointer and not the pointer to the pointer or something similair
into a function that takes a void*. And a newbie might/probably does not
know the details of that. But it happened close to a non standard function,
it's like a red flag for some people which makes those blind for the actual
problem, which still might be a sole C problem. Especially if the API has
been designed around C and knowledge of it's structures is required to
understand it. I'm just waiting for a X-post from c.u.p referring here with
a sentence like "that's a C question. You can't call 'xyz' without knowing,
how C treats the types of it's parameters."

Wolfgang