Formatted Directory Listing Question

Greetings to you. I have a quick question for the community today

I'm interested in the following format for recursive output from a command such as "ls" or "dir" when pointed to a folder:

...but there doesn't seem to be coverage for this type of output formatting in the manpages.

Maybe this is something "everyone just knows," and I missed the meeting?

Any ideas as to how this would look/work?

Thanks!

Hello LinQ,

You can use find -type f will help you to get the filenames in the recursive way. You can read in man find about maxdepth option too for same, if in case you need to fix the directories levels.

Thanks,
R. Singh

try
If you want files only

find $PWD -type f

If you want files and directories

find $PWD

If you want directories only

find $PWD -type d

Thanks so much folks!

REALLY CLOSE, but output formatting is still a bit of an issue...

Here's the output which seems to be required:

...and here's what

find | sort

gives:

:rolleyes:

I tried a couple of "tricks", but can't get anything to tick over...
(ugh)

Any thoughts as to what can be turned to pop this out?

Thanks again!

Hello LinQ,

If you want to get rid of . in results then, you can try following.

find `pwd` -type f

NOTE: This solution is only for finding files, you can make changes accordingly like if you want to look for directories or any specific files.

Thanks,
R. Singh

@RavinderSingh13:

Thanks but, unfortunately, -type doesn't take care of the leading periods issue (as tested on a couple of different Linux flavors); and the improperly-formatted first directory listing remains a problem in any case...

FWIW, (a hint, perhaps?) the formatting sought is also used by Debian when the package manager creates *.list files for installed programs

Thanks again --

---------- Post updated at 03:32 PM ---------- Previous update was at 02:20 PM ----------

This works for part of the problem:

find | sed s/.// | sort

...but the first line of the output still needs to be corrected.

Is there a way of piping this through another filter to put in the required /. @ the beginning of the output?

:rolleyes:

---------- Post updated at 03:40 PM ---------- Previous update was at 03:32 PM ----------

Back again.

echo /.; find | sed s/.// | sort

almost has it licked; but now we have a blank line left behind by sed:

???

---------- Post updated at 03:55 PM ---------- Previous update was at 03:40 PM ----------

Finished:

echo /.; find | sed s/.// | grep -v ^$ | sort

Thanks again, all

find -depth has almost the right output, but since it can't know it's done a folder until it's printed all its contents, does so backwards -- the folder contents first, then the folder itself.

So pipe it through tac and edit the first line to have a dot.

find / -depth | tac | sed 's/\/$/&./'

@Corona688:

Interesting! But it's not exactly a tame little monster; as it output the entirety of my drive: No limits.

A bit startling to see the commandline rummaging the whole disk for more than a minute. A real shock as visions of dd danced through my head --

But, no harm seems done.

Thanks again for dropping in...

It does exactly what you asked for, yes.

find /path/to/subfolder/ ... if you actually wanted less

Note the / after subfolder is important. find doesn't care, but the resulting text will look slightly different without it, ruining your character-perfect output.

@Corona688:

Curious!

Was wondering why find | ... seemed content with just moseying over to recurse whatever is on the dir with it. Thought your find / -depth | ... was indicative of yet another syntactical secret handshake which seems to permeate the bash world...

So, is my syntax correct as find | ... to simply rummage the folder(s) on the immediate dir, or does convention call for a different approach? If OK, would running your snippet with find -depth | ... fit the bill for a quick recurse through local folders only?

:rolleyes:

---------- Post updated at 08:57 PM ---------- Previous update was at 05:49 PM ----------

O -- one more quick question:

I've seen sed parameters both quoted and not in a pipe context. Both seem to work well... Is there a governing convention for this?

Thanks again --

The standard syntax for the find utility requires one or more pathname operands. Some implementations of find provide a pathname operand of . if you do not supply any pathname operands.

If there are any whitespace characters in your sed parameters or any other characters that have a special meaning in the shell, you have to quote those characters to keep the shell from modifying them before passing those parameters to sed .

The same reason 'ls' is, I suppose. That's what it's there for.

There are no secret handshakes. find is an external command like everything else.

Sure.