block in open()

[freegnu]

hi all, it strange, when i use open() to open a FIFO to write, but i find when i use
open(Fifo,O_WRONLY | O_CREAT | O_TRUNC);
it will block

i really confused

 

[Nick Keighley]

hi all, it strange, when i use open() to open a FIFO to write, but i find when i use
open(Fifo,O_WRONLY | O_CREAT | O_TRUNC);
it will block

i really confused

write() is not defined by the C standard. You need to post on an
appriate news group. Perhaps one that discusses Unix.

 

[Jens Thoms Toerring]

hi all, it strange, when i use open() to open a FIFO to write, but i find when i use
open(Fifo,O_WRONLY | O_CREAT | O_TRUNC);
it will block

That's a question you should take to another newsgroup (I guess that
comp.unix.programmer might do) since neither the open() function nor
FIFOs are something that are defined by the C language (the topic of
this group) but are extensions e.g. defined by the POSIX standard,
thus a group dealing with POSIX is the one where you should ask.

<OffTopic>
First, O_TRUNC is useless when opening a FIFO and O_CREAT also, be-
cause you already need to have created it using mkfifo(). Second,
opening a FIFO always blocks until both sides have opened it (unless
you open it in non-blocking mode), see the man page for fifo(4) and
mkfifo(3), both pointing this out.
</OffTopic>
Regards, Jens

 

[CBFalconer]

Part 1.1 Type: Plain Text (text/plain)
Encoding: quoted-printable

Don't use html or mime types in Usenet.

 

[Jordan Abel]

Don't use html or mime types in Usenet.

It's entirely unclear to me why not. IIRC the only format restriction on
usenet is that binary (i.e. anything whose mime type would not begin
"text/") is not acceptable in non-binary groups. Wouldn't it make more
sense for text-based newsreaders to automatically display the text/plain
and ignore the text/html portion? And "don't use mime types" is a bit
of a strange way to put it - surely you meant "don't use multipart
messages" - i'm using a mime type right now, which you likely wouldn't
have noticed if i hadn't pointed it out (in case you're stumped, try
checking the headers)

Note: My newsreader did not handle it the way I suggested either. My
point is, rather, that maybe it should have.

 

[CBFalconer]

It's entirely unclear to me why not. IIRC the only format
restriction on usenet is that binary (i.e. anything whose mime
type would not begin "text/") is not acceptable in non-binary
groups. Wouldn't it make more sense for text-based newsreaders to
automatically display the text/plain and ignore the text/html
portion? And "don't use mime types" is a bit of a strange way to
put it - surely you meant "don't use multipart messages" - i'm
using a mime type right now, which you likely wouldn't have
noticed if i hadn't pointed it out (in case you're stumped, try
checking the headers)

The fundamental reason for banning html is that they can carry
infections to unwary systems, such as webbugs, or worse. Pure text
cannot.

 

[Jordan Abel]

The fundamental reason for banning html is that they can carry
infections to unwary systems, such as webbugs, or worse. Pure text
cannot.

OK, I guess you're right.

 

[Mark McIntyre]

It's entirely unclear to me why not.

because html is an executable file format, and many other mime types
are frequently used to deliver virus payload.

Plus usenet is inherently a text medium, and many newsreaders display
multipart mime messages rather oddly.

and ignore the text/html portion? And "don't use mime types" is a bit
of a strange way to put it - surely you meant "don't use multipart
messages"

I agree, even plain text is techically a mime type.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Walter Roberson]

2006-10-24 <[email protected]>,

It's entirely unclear to me why not. IIRC the only format restriction on
usenet is that binary (i.e. anything whose mime type would not begin
"text/") is not acceptable in non-binary groups.

You don't RC (Recall Correctly).

Except where specifically permitted by charter, newsgroups messages
shall not be encoded.

Wouldn't it make more
sense for text-based newsreaders to automatically display the text/plain
and ignore the text/html portion?

