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.

  • 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. – Parthian Shot Jul 22 '15 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 '15 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... – Parthian Shot Jul 23 '15 at 0:22
  • 1
    @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 '15 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 '15 at 1:07

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.