Posting Usenet News Messages

[Camelback Jones]

Well, thanks to Paul Lalli, I can read - and print, file, etc - USENET
messages okay now.

Now I want to move on to posting USENET messages. And, of course, I'm doing
something stupid again. I think I've got a proper list of lines, and I
think I've got the lines formatted properly - at least, I don't see what's
wrong with the list.

Referring to O'Reilly's Pearl Cookbook, #18.4, i ahve slightly modified

$server->postok() or die "Not allowed to post";

# so we CAN post:

@lines=("From: Norbo Quantitator <aintg\@noemail.com>",
"Date: Fri, Feb 13 2004 15:14:13 CST",
"Newsgroups: alt.test",
"Subject: One More Test",
"Message-ID: <433498\@noemail.com>",
"Path: aintg",
" ",
"This is the body of this message.",
"There may be any number of body lines. Or not.",
" "
);

foreach $line (@lines) { print "$line\n";}


$server->post( [ @lines ] ) or die "Can't post: $!\n";

And it dies. "Can't post: " (no $! content).

Once again, I'm sure I'm doing something stupid, but it seems to me I'm
following the rules, and this code follows some in which we log onto a news
reader and select the "alt.test" newsgroup and read the last message... and
it =does= pass the postok() test... and the message format =looks= okay (as
far as I can tell... I've gone back and forth with and witout blank lines,
with and without newlines, and various versions of the required headers...).

 

[Tad McClellan]

I think I've got a proper list of lines, and I
think I've got the lines formatted properly - at least, I don't see what's
wrong with the list.

