[USRP-users] Reg : Image Downloader

Marcus Müller marcus.mueller at ettus.com
Wed Oct 21 13:01:25 EDT 2015


I can understand your frustration, it's just that when *exporting* these
environment variables, my uhd_images_downloader definitely tries to
access your proxy.
Can you try to
export http_proxy
prior to
uhd_images_downloader
?

This might really just be a shell strangeness.

Best regards,
Marcus
**
On 10/21/2015 06:48 PM, Sumit Kumar wrote:
> Well, I swear I never had to do all these setting with build-gnuradio
> script :D
> It was a peace meal !
>
> This is working :
>
> proxies =
> {"http":"http://proxy.iiit.ac.in:8080","https":"http://proxy.iiit.ac.in:8080","HTTP":"http://proxy.iiit.ac.in:8080","HTTPS":"http://proxy.iiit.ac.in:8080"}
>
> r = requests.get(images_url, stream=True, headers={'User-Agent': 'UHD
> Images Downloader'}, proxies=proxies)
>
> but this is not :
>
> proxies =
> {"HTTP":"http://proxy.iiit.ac.in:8080","HTTPS":"http://proxy.iiit.ac.in:8080"}
>
> r = requests.get(images_url, stream=True, headers={'User-Agent': 'UHD
> Images Downloader'}, proxies=proxies)
>
> Where can I get the old version of uhd_image_downloader.py Just want
> to check
>
> Meanwhile here is my environment :
>
> sumit at sumit-ThinkCentre-M72e:/usr/local/lib/uhd/utils$ cat
> /etc/environment
> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/lib/uhd/images:/usr/local/share/uhd/images"
> http_proxy="http://proxy.iiit.ac.in:8080/"
> https_proxy="https://proxy.iiit.ac.in:8080/"
> ftp_proxy="ftp://proxy.iiit.ac.in:8080/"
> socks_proxy="socks://proxy.iiit.ac.in:8080/
> <http://proxy.iiit.ac.in:8080/>"
> UHD_IMAGES_DIR="/usr/local/lib/uhd/images"
>
>
>
>
>
> On Wed, Oct 21, 2015 at 9:00 PM, Neel Pandeya <neel.pandeya at ettus.com
> <mailto:neel.pandeya at ettus.com>> wrote:
>
>     Maybe this is a rare case of a lower-case environment variable?
>     $HTTP_PROXY doesn't work, but $http_proxy works?
>
>     Just digging around, I found the following:
>     http://askubuntu.com/questions/228530/updating-http-proxy-environment-variable
>     http://unix.stackexchange.com/questions/212894/whats-the-right-format-for-the-http-proxy-environment-variable-caps-or-no-ca
>     http://superuser.com/questions/876100/https-proxy-vs-https-proxy
>
>
>
>
>     On 21 October 2015 at 07:49, Marcus Müller
>     <marcus.mueller at ettus.com <mailto:marcus.mueller at ettus.com>> wrote:
>
>         > It is likely the case that python-requests doesn't
>         automatically use
>         > the HTTP_PROXY variable, like various other url handlers do,
>         which is
>         >   why wget is working, as is your browser.
>         In my experience, requests **is** sensitive to HTTP_PROXY:
>
>
>         #10001|marcus>export
>         HTTP_PROXY=http://non-working.non-existing:9000/
>         #10002|marcus
>         <http://non-working.non-existing:9000/#10002%7Cmarcus>>uhd_images_downloader
>         Images destination:      /home/marcus/.usrlocal/share/uhd/images
>         Downloading images from:
>         http://files.ettus.com/binaries/images/uhd-images_003.009.git-184-gf2337d6f.zip
>         Downloading images to: 
>          /tmp/tmpb6Y7ec/uhd-images_003.009.git-184-gf2337d6f.zip
>         Downloader raised an unhandled exception: <urlopen error
>         [Errno -2] Name or service not known>
>
>
>         but wget is **not**:
>
>         #10004|marcus>wget
>         "http://files.ettus.com/binaries/images/uhd-images_003.009.git-184-gf2337d6f.zip"
>         --2015-10-21 16:44:36-- 
>         http://files.ettus.com/binaries/images/uhd-images_003.009.git-184-gf2337d6f.zip
>         Resolving files.ettus.com <http://files.ettus.com>
>         (files.ettus.com <http://files.ettus.com>)... 173.203.35.196
>         Connecting to files.ettus.com <http://files.ettus.com>
>         (files.ettus.com
>         <http://files.ettus.com>)|173.203.35.196|:80... connected.
>         HTTP request sent, awaiting response... 200 OK
>         Length: 23692146 (23M) [application/zip]
>         Saving to: ‘uhd-images_003.009.git-184-gf2337d6f.zip’
>
>
>         However, wget is sensitive to (notice capitalization) http_proxy:
>
>         #10005|marcus>export http_proxy=$HTTP_PROXY
>         #10006|marcus>wget
>         "http://files.ettus.com/binaries/images/uhd-images_003.009.git-184-gf2337d6f.zip"
>         --2015-10-21 16:47:02-- 
>         http://files.ettus.com/binaries/images/uhd-images_003.009.git-184-gf2337d6f.zip
>         Resolving non-working.non-existing
>         (non-working.non-existing)... failed: Name or service not known.
>         wget: unable to resolve host address ‘non-working.non-existing’
>
>
>         That's why I'm asking about the literal variable Sumit
>         exported; that's
>         bound to be a problem that'll come up more than once. By the
>         way, I do
>         think the no-caps version is more "standard", but I'm not sure.
>
>         Best regards,
>         Marcus
>
>
>
>
>
> -- 
> Sumit kumar
> Research Assistant
> Communication Research Center
> IIIT Hyderabad, India
> +91-7799081452
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151021/a5fbddd8/attachment-0002.html>


More information about the USRP-users mailing list