What's best way to extract file names from a folder?

[xan]

If I have many files in a folder is there a good way to get all the file names, dates and sizes into a text file?

I don't have any background using Linux so only know basic commands.

Best I have figured out so far is:
ls --color -gGh

but there must be a better way.

[nic007]

If I have many files in a folder is there a good way to get all the file names, dates and sizes into a text file?

I don't have any background using Linux so only know basic commands.

Best I have figured out so far is:
ls --color -gGh

but there must be a better way.

I'm sure someone will give you the complete solution for all file attributes but you can quickly get a list of the file names and sizes. Using ROX, click on the folder and then select all files. Right-click and chose count from menu. You can copy the result to a text editor.

[Burn_IT]

In Windows it would be:
DIR x:\folder -> y:\dir.TXT

I assume the redirection is available in Puppy as well (I'll try next time I'm at home)

[Karl Godt]

Code: Select all

for i in * ; do stat -c %n' '%s' '%x' '%y' '%z $i  >>files_stats.text; done

[L18L]

... into a text file?...

> textfile

Code: Select all

ls -la > textfile

[amigo]

It's not really a good idea to use ls to list files -it will not work if there are spaces in any of the names. The expansion of '*' by the shell does work accurately though, and saves an external call.

[MochiMoppel]

It's not really a good idea to use ls to list files -it will not work if there are spaces in any of the names.

??? Seems to work nicely. It's Karl's code that has problems with spaces.

[musher0]

Hello, xan.

Basically, you're very close. I would suggest the following:

For a screen by screen listing:

Code: Select all

ls --color -og ~ | more

This retains the color coding for the file types. The "-og" parameters
create a semi-long listing. It's like the "-la" parameters, but without the
two "ownership" columns.

For a file listing:

Code: Select all

ls --color=never -og ~ > files.lst

In addition to the above, the "--color=never" parameter removes all
color coding. In a file, color codings make the listing difficult to read,
because they incorporate the "Escape" color codes in the file.

Of course, you would change the wiggle "~" (which is bash short-hand
for "/root") to your desired folder -- or omit it altogether if you only
want the listing for the directory you are already in.

Another example. If you want a listing of all folders and files in your /root
folder, the command would be, assuming that you are already in /root:

Code: Select all

ls --color=never -og * > all-files.lst

Afterwards, if you want to easily read back and forth through the file to
see what files and folders you have, you could issue the command:

Code: Select all

less all-files.lst

You then use "G" or "g" to go to the bottom or the top of the text file,
"u" or "d" to go up or down. You'd press "F1" for the less help file, which
will suggest to you some other letters for browsing through your file.

As a reminder, if you just want a one column listing, with only the file
name, the parameter is

Code: Select all

ls -1

(The number, "1"; not the letter, "l".)

I hope this helps.

Best regards.

musher0

[xan]

Code: Select all

ls --color -og | more

Thanks for all the suggestions people.

Is there a way to omit the permissions column from the results?

I found a suggestion to use awk but I don't understand it and it doesn't handle spaces in file names.

Code: Select all

ls --color -ogh | awk '{ print $3, $4, $6 }'

[6502coder]

To omit the permissions fields, try

Code: Select all

ls  --color  -ogh  | cut  --characters=11-

[musher0]

To omit the permissions fields, try

Code: Select all

ls  --color  -ogh  | cut  --characters=11-

Personally, I'd go with:

Code: Select all

ls --color -ogh | cut -d" " -f3-12

It starts with the size and includes the target of the links as well.

But, this is obviously fine-tuning.

BFN.

musher0

[MochiMoppel]

It starts with the size and includes the target of the links as well.

But for no obvious reasons - like in your screenshot - includes year instead of time on some files:

Code: Select all

4.0K Aug  2  2011 pup_420
4.0K Oct  4 12:09 pup_lazy
4.0K Jul 12  2012 pup_lucid528
4.0K Oct  1 11:06 pup_precise
4.0K Aug 21 11:34 pup_raring

[musher0]

It starts with the size and includes the target of the links as well.

But for no obvious reasons - like in your screenshot - includes year instead of time on some files:

Code: Select all

4.0K Aug  2  2011 pup_420
4.0K Oct  4 12:09 pup_lazy
4.0K Jul 12  2012 pup_lucid528
4.0K Oct  1 11:06 pup_precise
4.0K Aug 21 11:34 pup_raring

Hello, MochiMoppel.

Thanks for your input.

I noticed that too. It seems to be coded in the "ls" program.
Maybe if it's the current year, it indicates the time?
It's the only logic I see at present.

BFN.

musher0

[MochiMoppel]

It's the only logic I see at present.

You see logic?

Here some more ideas

Code: Select all

find /root/ -maxdepth 1 -printf "%TY-%Tm-%Td %TH:%TM\t%s\t%h/%f\n"
2013-10-10 16:32	520	/root/root/
2013-10-10 14:09	799	/root/list
2013-10-10 14:06	25	/root/tmp.txt
2013-10-10 11:20	60	/root/.macromedia
2013-10-10 11:20	60	/root/.adobe
2013-10-10 11:17	23347	/root/.jwmrc
2013-10-10 11:17	23347	/root/.jwmrc-previous
2013-10-10 11:18	160	/root/.wine
2013-10-10 11:17	80	/root/.packages

