Hi All,

I'm running into a problem with a pretty old freeware perl script called
"readnews" it is in an archive named "readnews-1.85.tar.gz" that is
available here:

http://web.archive.org/web/20080616183736/http://www.scn.org /~bb615/scripts/readnews-1.85.tar.gz

I used these plus inn to create a private bulletin board setup. The
system works perfectly under FreeBSD 6.4 running perl 5.8.8, and appears
to work under Ubuntu running perl 5.10.1 but fails immediately under
FreeBSD 8.1 running perl 5.10.1

The problem is in this fragment of listgroups.pl:

..
..
..

sub ConnectToNewsServer
{
# get news host name
($name, $aliases, $proto) = getprotobyname ('tcp');
if ($port !~ /^\d+$/)
{
($name, $aliases, $port) = getservbyname ($port, 'tcp');
}
if ($newshost =~ /(\d+)\.(\d+)\.(\d+)\.(\d+)/)
{
$thataddr = pack ('C4', $1, $2, $3, $4);
}
else
{
if ($newshost =~ /(\w+)(\.\w+)*/)
{
($name, $aliases, $type, $len, $thataddr) = gethostbyname
($newshost);
}
else
{
print "Error: NNTP host not specified in proper format\n";
exit 1;
}
}

# get socket
$this = pack ($sockaddr, $AF_INET, 0, $thisaddr);
$that = pack ($sockaddr, $AF_INET, $port, $thataddr);
if (!socket (S, $AF_INET, $SOCK_STREAM, $proto))
{
print "Error: socket failed $1\n";
exit 1;
}

# bind to socket
if (!bind (S, $this))
{
print "Error: bind to $this failed $1\n";
exit 1;
}

# connect to socket
if (!connect (S, $that))
{
print "Can't connect to $newshost tcp/ip port $port. Error: $1\n";
exit 1;
}

# buffer the socket
select (S);
$| = 1;
select (STDOUT);

# read server status
$_ = <S>;
($status, $rest) = split (/ /, $_, 2);
if ($status == 200 || $status == 201)
{
# 200 server ready - posting allowed
# 201 server ready - no posting allowed
}
else
{
print "$newshost refused connection: status $status - $rest\n";
exit 0;
}
}


Everytime I run it I get the immediate error

"Can't connect to XXXX tcp/ip port 119. Error: "

(I removed the name of the actual server system)

I've tried this on several FreeBSD systems and get the same problem
on all of them.

If it was a firewall thing I would expect the code to hang
then fail, but this just exits immediately, like it can't
create the socket.

I know the code is a decade old and probably isn't the
recommended way of doing things nowadays but we want to
upgrade the server and this is what is keeping me from
doing it, and I don't want to really tear into the thing
and use something else.

Any suggestions?

Thanks,
Ted

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

At 6:16 PM -0800 2/23/11, Ted Mittelstaedt wrote:
>Hi All,
>
>I'm running into a problem with a pretty old freeware perl script called
>"readnews" it is in an archive named "readnews-1.85.tar.gz" that is
>available here:
>
>http://web.archive.org/web/20080616183736/http://www.scn.or g/~bb615/scripts/readnews-1.85.tar.gz


[program fragment snipped]

>Everytime I run it I get the immediate error
>
>"Can't connect to XXXX tcp/ip port 119. Error: "
>
>(I removed the name of the actual server system)

Can you connect via telnet?

telnet XXXX 119

Can you ping the server?

ping XXXX

Those will tell you if it is a connectivity problem.

>I've tried this on several FreeBSD systems and get the same problem
>on all of them.
>
>If it was a firewall thing I would expect the code to hang
>then fail, but this just exits immediately, like it can't
>create the socket.

It can create the socket, but the socket cannot connect to the server socket.

>I know the code is a decade old and probably isn't the
>recommended way of doing things nowadays but we want to
>upgrade the server and this is what is keeping me from
>doing it, and I don't want to really tear into the thing
>and use something else.
>
>Any suggestions?

Well I know that it is not what you want to hear, but it is probably
time to rewrite the program using a module that has already been
written and done all of the hard work for you. See the Net::NNTP
module on CPAN or search <http://search.cpan.org> for NNTP for
alternatives.

