500 Can't connect to search.cpan.org:80 (Bad protocol 'tcp') at web.plline 24.

[Nirvana]

#!C:/Perl/bin/perl.exe -w

use LWP::Simple;
use HTML:arse;
use HTML::Element;
use HTML:arser;
use HTML::FormatText;
use Socket;

$ENV{"SYSTEMROOT"} = "C:/WINDOWS/system32";

require LWP::UserAgent;

my $ua = LWP::UserAgent->new;
$ua->timeout(10);
$ua->env_proxy;

my $response = $ua->get('http://search.cpan.org/');

if ($response->is_success) {
print $response->content; # or whatever
}
else {
die $response->status_line;
}

I'm getting following error:
500 Can't connect to search.cpan.org:80 (Bad protocol 'tcp') at web.pl
line 24.

Any help ?

 

[Peter Wyzl]

: Nirvana wrote:
: ...
: > $ENV{"SYSTEMROOT"} = "C:/WINDOWS/system32";
: ...
: > I'm getting following error:
: > 500 Can't connect to search.cpan.org:80 (Bad protocol 'tcp') at web.pl
: > line 24.
: >
: > Any help ?
: >
:
: Not sure why, but removing the bogus environment variable setting makes
: it work on my system. Somewhere in the bowels of LWP, it must refer to
: some Windoze component that needs a valid setting for the SYSTEMROOT
: environment variable. I'm not sure why you'd want to mess with that one
: anyway -- but I'm pretty sure it will have to have genuine backslashes
: in it if Windoze is looking at it.

Generally not, though with an environment variable I don't know.
command.com and cmd.exe both understand / as well as \ for directory
seperators.

It's probably worth noting that systemroot is normally set to c:\windows NOY
c:\windows\system32 (being the root of the system tree not a directory
within it)

 

[Peter Wyzl]

: Peter Wyzl wrote:
:
: > : > : Nirvana wrote:
: ...
: > command.com and cmd.exe both understand / as well as \ for directory
: > seperators.
:
: Bull****. A / does not work as a directory separator in DOS or Windoze,
: and never has -- it is a command options or "switch" designator:
:
: D:\junk>dir d:/junk
: Invalid switch - "junk".
:
: D:\junk>ver
:
: Microsoft Windows XP [Version 5.1.2600]

I beg to differ... the problem you have is with the dir command, not
cmd.exe.

you can 'cd' to /junk

you can cd to /junk/junk2 etc

open (IN, 'c:/junk/junk2/file.txt') or die "Can't $!\n";

works perfectly fine as well.

Since we are dealing with Perl, the context of the comment is important, in
that a forward slash works perfectly well, in all instances except accessing
the root of a drive directly, where I have found that c:\\ is more reliable
(particularly with File::Find which is a little inconsistent with what it
reports for files and directories).

 

[Michele Dondi]

: > command.com and cmd.exe both understand / as well as \ for directory
: > seperators.
:
: Bull****. A / does not work as a directory separator in DOS or Windoze,
: and never has -- it is a command options or "switch" designator: [...]
I beg to differ... the problem you have is with the dir command, not
cmd.exe.

you can 'cd' to /junk

you can cd to /junk/junk2 etc

open (IN, 'c:/junk/junk2/file.txt') or die "Can't $!\n";

works perfectly fine as well.

I beg to differ... what you wrote is still BS, since it has nothing to
do with command.com and/or cmd.exe: indeed Windows *APIs* do support
both '/' and '\' as directory separators. You can even mix them in a
single specification.

Since we are dealing with Perl, the context of the comment is important, in
that a forward slash works perfectly well, in all instances except accessing

It works perfectly *within* perl[1]. Still this has NOTHING to do with
either command.com or cmd.exe! Whatever the context of the comment can
be, whatever we're dealing with, what you wrote about command.com and
cmd.exe is WRONG, period.

The examples you gave are wrong and misleading as they have nothing to
do with any shell (apart a possible ambiguity with C<cd>, that could
be interpreted as an internal Perl command or a shell one).


[1] no matter if by means of some magic it does or directly by means
of Windows APIs capabilities. I don't know which of the two is true,
BTW...


Michele

 

[Peter Wyzl]

: On Mon, 29 Nov 2004 08:47:52 GMT, "Peter Wyzl" <[email protected]>
: wrote:
:
: >: > command.com and cmd.exe both understand / as well as \ for directory
: >: > seperators.
: >:
: >: Bull****. A / does not work as a directory separator in DOS or
Windoze,
: >: and never has -- it is a command options or "switch" designator:
: [...]
: >I beg to differ... the problem you have is with the dir command, not
: >cmd.exe.
: >
: >you can 'cd' to /junk
: >
: >you can cd to /junk/junk2 etc
: >
: >open (IN, 'c:/junk/junk2/file.txt') or die "Can't $!\n";
: >
: >works perfectly fine as well.
:
: I beg to differ... what you wrote is still BS, since it has nothing to
: do with command.com and/or cmd.exe: indeed Windows *APIs* do support
: both '/' and '\' as directory separators. You can even mix them in a
: single specification.
:
: >Since we are dealing with Perl, the context of the comment is important,
in
: >that a forward slash works perfectly well, in all instances except
accessing
:
: It works perfectly *within* perl[1]. Still this has NOTHING to do with
: either command.com or cmd.exe! Whatever the context of the comment can
: be, whatever we're dealing with, what you wrote about command.com and
: cmd.exe is WRONG, period.
:
: The examples you gave are wrong and misleading as they have nothing to
: do with any shell (apart a possible ambiguity with C<cd>, that could
: be interpreted as an internal Perl command or a shell one).
:
:
: [1] no matter if by means of some magic it does or directly by means
: of Windows APIs capabilities. I don't know which of the two is true,
: BTW...