Can't display just seconds, it's always split seconds:

Code: Select all

find /root/ -maxdepth 1 -printf "%TY-%Tm-%Td %TH:%TM:%TS\t%s\t%h/%f\n"
2013-10-10 16:32:55.8519607360	520	/root/root/
2013-10-10 14:09:29.8225191960	799	/root/list
2013-10-10 14:06:46.0334179900	25	/root/tmp.txt
2013-10-10 11:20:42.3953408790	60	/root/.macromedia
2013-10-10 11:20:42.3386745240	60	/root/.adobe
2013-10-10 11:17:59.3995686430	23347	/root/.jwmrc
2013-10-10 11:17:52.5662728070	23347	/root/.jwmrc-previous
2013-10-10 11:18:35.8527019420	160	/root/.wine
2013-10-10 11:17:53.5096009640	80	/root/.packages

Getting rid of the split seconds:

Code: Select all

find /root/ -maxdepth 1 -printf "%TY-%Tm-%Td %TH:%TM:%TS\t%s\t%h/%f\n" | sed 's/\.[0-9]*//'
2013-10-10 16:32:55	520	/root/root/
2013-10-10 14:09:29	799	/root/list
2013-10-10 14:06:46	25	/root/tmp.txt
2013-10-10 11:20:42	60	/root/.macromedia
2013-10-10 11:20:42	60	/root/.adobe
2013-10-10 11:17:59	23347	/root/.jwmrc
2013-10-10 11:17:52	23347	/root/.jwmrc-previous
2013-10-10 11:18:35	160	/root/.wine
2013-10-10 11:17:53	80	/root/.packages

There must be easier ways ...

[musher0]

MochiMoppel,

If you have complaints about how find or ls performs, the best way
is to address them to the respective author(s). This is not the place.

Regards.

musher0

[MochiMoppel]

I have no complaints and I didn't complain. Find works nicely and though ls looks odd to me and I was wondering how this might be useful, I don't see this as a "complaint". I know now this behaviour can be changed, that it depends on the version and is an intended feature (files older than 6 months can be displayed with a different time format).

Unfortunately Puppy uses different versions of ls (Lucid uses 7.4, Precise 8.13 etc.). They differ in their defaults (7.4 uses time-style=long-iso, 8.13 time-style=locale) which makes it difficult to propose a short command as I don't know the OP's Puppy version. Bottomline: Parameters should be explicitly set and not taken for granted.

To omit the permissions column from the results: Cut doesn't work reliably. The last column seems to be the number of first-level subdirectories, which may be more than 9, in which case the number of space delimiters may increase...
I would still go with sed here. It's much more flexible.

Proposal:

Code: Select all

ls --color=never --group-directories-first  --time-style=long-iso  -Aogp  | sed 's/^[^0-9]*[0-9]* //'

[amigo]

Karl was nearly right -except for not double-quoting the file name:

Code: Select all

for i in * ; do stat -c %n' '%s' '%x' '%y' '%z "$i"  >>files_stats.text; done

ls will definitely fail when there are spaces in paths -but I think it's always been a will-not-fix sort of feature/bug for the authors. Anyway, using shell globbing (*) is more efficient. Using stat is straightforward, but you could conceivably us ls for it there -just for one file at a time. Uh, don't forget to doublequote the file name LOL.

You could even use a tar pipeline to generate the info. But, the output from both tar and ls will still need parsing to cull out unwanted items. stat gives finer control.

What's the fastest way? Time them if you like. The real issue is that it work right and be available on the target system. Another drawback to using 'ls' is the differing features among implementations. If you use advanced options which work with ls from coreutils, it may not behave the same using ls from busybox, toybox or whatever.

If your really a compatibility freak, then stat is not the way either, as it is linux-only.
Practically speaking, using stat is the cleanest way to get the, well, stats of each file. And using builtin globbing is faster than call find, ls or whatever. However, there is a caveat for the above code -in the case of an empty directory, where ls would return nothing, globbing will return a '*'. So, it must be eliminated -which needs an extra step.

Code: Select all

for i in * ; do
 case "$i" in
  *'*') : ;;
  *)
   stat -c %n' '%s' '%x' '%y' '%z "$i"  >>files_stats.text
  ;;
 esac
done

[musher0]

Hi, MochiMoppel.

Yours may not be an "official" complaint. However, the shortcomings
would not have been exposed on this thread if there was not a feeling of
some kind of dissatisfaction about the lack of a standard on the subject of
reporting file sizes.

It is certainly laudable to come up with expert suggestions here on how to
overcome those shortcomings, -- and we can continue doing so until the
cows come home --, but the fact will remain that we have no control on
the next versions of either ls or find. So, how do we draw the authors'
attention, if not by sending them some kind of "complaint"? Or "lament"?
Is "protest" too strong a word? Ok, maybe "a suggestion for
improvement" is a more positive expression.

I hope you see my point. In any case, my comments were never and are
not meant to be personal, far from it. English is not my native language;
please forgive me if some part of my previous post has lent itself to an
interpretation with that "tonality".

Best regards,

musher0