--
Jim Gibson
Jim [at] Gibson.org

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2/23/2011 7:18 PM, Jim Gibson wrote:
> At 6:16 PM -0800 2/23/11, Ted Mittelstaedt wrote:
>> Hi All,
>>
>> I'm running into a problem with a pretty old freeware perl script called
>> "readnews" it is in an archive named "readnews-1.85.tar.gz" that is
>> available here:
>>
>> http://web.archive.org/web/20080616183736/http://www.scn.org /~bb615/scripts/readnews-1.85.tar.gz
>>
>
>
> [program fragment snipped]
>
>> Everytime I run it I get the immediate error
>>
>> "Can't connect to XXXX tcp/ip port 119. Error: "
>>
>> (I removed the name of the actual server system)
>
> Can you connect via telnet?
>
> telnet XXXX 119
>
> Can you ping the server?
>
> ping XXXX
>
> Those will tell you if it is a connectivity problem.
>

Yes, I can, that works just fine.

>> I've tried this on several FreeBSD systems and get the same problem
>> on all of them.
>>
>> If it was a firewall thing I would expect the code to hang
>> then fail, but this just exits immediately, like it can't
>> create the socket.
>
> It can create the socket, but the socket cannot connect to the server
> socket.
>
>> I know the code is a decade old and probably isn't the
>> recommended way of doing things nowadays but we want to
>> upgrade the server and this is what is keeping me from
>> doing it, and I don't want to really tear into the thing
>> and use something else.
>>
>> Any suggestions?
>
> Well I know that it is not what you want to hear, but it is probably
> time to rewrite the program using a module that has already been written
> and done all of the hard work for you. See the Net::NNTP module on CPAN
> or search <http://search.cpan.org> for NNTP for alternatives.
>

Think of this as a chance to educate. If you were teaching a math
class in elementary school and a child asked how to add 2 + 2 would
you tell them to get a calculator? The NNTP protocol is very simple and
this only uses a few of it's commands.

The code works on older FreeBSD, and on a modern Ubuntu system running
the same version of Perl as on the newer FreeBSD. I have to thus
assume the problem isn't the code, the problem is something inherent
in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.

Ted

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Ted Mittelstaedt wrote:
>
> Think of this as a chance to educate. If you were teaching a math
> class in elementary school and a child asked how to add 2 + 2 would
> you tell them to get a calculator? The NNTP protocol is very simple and
> this only uses a few of it's commands.
>
> The code works on older FreeBSD, and on a modern Ubuntu system running
> the same version of Perl as on the newer FreeBSD. I have to thus
> assume the problem isn't the code, the problem is something inherent
> in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.

That all depends on how you define "works"? The program 'readmsg' has
some serious problems with incorrect regular expressions. And if you
compile the programs with warnings enabled you will get a few messages.



John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

OK since nobody helped me (sniff, sniff) I had to figure it out myself.

Here is the problem code in the fragment:

$sockaddr = 'S n a4 x8';

replacing it with

$sockaddr = 'x C n a4 x8';

fixed the problem. The template for the pack command was wrong.

Th first two bytes are length (0) and family, both of which are unsigned
char, so 'x C' (or 'n') handles those.

I got this from a similar socket problem posting dug out of
a mailing list posting from 2003.

Perhaps a better way to fix this would be to rewrite it to
do something like:

use Socket;

$that = sockaddr_in($port,inet_aton($newshost));

($newshost is the FQDN of the new host, $thataddr is the IP# of the news
host)

but as I said before, I don't want to rewrite everything.

Ted

