"hostname -I" should be "hostname -i"?

[GoogleCodeExporter]

using ash 0.5.r .r158 on arch linux i get the following error message:

/bin/hostname: invalid option -- 'I'
Try 'hostname --help' or 'hostname --usage' for more information.

changing the GetHostIp() function in unix.py (line 49) from "hostname -I" to 
"hostname -i" fixes the problem for me...

Original issue reported on code.google.com by gsteed...@talkthree.com on 18 Apr 2013 at 2:49

[GoogleCodeExporter]

From the hostname man page in Ubuntu:

       -I, --all-ip-addresses
              Display   all   network  addresses  of  the  host.  This  option
              enumerates all configured addresses on all  network  interfaces.
              The   loopback  interface  and  IPv6  link-local  addresses  are
              omitted. Contrary to option -i, this option does not  depend  on
              name  resolution. Do not make any assumptions about the order of
              the output.

So, if you have a --all-ip-addresses flag, this is what you probably want.  I'm 
not sure if / when the arch linux hostname command will get -I, but -i is 
probably not ideal.

On my machine, hostname -i gives me the IPv4 loopback address - this is not 
really useful information.

That being said, I can look into making the method for finding the host IP 
address configurable.

Original comment by carl.and...@gmail.com on 23 Apr 2013 at 3:56

[GoogleCodeExporter]

thanks for that.

it seems that Arch uses GNU hostname (from GNU inetutils:
http://www.gnu.org/software/inetutils/manual/inetutils.html#hostname-invocation)
which has fewer options than debian hostname...

Original comment by gsteed...@talkthree.com on 23 Apr 2013 at 4:16

[GoogleCodeExporter]

I'm sure there is a more pythonic way to get the ip addresses of the current 
machine - I was being lazy and thought hostname -I was a safe bet.  I'll see if 
I can't figure it out and submit a change soon.

Oh, and the C++ version may work for you in the meantime.

Original comment by carl.and...@gmail.com on 23 Apr 2013 at 11:02

[GoogleCodeExporter]

So, the obvious thing to try is:
  you@yourhost:~$ python
  >>> import socket
  >>> socket.gethostbyname(socket.gethostname())
  '123.45.67.8'

If this works, this is one way easy way to do it.

Otherwise, this method looks promising:
http://stackoverflow.com/a/9267833

Original comment by carl.and...@gmail.com on 23 Apr 2013 at 11:15

[GoogleCodeExporter]

works for me fwiw... might be easier to maintain since it's one less
dependency...

Original comment by gsteed...@talkthree.com on 24 Apr 2013 at 1:54

[GoogleCodeExporter]

I have scrapped the idea of using fcntl to parse devices.  Instead I'm scraping 
the information I want from ifconfig.

I've loosely tested this on OSX and Ubuntu Precise.

If you have a chance, please check out the head and see if it works for you.

Original comment by carl.and...@gmail.com on 30 Apr 2013 at 7:01

[GoogleCodeExporter]

fwiw, ifconfig is deprecated in Arch, though it is available in the package
net-tools. /usr/sbin/ip is installed by default... equivalent usage is "ip
addr" or "ip a"

iirc fedora does something similar

might be wise to test for /sbin/ifconfig rather than assume it's available?
if it helps, i can provide a patch to make subprocess use ip if it can't
find ifconfig & then parse out the ip & mac addresses. let me know

here's some background in case it's useful:

https://www.archlinux.org/news/deprecation-of-net-tools/
http://blog.timheckman.net/2011/12/22/why-you-should-replace-ifconfig/

Original comment by gsteed...@talkthree.com on 30 Apr 2013 at 7:42

[GoogleCodeExporter]

I am using the python version on Mac OS X and also noticed that "hostname -I" 
doesn't work.  I am attaching a patch that lets the user pass in a command to 
use to determine the host IP.  That workaround was good enough to get me going.

Original comment by laura.be...@gmail.com on 7 Jun 2015 at 1:42

Attachments:

• unix_py_patch
• ash_conf_patch

[GoogleCodeExporter]

This patch is obviated by changes that are currently only in the subversion 
code, not in the "release" tarball. If you try the latest code it should 
hopefully work.

Also, since there seems to be zero activity by the project owner here I've 
exported this to github and I'm trying to pull in fixes for at least some of 
these issues - the repository is at 
https://github.com/sjjf/advanced-shell-history.

Simon

Original comment by sjjfow...@gmail.com on 21 Jul 2015 at 1:08