![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
>> ...so how do you actually do this then?
>
> Save the text below as "demoScript.vbs" and double-click it. It will
> write a list of all files in your C: drive to a text file called
> "FileList.txt". Obviously way more complex stuff can be done (like
> recursing subdirectories if you want).
Several interesting things happening here...
1. SciTE recognises Pascal and COBOL, but not VB?
2. This script somehow works, even though I haven't installed WSH.
3. It really takes that much code just to do the same task as DIR /B C:\
> C:\FileList.txt?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott <sco### [at] scott com> wrote:
> > You use your text editor to tell you which files in a directory structure
> > contain a specified string? Talk about being overly complicated. grep is a
> > way, way simpler way to do that.
> Or, in Windows, you can just type the string into the top right of any
> explorer view, in the box that says "Search".
I wish it worked. It doesn't.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Or, in Windows, you can just type the string into the top right of any
>> explorer view, in the box that says "Search".
>
> I wish it worked. It doesn't.
Works fine here - I just tested it by typing in "Vector3" (used in XNA game
studio to represent a 3D vector) and within about 1 second the explorer
window had filled up with lots of C# source code files, plus lots of POV
source files (I guess it uses Vector3 too).
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> No, I mean... I thought grep can only search within a single file (as
> can any decent text editor). I didn't realise it can search multiple files.
You tell it which files it should search, like:
grep 'abc' file1.txt file2.txt file3.txt
Of course if you are in a command line shell, you can use the shell to aid
you in specifying more files by using a pattern, eg:
grep 'abc' file*.txt
(Note that it's the shell that expands the pattern to actual file names,
not grep.)
> (I'm still having trouble thinking up a use-case for that. About the
> only thing I can think of is trying to find out which header file
> defines a particular symbol or something.)
'grep' is one of the most used utilities in Unix systems. It's quite handy
for many, many things. The reason why it's useful is because as it prints
the found results to stdout, you can pipe them to something else, which may
then do something with those results, and so on. Using 'grep' as part of such
a chain of commands is pretty common.
Of course 'grep' is useful all in itself as well, if you want to find files
which contain a certain string.
> >> I guess I don't very often edit large files...
> >
> > What does file size have to do with anything?
> If it's a small file, you can search it just be scrolling through it and
> looking with your eyes. You don't need an automated search facility. The
> only real reason to use an automated search is if there's too much data
> to hunt through manually.
What if you have 50 small files?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 2. This script somehow works, even though I haven't installed WSH.
http://en.wikipedia.org/wiki/VBScript
> 3. It really takes that much code just to do the same task as DIR /B C:\
> > C:\FileList.txt?
Obviously it's just a simple example so you can see how it works.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> I mean, I realise that hypothetically a regex can find things that a
> normal search can't. But in reality, when are you *ever* going to use
> that? What would it be useful for?
Maybe you should start reading more about regular expressions, and why
they can be useful. I'm pretty sure there are regexp libraries for Haskell
as well.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> I mean, I realise that hypothetically a regex can find things that a
>> normal search can't. But in reality, when are you *ever* going to use
>> that? What would it be useful for?
>
> Maybe you should start reading more about regular expressions, and why
> they can be useful. I'm pretty sure there are regexp libraries for Haskell
> as well.
There are. Several different kinds, in fact. (Apparently there's more
than one possible regex syntax or something.)
I still don't get why you'd need to do complex searching. And if for
some strange reason you do need to, why use an obfuscated text string
with limited processing capabilities when you can use a real programming
language?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Exactly my point. Write a program in Linux that walks a directory tree and
> does *not* account for soft links (or "..") and you have a problem.
And that's the reason why they are not supported in Unix systems?
(Oops, they are! Why, since they are so extremely dangerous?)
> > I don't want to see it in a separate dialog. I want to see it in the file
> > listing.
> http://www.codeproject.com/KB/shell/shellextguideindex.aspx
> More specifically,
> http://www.codeproject.com/kb/shell/ShellExtGuide8.aspx
So in order to get Windows Explorer to show exact byte counts, I would have
to download and install Visual Studio, get it to work, write an extension
manually, install it, and keep it with me in an USB stick so that I can
install it in a friend's computer if I ever want to see the byte sizes there
as well?
I think you made some kind of claim containing the word "trivial" in some
post of yours.
> >> And which byte count do you want?
> >
> > The size of the file. How many bytes it contains. If I opened it with a
> > program and started reading bytes, how many I would get before EOF.
> Open it raw, or processed, or for backup?
You are nitpicking, and you know it.
Windows Explorer already shows the actual size of the file. The major
problem is that it shows it *rounded* to kilobytes, megabytes or gigabytes
rather than showing the exact byte count, and there is no setting to make
it show the size in bytes. *That* is the problem.
You are inventing some kind of issue that is not the problem at all, just
for the sake of argument. Why do you do that? You understand perfectly what
I mean. Is agreeing with something really so hard?
> On the rare occasion I wanted exact byte counts, I used Properties. I find
> it more annoying that Linux doesn't put thousands-separators in numbers, so
> when it shows me the size of a 20G file, it takes me lots of staring to
> figure it out. :-)
Yeah, because there's exactly one single way of listing files in "Linux".
Konqueror uses thousands-separators in file sizes.
> > Seeing the exact size of a file is a pretty common and useful thing to
> > want.
> For programmers, yes. Not for regular users. And you can see it with one
> extra step. :-)
So if I want to see the individual byte sizes of 20 files, exactly how do
I do that "with one extra step"?
What harm could there be if Windows Explorer had an option to show file
sizes in bytes?
Each file in a list having its size shown with a different unit is
confusing. You can't visually see which of the files are larger and
which ones are smaller. You have to spend time looking at the units in
order to get an idea. There's no visual feedback to tell you that.
> > Except that it doesn't tell that. If you try to copy it to another file
> > system or an archive file, it will most probably end up taking a completely
> > different amount of space.
> Hence the "which size do you want" question. :-)
The amount of bytes in the file. What's so damn hard to understand about
that?
> That's another good point:
> if it's an archive, do you want the size of the archive, the size of the
> total files in the archive, etc? :-)
The amount of bytes in the file. What's so damn hard to understand about
that?
> > Showing how much disk space a file takes is *useless* information. *That*
> > is what should be in some info dialog. The file listing should show the
> > exact byte size. Apple has done it completely in reverse of what it should be.
> I think showing it as a readable size ("1.7 meg") is reasonable.
It may be reasonable for *one* file. It's unreasonable when you have 50
files, each with different size units.
> Showing it
> as "size in bytes" and "size on disk" are fine too.
But Apple has decided to completely hide the actual size of the file from
the file listing, for some incomprehensible reason.
> > Yeah, start doing that to a dozen files, rather than seeing it in one
> > glance in the file listing. It *is* extremely inconvenient.
> If I want the total, I pick a dozen files and say "properties" and it tells
> me the total.
Do you have reading comprehension problems? I was not talking about totals.
> If I want to compare some in one window with some in another,
> it's mildly more tedious. I might even have to open a shell script or
> something. But even as a nerd, I don't do that too often. Mostly after doing
> a download, to make sure I got all the bytes.
Why are you defending Microsoft on this? I don't get it. What possible harm
could there be, if there was some option somewhere to make Explorer show file
sizes in bytes instead of rounding them?
> No, they *can* make that possible. You're not their target audience
> (namely, a nerd who doesn't program Windows). Hence, they haven't
> implemented it. They spent their time on other things.
Yeah, I see how implementing that would take years and years of work.
This coming from the same person who in this very article posted links to
tutorials where you could make an extension to do exactly that.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
>> 2. This script somehow works, even though I haven't installed WSH.
>
> http://en.wikipedia.org/wiki/VBScript
Much digging later: It seems that WSH is no longer a seperate download.
Apparently it now comes bundled with Windows and is installed by default.
Obviously, this makes a pretty dramatic difference. Nobody (except maybe
me) is going to go to the Microsoft download site and search for
"Windows Script Host" and download and install the file. In other words,
nobody's PC will ever have this installed. But now that it comes with
Windows itself, it'll be installed absolutely everywhere...
>> 3. It really takes that much code just to do the same task as DIR /B
>> C:\ > C:\FileList.txt?
>
> Obviously it's just a simple example so you can see how it works.
Wikipedia seems to indicate that WSH supports JavaScript. I wonder if I
can get that to work...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> No, I mean... I thought grep can only search within a single file (as
>> can any decent text editor). I didn't realise it can search multiple files.
>
> You tell it which files it should search, like:
>
> grep 'abc' file1.txt file2.txt file3.txt
I didn't know you could do that. (Then again, I've never used grep, so...)
> Of course if you are in a command line shell, you can use the shell to aid
> you in specifying more files by using a pattern, eg:
>
> grep 'abc' file*.txt
>
> (Note that it's the shell that expands the pattern to actual file names,
> not grep.)
Heh. I didn't know the shell could do that either. (Although you didn't
specify *which* shell - Unix has several...)
>> (I'm still having trouble thinking up a use-case for that. About the
>> only thing I can think of is trying to find out which header file
>> defines a particular symbol or something.)
>
> 'grep' is one of the most used utilities in Unix systems. It's quite handy
> for many, many things. The reason why it's useful is because as it prints
> the found results to stdout, you can pipe them to something else, which may
> then do something with those results, and so on. Using 'grep' as part of such
> a chain of commands is pretty common.
>
> Of course 'grep' is useful all in itself as well, if you want to find files
> which contain a certain string.
I'm still not seeing what's so useful about being able to search a file
for something.
Now, I suppose if you were trying to script something, being able to
pipe output from another command into grep so that it can grab a
particular substring that you can then pipe to something else might be
useful. But then, if *I* wanted to do something like that, I wouldn't
script it. I'd write a real program, not a script.
>> If it's a small file, you can search it just be scrolling through it and
>> looking with your eyes. You don't need an automated search facility. The
>> only real reason to use an automated search is if there's too much data
>> to hunt through manually.
>
> What if you have 50 small files?
Maybe that's the difference. I never have 50 small files.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |