wget fails up update link from busy box to /usr/local/bin/wget [solved]

[b1ackmai1er]

When installing wget the documentation states that the link to wget will get updated from busybox wget  to /usr/local/bin/wget.

But this fails to happen and the user has to use the full pathname to run the extension version of wget.

Regards b1acmai1er

[Jason W]

My terminal output:

tc@box:~$ which wget
/usr/local/bin/wget
tc@box:~$


Make sure and open a new terminal after you install the wget extension or the path will not be updated in the same terminal you issued "tce-load ....  wget.tcz". 

[maro]

There is a way that you don't have to "abandon" your current shell after a 'tce-load ...' (which one would do by opening a new terminal, which implies a new shell process that starts with a "clean" command cache):
Use the hash -r command after your 'tce-load ...'. That "resets" the command cache and the problem described by the OP should be resolved.

[b1ackmai1er]

I understand what you are saying but I think something is broken.

wget worked yesterday except for simple issue raised in this thread that you have explained the behavior for but now it is not working at all.

My process:

reboot TC from cdrom
install wget.tcz using Appbrowser using default mirror i.e. don't select a mirror
close Appbrowser
start aTerm window
if I type type wget
wget:error while loading shared library libidn.so.11: .....
if I type type /usr/bin/wget
Busybox v1.17.0 .....
if I type type /usr/local/bin/wget
wget:error while loading shared library libidn.so.11: .....

So not wget from default repository not working

if I use the mirror I made overnight, everything works.

reboot TC from cdrom
start aTerm window
echo "http://192.168.2.1:8091/" > /opt/tcemirror
install wget.tcz using Appbrowser using new default mirror
type in aTerm window wget
wget: missing url
type in aTerm wget --version
GNI wget 1.12 built on linux-gnu

So yesterday it couldn't find the new installed wget, today it can if I use my overnight local repository whether I open/close a new aterm window or not. Does not work at all if I use the default repository today (ibiblio?)

[Jason W]

What you are seeing now is a different issue.  I rebuilt wget against the current openssl in the repo, and libidn is now a needed dependency but I forgot to list it in the dep file.  It is now in the dep file, just download libidn.tcz and all should be well.

[b1ackmai1er]

Hi,

Needs libiconv.tcz as well.

Damn, this is getting big now...

I was looking for a quick way to retrieve my extensions from my local ftp server.
What I was doing was using the built in wget to retrieve the full wget  (+openssl) and then use the wget -mirror option to pull all the files over.
program=258k, libraries=2.5meg!

Should /usr/local/bin be in the default path if this is where all extension binaries get stored?

Thanks.

[Jason W]

/usr/local/bin is in the default path or nothing would work, in fact it is ahead of /usr/bin if I recall - I am away from tc at the moment.  

I added libiconv.tcz to the wget dep file.  I may build a basic wget that has no ssl or idn support and call this full version wget-ssl.  

But as there is a busybox wget for minimal functionality, and full functionality is what is normally desired of extensions, I don't see a pressing need to have 2 builds of wget in the repo.

[Jason W]

On second thought, there has yet to be a request for IDN support in the wget extension, and 2.5MB is a lot of stuff to pull in for those who want the basic GNU wget without needing SSL or IDN.  

Offering a full featured wget and a basic one sounds reasonable.  I think it is good to at least have a choice to stay small.

[tinypoodle]

Should /usr/local/bin be in the default path if this is where all extension binaries get stored?

Code: [Select]

grep local /etc/profile


[b1ackmai1er]

Thanks. I think the small/big idea for wget is a good idea.

Looked up the  hash command and now understand the command execution sequence. This must trip a few people up!

Learning every day.

Cheers