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 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. 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. 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 ;) 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 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox