Tiny Core Linux

Tiny Core Extensions => TCE Bugs => Topic started by: b1ackmai1er on July 23, 2010, 10:31:07 PM

Title: wget fails up update link from busy box to /usr/local/bin/wget [solved]
Post by: b1ackmai1er on July 23, 2010, 10:31:07 PM
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
Title: Re: wget fails up update link from bust box to /usr/local/bin/wget
Post by: Jason W on July 23, 2010, 10:57:49 PM
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". 

Title: Re: wget fails up update link from bust box to /usr/local/bin/wget
Post by: maro on July 24, 2010, 12:22:46 AM
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.
Title: Doesn't work for me ???
Post by: b1ackmai1er on July 25, 2010, 05:26:03 AM
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?)

???




Title: Re: wget fails up update link from bust box to /usr/local/bin/wget
Post by: Jason W on July 25, 2010, 05:36:17 AM
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.
Title: dependencies
Post by: b1ackmai1er on July 25, 2010, 06:33:43 AM
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.
Title: Re: dependencies
Post by: Jason W on July 25, 2010, 07:27:51 AM
/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.
Title: Re: dependencies
Post by: Jason W on July 25, 2010, 08:58:15 AM
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.
Title: Re: wget fails up update link from bust box to /usr/local/bin/wget
Post by: tinypoodle on July 25, 2010, 09:09:38 AM
Should /usr/local/bin be in the default path if this is where all extension binaries get stored?
Code: [Select]
grep local /etc/profile

;)
Title: Re: wget fails up update link from bust box to /usr/local/bin/wget
Post by: b1ackmai1er on July 26, 2010, 03:43:54 AM

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