On Monday 09 December 2013 22:56:34 you wrote: > 10.12.2013 01:40, Tito wrote: > > On Monday 09 December 2013 18:56:43 Michael Tokarev wrote: > >> There's no reason to call gethostbyname() on the value returned > >> by uname() when asked just for a short name of a host. This may > >> also be wrong, when uname is set to one value, but in /etc/hosts > >> (or elsewhere) the "canonical" name is different. This is often > >> the case for localhost entry in /etc/hosts: > >> > >> 127.0.0.1 localhost myname > >> > >> With this content of /etc/hosts, and uname being set to myname, > >> busybox hostname -s will return localhost, while regular > >> hostname utility returns myname. > >> > >> Fix this by not calling gethostbyname() for the simple `hostname -s' > >> use. > [] > > Hi, > > I cannot reproduce the case you show with busybox hostname > > and /etc/hosts on debian 7: > > Interesting. Debian7 is exactly the system where I had issues with > original implementation: > > $ uname -n > gandalf > $ head -n1 /etc/hosts > 127.0.0.1 localhost gandalf > $ hostname -s > gandalf > $ busybox hostname -s > localhost > $ cat /etc/debian_version > 7.2 > $ _ > > _My_ /etc/hosts actually has the first line like this: > > # list real hostname first localhost second or else busybox return wrong name > 127.0.0.1 gandalf localhost > > and it is dated Sep-2010, so the comment should be from 2010 or before. > I changed it like shown above for this test. > > Today I discovered the same issue within a freshly installed debian system > in a virtual machine, the generated /etc/hosts had similar line > > 127.0.0.1 localhost debian Hi, looks exatcly like mine.
> > which resulted in busybox testsuite to fail (hostname-s-works failure due to > busybox returning localhost while system hostname returns debian). This > failure prompted me to try to fix this finally. Didn't use the testsuite, but results were different. The problem is confirmed by the other example. > The thing is that busybox hostname calls gethostbyname() on the > result of uname() call, while system hostname doesn't do this. But the patch > shows it too. > > > Even modifying /etc/hosts makes no difference: > > > > So now I'm wondering where "(or elsewhere)" could be? > > Well, I don't know what's wrong with our systems.. ;) > > > > BTW.: It is better if you attach patches as my or your email client > > ate the tabs and the patch doesn't apply cleanly. > > Almost always when someone sends patches as attachments, people > complain saying it is better to send patches inline. It really > is easier to reply to inline-patches adding comments to particular > place in the patch, and here I agree too - it is better to send > patches inline. I usually send both, inline for review and attached to preserve TABS etc. > My client can't ate tabs, -- it is more, I see the tabs in your > reply exactly as they were in my initial email. I used > /usr/sbin/sendmail directly to send my initial email ;) So the culprit is Kmail's copy and paste.... > I just tried saving the patch (whole my email) from thunderbird > to a temp file and applying it - it applies cleanly to both > 1.21 version and current git head. Patch utility strips CRs > when applying, but that's typical. > > Thanks, > > /mjt > Ciao, Tito _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
