What's best way to extract file names from a folder?
What's best way to extract file names from a folder?
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 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.
Re: What's best way to exctract a file names from a folder?
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.xan wrote: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.
Code: Select all
for i in * ; do stat -c %n' '%s' '%x' '%y' '%z $i >>files_stats.text; done
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
Hello, xan.
Basically, you're very close. I would suggest the following:
For a screen by screen listing:
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:
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:
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:
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
(The number, "1"; not the letter, "l".)
I hope this helps.
Best regards.
musher0
Basically, you're very close. I would suggest the following:
For a screen by screen listing:
Code: Select all
ls --color -og ~ | more
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
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
see what files and folders you have, you could issue the command:
Code: Select all
less all-files.lst
"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
I hope this helps.
Best regards.
musher0
- Attachments
-
- color_never.jpg
- (55.33 KiB) Downloaded 846 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Thanks for all the suggestions people.musher0 wrote:Code: Select all
ls --color -og | more
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 }'
To omit the permissions fields, try
Code: Select all
ls --color -ogh | cut --characters=11-
Personally, I'd go with:6502coder wrote:To omit the permissions fields, try
Code: Select all
ls --color -ogh | cut --characters=11-
Code: Select all
ls --color -ogh | cut -d" " -f3-12
But, this is obviously fine-tuning.
BFN.
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
But for no obvious reasons - like in your screenshot - includes year instead of time on some files:musher0 wrote:It starts with the size and includes the target of the links as well.
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.MochiMoppel wrote:But for no obvious reasons - like in your screenshot - includes year instead of time on some files:musher0 wrote:It starts with the size and includes the target of the links as well.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
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
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
You see logic?musher0 wrote:It's the only logic I see at present.
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
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
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
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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:
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]* //'
Karl was nearly right -except for not double-quoting the file name:
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 stat -c %n' '%s' '%x' '%y' '%z "$i" >>files_stats.text; done
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
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
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
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)