 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> 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 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > Well, duh. People don't use soft links because Windows doesn't support
> > them. Seems plainly obvious.
> It has some support. People don't use them because they don't need them,
> really.
No. Windows doesn't support them, so user have learned to live without
them, and then they are claiming that they "don't need them" (one of the
most common "windows'isms").
If Windows had supported soft links from day one, they would probably be
in pretty common use, and it would be unthinkable to drop them.
> Software is written to not hard-code paths that don't need to be
> hard-coded.
Yeah, because that's the *only* thing soft links are used for.
> > I'm pretty sure you wouldn't be writing that if Windows had full support
> > for soft links from day one to this day.
> Uh, yes, actually, I would.
You might yourself believe that, but I don't think it's true. I'm pretty
certain that if Windows had supported soft links from the very beginning,
you would today be defending them. (You would *especially* be defending
them if Unix/Linux didn't support them, I'm pretty sure.)
> I think soft links are an abomination, and I've
> only ever seen them used to basically correct flaws in software
> configurations.
Linux distros use them frequently to, for example, make "aliases" of
libraries of different versions to an actual file which is fully compatible.
In other words, if version 1.2.3 of a library is fully backwards compatible
back to version 1.0.0 of the library, the "versionless" library (eg.
"libsomething.so") file will usually be linked to the 1.2.3 version of the
file (eg. "libsomething.so.1.2.3"), as well as the several versioned files
(eg. "libsomething.so.1" would be a soft link to "libsomething.so.1.2.3" if
the latter is fully backwards compatible with version 1).
This is not a question of "bad configuration". It's a question of
practicality (an executable may have been linked against version 1.0.0 of
the library, but it will work ok with the version 1.2.3, so the soft link
will make it load that) and saving disk space (especially if the library is
several megabytes in size).
And before you start nitpicking about how that could be solved in other
ways (which I'm 100% sure you will do), that was just ONE EXAMPLE of many.
(Another cool example is when a software package consists of several
executables, each one doing slightly different things... But instead of
having a 5-megabyte file for each executable, they are all in fact soft
links to one single 6-megabyte executable which then acts different depending
in which name was used to start it. Again, this saves disk space.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I.e., "I find Windows difficult because it's not made for nerds by nerds, so
> to make it as nerdy as Linux, I have to download some free programs and
> install them." :-)
Most of which are very specific, support only a limited amount of
functionalities, cannot be chained to perform more complex operations,
are often inconvenient to use, large and heavy, and litter your system
with tons of setup files and registry entries which it will leave there
even after you uninstall the app. Also if they do very low-level stuff,
they usually don't integrate very well with Windows and its own apps
(such as Windows Explorer).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
