in reply to Scoping Issue

The problem is the empty set of parens in your sub declaration.

sub valid_req() {
#            ^^

[download]

In perl, that is called an empty prototype, and it basically says "This sub never takes any arguments". Which means that 

@command = (@_);

[download]

will always result in @command being empty, regardless of what you try to pass in when calling the sub.

If you had strict & warnings* enabled, then you would have been informed of your error with the message 

Too many arguments for main::valid_req at ...

[download]

The short term answer is to remove the parens completely, and never use a prototype in perl unless you know that you need to.

The better, long term, answer is to make the transition to using strict and warnings* in your code. It only takes a little while to get used to the few easy steps required to satisfy them.

It just makes life easier.

*References to the warnings pragma added after ambrus's correction below.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail

Replies are listed 'Best First'.
Re: Re: Scoping Issue
by ambrus (Abbot) on May 16, 2004 at 19:18 UTC

    I think it's warnings you're speaking about, not strict. Agreed, otherwise.

[reply]
[d/l]
[select]

      Probably. I always use both, so I'm rarely aware of exactly which messages are as a result of which pragma.

      I'll update:)

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
[reply]
Re: Re: Scoping Issue
by Errto (Vicar) on May 16, 2004 at 23:24 UTC

    Actually, that's not the problem at all. If you look at the OP, the first line of output after the "sdf" line shows that @command is in fact being set correctly. I was surprised too, but removing the parentheses and adding use warnings doesn't actually fix the problem.

    The real problem, as best I can tell, has to do with connecting to this server using telnet(1) as your client. Somehow telnet is sending some special escapes which your program is choking on. Try adding the following line in "spawn" and you'll see what I mean: print "***$clientreq***\n";

    Also, within your while loop you need to add this line, or else it will start spinning forever as soon as your first client disconnects:

    last if !defined $clientreq;

    Update: By the way, the --debug option in your code won't work the way you think it will. use warnings is lexically scoped, so in fact it will have no effect at all the way you've written it. To see what I mean, try this:

    if (1) {
  use warnings;
}
print undef;

    [download]

    Note that you don't get an "uninitialized value" warning like you might expect to. One way you can work around this is with:

    BEGIN {
  if ($ARGV[0] eq '--debug') {
     require warnings;
     warnings->import();
   }
}

    [download]
[reply]
[d/l]
[select]
      There's no somehow about it, telnet is defined as having a bunch of internal commands which anyone using it should consider. It uses the 255 character to indicate that one or more following characters will be telnet options. (An actual 255 char is sent doubled.) See telnet protocol.

      (I've actually written a module to allow telnet options to be ignored/dealt with on any socket, but not gotten around to documenting/finishing it .. )

      C.

[reply]
        some interesting points... I made the following changes but am still having the same problem. changed Socket to IO::Socket. removed the () in valid_req sub. removed the --debug option , and just made it use warnings; when i print "***$clientreq***\n" i get something like the following. >hello ***hello ...etc etc i don't see any extra chars... added the following line after my chomp. $clientreq =~ s/\n//g; no difference. any other ideas?
[reply]

In Section Seekers of Perl Wisdom