Newsreaders were designed around the NNTP standards and standard
Usenet usage, which in turn was -specifically- tailored towards maximizing
the opportunities to read the message, especially on high-cost links.
MIME did not exist when the major newsreaders were designed. Telling
people that they have to start using clunky new interfaces such as
IE is Not Acceptable.

You are presuming that HTML messages get posted in both formats.
A lot of the time they don't, and are only posted in HTML.

Permitting HTML is also an open invitation to use non-ASCII
characters (by &entity; or ), and big invitation
to include embedded images and embedded javascript and Active X
and so on -- after all, if people don't like it, all they have to
do is tell their newsreader to show them the plain text version, right?

And "don't use mime types" is a bit
of a strange way to put it - surely you meant "don't use multipart
messages" - i'm using a mime type right now, which you likely wouldn't
have noticed if i hadn't pointed it out (in case you're stumped, try
checking the headers)

MIME -- are you aware that the very name of it includes the word "Mail".
Not "Usenet" but "Mail".

As far as Usenet is concerned, a Content-type header is just another
non-standard header that should have been named starting with
X- to indicate an optional eXtension header (like X-Face), but which
is tolerated on sufferance under the principle of "It's best to just
ignore non-standard headers; they shouldn't be there, but if you
pretend it wasn't there then maybe the reader will be able to make
*some* sense out of the message." The key word there is "ignore":
as far as Usenet and NNTP are concerned, Content-type: is a noise
header and the body must stand on its own.


If you feel strongly that HTML should be permitted in comp.lang.c
then create an HTML-friendly comp.lang.c analog somewhere and see
whether you get much company.

If you feel strongly that HTML (and Content-Type) should be
recognized by NNTP and permitted in Usenet, then you could -try-
reviving the moribund "Usenet 2" project -- or you could just do
what a lot of other people have done and gone and migrated over to
web sites.


"Think of the starving children in Africa!" -- no, but seriously,
Usenet is still expensive in a lot of the world, and the mission of
Usenet has always been to reach as far as practical as cheaply as
practical, rather than to be a playground for what the rich kids
in the "First World" could afford.

 

[Richard Bos]

The fundamental reason for banning html is that they can carry
infections to unwary systems, such as webbugs, or worse. Pure text
cannot.

And it costs considerably more bandwidth than plain text (yes, I know,
binary groups cost more, but that's no reason to waste any for frippery
like HTML) - for the worst (and therefore most common...) generators
several times more; and it's bloody ugly, and if there is no plain text
part, damn near illegible.

Richard

 

[Jordan Abel]

because html is an executable file format,

No, it's not. What ever gave you the idea that it was? HTML is no more
an executable format than JPEG. (and, I chose the example of JPEG for
a specific reason - can you guess what it is?)

and many other mime types are frequently used to deliver virus payload.

That's hardly relevant to this discussion.

Plus usenet is inherently a text medium, and many newsreaders display
multipart mime messages rather oddly.

N years ago, many newsreaders displayed quoted-printable rather oddly.
Some still do.

 

[Jordan Abel]

You don't RC (Recall Correctly).

Except where specifically permitted by charter, newsgroups messages
shall not be encoded.

Text is text, binary is binary, and CLC has no charter on record. But,
that aside... Can you cite a source for that? Is ascii forbidden because
it's not specifically permitted? What about utf-8 or latin-1? Or, what
about... well, see below.

 

[Stephen Sprunk]

MIME -- are you aware that the very name of it includes the word
"Mail".
Not "Usenet" but "Mail".

Another case of an IETF standard that's spread rather successfully. Do
you think MIME types don't belong in HTTP since HTTP isn't "mail"?

Using MIME headers is pretty much unavoidable since you need them for
any non-ASCII content, and there's no reason to object to news posts in
UTF-8 or Latin-1 or anything else as long as they remain in text/plain
types.