@lines=("From: Norbo Quantitator <aintg\@noemail.com>",

@lines=('From: Norbo Quantitator <[email protected]>',


I hate backslashes, they slow me down when reading the code.

"Date: Fri, Feb 13 2004 15:14:13 CST",

'Date: Fri, Feb 13 2004 15:14:13 CST',


I dislike being tricked into looking for variables being
interpolated when there are no variables being interpolated.

Consider using single quotes unless you are going to actually
make use of one of the two extra things that double quotes give
you, namely interpolation and backslash escapes.

"Newsgroups: alt.test",
"Subject: One More Test",
"Message-ID: <433498\@noemail.com>",
"Path: aintg",
" ",

^
^
^ you don't want that space character there.

"This is the body of this message.",
"There may be any number of body lines. Or not.",
" "
);

foreach $line (@lines) { print "$line\n";}

So what will be output? Here's part of it:

Path: aintg\n \nThis is the body of this message.\n
^^^^^

But you need "\n\n" to end the headers, and that sequence is not there.

So the claim "This is the body of this message." is a lie, it
is in the headers of the message.

 

[Camelback Jones]

@lines=('From: Norbo Quantitator <[email protected]>',


I hate backslashes, they slow me down when reading the code.




'Date: Fri, Feb 13 2004 15:14:13 CST',


I dislike being tricked into looking for variables being
interpolated when there are no variables being interpolated.

No one's "tricking" you, except possibly yourself.

Consider using single quotes unless you are going to actually
make use of one of the two extra things that double quotes give
you, namely interpolation and backslash escapes.

Given that the backslashes are there and (as far as I know) there's nothing
to interpolate, it won't make any difference, will it? With single quotes,
you don't get the escaped newline, either/

^
^
^ you don't want that space character there.

Why not? The spec calls for a blank line. What DO you want there?

So what will be output? Here's part of it:

Path: aintg\n \nThis is the body of this message.\n
^^^^^

But you need "\n\n" to end the headers, and that sequence is not there.

And with single quotes, it won't be there either, it'll just be the
characters "\n\n".


I've gone back and forth, with and without one or more "blank" lines, and,
as stated, with and without newlines as part of the line content. Doesn't
seem to have made a diff so far.

So the claim "This is the body of this message." is a lie, it
is in the headers of the message.

No, it's not a lie. It may be incorrect, but it's not a lie - you need to
be able to distinguish those conditions.


If I'm interpreting your comments, should this work?

@lines = ('From: Norbo Quantitator <[email protected]>',
'Date: Fri, Feb 13 2004 15:14:13 CST',
'Newsgroups: alt.test',
'Subject: One More Test',
'Message-ID: <[email protected]>',
'Path: aintg',
'',
'',
'This is the body of this message.',
'There may be any number of body lines. Or not.',
''
);

It doesn't - perhaps you have an example that does?

 

[Tad McClellan]

Why not?

Because then you will make the 3-char sequence "\n \n" when
you are supposed to be making the 2-char sequence "\n\n".

The spec calls for a blank line. What DO you want there?

A blank line.

A line with a space character on it is not blank,
it has a space character on it.

No, it's not a lie.

Didn't you see the smiley?

Do you know what a smiley means?

If I'm interpreting your comments, should this work?

Yes.


@lines = ('From: Norbo Quantitator <[email protected]>',
'Date: Fri, Feb 13 2004 15:14:13 CST',
'Newsgroups: alt.test',
'Subject: One More Test',
'Message-ID: <[email protected]>',
'Path: aintg',
'',
'',
'This is the body of this message.',
'There may be any number of body lines. Or not.',
''
);

It doesn't

I can't help then. Sorry.

 

[Toby]

Camelback Jones wrote:

OK, perl learner here ...

$server->post( [ @lines ] ) or die "Can't post: $!\n";

Isn't that going to pass an anonymous array to post() with @lines
in [0] ?

And it dies. "Can't post: " (no $! content).

I've heard (on clpm) that you you shouldn't use \n after $! as it
supresses messages (or something like that). YMMV

Cheers
Toby

 

[Camelback Jones]

Because then you will make the 3-char sequence "\n \n" when
you are supposed to be making the 2-char sequence "\n\n".




A blank line.

A line with a space character on it is not blank,
it has a space character on it.

This depends on how the NNTP server interprets it. Many pieces of software
do in fact interpret a line as "blank" if there are no "printable"
characters on it, and an ascii 32 is not considered "printable". I don't
know whether NNTP considers it to be a "blank" line if it has one or more
spaces, but I do know that at least this particular part of it - so far -
hasn't seemed to make the slightest difference whether it's accepted for
posting or not.

Didn't you see the smiley?

Do you know what a smiley means?

Sure, but it's a bit (or maybe several bits) on the disingenuous side to
argue that a line with a ascii character 32 on it is not "blank" on the one
hand and then fail to discriminate between "lie" and "incorrect", on the
other, no?

I can't help then. Sorry.

I'll take that as a "no".

Thank you for trying, anyway. I'll let you know when I do get this working,
and then you'll know, too.

 

[Camelback Jones]

Camelback Jones wrote:

OK, perl learner here ...

$server->post( [ @lines ] ) or die "Can't post: $!\n";

Isn't that going to pass an anonymous array to post() with @lines
in [0] ?

Good question - that's directly from the example I quoted. The problem with
this particular "example" is that there's no definition in it of what
@lines is supposed to contain... hmmmm...

However, I've tried it with and without the brackets, and it hasn't changed
the result.

I've heard (on clpm) that you you shouldn't use \n after $! as it
supresses messages (or something like that). YMMV

I tried it without the newline (which I had added, since I had put in
several alternative sets of data for @lines), and it showed the program
name and line number, which I already knew...

Cheers
Toby

Hey, thanks for taking a shot at it!

 

[Camelback Jones]

Tad told you this in the process of kindly giving you a few pointers
on other potential problems with your code.

Definitely, there are some pointers, I agree. "Kindly" is an assumption
that may or may not be valid: neither you nor I know his motive(s) and
"kindness" may or may not play a part. I certainly appreciate his attempts,
whatever his motives may be, at any rate. However, the fact remains that -
as helpful as they may be - they haven't resulted in the code functioning,
and I merely report that fact; I can't see any reason for you to take
exception to my statement.

Consider: "Text\n\n"

Note the construction: text and a newline, then another newline.
The second newline *is* a blank line since nothing preceeds the
newline on that line...and nothing can come after it, obviously.

---------------

Consider: "Text\n \n"

Note the constructon: text and a newline, a space and a newline.
The first line holds text, the second line holds a space.
I don't see any blank lines there, do you?

That depends on what you mean by "blank", and on what perl interprets as
"blank".

I understand that what you are trying to say here is that a "blank" line is
one that consists of nothing but a single ascii character 10 - which is not
necessarily the case for every language and every piece of software.

For all I know, NNTP is perfectly happy to consider a line as "blank" if
there's nothing on it but spaces - I've tried it both ways, and it hasn't
made any difference so far, and I therefore have no basis on which to
conclude whether there is or is not an issue there - certainly it is not
"the" issue.

However, that's not the point I was making there, which was: "lie" and
"incorrect" are not the same thing. What I said was not a "lie", it was -
in terms of what NNTP apparently wants - "incorrect".

Take a look at the documentation (pod) for NET::NNTP and see what
it says.

No such documentation exists, for the simple reason that there is no such
piece of code as NET::NNTP. No, wait! I see... it's a lie! You really meant
Net::NNTP, didn't you?


Really, though, I did look at both pod and man for Net::NNTP. I didn't see
much, if any, difference between them. Is there something specific in the
pod thant's not in the man pages? What is it you think I'm missing?

I do appreciate your trying to help, although, to be frank, RTFM is not
really terribly helpful, since I am RTFM, and it (whatever "it" is) is not
jumping off the page at me.

Here, for what it's worth, is the current version of the code, which, with
or without the newlines (one to terminate headers and one or more at start
and end the message body) and with or without the square brackets, gives
"Can't post". I can pop over to knode and post manually, and the top part
of the particular program does successfully log onto the server and
download headers, download the last message, and print it before proceeding
on to this last bit:

$server->postok() or die "Server said no posting allowed.\n";

print "Apparently we CAN post to $name\n";

@lines = ("From: Norbo Quantitator <[email protected]>\n",
"Date: Fri, Feb 13 2004 15:14:13 CST\n",
"Newsgroups: alt.test\n",
"Subject: \"There is no subject\"\n",
"Message-ID: <$randid\@noemail.com>\n",
"Path: aintg\n",
"\n",
"\n",
"This is the body of this message.\n",
"There may be any number of body lines. Or not.\n",
"\n"
);
$server->post( [ @lines ] ) or die "Can't post: $!\n";


Tad didn't seem to have a working example of what I was trying to do - do
you? Or can you see something wrong with either the construction or the
approach?

 

[Ben Morrow]

Camelback Jones wrote:

OK, perl learner here ...

$server->post( [ @lines ] ) or die "Can't post: $!\n";

Isn't that going to pass an anonymous array to post() with @lines
in [0] ?

No... the elements of an array (anon or not) are scalars, and scalars
cannot hold arrays. Say @lines contained (1, 2, 3). The construction
[ @lines ]
first evaluates @lines in list context, when it returns a list of its
elements:
[ (1, 2, 3) ]
.. Then it creates an anonymous array from that list, which will thus
contain a copy of the elements of @list.

I've heard (on clpm) that you you shouldn't use \n after $! as it
supresses messages (or something like that). YMMV

It's nothing to do with $!, rather to do with warn and die. If you put
"\n" on the end, it will suppress the line-number and file information,
which is usually essential to debugging any problem.

Ben

 

[gnari]

Steve May wrote:


That depends on what you mean by "blank", and on what perl interprets as
"blank".

actually it depends mostly on what NNTP considers blank, and I can tell
you for sure that NNTP does not consider a line with space to be empty.

However, that's not the point I was making there, which was: "lie" and
"incorrect" are not the same thing. What I said was not a "lie", it was -
in terms of what NNTP apparently wants - "incorrect".

look back at the original context:

a) the statement was followed by a smilie
b) the joke was that the text 'This is the body of this message'
ended up in the headers because of the extra space. so it
was a counterfactual selfreferencial sentence. in other words, a lie
of the most entertaining sort. thus the smilie