On 2/23/2011 8:24 PM, Ted Mittelstaedt wrote:
> On 2/23/2011 7:18 PM, Jim Gibson wrote:
>> At 6:16 PM -0800 2/23/11, Ted Mittelstaedt wrote:
>>> Hi All,
>>>
>>> I'm running into a problem with a pretty old freeware perl script called
>>> "readnews" it is in an archive named "readnews-1.85.tar.gz" that is
>>> available here:
>>>
>>> http://web.archive.org/web/20080616183736/http://www.scn.org /~bb615/scripts/readnews-1.85.tar.gz
>>>
>>>
>>
>>
>> [program fragment snipped]
>>
>>> Everytime I run it I get the immediate error
>>>
>>> "Can't connect to XXXX tcp/ip port 119. Error: "
>>>
>>> (I removed the name of the actual server system)
>>
>> Can you connect via telnet?
>>
>> telnet XXXX 119
>>
>> Can you ping the server?
>>
>> ping XXXX
>>
>> Those will tell you if it is a connectivity problem.
>>
>
> Yes, I can, that works just fine.
>
>>> I've tried this on several FreeBSD systems and get the same problem
>>> on all of them.
>>>
>>> If it was a firewall thing I would expect the code to hang
>>> then fail, but this just exits immediately, like it can't
>>> create the socket.
>>
>> It can create the socket, but the socket cannot connect to the server
>> socket.
>>
>>> I know the code is a decade old and probably isn't the
>>> recommended way of doing things nowadays but we want to
>>> upgrade the server and this is what is keeping me from
>>> doing it, and I don't want to really tear into the thing
>>> and use something else.
>>>
>>> Any suggestions?
>>
>> Well I know that it is not what you want to hear, but it is probably
>> time to rewrite the program using a module that has already been written
>> and done all of the hard work for you. See the Net::NNTP module on CPAN
>> or search <http://search.cpan.org> for NNTP for alternatives.
>>
>
> Think of this as a chance to educate. If you were teaching a math
> class in elementary school and a child asked how to add 2 + 2 would
> you tell them to get a calculator? The NNTP protocol is very simple and
> this only uses a few of it's commands.
>
> The code works on older FreeBSD, and on a modern Ubuntu system running
> the same version of Perl as on the newer FreeBSD. I have to thus
> assume the problem isn't the code, the problem is something inherent
> in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.
>
> Ted
>


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "TM" == Ted Mittelstaedt <tedm [at] mittelstaedt.us> writes:



TM> $sockaddr = 'x C n a4 x8';
TM> Th first two bytes are length (0) and family, both of which are
TM> unsigned char, so 'x C' (or 'n') handles those.

TM> use Socket;

TM> $that = sockaddr_in($port,inet_aton($newshost));

TM> ($newshost is the FQDN of the new host, $thataddr is the IP# of the
TM> news host)

TM> but as I said before, I don't want to rewrite everything.

jeez.

use IO::Socket ;

my $sock = IO::Socket->new( "$host:$port" ) ;

done.

use a module for at least that. dealing with pack templates for socket
addresses is insane and never needed anymore.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2/23/2011 11:32 PM, John W. Krahn wrote:
> Ted Mittelstaedt wrote:
>>
>> Think of this as a chance to educate. If you were teaching a math
>> class in elementary school and a child asked how to add 2 + 2 would
>> you tell them to get a calculator? The NNTP protocol is very simple and
>> this only uses a few of it's commands.
>>
>> The code works on older FreeBSD, and on a modern Ubuntu system running
>> the same version of Perl as on the newer FreeBSD. I have to thus
>> assume the problem isn't the code, the problem is something inherent
>> in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.
>
> That all depends on how you define "works"?

Displays the posts (articles) on a web interface.

> The program 'readmsg' has
> some serious problems with incorrect regular expressions.

I'm sure it does. Cheap hacks have always characterized Usenet.

> And if you
> compile the programs with warnings enabled you will get a few messages.
>

Well, unfortunately there is a huge lack of web-to-Usenet interfaces out
there that are open source (ie: free) Most folks that are content with
a Usenet webinterface can get their web access from Google Groups. So
there is little incentive for many ISP's to field a web-to-news
interface and far less than that for anyone to write one.

The readnews interface is one of the few out there and although it is
probably classed as "antique" software, it still works fine.

Ted

>
>
> John


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2/24/2011 12:42 AM, Uri Guttman wrote:
>>>>>> "TM" == Ted Mittelstaedt<tedm [at] mittelstaedt.us> writes:
>
>
>
> TM> $sockaddr = 'x C n a4 x8';
> TM> Th first two bytes are length (0) and family, both of which are
> TM> unsigned char, so 'x C' (or 'n') handles those.
>
> TM> use Socket;
>
> TM> $that = sockaddr_in($port,inet_aton($newshost));
>
> TM> ($newshost is the FQDN of the new host, $thataddr is the IP# of the
> TM> news host)
>
> TM> but as I said before, I don't want to rewrite everything.
>
> jeez.
>
> use IO::Socket ;
>
> my $sock = IO::Socket->new( "$host:$port" ) ;
>
> done.
>
> use a module for at least that. dealing with pack templates for socket
> addresses is insane and never needed anymore.
>