The objection is to text/html or binary attachments, and I support that.
I have no objection to MIME itself.

As far as Usenet is concerned, a Content-type header is just another
non-standard header that should have been named starting with
X- to indicate an optional eXtension header (like X-Face), but which
is tolerated on sufferance under the principle of "It's best to just
ignore non-standard headers; they shouldn't be there, but if you
pretend it wasn't there then maybe the reader will be able to make
*some* sense out of the message." The key word there is "ignore":
as far as Usenet and NNTP are concerned, Content-type: is a noise
header and the body must stand on its own.

Correction: Any headers not standardized by the IETF, i.e. private
headers, are supposed to start with X-. The IETF only defines new
extensions _without_ the X-. The X is for eXperimental, not eXtension.

S

 

[Jordan Abel]

Correction: Any headers not standardized by the IETF, i.e. private
headers, are supposed to start with X-. The IETF only defines new
extensions _without_ the X-. The X is for eXperimental, not eXtension.

It might be worth mentioning that Content-Type is in fact standardized
by the IETF.

Quoted from USEFOR:

The MIME headers Content-Type and Content-Transfer-Encoding are often
used in news articles and have the identical meaning as that
specified in [RFC2045] with the added restrictions detailed in
Section 2.2.
Also:
User agents MUST meet the definition of MIME-conformance in
[RFC2049]. This level of MIME Conformance provides support for
internationalization and multimedia in message bodies [RFC2045], and
support for internationalization of headers [RFC2047]. Note that
[Errata] currently exist for [RFC2046] and [RFC2231].

There you have it. Content-type and Content-transfer-encoding are
officially acknowledged by a usenet standard. MIME is officially
acknowledged (and with a MUST, even) by the same usenet standard.

RFC 2049, on MIME conformance. A user agent (it says mail user agent,
but in context USEFOR is adapting this section to apply equally to
usenet user agents) that is MIME conformant MUST:

(6) Explicitly handle the following media type values, to
at least the following extents: [...]
Multipart:

-- Recognize the mixed subtype. Display all relevant
information on the message level and the body part
header level and then display or offer to display
each of the body parts individually.

-- Recognize the "alternative" subtype, and avoid
showing the user redundant parts of
multipart/alternative mail.

-- Recognize the "multipart/digest" subtype,
specifically using "message/rfc822" rather than
"text/plain" as the default media type for body parts
inside "multipart/digest" entities.

-- Treat any unrecognized subtypes as if they were
"mixed".

In other words, a usenet user agent MUST properly decode a multipart
message and display the appropriate part(s) (since this was an
"alternative" message, the appropriate part would be the text/plain part
for a user-agent that cannot handle text/html). This all started because
someone's user agent failed to do so, and he or she decided to blame
the sender instead of his or her own faulty newsreader.

MIME is part of usenet, and your insistence on living in the 70s does
not change that fact. I would argue that even _attachments_ (that is,
multipart/mixed) are legal in all newsgroups, as long as the attachments
themselves are text types. I think it would not be out of line for
someone to post a message with an attachment of type text/x-csrc or
text/x-chdr, for example.

 

[Walter Roberson]

Using MIME headers is pretty much unavoidable since you need them for
any non-ASCII content, and there's no reason to object to news posts in
UTF-8 or Latin-1 or anything else as long as they remain in text/plain
types.

RFC1036 (format of Usenet messages) requires RFC822 (mail format) as a
base; RFC 822 section 3.3 requires the characters to be ASCII.
RFC977 (NNTP) says,

2.2. Character Codes

Commands and replies are composed of characters from the ASCII
character set. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted
right justified in an octet with the high order bit cleared to zero.


When an article is retrieved, the body of an article is part of
the reply to a command, so the strict 7 bit ASCII requirement applies
to posting bodies and headers. If the article managed to make it
into the system in an 8 bit character set (such as Latin-1), then the
eighth bit -must- be cleared during article retrieval in accordance
with RFC977 2.2.