gnari

 

[Ben Morrow]

That depends on what you mean by "blank", and on what perl interprets as
"blank".

....and what NNTP interprets as blank.

I understand that what you are trying to say here is that a "blank" line is
one that consists of nothing but a single ascii character 10 - which is not
necessarily the case for every language and every piece of software.

As a general rule, Unix software (and descendants, such as perl)
consider a line blank iff it has nothing on it.

For all I know, NNTP is perfectly happy to consider a line as "blank" if
there's nothing on it but spaces

Well, you don't know much then, do you? Try reading the relevant RFC
before writing a newsreader: NNTP considers a blank line to be exactly

"\015\012\015\012"

, ie. ASCII CR LF CR LF.

However, that's not the point I was making there, which was: "lie" and
"incorrect" are not the same thing. What I said was not a "lie", it was -
in terms of what NNTP apparently wants - "incorrect".

Oh, FFS, get a life. The only thing that matters is whether what you
said was correct or not: getting on your high horse about the fact that
you didn't mean it to be false helps noone.

Really, though, I did look at both pod and man for Net::NNTP. I didn't see
much, if any, difference between them. Is there something specific in the
pod thant's not in the man pages? What is it you think I'm missing?

There is no difference.

Ben

 

[gnari]

This depends on how the NNTP server interprets it. Many pieces of software
do in fact interpret a line as "blank" if there are no "printable"
characters on it, and an ascii 32 is not considered "printable". I don't
know whether NNTP considers it to be a "blank" line if it has one or more
spaces, but I do know that at least this particular part of it - so far -
hasn't seemed to make the slightest difference whether it's accepted for
posting or not.

