10

After installing Debian 8, I started poking around /bin (as I'm always wont to do), and I noticed that ls and vdir share, not only the same manpage (except for the whatis line), but the exact same compiled size. The only thing they don't have in common is the inode number (which seems inefficient, but that's tangential).

Is there any reason for this? What's the historical precedent? Why would we want to have both?

I'd never ever heard of vdir before today, so it can't be immensely common, and it seems like it should be easy to simply have vdir be a script that calls ls with the correct arguments.

13
  • 1
    @mikeserv I hadn't thought to (the last time I read an info page was at least three years ago), but on running it I got "‘vdir’ is equivalent to ‘ls -l -b’; that is, by default files are listed in long format and special characters are represented by backslash escape sequences." Still doesn't explain the reasoning behind having it. In fact, that explanation appears to argue against having it, since it is functionally equivalent to an existing app, yet it's an additional 118280 bytes. Jul 22, 2015 at 23:32
  • 1
    Sure it does. ls -l -b is ambiguous if ls doesn't understand the -b option. It might even return successfully if the file -b exists in the current directory. The command vdir is a self-contained command, though, and so if you are writing a GNU-dependent script which depends on that stuff, vdir is a more simple thing for which to test. That it is an extra 118k probably speaks more to a lazy packager tthan otherwise. coreutils can be compiled as a single binary - the lot of them.
    – mikeserv
    Jul 22, 2015 at 23:39
  • 1
    @saiarcot895 True, but what does an actual non-linewise diff give? One important property of crypto hashes is that they cascade; a small change in input results in a large number of output bit flips. A fuzzy hash, OTOH... Jul 23, 2015 at 0:22
  • 2
    @mikeserv There's no way that any well-behaved utility would interpret an unrecognized option as an argument, so any ls implementation that did not recognize -b would produce an error, not a listing for the file ./-b, if that option were given.
    – Celada
    Jul 23, 2015 at 1:04
  • 2
    @saiarcot895 cmp -l is more useful than sha*sum for cases like this. Not much point bothering with hashes when you can just compare directly, and you get a complete list of the differences as a bonus, which the OP was interested in seeing. By the way, those byte-by-byte differences aren't many!
    – Celada
    Jul 23, 2015 at 1:07

1 Answer 1

8

Most likely, for historical reasons and/or backward compatibility.

It's part of the GNU core utilities package, so it'll be around until Richard Stallman et al feel it's necessary to purge it from existence.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .