 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> I wish it worked. It doesn't.
> Works fine here -
You missed the part of the conversation where Warp is still using XP, where
the search works poorly, along with the numerous suggestions I gave to make
it work better.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> looking for which source file contains certain code. Outside of
> programming/development I can't think of many other common cases (maybe
Songs by a particular singer. Photos by a particular camera. Word documents
commented on by a particular employee. Email messages about a particular
topic. These are all the same search process.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> As this isn't easily possible using Windows Explorer then the only
> option sometimes is to search.
Yeah it is, as long as your file has someplace to *put* that data.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The shell doing the expansion rather than the program is a rather clever
> idea.
It has its drawbacks, too. Having a file named -rf in your home directory
leads to problems, for example. Before shells properly escaped everything,
files with spaces in the names were very problematic as well.
> Filtering some files through a chain of programs (such as grep and sed)
> takes just a few seconds of writing a few commands on the command line.
> Writing a program to do that would probably take a hundred times longer.
Depends on your tools at hand and what kind of files you're searching.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible 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?
For example, finding where in the file a symbol is defined instead of used.
I do that all the time. "Where is the definition of this macro?"
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> why use an obfuscated text string
Because it's a text string, and not a programming language. And because
everyone uses essentially the same text strings.
Do you type your three lines of code as the argument to a command-line program?
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> It has its drawbacks, too. Having a file named -rf in your home
> directory leads to problems, for example. Before shells properly
> escaped everything, files with spaces in the names were very problematic
> as well.
Hell, I *still* see programs and libraries saying "don't install this in
a path with spaces".
Wanna guess where the default location for Windows programs is?
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?
>
> For example, finding where in the file a symbol is defined instead of used.
>
> I do that all the time. "Where is the definition of this macro?"
As I say, I've never needed to do that. (Then again, I don't work with
other people's code, only my own.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] san rrcom> 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?)
No, I just said you need to account for it. The Linux tools that walk
directory structures all are aware of sym links. The Windows tools aren't.
Hence, sym links are more dangerous on Windows than on Linux, for exactly
the same reason that it took so long for programs to be able to run without
unnecessary permissions under Windows - it wasn't always like that.
Vista supports symlinks from the command line. There's an extension
(naturally) that lets you do it from explorer. Why do you keep complaining
that your two-generations-outdated OS doesn't come with all the stuff you
can download for free to make it suit your needs?
> 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?
Pretty much, yah. Same as any other program you write. What did you expect?
You mean if I want to indent files the way I like, I have to download emacs,
write some elisp code, then stick it on a USB stick and carry it around to
every other emacs-enabled computer?
> I think you made some kind of claim containing the word "trivial" in some
> post of yours.
More trivial than rewriting the shell. A 50-line program is pretty trivial, yes?
>>>> 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.
You're nitpicking. You want exact byte counts in one window but not the
other. It's trivial to get that information, yet you complain it's
difficult. Plus, you can't even clearly define what it is you want to see.
> Is agreeing with something really so hard?
I already agreed. You kept bashing at it.
> Yeah, because there's exactly one single way of listing files in "Linux".
It generally doesn't put in thousands-separators anywhere.
> Konqueror uses thousands-separators in file sizes.
Good to know.
> So if I want to see the individual byte sizes of 20 files, exactly how do
> I do that "with one extra step"?
"dir"
> What harm could there be if Windows Explorer had an option to show file
> sizes in bytes?
I already agreed there was no harm. You didn't like my answer for some reason.
Again:
>> 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.
> 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.
Click the size column header and it sorts by size.
>>> 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?
OK, now I ask you "how big is the directory? What's its size? How many bytes
in that Linux directory? What's so damn hard to understand? I just want to
know how many bytes are in it."
"How big is that process? How many bytes does it take in memory? What's so
hard to understand about that?"
Copy the file to another system or an archive file. That's three different
sizes. Copy the file to another file system may or may not lose the
compression. Copying it to an archive file is going to need it to carry the
encryption and ACL overhead as well as alternate streams. That's exactly my
point.
> The amount of bytes in the file. What's so damn hard to understand about
> that?
Because first you ask for the amount of bytes in the file, then you ask for
the amount of bytes you'd read if you opened and read the file. And that's
two different numbers.
>> 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.
True.
> But Apple has decided to completely hide the actual size of the file from
> the file listing, for some incomprehensible reason.
Dunno about that.
>>> 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.
The "that" wasn't really clear there. "Start doing that to a dozen files"
doesn't really say whether you mean "one at a time" or "all at once."
> 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?
I'm not defending Microsoft per se. I'm just saying you seem to think
there's some big important reason for this feature not to be here. I just
think it's that it didn't sell more copies of Windows. There would be no
downside to providing it except the need to spend resources providing it.
> 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.
I didn't say years and year. Indeed, I said
>>> There are a zillion things that some people want.
Don't you see? I also gave examples of other things that other people want
that would be pretty trivial to provide, that aren't provided.
I'm not saying Microsoft did right not providing it. I'm just saying that
they're not catering to your personal needs, *and* I'm giving you the
resources to fix your pain.
Maybe I'm like Andrew: I've never needed to put two columns of file sizes
next to each other in explorer windows and compare them.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> ...so how do you actually do this then?
>>
>> That's what the whole COM thing is all about, along with things like
>> "Windows Scripting Host" and "Power Shell".
>
> From what I've seen, you can't touch COM unless you're programming in C
> or C++.
Nonsense. Every programming language and every scripting language supports
COM that I've seen. Didn't you tell me Haskell has a COM interface? I know
Tcl does. WSH does. C# has a particularly nice one. Python does.
OK, I'll grant that maybe postscript doesn't do COM. Whoops, nope, I take
that back. Ghostscript supports COM.
What language have you used on Windows that does *not* do COM? That would be
like having a language on Linux that doesn't support environment variables.
> Last time I checked, neither WSH nor Power Shell comes with Windows. You
> said "all of this is trivial using only the scripting tools that come
> with Windows". So how exactly do you do this then?
They both come with Windows.
Obviously "last I checked" didn't include googling before you posted.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