Uri, I am perfectly aware of what constitutes modern programming
practice. And the fact of the matter is that your very wrong, because
if I was going to rewrite this code the correct way would be to use one
of the NNTP Perl modules (NNTP Client for example) The listgroups
script could probably be replaced by something along the lines of

use News::NNTPClient;

$nntp = new News::NNTPClient("xxx.xxx.xxx","",2);

outer loop
get a listgroup list
iterate through it

inner loop
get an article list from the current group
iterate through it and write the stuff out
end inner loop

end outer loop


But I will point out that perl modules are built in a pyramid, you
have ones like NNTPClient that use IO::Socket and that module
uses Socket and that module uses...what? Well, it turns out it
uses the same approach that's in the listgroups.pl script.

If your answer to a bug in the program is to hack out the
section and replace it with a module, your basically saying
that you don't know how the section works. So your going to
drop in a black box that does the same as that section. In
other words, you don't know how the black box works anymore
than you know how the section your hacking out works.

And the day that a new platform comes along and the module your
using blows up on that then you will be just as screwed as
I was. Worse, probably, because I didn't give up I kept plugging
away at it. You won't, you will just complain loudly for the
maintainer of the IO::Socket module to fix it and do nothing until he does.

I'm not proposing that someone take and write a brand new project
from scratch.

For new perl code you want to use as many of the WIDELY USED
modules that have ONGOING SUPPORT as you can. That is a given.

But for older, running code that breaks on new platforms, wouldn't
you rather just correct the bug in it than spend all that time
rewriting it?

Ted

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Ted Mittelstaedt wrote:
> On 2/23/2011 11:32 PM, John W. Krahn wrote:
>> Ted Mittelstaedt wrote:
>>>
>>> Think of this as a chance to educate. If you were teaching a math
>>> class in elementary school and a child asked how to add 2 + 2 would
>>> you tell them to get a calculator? The NNTP protocol is very simple and
>>> this only uses a few of it's commands.
>>>
>>> The code works on older FreeBSD, and on a modern Ubuntu system running
>>> the same version of Perl as on the newer FreeBSD. I have to thus
>>> assume the problem isn't the code, the problem is something inherent
>>> in how Perl is implemented on FreeBSD 8.X. I just don't know what it is.
>>
>> That all depends on how you define "works"?
>
> Displays the posts (articles) on a web interface.
>
>> The program 'readmsg' has
>> some serious problems with incorrect regular expressions.
>
> I'm sure it does. Cheap hacks have always characterized Usenet.
>
>> And if you
>> compile the programs with warnings enabled you will get a few messages.
>>
>
> Well, unfortunately there is a huge lack of web-to-Usenet interfaces out
> there that are open source (ie: free) Most folks that are content with
> a Usenet webinterface can get their web access from Google Groups. So
> there is little incentive for many ISP's to field a web-to-news
> interface and far less than that for anyone to write one.

It has already been written, and I've even used it myself: Net::NNTP


> The readnews interface is one of the few out there and although it is
> probably classed as "antique" software, it still works fine.

Antique yes! It is written for Perl4 which is about 18 years old.



John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Ted Mittelstaedt wrote:
> OK since nobody helped me (sniff, sniff) I had to figure it out myself.
>
> Here is the problem code in the fragment:
>
> $sockaddr = 'S n a4 x8';
>
> replacing it with
>
> $sockaddr = 'x C n a4 x8';
>
> fixed the problem. The template for the pack command was wrong.
>
> Th first two bytes are length (0) and family, both of which are unsigned
> char, so 'x C' (or 'n') handles those.

Why is 'x8' at the end of that string? Do you know what is does and why
it is there?

Have you read and of W. Richard Stevens' books?



John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "TM" == Ted Mittelstaedt <tedm [at] mittelstaedt.us> writes:

TM> On 2/24/2011 12:42 AM, Uri Guttman wrote:

