Page 1 of 1
What's best way to extract file names from a folder?
Posted: Thu 03 Oct 2013, 09:02
by 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.
Re: What's best way to exctract a file names from a folder?
Posted: Thu 03 Oct 2013, 10:12
by nic007
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.
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.
Posted: Thu 03 Oct 2013, 11:30
by 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)
Posted: Thu 03 Oct 2013, 11:39
by Karl Godt
Code: Select all
for i in * ; do stat -c %n' '%s' '%x' '%y' '%z $i >>files_stats.text; done
Re: What's best way to exctract a file names from a folder?
Posted: Thu 03 Oct 2013, 12:05
by L18L
xan wrote:... into a text file?...
> textfile
Posted: Sat 05 Oct 2013, 07:33
by 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.
Posted: Sat 05 Oct 2013, 09:22
by MochiMoppel
amigo wrote: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.
Posted: Sat 05 Oct 2013, 19:43
by musher0
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:
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:
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
Posted: Sun 06 Oct 2013, 02:33
by xan
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 }'
Posted: Sun 06 Oct 2013, 04:03
by 6502coder
To omit the permissions fields, try
Code: Select all
ls --color -ogh | cut --characters=11-
Posted: Sun 06 Oct 2013, 15:51
by musher0
6502coder wrote: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
Posted: Thu 10 Oct 2013, 03:05
by MochiMoppel
musher0 wrote: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
Posted: Thu 10 Oct 2013, 03:28
by musher0
MochiMoppel wrote:musher0 wrote: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
Posted: Thu 10 Oct 2013, 09:38
by MochiMoppel
musher0 wrote: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 ...
Posted: Thu 10 Oct 2013, 16:10
by 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
Posted: Mon 14 Oct 2013, 07:03
by 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]* //'
Posted: Mon 14 Oct 2013, 08:11
by 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
Posted: Wed 16 Oct 2013, 03:38
by 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