Windows API.

To get back to the original comment, Bob said that as far as he knew it had
to have a literal backslash if Windows was looking at it. I countered that
this is not true. There are cases where Windows requires a literal
backslash (File::Find suffers from it) but it is not universally true. Bob
gave an example where a forward slash is not accepted (/ being a switch
delimiter) and I gave an example where it is. Within Perl / is accepted
because perl does the right thing. Stating that 'Windows requires a literal
backslash' is what was incorrect.

However, this was not intended to be a discussion about Windows or cmd.exe.
It WAS intended to be a discussion about what happens within [Pp]erl and
that / can be used as much as \\ in programs written in Perl. This enhances
readability and portability.

What I wrote about cmd.exe is not wrong, I gave an example that supported
that statement. This is NOT universal, and is not even the difference
between internal/external commands. However, the point I was making was
(trying to make?) is that / works in perl. Why you have to tell me I wrote
BS and then state the same thing is a little confusing to me.

 

[Michele Dondi]

do with any shell (apart a possible ambiguity with C<cd>, that could
be interpreted as an internal Perl command or a shell one).

Incidentally this *is* BS!


Sorry,
Michele

 

[Michele Dondi]

To get back to the original comment, Bob said that as far as he knew it had
to have a literal backslash if Windows was looking at it. I countered that
this is not true. There are cases where Windows requires a literal

Let me see... he wrote:

| Not sure why, but removing the bogus environment variable setting makes
| it work on my system. Somewhere in the bowels of LWP, it must refer to
| some Windoze component that needs a valid setting for the SYSTEMROOT
| environment variable. I'm not sure why you'd want to mess with that one
| anyway -- but I'm pretty sure it will have to have genuine backslashes
| in it if Windoze is looking at it.

It *seems* to me that he's saying that *in this particular case*
"genuine backslashes" may be required. Also he has not claimed
anything for certain, and it seems to me that he has stressed enough
that he's making a guess, even if he's pretty (note: *not*
absoultely!) sure about it.

In other words it seems to me that he's never claimed that genuine
backslashes are required in Windows paths. But to be fair I admit that
his sentence could be interpreted in both ways so I'm not arguing
about your interpretation, notwithstanding the fact that it's not the
same as mine.

However in your answer you included these lines:

: command.com and cmd.exe both understand / as well as \ for directory
: seperators.

(incidentally I can't understand why you mentioned them, since they
have few to nothing to do with what we/you were talking about...)

to which bob replied in turn:

| Bull****. A / does not work as a directory separator in DOS or Windoze,
| and never has -- it is a command options or "switch" designator:
[snip examples]

Again his statement is ambiguous for "DOS or Windoze" may refer both
to the system (or some component of it) or to the shell. Both the fact
that he was aswering to your lines quoted above (which are the *only
ones* of your post he quoted) and the examples he gave can make one
undoubtedly sure he's referring to the latter.

Then again you replied

: I beg to differ... the problem you have is with the dir command, not
: cmd.exe.
:
: you can 'cd' to /junk
:
: you can cd to /junk/junk2 etc

In cmd.exe that is, I didn't know that, but I'll take your word for
it. In command.com not for sure:

C:\WINDOWS>cd /temp
Opzione non valida - /TEMP

C:\WINDOWS>cd "/temp"
Opzione non valida - /TEMP"

C:\WINDOWS>cd "C:/temp"

C:\WINDOWS>

: open (IN, 'c:/junk/junk2/file.txt') or die "Can't $!\n";

This is perl code and has nothing to do with cmd.exe or command.com,
just as much the latter ones had nothing to do with the subject matter
being discussed in the first place.

backslash (File::Find suffers from it) but it is not universally true. Bob
gave an example where a forward slash is not accepted (/ being a switch
delimiter) and I gave an example where it is. Within Perl / is accepted

Again, I must admit that I didn't know cmd.exe does that. I would say
that it is of little use anyway, since (most) external commands won't
understand it in any case, so that it may generate some confusion IMHO
to mix the two separators on the cmd line.

because perl does the right thing. Stating that 'Windows requires a literal
backslash' is what was incorrect.

Yes, it is incorrect. But as I wrote above, it doesn't seem to me that
Bob ever claimed that.

OTOH I thought that what you said of cmd.exe and command.com was
wrong: now it may well be that at least as far as cmd.exe is concerned
it is *not* strictly wrong.

However, this was not intended to be a discussion about Windows or cmd.exe.
It WAS intended to be a discussion about what happens within [Pp]erl and
that / can be used as much as \\ in programs written in Perl. This enhances
readability and portability.

I agree. I have never said the opposite. FWIW I also always use '/'.

(trying to make?) is that / works in perl. Why you have to tell me I wrote
BS and then state the same thing is a little confusing to me.

Both my cmt and Bob's original one were referring exclusively to your
claim about Windows' shells.


Michele