ifconfig(8) syntax intuitiveness

[Joseph Garcia]

Danial Thom wrote:
--- Joerg Sonnenberger <joerg at xxxxxxxxxxxxxxxxx>
wrote:

On Wed, Aug 24, 2005 at 03:26:17PM +0200, Erik
P. Skaalerud wrote:
Joseph Garcia wrote:

I was using ifconfig when it occurred to me
how non-intuitive it is

having to use 255.255.255.255 as the netmask
when adding an address

that is on the same subnet as an address
already on the interface. For

example, if you already have 192.168.0.1/24
on fxp0, then you should be

able to add the following address with this
command:

	ifconfig fxp0 add 192.168.0.2 netmask
255.255.255.0

instead of:

	ifconfig fxp0 add 192.168.0.2 netmask
255.255.255.255

I second this. I had problems with this when
I first used IP aliasing on 

FreeBSD long time ago because I had the wrong
netmask set. (/24 instead 

of /32).
It's not that easy. This has nothing to do with
the interface, but is a
restriction from the routing stack. Once that
restriction goes away,
there's no reason why aliases wouldn't allow it
too.

I second your thoughts about "delete". You
don't delete it, you remove it.

You delete the route.


I have another suggestion for ifconfig
aswell. Show netmaskes in human 

readable format (decimal) instead of HEX. I
mean, who really thinks 

about netmasks in HEX formats?
Me. Actually, decimal netmasks are *not* human
readable, because it is
much harder to determine the *binary* affect
they have.
Joerg


My opinion is, if you want to add another syntax,
fine, but leave the old syntax also, because even
though it may not seem intuitive, its familiar.
The same reasoning goes for not changing "grep"
to "search". Linux changed a lot of the ifconfig
syntax and its confusing to new users who are
familiar with something else, and it doesn't
improve the experience. Better to have one
arguably wrong syntax that 4 different ones that
are marginally more correct.
DT
Oh yeah, I definately wouldn't want to remove any of the old syntax 
because of the fact that doing so would most likely break scripts and 
what not. Also, people are used to using them.

Although, it wouldn't hurt to make *remove* the same as *delete* (make 
it a synonym) then maybe have a note in the man page saying that 
alias/-alias and delete are deprecated until people get used to using 
add/remove.

Then again, this actually isn't really a big deal since add/delete is 
okay. I don't mind too much if that was left alone. I only mentioned it 
because I thought it would make the utility more intuitive.

On the other hand, the 255.255.255.255 thing just doesn't seem right. I 
installed OpenBSD 3.8 Beta yesterday just out of curiosity. I was able 
to add two addresses on the same subnet with the following commands:

   ifconfig pcn0 inet 192.168.0.172 netmask 255.255.255.0 alias
   ifconfig pcn0 inet 192.168.0.19  netmask 255.255.255.0 alias
NOTE: OpenBSD doesn't sseem to like *add* instead of *alias*. Also, it 
seems that using *alias* doesn't work before the address family like it 
does in FreeBSD/DragonFlyBSD's ifconfig.

Here's some sample ouput of when I look at that interface afterwards:

   # ifconfig pcn0
   pcn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
           lladdr 00:0c:29:54:cf:00
           groups: egress
           media: Ethernet autoselect (autoselect)
           inet6 fe80::20c:29ff:fe54:cf00%pcn0 prefixlen 64 scopeid 0x1
           inet 192.168.0.19 netmask 0xffffff00 broadcast 192.168.0.255
           inet 192.168.0.172 netmask 0xffffff00 broadcast 192.168.0.255
NOTE: Seems like I don't need to type -a to show interface info anymore. 
When did that happen? I actually haven't used OpenBSD since 3.5 and this 
is 3.8 Beta.

Someone mentioned displaying the netmask in decimal form. I thought that 
would be a good idea. It would seem easier to read that way. I tend to 
think of numbers in decimal and not in hexadecimal, but that's just me. 
Although, that doesn't concern me as much as the netmask thing. Then 
again, if you have a funky netmask then maybe reading it in hexadecimal 
would be kinda tedious for those of us that don't naturally read 
hexadecimal.