TM> Uri, I am perfectly aware of what constitutes modern programming
TM> practice. And the fact of the matter is that your very wrong, because
TM> if I was going to rewrite this code the correct way would be to use
TM> one of the NNTP Perl modules (NNTP Client for example) The listgroups
TM> script could probably be replaced by something along the lines of

s/your/you're/

and i know about using the nntp module. but your last post was jusy
about crappy low level socket stuff and that bothered me more. that
isn't even a rewrite or changing the logic. it was one line to replace
about 10 hard to fix lines. drop in replacement is not a rewrite.

TM> But I will point out that perl modules are built in a pyramid, you
TM> have ones like NNTPClient that use IO::Socket and that module
TM> uses Socket and that module uses...what? Well, it turns out it
TM> uses the same approach that's in the listgroups.pl script.

IO::Socket is in core perl. it is not a heavy dependency. the issue
isn't whether a module uses other modules but your time wasted fixing
socket stuff that doesn't need fixing. if you thing spending time there
is worth it vs a single line of code, that is your problem. see how well
it does on your resume! :)

TM> If your answer to a bug in the program is to hack out the
TM> section and replace it with a module, your basically saying
TM> that you don't know how the section works. So your going to
TM> drop in a black box that does the same as that section. In
TM> other words, you don't know how the black box works anymore
TM> than you know how the section your hacking out works.

bullshit. simple as that. i can hack at any level i feel like having
done it for over 3 decades. i have done massive amounts of socket work
in c and perl. i choose to be lazy and use the right module for the
job. that is a skill i promote when i job hunt.

TM> And the day that a new platform comes along and the module your
TM> using blows up on that then you will be just as screwed as I was.
TM> Worse, probably, because I didn't give up I kept plugging away at
TM> it. You won't, you will just complain loudly for the maintainer
TM> of the IO::Socket module to fix it and do nothing until he does.

huh?? you don't get it. that is basic client socket connection. that
hasn't changed in eons. if you think depending on that is a ball and
chain, you are not worth talking to.

TM> I'm not proposing that someone take and write a brand new project
TM> from scratch.

TM> For new perl code you want to use as many of the WIDELY USED
TM> modules that have ONGOING SUPPORT as you can. That is a given.

TM> But for older, running code that breaks on new platforms, wouldn't
TM> you rather just correct the bug in it than spend all that time
TM> rewriting it?

nope. you spent way more time fixing this than even a modest rewrite
would have taken. and i am not even talking nntp here. the reason it
blew up was BECAUSE it did the low level stuff poorly and wasn't
portable. that is what bit you. you have it backwards.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2/24/2011 2:05 AM, John W. Krahn wrote:
> Ted Mittelstaedt wrote:
>> OK since nobody helped me (sniff, sniff) I had to figure it out myself.
>>
>> Here is the problem code in the fragment:
>>
>> $sockaddr = 'S n a4 x8';
>>
>> replacing it with
>>
>> $sockaddr = 'x C n a4 x8';
>>
>> fixed the problem. The template for the pack command was wrong.
>>
>> Th first two bytes are length (0) and family, both of which are unsigned
>> char, so 'x C' (or 'n') handles those.
>
> Why is 'x8' at the end of that string?

8 null bytes of padding

Do you know what is does

A description of what it does is available here:

http://www.linuxjournal.com/article/2057

it basically pads out the binary data that is being fed to
the connect() function to the correct length for the 16 byte
binary structure connect() uses.

The Perl connect() function requires SOCKET, NAME. In the code
the author used "S" as the socket. The connect function (per
the docs) "requires NAME to be a packed address of the appropriate type
for the socket."

The original pack template of S n a4 x8 was "An unsigned short value of
16 bits" (2 bytes) "unsigned short in network big endian value" (2
bytes) "string of arbitrary binary value 4 long" (4 bytes) "8 null
bytes" (8 bytes) This gives us our 16 bytes dictated in <netinet/in.h>

IMHO the author probably used 'S n a4 x8' because that pack template
appears in most if not all of the various tutorials and texts
scattered around the Internet. (and which all contain a lot of hand
waving when it comes to the nitty-gritty) Remember my warning about
using black boxes you don't want to understand!

