\ls will also bypass any alias set and run the program with its defaults. \ls is the same as running /usr/bin/ls (or whatever program you need to run without an alias).
ls and dir are separate programs that behave similarly. As explained and referenced below, the purpose of dir is to provide a command like ls whose output does not vary depending on whether or not it is going to a terminal. To achieve this helpfully, dir must format its output in a way that is reasonable and useful both for viewing in a terminal and for writing to a file or pipe. There are two common misconceptions about dir: Many people believe dir is an alias of ls, but that is not the case. Neither command is an alias of the other, and by default in Ubuntu, dir is not an alias at all. ls and dir are provided by separate, non-identical executables. Many people believe dir exists for obscure historical reasons or to provide compatibility with some standard or some other OS. That is not the case either. ls behaves the way it does for compatibilty. dir, which doesn't have to be compatible because it's not a standard Unix command, behaves in an alternate way that the developers consider valuable in its own right and possibly even preferable. OK, but exactly how do ls and dir differ? Both ls and dir list the contents of directories. Two specific differences in their default behaviors distinguish them. When its standard output is a terminal, ls lists filenames in vertically sorted columns (like ls -C). When its standard output is not a terminal (for example, a file or pipe), ls lists filenames one per line (like ls -1). Whether or not its standard output is a terminal, dir lists filenames in vertically sorted columns (like ls -C). For both ls and dir, these defaults may be overridden by the --format= flag and by the -1, -C, -m, and -x flags, which abbreviate particular --format= options. See 10.1.4 General output formatting in the GNU coreutils reference manual for details. When its standard output is a terminal and a filename to be listed contains control characters, ls prints ? instead of each control character (like ls -q). When its standard output is not a terminal, ls prints control characters as-is (like ls --show-control-chars). Whether or not its standard output is a terminal, when dir encounters a control character or any other character that would be interpreted specially if entered into a shell, it prints backslash sequences for the characters. This includes even relatively common characters like spaces. For example, dir will list an entry called Documents backups as Documents\ backups. This is like ls -b. For both ls and dir, these defaults may be overridden by the flags listed in 10.1.7 Formatting the file names in the GNU coreutils reference manual. This includes -b, -q, --quoting-style=, and some others. Sources: ls invocation and dir invocation, in the GNU coreutils reference manual. Why have dir? The rationale for a separate dir utility is given in 4.5 Standards for Interfaces Generally of the GNU coding standards. I recommend reading that whole section to understand the developers' reasoning, but here are the highlights as applicable to ls/dir: Please don’t make the behavior of a utility depend on the name used to invoke it.... Instead, use a run time option or a compilation switch or both to select among the alternate behaviors.... Likewise, please don’t make the behavior of a command-line program depend on the type of output device.... Compatibility requires certain programs to depend on the type of output device. It would be disastrous if ls or sh did not do so in the way all users expect. In some of these cases, we supplement the program with a preferred alternate version that does not depend on the output device type. For example, we provide a dir program much like ls except that its default output format is always multi-column format. The GNU Project considers it undesirable, from a technical perspective, for a utility to produce different output depending on what kind of device it is writing to (at least in the utility's default configuration). For some utilities, including ls, device-dependent output is necessary for compatibility and so it works the way users expect. Some users do also specifically prefer this device-dependent behavior. While ls could not reasonably be written to behave device independently, a separate dir utility was created to achieve this. Thus dir is not the utility that behaves strangely for reasons of historical compatibility--ls is.
I never used id until I had to use a compute cluster that strictly limited disk quota by group! Now I run id -gn pretty often to make sure I'm in the right group before submitting calculations.
The `ls` command came before the `dir` command. The `ls` command has its origins in the early 1960s, specifically in the Compatible Time Sharing System at MIT, where it was originally called `listf`. By 1963, `listf` had several options and was later renamed to `list`, which could be abbreviated to `ls` when it was implemented in Multics. When Bell Labs began Unix development in 1969, the `ls` command was retained and documented in the First Edition Unix manual by 1971.
I have used the dir command mostly by accident, after spending some time in my company's computer running Windows and switching back to my personal Linux box, so sometimes the muscle memory of my fingers just type "dir" instead of "ls" or "ll", which reminds me that I am back at home in my lovely terminal and not in cmd or powershell (the opposites also happens, trying desperately to list the contents of a Windows directory by using ll or ls)
I just used dir to list my files without formatting in my hibernated windows partition, mount mounted them all as read-only and I couldn't actually read the names with it due to the read-only highlight colour. I don't know enough about ls, but dir was a quick workaround!
Hi DT! I thought that EXA was the name of the command you reference from the 'ls' alias? Did the project change names or is EZA another project? Thanks and great video!
I use `id` in some scripts. And I regularly use `cal` or `ncal` just because I don't want to open large app like Thunderbird or something. `ncal -M -A 2` gives me current month + 2 consequent months with weeks starting from Monday.
I'm weird. I use dir all the time and rarely use ls. I was used to dos at work before I started playing with Linux and it just stuck. I have dir aliased as dir -alh --color=always
The output of dir on regular bash is not very pretty, so definitely not using it. For cal I use ncal -b, as it gives me the month , the name of the month, and weeks starting on Monday. For id, I usually use whoami or who, both very useful. command and type also very useful.
I come from a long background of MS-DOS and Windows. I don't bother w/ the linux DIR command but due to that background, I alias dir to ls -lah. I am going to have to play around with esa though. Interesting tool.
they're default aliases to commads like Get-Items or something like that, so i'm pretty sure flags don't work remotely the same, so i probably wouldn't call it "support".
1) Neither "dir" nor "vdir" look much at all like what the standard output of "dir" used to look like on DOS or looks like on Windows, so if that was the purpose, they've failed pretty hard IMO. 2) Why on Earth do you spell it out in speech, in stead of just pronouncing "dir" as a word? It's not like it's an acronym, you know.