Thus, for non-ASCII content, text/plain is not sufficient: at the
very least you would need to add a Content-type heading.

 

[Walter Roberson]

It might be worth mentioning that Content-Type is in fact standardized
by the IETF.

Quoted from USEFOR:

All USEFOR documents, including the latest from September 16, 2006,
are *draft* documents, not yet IETF approved.

Which negates the rest of your post.

 

[Jordan Abel]

[encoded content by hand just to prove a point. message contains no
8-bit characters over the wire]

RFC1036 (format of Usenet messages) requires RFC822 (mail format) as a
base; RFC 822 section 3.3 requires the characters to be ASCII.

And they are. the =3D sign and all hex digits are ascii. By UTF-8 I meant =
UTF-8 over quoted-printable of course. You have to read the requirements =
in their proper context. =E2=98=BA

 

[CBFalconer]

.... snip ...

In other words, a usenet user agent MUST properly decode a
multipart message and display the appropriate part(s) (since this
was an "alternative" message, the appropriate part would be the
text/plain part for a user-agent that cannot handle text/html).
This all started because someone's user agent failed to do so,
and he or she decided to blame the sender instead of his or her
own faulty newsreader.

That is not the point. The point is that html is dangerours to
unwary systems and operators. This started not because my
newsreader cannot read html, but because I have taken the
precaution of forbidding it to do so, for security reasons, and I
advised the OP of the situation. HTML does not belong in news
groups, and I will not read HTML email either. Just because you
can step out your back door and urinate on the geraniums does not
mean that that is an advisable thing to do.

MIME is part of usenet, and your insistence on living in the 70s
does not change that fact. I would argue that even _attachments_
(that is, multipart/mixed) are legal in all newsgroups, as long
as the attachments themselves are text types. I think it would
not be out of line for someone to post a message with an
attachment of type text/x-csrc or text/x-chdr, for example.

Some newsgroups allow it. However the consensus here is no. In
addition the addition of attachments reduces the number of servers
carrying your article, inasmuch as the better servers will simply
delete any article carrying an attachment. This also means they
will not propagate it to further servers. Since you write the
article with the intent of having others read it (unless you are
only trying to annoy) attachments defeat your own purpose.

We are not simply being obstinate antediluvians. HTML works quite
well on the www (except when misused, which is often). It has its
place, which is not here.

 

[Walter Roberson]

MIME is part of usenet, and your insistence on living in the 70s does
not change that fact.

Jordan, do I make personal judgemental comments such as
"living in the 70s" about -you-?

When it comes to Usenet, let me ask you this:

Declare, if thou hast understanding.
Who hath laid the measures thereof, if thou knowest?
or who hath stretched the line upon it?
Whereupon are the foundations thereof fastened? or who laid
the corner stone thereof;

 

[Jordan Abel]

All USEFOR documents, including the latest from September 16, 2006,
are *draft* documents, not yet IETF approved.

Which negates the rest of your post.

And an RFC does not have the status of a standard. And guess how many
STDs apply to usenet? The answer: exactly zero. RFC822 is STD11, but
there aren't any usenet standards to reference it. No NNTP, no usenet
message standard, heck no mime when you get right down to it - as far as
standards are concerned, Usenet doesn't exist.

Now, USEFOR is quite good at _passing for_ a standard - newsreaders are
judged on it and USEAGE, posters are judged on USEAGE, etc. And there's
really nothing better.

And if we only used headers that are present in STD11... well, no
Newsgroups. no path, no xref.

USEFOR and its cousins are widely adhered to, quoted, and generally
accepted. Who gives a crap what the IETF approves - their last standard
(not counting STD1, which doesn't really count since it's just an index)
is dated 2000.

And, regardless, the fact that RFC 822 is the basis for all this means
that there are no headers that are valid for mail but invalid for
usenet, or vice versa.