The corrected pack template of x C n a4 x8 was "Null byte" (1 byte)
"unsigned char value" (1 byte) "unsigned short in network big endian
value" (2 bytes) "string of arbitrary binary value 4 long" (4 bytes) "8
null bytes" (8 bytes) This also gives us our 16 bytes with one
critical difference - the pack command now knows that the data that
it's expected to stuff into byte 2 is an unsigned char value.

These were used in:

$that = pack ($sockaddr, $AF_INET, $port, $thataddr);

So, after applying the template the main change is that we
are stuffing AF_INET into byte 2 is an unsigned char value.

In other words, it's x is 0, AF_INET is C, port 119 is n,
and the IP address is a4, and the last 8 bytes is zeros. (x8)

At least, this is MY understanding of it. If it is wrong, say
so!

The $64,000 question in all of this is WHY DID THE 'S n a4 x8'
WORK in the older FreeBSD 6.4 version, the current Ubuntu version,
and in a lot of other code people have used. It appears to be
basically wrong. I'd love to know why it "worked". And incidentally
the original person who pointed this out years ago on another
mailing list (that led me to this solution) didn't have an
answer for that, either.

FreeBSD has a reputation for being very nasty to wrong-written
code. Linux has a reputation for accepting all sorts of
wrong-written code and "trying to do the right thing" I would
assume that the newer Perl version became more strict somehow,
and the newer FreeBSD version glommed on to that in it's
Perl build, while the Perl install on Ubuntu made it less strict in
accordance with Linux'es more laid-back philosophy about working with
sloppy code. There is probably a Perl compile flag that can be
set if I recompiled Perl on FreeBSD 8 that would break it again
so the original wrong code would "work"

and why
> it is there?
>
> Have you read and of W. Richard Stevens' books?
>

No, I did the "Internetworking with TCP/IP" series by Comer, not the
TCP/IP Illustrated" series by Stevens. That was a while ago when
we still used real paper books. ;-)

Ted

>
>
> John


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2/24/2011 2:00 AM, John W. Krahn wrote:
> Ted Mittelstaedt wrote:
>> On 2/23/2011 11:32 PM, John W. Krahn wrote:
>>> Ted Mittelstaedt wrote:
>>>>
>>>> Think of this as a chance to educate. If you were teaching a math
>>>> class in elementary school and a child asked how to add 2 + 2 would
>>>> you tell them to get a calculator? The NNTP protocol is very simple and
>>>> this only uses a few of it's commands.
>>>>
>>>> The code works on older FreeBSD, and on a modern Ubuntu system running
>>>> the same version of Perl as on the newer FreeBSD. I have to thus
>>>> assume the problem isn't the code, the problem is something inherent
>>>> in how Perl is implemented on FreeBSD 8.X. I just don't know what it
>>>> is.
>>>
>>> That all depends on how you define "works"?
>>
>> Displays the posts (articles) on a web interface.
>>
>>> The program 'readmsg' has
>>> some serious problems with incorrect regular expressions.
>>
>> I'm sure it does. Cheap hacks have always characterized Usenet.
>>
>>> And if you
>>> compile the programs with warnings enabled you will get a few messages.
>>>
>>
>> Well, unfortunately there is a huge lack of web-to-Usenet interfaces out
>> there that are open source (ie: free) Most folks that are content with
>> a Usenet webinterface can get their web access from Google Groups. So
>> there is little incentive for many ISP's to field a web-to-news
>> interface and far less than that for anyone to write one.
>
> It has already been written, and I've even used it myself: Net::NNTP
>

That's not a web interface that is just a module that can be used
to create one. Many people say they have written such a thing and
even deployed them but I can't find much code out there. Is the
interface you wrote using this available, for example?

There are a number of PHP webnews interfaces and I have also deployed
some of those for fun. All have their warts. And most are slower than
this script. Not that that matters much nowadays, with hardware what
it is.

When I first put up this system it was in 1999 and I found no
webinterface code then either, although the situation was the same,
people saying they were using it but no examples. The SCN scripts
came out a year earlier and they ran on FreeBSD 3. Once you get
people trained to use an interface and the interface works and is
stable, you keep using it as long as it runs on the newer platforms.