listen, you have an attitude problem. Tad is trying to help you. he is
pointing
out that you should not have a space at that position, and you start
nitpicking
about it, without any knowledge, when Tad most definitively has.

the fact that his help was not enough for you to make your program work
is not good reason to slap him.

Thank you for trying, anyway. I'll let you know when I do get this working,
and then you'll know, too.

we wait in anticipation

gnari

 

[Ron Parker]

This depends on how the NNTP server interprets it. Many pieces of software
do in fact interpret a line as "blank" if there are no "printable"
characters on it, and an ascii 32 is not considered "printable".

[ron@mail ron]$ cat >foodle.c
int main() {printf("%s", isprint(' ')?"printable":"not printable");}
[ron@mail ron]$ gcc foodle.c -o foodle
[ron@mail ron]$ ./foodle
printable

That said, I think your real problem might be that Net::NNTP 'post' is
morally equivalent to Net::Cmd 'datasend' and neither of them makes any
assumptions about where you wanted newlines. That is, just calling your
array 'lines' doesn't make it actual lines; you should put a newline at
the end of each line.

As evidence, here's a couple of lines from the top of Net::Cmd:

my $arr = @_ == 1 && ref($_[0]) ? $_[0] : \@_;
my $line = join("" ,@$arr);

The first line sets $arr equal to a reference to the array you passed,
whether or not what you passed was a reference. The next line joins the
whole array into one long scalar. Note the lack of newlines in the first
parameter to join.

So, to make the smallest possible change to your program, try replacing
the not-really-blank lines with an empty string, and then replacing
[@lines] with [join("\n", @lines)] in your call to nntp->post.

Alternatively, you can just put the necessary newlines at the end of every
element in @lines.

 

[Ben Morrow]

On Wed, 18 Feb 2004 11:00:54 -0600, Camelback Jones wrote:

That said, I think your real problem might be that Net::NNTP 'post' is
morally equivalent to Net::Cmd 'datasend' and neither of them makes any
assumptions about where you wanted newlines. That is, just calling your
array 'lines' doesn't make it actual lines; you should put a newline at
the end of each line.

Almost certainly a CRLF pair.

So, to make the smallest possible change to your program, try replacing
the not-really-blank lines with an empty string, and then replacing
[@lines] with [join("\n", @lines)] in your call to nntp->post.

or simply
join "\015\012", @lines;

Ben

 

[Ron Parker]

Almost certainly a CRLF pair.

That'll work, but note that datasend changes bare newlines to CRLF.

So, to make the smallest possible change to your program, try replacing
the not-really-blank lines with an empty string, and then replacing
[@lines] with [join("\n", @lines)] in your call to nntp->post.

or simply
join "\015\012", @lines;

I'm partial to \r and \n myself, not being overly fond of octal. TMTOWTDI,
of course. And you're right about not needing the reference; I don't know
what came over me.

 

[Camelback Jones]

...and what NNTP interprets as blank.

.... Oh, actually it's probably a lot MORE important what NNTP thinks, as I
tried to indicate a few lines after that, which you snipped.

As a general rule, Unix software (and descendants, such as Perl)
consider a line blank iff it has nothing on it.

Okay, as a GENERAL rule.

Well, you don't know much then, do you?

Well, let's see... no, that's not true: actually I know plenty. I happen to
not know a lot about Perl and *n*x; certainly not enough, at any rate. But
I'm trying to learn.

