somewhat OT: http_proxy format (was: tor controller hangs / doesn't reply)

[Sambuddho Chakravarty]

Hello Scott and Drake
  Changing http_proxy=http://localhost:8118 with 
http_proxy=localhost:8118 doesn't show any difference . Eventually the 
tor controller hangs and fails to response to commands (and the wget 
session fails as well). I am not sure weather the problem is with wget 
or with tor ...

Thanks
Sambuddho
Scott Bennett wrote:
>      On Wed, 3 Jun 2009 13:31:53 -0500 Drake Wilson <drake at begriffli.ch> wrote:
>   
>> Quoth Scott Bennett <bennett at cs.niu.edu>, on 2009-06-03 08:17:10 -0500,
>> providing neither a References nor an In-Reply-To header:
>>     
>>>      On Wed, 03 Jun 2009 09:01:09 -0400 Sambuddho Chakravarty
>>> <sc2516 at columbia.edu> top-posted (grrr...):
>>>       
>>>> I am using :-
>>>>
>>>> http_proxy=http://localhost:8118
>>>>
>>>>         
>>>      Well, you probably need to fix that first.  Both ftp_proxy and
>>> http_proxy are supposed to be set to the *proxy*, not to a URL.  (See
>>> fetch(3) for more information.)
>>>       
>> I believe that this idea does not reflect current practice, at least
>> on GNU/Linux systems, and that Sambuddho's usage is correct for Bourne
>> shell, modulo a possibly-missing "export" command.  (Not that current
>> practice is particularly well-defined in this case.)
>>
>> >From the GNU Wget 1.11.4 manual, node "Proxies", at
>>     
>
>     [great list of examples snipped  --SB]
>
>   
>> (This doesn't reference http_proxy specifically, but I interpret it to
>> mean that all *_proxy environment variables (except no_proxy) use
>> URLs, which is consistent with the rest of the page.)
>>
>> I can't find a copy of the aforementioned fetch(3) page anywhere on
>> the Web or on any system to which I have access.
>>     
>
>      Try here:
>
> http://www.freebsd.org/cgi/man.cgi?query=fetch&apropos=0&sektion=3&manpath=FreeBSD+7.2-RELEASE&format=html
>
> (Beware of URL linewrap.)
>      I referred to the fetch(3) man page in FreeBSD because the individual man
> pages for fetch(1) and wget(1) didn't specify that information when I first
> needed to know it, but rather referred to fetch(3).  man pages are naturally
> different for different operating systems, though.
>   
>> Much of this software is common on other Unix-like systems, and to my
>> knowledge their environment variable semantics are not changed there.
>> The consensus for users appears to be that you should set *_proxy
>> variables to URLs with the scheme and host component required and the
>> port and authentication components optional.  The consensus for
>>     
>
>      I don't think I ever tried it that way.  (If I ever did try it that way,
> it must not have worked, or I wouldn't have changed it.)  My vague recollection
> is that I had no idea initially of how to get fetch(1) and wget(1) to use
> proxies, so I tracked it down to the fetch(3) page via both the fetch(1) and
> wget(1) pages.  At some point, I'll try it that way to see whether it works
> on my system, too.
>
>   
>> programs appears to be that you should accept *_proxy variables in
>> either URL format or in raw host[:port] format with the equivalent URL
>> scheme defaulting to that for the protocol for which the variable is
>> set.
>>
>>     
>      Accepting both ways does seem like the best way to do it.  I apologize
> for inadvertently giving out information that apparently is not universally
> applicable across operating systems as though it were.
>
>
>                                   Scott Bennett, Comm. ASMELG, CFIAG
> **********************************************************************
> * Internet:       bennett at cs.niu.edu                              *
> *--------------------------------------------------------------------*
> * "A well regulated and disciplined militia, is at all times a good  *
> * objection to the introduction of that bane of all free governments *
> * -- a standing army."                                               *
> *    -- Gov. John Hancock, New York Journal, 28 January 1790         *
> **********************************************************************
>
>