>
>> The readnews interface is one of the few out there and although it is
>> probably classed as "antique" software, it still works fine.
>
> Antique yes! It is written for Perl4 which is about 18 years old.
>

But this is a sales point. Many people have 18 year old cars that still
run and they drive every day. You have to understand that with non-
technical members of the general public they absolutely detest this
constant harping on upgrading to the newest and latest software. They
have never bought into it and still don't. It isn't the consumers who
want new software every year, it's the software vendors that push it
on them.

I guarantee to you that LOTS of people would still today be buying
brand new PC's with Windows XP loaded on them if they could.

Linux would never have made the inroads against Windows that it has
today if it could not run older software. For that matter there are
people running decade-old versions of Microsoft Office on Windows 7.

Software lasts, man, and there's good money in supporting it. Look at
all those COBOL programmers who made a mint in 1999 due to Y2K. I'll
bet most of those programs are still running today.

Ted


>
>
> John


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

--90e6ba25eb2bdd2434049d176452
Content-Type: text/plain; charset=ISO-8859-1

You want quick and dirty? Figure out how the nntp module works. Then figure
out at what point your program is calling that function and with what
parameters. Then replace that function with yours. Then figure out what the
program is looking for for output and fix the output that the Net::NNTP
module returns to match what the program wants and you're back in business.

The right way: scrap the whole thing. Get catalyst and use the NNTP module
with that. If you do it that way you can even give it a nice new look. Hell,
you could even add some css while you're at it.

.... third option, figure out what module is giving those functions and see
if its still maintained and how it works now. Or find an equivalent module
and use that.

You want a simple solution. Fact is, while I've been having fun /trying/ to
figure out 20 year old ioccc (c code) I don't think anyone really wants to
look at perl code even half that old.

--90e6ba25eb2bdd2434049d176452--

On 2/24/2011 9:29 AM, Uri Guttman wrote:
>>>>>> "TM" == Ted Mittelstaedt<tedm [at] mittelstaedt.us> writes:
>
> TM> On 2/24/2011 12:42 AM, Uri Guttman wrote:
>
> TM> Uri, I am perfectly aware of what constitutes modern programming
> TM> practice. And the fact of the matter is that your very wrong, because
> TM> if I was going to rewrite this code the correct way would be to use
> TM> one of the NNTP Perl modules (NNTP Client for example) The listgroups
> TM> script could probably be replaced by something along the lines of
>
> s/your/you're/
>
> and i know about using the nntp module. but your last post was jusy
> about crappy low level socket stuff and that bothered me more. that
> isn't even a rewrite or changing the logic. it was one line to replace
> about 10 hard to fix lines. drop in replacement is not a rewrite.
>

Ah, but that same template problem appeared in the other 2 scripts
that are part of this software package. Also I think it may have been
used in multiple places in each script. In the interests of keeping the
original question simple I omitted that. Expending the effort to fix
one script fixes all 3. Of course when I embarked on the attempt to fix
the one I didn't know the other 2 scripts would have the identical fix
but I suspected - since their failure symptoms were very similar.

> TM> But I will point out that perl modules are built in a pyramid, you
> TM> have ones like NNTPClient that use IO::Socket and that module
> TM> uses Socket and that module uses...what? Well, it turns out it
> TM> uses the same approach that's in the listgroups.pl script.
>
> IO::Socket is in core perl. it is not a heavy dependency. the issue
> isn't whether a module uses other modules but your time wasted fixing
> socket stuff that doesn't need fixing. if you thing spending time there
> is worth it vs a single line of code, that is your problem. see how well
> it does on your resume! :)
>

Once more, this was not a design decision to write new code it was a
repair decision.

Re read my original post. At the time I first started looking at this
I had no idea the problem was in the socket code. It could have just as
easily been an operating system issue. Since the script worked on a
modern Ubuntu system I assumed the problem wasn't in the script.

Sure I knew the script has some hoary old code in it. But just because
code is old does not mean it's bad. Particularly when the code has been
around for a decade and worked on several different FreeBSD versions.

