Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In Linux, is there an equivalent to Dir /s /a /b where the full path and filename is listed? I'm new to Linux, and without a GUI, I want to get an idea of the structure of what's on the hard disk.

share|improve this question
up vote 8 down vote accepted

Use the find command. By default it will recursively list every file and folder descending from your current directory, with the full (relative) path.

If you want the full path, use: find "$(pwd)".

  • If you want to restrict it to files or folders only, use find -type f or find -type d, respectively.
  • If you want it to stop at a certain directory depth, use find -maxdepth 2, for example.

Read Finding Files for an extensive manual on GNU find, which is the default on Linux.

share|improve this answer
Thank you very much. Can you briefly describe what $(pwd) is actually instructing? – Luke Puplett Jan 3 '13 at 12:29
pwd is your working directory. Type it into console and you'll see where you are (useful if your prompt doesn't tell you). – mcalex Jan 3 '13 at 12:41
@LukePuplett pwd will print your current working directory. If you enclose a command with $(), its output (i.e. your working directory) will be substituted before the outer command is run. So find will actually not see find $(pwd), but find /home/luke/, for example. This is called command substitution. – slhck Jan 3 '13 at 12:41
You probably meant the second example in the first bullet point to be find -type d (d for directory). At the moment the two are identical. (And I don't have the rep to make "trivial" edits here at SU.) – Michael Kjörling Jan 3 '13 at 12:56
@MichaelKjörling Indeed. Thank you for pointing out that typo. – slhck Jan 3 '13 at 12:57

For completeness, the ls -lR / command will list the name of each file, the file type, file mode bits, number of hard links, owner name, group name, size, and timestamp of every file (that you have permission to access) from the root directory down. (l is for long list ie all that info, R is to recurse through directories, / starts at the root of the filesystem.)

There are a number of params to make the output info closer to dir /S /A, but I have to admit I can't work out how to translate the /B.

For useful info, I would try: ls -lAFGR --si /


  • l = long list (as mentioned above)
  • A = almost all files (doesn't include . and .. in each dir, but does show all hidden files)
  • F = show file indicator, (one of * for exe files, / for directories, @ for symbolic links, | for FIFOs, = for sockets, and > for doors)
  • G = don't show group info (remove this if you want to see it)
  • R = recursively list directories (subdirectories) and
  • --si = show the file size in human readable eg 1M format (where 1M = 1000B)

ls can provide an easier to read synopsis of directories and files within those directories, as find's output can be difficult to scan when files are contained within really long directory structures (spanning multiple lines). The corollary is that each file is listed on its own (ie without directory path information) and you may have to go back a couple of pages/screens to find the directories a particular file is located in.

Also, find doesn't contain the /A information in the DIR command. I've suggested a number of attributes in the command I've shown (that coincidentally show the extra usefulness that you get from linux over a certain proprietary system), but if you read the man and info pages on ls, you will be able to see what to include or not.

share|improve this answer
Thanks for this extra detail. For all the switches, its the non default human-readable one which makes me laugh. – Luke Puplett Jan 3 '13 at 17:31
lol, why would you want to see file sizes in anything but bytes? – mcalex Jan 3 '13 at 17:37
Why would you want to parse the ls output? ;P (Okay, I'll stop now.) But seriously, @LukePuplett, it's been the default for *nix systems since non-human readable file sizes are easier to calculate with. – slhck Jan 3 '13 at 17:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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