A
Andy Burns
DIR /b C:\first\folder D:\second\folder | SORT > C:\results.txtMetspitzer said:
A
Andy Burns
You'll like my one-liner thenChar said:
P
Paul
Imagine what it would look like in assembler.Char said:
There are other ways to do it. But, the reason I wouldn't
bother posting them, is it would mean downloading a load of
little utility programs to make it happen. (The utilities
would be Windows ports of Linux/Unix programs.) I wanted
something monolithic Metz could use.
However, since this is a "contest", let's try the following.
All done in Windows. (Although I normally do this in Linux,
because all aspects of the command work properly, and the
thing isn't quite as clunky as this happens to run. The ports
barely hang together at times. I have to select my options
with care, on the Windows versions, to get them to run.)
*******
This one line, lists an entire tree and sorts it.
find C:\Downloads -type f -exec ls -al -1 {} ; | sort -t: -k3 > output44.txt
Programs used:
find.exe (http://gnuwin32.sourceforge.net/packages/findutils.htm)
ls.exe (http://gnuwin32.sourceforge.net/packages/coreutils.htm)
sort.exe (http://gnuwin32.sourceforge.net/packages/coreutils.htm)
How the command works:
Find, finds all files meeting the search criterion.
Setting -type f, means match on files and not directories. That
is to prevent directories from being listed. We only want a
file list here, a complete path for each one, so they can be
sorted.
The -exec, means to launch a separate program to handle the path
that find locates. The separate program is "listdir", a.k.a. "ls.exe".
ls -al is to get an output format, to list a fair amount of info about
a file, including the size field.
Much of the garbage emitted, doesn't make sense in a Windows environment
and it's more like noise here.
The {} ; as opposed to {} +, is to call "ls.exe" for each output.
While the {} + option is more economical, testing of the Windows port
with that option, led to a failure. So I had to back off to the less
efficient {} ; syntax.
The sort.exe command comes up next. The pipe symbol "|", pipes the output of
all the forked "ls.exe" commands, to the sort program.
The sort program is told to use ":" as a field separator. Let's take a line
of input to be sorted, to figure out why.
This is the output format, from each time that the "ls.exe" program runs.
White space can't be used as a field delimiter, because file names
can contain spaces. Since I know I'm listing "C:\" , I know I'll have
a colon character I can count on. By making the field separator
the colon character, that splits the line into three pieces. Everything
to the right of the C: colon, is "field 3" of the input line, and is the
thing we wish to sort on.
< ---------------- field #1 ----------------> #2 <---------------------- field #3 ---------------------------->
| |
| |
-rw-rw-rw- 1 User Name 0 32787 2009-10-30 06:29 C:\Downloads/VLC Media Player/vlc-1.0.3/plugins/liba52_plugin.dll
So when I do "sort -t: -k3", that chops the line in three pieces, at
the ":", then does a sort using field 3, in default sort order
(whatever that is). I could add other sort options, if need be.
The stuff on the left, is bogus, and is done by the authors of the
port to keep things consistent with Linux. (The "User Name" field, is my
Windows login name.) What we'd really want to keep, would be something like this.
I have ways I could fix this, on the same line, but doing so would
only obscure things.
Size <--- Date -----> <--------------------------- Name ------------------------------>
32787 2009-10-30 06:29 C:\Downloads/VLC Media Player/vlc-1.0.3/plugins/liba52_plugin.dll
Anyway, I don't think there's any point to dumping the entire listing. For
this example, it was around 4MB or so. The method is slow, because
each file encountered, needs "ls.exe" to run. The sort command, is
pretty fast (fraction of a second), so it contributes little to the
waiting time.
If it was desired to sort on the "size" field, that can be done too. Just
a matter of changing back to white space as a field separator, and
specifying -k 6.
Paul
D
Dave \Crash\ Dummy
Cool. I didn't say it couldn't be done with a batch file, just that IChar said:
couldn't do it. I abandoned batch files years ago and don't remember all
the tricks. I will just add one thing to your rendition. If the OP wants
to limit the files to a specific type. he could refine the sources thus:
d:\folder1\*.ext
d:\folder2\*.ext
D
Dave \Crash\ Dummy
Awesome! I will just add the same tip I posted for Char's batch file. IfAndy said:
the OP wants to limit the list to a specific type. he could refine the
sources thus:
C:\first\folder\*.ext D:\second\folder\*.ext
D
Dave \Crash\ Dummy
<snipped>Paul said:
Way too complicated. This will do the job with VBScript alone, but it is
still much more complicated than the batch files posted.
'========================================
dim fldrs(2)
fldrs(1)="d:\folder1"
fldrs(2)="d:\folder2"
ext="vid"
outputFile="d:\vidlist.txt"
dim filelist
set fso=CreateObject("Scripting.FileSystemObject")
for fx=1 to ubound(fldrs)
set f=fso.GetFolder(fldrs(fx))
for each file in f.files
if right(lcase(file.name),3)=ext then
filelist=filelist & "#" & file.name
end if
next
set f=nothing
next
filelist=mid(filelist,2)
list=split(filelist,"#")
for m=0 to ubound(list)-1
for n=m to ubound(list)
if lcase(list(m))>lcase(list(n)) then
tmp=list(m)
list(m)=list(n)
list(n)=tmp
end if
next
next
set output=fso.CreateTextFile(outputFile)
output.write join(list,vbCRLF) & vbCRLF
output.close
set output=nothing
set fso=nothing
'========================================
W
Wolf K
Very nice! Takes me back to the days when I could do something like that
during coffee break while munching on muffins. At least I can still read
a script when I see it. ;-)
W
Wolf K
It's Visual Basic. Very explicit. BASIC was invented a a language to
teach programming, so it's um, Very Explicit. ;-)
W
Wolf K
Elegant! First prize for brevity. ;-)
W
Wolf K
On 28/08/2012 7:45 AM, Dave "Crash" Dummy wrote:
[snip]
True, but recall that BASIC was originally invented as a teaching
language, so it was very explicit, really just a step above assembly
language. Its derivatives extended the language by allowing named
subroutines and parameter passing, so that a functional program could be
very short if the subroutines were stored somewhere on the system. At
our school, we stored a bunch of them on the server, and allowed the
kids to call them (after they had learned how to write them explicitly
so that they knew what they were doing). FWIW, I preferred COMAL, and
for a few months I was pretty good at it. ;-)
Mind you, I've forgotten all that stuff. I can still outline a program
in meta-language, but that's really just describing the work the program
must do.
[snip]
[snip]
True, but recall that BASIC was originally invented as a teaching
language, so it was very explicit, really just a step above assembly
language. Its derivatives extended the language by allowing named
subroutines and parameter passing, so that a functional program could be
very short if the subroutines were stored somewhere on the system. At
our school, we stored a bunch of them on the server, and allowed the
kids to call them (after they had learned how to write them explicitly
so that they knew what they were doing). FWIW, I preferred COMAL, and
for a few months I was pretty good at it. ;-)
Mind you, I've forgotten all that stuff. I can still outline a program
in meta-language, but that's really just describing the work the program
must do.
W
Wolf K
On 28/08/2012 9:35 AM, Wolf K wrote:
Who is rewriting my posts????
Who is rewriting my posts????
D
Dave \Crash\ Dummy
Any resemblance between Basic and Visual Basic is purely coincidental.Wolf said:
Basic, the original Basic, was my first serious programming experience,
but I quickly went on to Assembler. Basic and Assembler are machine
oriented "string code." Visual Basic and virtually all modern compiled
and interpreted codes are object oriented, relying on preassembled
machine code.
W
Wolf K
Someone or something is rewriting my posts "imprioving them".. Worse,
the Sent folder shows the rewritten ones.
GAAAH!
W
Wolf K
My post was edited, I don't know how or by whom.
C
Char Jackson
I haven't tried it, but I like the structure. Thanks.You'll like my one-liner thenChar said:
C
Char Jackson
It looked more to me like VBscript than Visual Basic.
G
Gene Wirchenko
Were any error handling required, the VBScript solution might be
better. If not though, it is overly ornate.
I have several complex batch file utilities that I use in my
programming. The beauty of them is that they are easy to write, easy
to run, and easy to change. The downside is that they are somewhat
primitive in interface and error handling.
[snip]
Sincerely,
Gene Wirchenko
G
Gene Wirchenko
Yes. I forgot about being able to have more than one filespec.
If your filespecs have spaces, remember to quote the filespecs.
Sincerely,
Gene Wirchenko
M
Metspitzer
Thanks everyone.
I actually learned basic when I had a Tandy Coco and there was nothing
else to do with them. I noticed right away that there were people
much better at it than I was. I was happy to let them write them and
I ran them.
I probably could have come up with a working few lines with lots of
trial and error, but thankfully Usenet has some very helpful people
and I don't have to.
G
Gene E. Bloch
Excuse me. That's a batch file.
Nah, I'm just having fun.
It could also just be run from the command line by typing those commands
in, but it's riskier, since typos happen...Editing and triple checking a
batch file (or command file) could be safer.
A couple of further notes for Metspitzer:
1. It's a good idea (but not necessary) to have the batch file in a
separate directory from all the others, otherwise it, and the output
file, would be listed in the output. Probably not a major problem, but
worth a bit of effort.
2. If the path names represented above as drive:\dir1 and so on have
spaces in them they must be enclosed in quotes, like this:
"drive:\dir1".
3. If you don't like seeing the commands echoed on screen add a first
line to the batch file saying this:
@echo off
4. The batch file could be a .bat file or a .cmd file. In the given case
there's no significant difference, but there might be in more advanced
scripts. I don't know a lot about cmd (but I guess I had to mention this
to muddy the waters).