Consider it again. The script worked on FreeBSD 6.4 running Perl 5.8.8
It worked on the current version of Ubuntu running perl 5.10.1. And it
failed on FreeBSD 8 running perl 5.10.1 Why would it be reasonable to
assume that the script was the problem? The birds eye view would say
that it was a new bug introduced in FreeBSD 8. Particularly when the
old and new version of FreeBSD is 32 bit and the new hardware was a
pentium 4 and the old hardware a pentium 3.

> TM> If your answer to a bug in the program is to hack out the
> TM> section and replace it with a module, your basically saying
> TM> that you don't know how the section works. So your going to
> TM> drop in a black box that does the same as that section. In
> TM> other words, you don't know how the black box works anymore
> TM> than you know how the section your hacking out works.
>
> bullshit. simple as that. i can hack at any level i feel like having
> done it for over 3 decades. i have done massive amounts of socket work
> in c and perl. i choose to be lazy and use the right module for the
> job. that is a skill i promote when i job hunt.
>

Good for you. But I was not talking specifically about you but in
general. In your specific case since you know everything from the low
to the high level you POSSIBLY could have taken one look at the script
that was not working and had a "gut feeling" that even though the
early indicators pointed to an operating system bug, the problem still
was the script because the code in it was old. You might have then
taken a leap of faith that you were right and then cut out the socket
code and replaced it with calls to IO:Socket and then sat back in
satisfaction when everything worked. You wouldn't have even bothered
in that case trying to figure out why the socket code didn't work since
you just would have assumed it was broken.

> TM> And the day that a new platform comes along and the module your
> TM> using blows up on that then you will be just as screwed as I was.
> TM> Worse, probably, because I didn't give up I kept plugging away at
> TM> it. You won't, you will just complain loudly for the maintainer
> TM> of the IO::Socket module to fix it and do nothing until he does.
>
> huh?? you don't get it. that is basic client socket connection. that
> hasn't changed in eons. if you think depending on that is a ball and
> chain, you are not worth talking to.
>

I didn't say that was a ball and chain. What I was trying to illustrate
was that ultimately Perl depends on the implementation of the operating
system function calls and it helps to understand those calls. Perl
today is much more modularized than it used to be, that helps in many
areas but it particularly helps in this kind of problem because it is
always easier to troubleshoot a large piece of software if it is divided
up internally than if it is just one big
monolithic whole, because you can test each segment. The ball and chain
here is the operating system.

And even then, it's not really that because the OS is just machine code
to the CPU anyway. Once more, more modularization.

I think you and I are more in agreement than you think. You say that
people should operate in the upper layers of Perl and use the modules.
Yet you boast about being able to hack at any level. Well, your
boasting because you know that this is an advantage. If you really and
truly thought that your skills were equal to a perl coder who didn't
understand anything at a low level and just used the modules then you
wouldn't be boasting. But you know what I have been saying is true -
that while a programmer should use the modules, there are times that
if a module isn't working right that you have to dive into the lower
level and figure it out. You can do that while Joe Admin who thinks
that C is something he finds in his alphabet soup cannot.

> TM> I'm not proposing that someone take and write a brand new project
> TM> from scratch.
>
> TM> For new perl code you want to use as many of the WIDELY USED
> TM> modules that have ONGOING SUPPORT as you can. That is a given.
>
> TM> But for older, running code that breaks on new platforms, wouldn't
> TM> you rather just correct the bug in it than spend all that time
> TM> rewriting it?
>
> nope. you spent way more time fixing this than even a modest rewrite
> would have taken. and i am not even talking nntp here. the reason it
> blew up was BECAUSE it did the low level stuff poorly and wasn't
> portable. that is what bit you. you have it backwards.
>

Except that I didn't know that this is what bit me until I made a
guess that this was what it was and lo and behold, I fixed it.

Hindsight is easy. Correcting the template proves that the original
code was poorly written, because if the original author really and truly
understood the pack call he would have used the correct template. The
template was wrong the day it was written back in 1998 and it only
worked through what they call "dumb luck" meaning we really don't know
why broken code works on some operating systems and it's not worth
investigating to figure it out. And if I had known at the very
beginning of trying to fix the script that the reason it was broken
in the socket code was because the code was poorly written then I
might have taken a different repair path and just planned on removing
those 10 lines and replacing them with an IO::Socket call wherever they
appeared in the scripts.

Ted

> uri
>


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/