How about you? Quick, without looking 'em up, what's the average weight of
an adult bald eagle, who used "graxaflexaflugula" as a spelling bee word,
and who originated the worlds' most widely known equation, e = m c^2?

Try reading the relevant RFC

I read 1036 and 822. I've no doubt I missed plenty in those. If neither of
those is the relevant one, what is?

before writing a newsreader:

Ahhhh, no, that would be "newsposter", not "newsreader". Reading works,
this is about "posting" - see the subject?

NNTP considers a blank line to be exactly

"\015\012\015\012"

, ie. ASCII CR LF CR LF.

I'm gruntled to know that. If you'll tell me where this is documented, I'd
love to read it and see what other nuggets are to be found. This seems to
be a difference from the general rule that LF's end a line and CR's cause
problems.

Oh, FFS, get a life.

Gander sauce, bucko. I appreciate the help, but I can do without the petty
insults.

The only thing that matters is whether what you
said was correct or not: getting on your high horse about the fact that
you didn't mean it to be false helps noone.

It's not about being on a high horse, old son, it's about the difference
between "lie" and "mistake". I don't have any problem at all saying "I
don't know" and "I screwed up" - but I have a big problem with any
intimation of untruthfulness, smiley or no smiley. If you don't understand
that, that says something about you, not about me. Now, as far as I'm
concerned, that part is over, but if you want to keep harping on it, you'll
get a response. 'Nuff said.

There is no difference.

That's what I thought, too... by golly, that might not be much, but at
least it shows I know =something=, huh?


So, how about it - do YOU have a working example of what I'm trying to do?
I could sure enough use the help, and telling me I don't know much isn't
telling me anything I don't already know.

Thanks, again.

 

[Camelback Jones]

This depends on how the NNTP server interprets it. Many pieces of
software do in fact interpret a line as "blank" if there are no
"printable" characters on it, and an ascii 32 is not considered
"printable".

[ron@mail ron]$ cat >foodle.c
int main() {printf("%s", isprint(' ')?"printable":"not printable");}
[ron@mail ron]$ gcc foodle.c -o foodle
[ron@mail ron]$ ./foodle
printable

Sez C. Presumably isprint() returns a true for any character thing over 31,
or perhaps just the non-control characters of the 7-bit set... Or 32-255?
Is a DEL printable? Does your printer actually have a space character on it
(or in it) or does it just index the print "head" and skip a little bit?
Can a space really be "printed"? If you have three sheets of paper and one
of them was "printed" by sending a page eject, the second was printed by
sending 60 (or 66) line feeds, and the third by sending five or six
thousand spaces, can you tell which is which?

Bottom line: the only meaningful test is "what does THIS piece of software
want"?

That said, I think your real problem might be that Net::NNTP 'post' is
morally equivalent to Net::Cmd 'datasend' and neither of them makes any
assumptions about where you wanted newlines. That is, just calling your
array 'lines' doesn't make it actual lines; you should put a newline at
the end of each line.

As evidence, here's a couple of lines from the top of Net::Cmd:

my $arr = @_ == 1 && ref($_[0]) ? $_[0] : \@_;
my $line = join("" ,@$arr);

The first line sets $arr equal to a reference to the array you passed,
whether or not what you passed was a reference. The next line joins the
whole array into one long scalar. Note the lack of newlines in the first
parameter to join.

So, to make the smallest possible change to your program, try replacing
the not-really-blank lines with an empty string, and then replacing
[@lines] with [join("\n", @lines)] in your call to nntp->post.

Alternatively, you can just put the necessary newlines at the end of every
element in @lines.

As I thought I'd said, I've been back and forth with newlines (as well as
with spaces and no spaces on the "blank" line(s)), and it didn't work
either way. Someone else has indicated that NNTP specifically demands a
CR/LF pair as a "blank" line, so I've tried combinations of LF and CR/LF to
end each line of @lines with LF and CR/LF as the "blank" line(s).

Here's the current version:

