There are several realpath
commands around.
The realpath
utility is a wrapper around the realpath
library functions and has been reinvented many times.
Debian used to maintain a realpath
package (separated from dwww
since woody) which hasn't changed except regarding packaging and documentation since 2001, but has now been phased out. This utility was deprecated because there are now more standard alternatives (GNU readlink
and soon GNU realpath
), but at the time, GNU utilities didn't even have readlink
at all. This implementation of realpath
supports a few options
to prevent symbolic link resolution or produce null-terminated output.
BusyBox also includes its own realpath
command (which takes no option).
GNU coreutils introduced a realpath
command in version 8.15 in January 2012. This is a compatible replacement for BusyBox's and Debian's realpath
, and also has many options in common with GNU readlink
.
realpath
has the same effect as readlink -f
with GNU readlink
. What distinguishes the two commands (or rather the various realpath
commands from readlink -f
) is the extra options that they support.
GNU realpath
is not deprecated; it has the opposite problem: it's too new to be available everywhere. Debian used to omit GNU realpath
from its coreutils
package and stick with its own realpath
. I don't know why, since GNU realpath
should be a drop-in replacement. As of Debian jessie and Ubuntu 16.04, however, GNU realpath
is used.
On Linux systems, at the moment, your best bet to canonicalize a path that may contain symbolic links is readlink -f
.
BSD systems have a readlink
command, with different capabilities from GNU readlink
. In particular, BSD readlink
does not have an option to canonicalize paths, it only traverses the symlink passed to it.
readlink
, incidentally, had the same problem — it was also invented many times (not adding this utility when symbolic links were added to Unix was a regrettable omission). It has now stabilized in several implementations with many incompatible flags (in particular BSD vs. GNU).
The /sys
filesystem (sysfs) contains files that provide information about devices: whether it's powered on, the vendor name and model, what bus the device is plugged into, etc. It's of interest to applications that manage devices.
The /dev
filesystem contains files that allow programs to access the devices themselves: write data to a serial port, read a hard disk, etc. It's of interest to applications that access devices.
A metaphor is that /sys
provides access to the packaging, while /dev
provides access to the content of the box.
The files in /sys
are not device nodes, but symbolic links and regular files. Those regular files are special in that reading or writing to them invokes file-specific functions in the kernel, like device nodes. The difference is that files in /sys
work this way because of the filesystem they are on, whereas device nodes work this way due to their device node characteristics (the file type indicating a (block or character) device, and the device major and minor number indicating which device it is).
The reason for /dev
existing independently of /sys
is partly historical: /dev
dates back to the dawn of Unix, while /sys
is a much more recent invention. If Linux was designed today with no historical background, /dev/sda
might be /sys/block/sda/content
.
Best Answer
ifconfig
is fromnet-tools
, which hasn't been able to fully keep up with the Linux network stack for a long time. It also still usesioctl
for network configuration, which is an ugly and less powerful way of interacting with the kernel.A lot of changes in Linux networking code, and a lot of new features aren't accessible using
net-tools
: multipath routing, policy routing (see the RPDB).route
allows you to do stupid things like adding multiple routes to the same destination, with the same metric.Additionally:
ifconfig
doesn't report the proper hardware address for some devices.ipip
,sit
,gre
,l2tp
, etc. in-kernel static tunnels.tun
ortap
devices.net-tools
either.See also
ifconfig
sucks.EDIT: Removed assertion about
net-tools
development ceasing that by now I forgot where I got for this post.net-tools
' has been worked on sinceiproute2
was released, though it's mostly bug fixing and minor enhancements and features, like internationalization.