#!/usr/bin/perl
use Net::NNTP;
$service="enews.newsguy.com"; $user="bolivar"; $password="124c41";
srand(time);
$server = Net::NNTP->new($service)
or die "Can't connect to news server $service\n";
$thegroup="alt.test";
$something = $server->authinfo($user,$password);
($narticles, $first, $last, $name) = $server->group( $thegroup )
or die "Can't select $thegroup\n";
$randid = int(rand(999999));
$server->postok() or die "Server didn't tell me I could post.\n";
print "Apparently we're ALLOWED to post to $name\n";
$crlf = "\015\012"; # try various versions of cr/lf
$eol = "\012"; # and eol
@lines = ("From: Norbo Quantitator <aintg\@noemail.com>$eol",
"Date: Fri, Feb 13 2004 15:14:13 PST$eol",
"Newsgroups: $thegroup$eol",
"Subject: \"There is no subject\"$eol",
"Message-ID: <$randid\@noemail.com>$eol",
"Path: aintg$eol",
"$crlf",
"$crlf",
"This might be the body of this message.$crlf",
"Say, who DOES shave the barber, anyway???$eol",
"There may be any number of body lines. Or not.$crlf",
"$crlf"
);
if ($server->post( [ @lines ] ))
{print "Might've posted THIS time... check $thegroup";}
else
{warn "Can't post: $!";}
open HANDLE, ">np.txt";
print HANDLE @lines;
close HANDLE;

I think I've tried all the permutations for $crlf and $eol, and still no
luck, but maybe I've missed some...

The output file (np.txt) looks reasonable, in that there ARE lf's after
each line and cr/lf's where indicated (for this particular version) - and
yes, the mixture in the body of eol's and crlf's is intentional, although
I've tried both ways.

I've also tried typing the header and body from RFC 1036 into files and
using datasend() to send those lines and a couple of cr/lf's between. There
doesn't seem to be any response other that "1" from datasend(), though, so
we just have to wait a bit and see if the message shows up... which it
hasn't yet.

If you've got a working example, or have any idea where I can find one, I'd
love to see it. I've been googling the snot out of various search strings
and haven't found anything workable yet... but I'll get there, one of these
days!

Thanks for the ideas!

 

[Camelback Jones]

actually it depends mostly on what NNTP considers blank, and I can tell
you for sure that NNTP does not consider a line with space to be empty.

Okaaaay... that's two for two on managing to miss the reference a few lines
down to how NNTP interprets it, as well as the more specific statement in
another message in the same thread. In any event, the specific response was
to his question "I don't see any blank lines =here=, do you?"

look back at the original context:

a) the statement was followed by a smilie
b) the joke was that the text 'This is the body of this message'
ended up in the headers because of the extra space. so it
was a counterfactual selfreferencial sentence. in other words, a lie
of the most entertaining sort. thus the smilie

gnari

Yes, and no. Whether the self-reference is - or was - contrafactual is
conditional upon circumstances outside of itself; that is, if the header of
the message were formatted properly, then it would be factual, but it has
no control over that.

The truly funny thing is that in the original version of the code, it was
"This is not the body", along the lines of Magritte's famous "Ceci n'est
pas une pipe".

Thanks for the response.

 

[Ben Morrow]

That'll work, but note that datasend changes bare newlines to CRLF.

Ah right, DWIM... didn't know that. (yes, I (c|sh)ould have read the docs).

I'm partial to \r and \n myself, not being overly fond of octal. TMTOWTDI,
of course.

....but, in this case, one is portable and the other isn't. Macs consider
\r to be \n and v.v. (as it were).

Ben

 

[Ben Morrow]

I read 1036 and 822. I've no doubt I missed plenty in those. If neither of
those is the relevant one, what is?

They'll do... 822 is obsoleted by 2822, but that doesn't matter for
these purposes.

I'm gruntled to know that. If you'll tell me where this is documented, I'd
love to read it and see what other nuggets are to be found. This seems to
be a difference from the general rule that LF's end a line and CR's cause
problems.

RFC822, section 3.2:

field = field-name ":" [ field-body ] CRLF

section 4.1:

message = fields *( CRLF *text )

As another general rule, Internet protocols (including
Usenet-over-Internet , use CRLF as the end-of-line sequence and
big-endian number representations.

So, how about it - do YOU have a working example of what I'm trying to do?
I could sure enough use the help, and telling me I don't know much isn't
telling me anything I don't already know.

No I don't, sorry. As someone else said, you perhaps need to put the
newlines on the end of you lines before passing them to post.

Ben