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] 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?)

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

Warp wrote:
>   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").

More like "Programmers learned to live without them." I'd classify that as a 
good idea.

What do you *need* symlinks for?  I've never found a good use except getting 
around paths that are hard-coded that shouldn't be, or distributing files 
from one directory onto multiple file systems due to not all file systems 
having the same capabilities.

>   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.

Possibly.  That wouldn't necessarily be a good thing.

>>  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.

Well, tell me what else you *need* them for that a configuration variable 
wouldn't work just as well.

>   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.)

Oh, give it a rest, Warp.

>>  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.

OK. Windows puts this information in the files themselves, and the code asks 
to load the library with the compatible version. Or it looks up the 
registration in the registry. (Hence the name, you see.)

The symlink solution works OK until the upgrade from libxyz.1.2.so to 
libxyz.1.3.so breaks the program written to use libxyz.so. And dont tell me 
it doesn't happen, as I have not infrequently binary-edited libraries to 
change the strings there.

> 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).

Yes, I know how that works.

>   This is not a question of "bad configuration". 

Inadequate configuration. The program itself should be telling you which 
versions it's compatible with, and the loader should be enforcing that. The 
fact that you *can* do it with the file system doesn't mean that's a *good* 
way to do it. :-)

> 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).

This works less well when you have a bunch of programs that you don't have 
the source for which may or may not break when you change library versions. 
Hence, "DLL Hell".  That's much less common when you can just test every 
piece of software written for the platform when you change a library.

>   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.

Sure. Let's hear some others. Seriously.

>   (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.)

Yep. This is what the whole busybox thing is about. Given that, the common 
functionality ought be in a shared library. Otherwise, you're taking up more 
memory than disk space.

Or in the Windows way, you have one tiny file that launches the library with 
different arguments, so you don't have to depend on the file name not 
changing in order to make it work. You know, like, a shortcut or something. :-)

How would a *user* use symlinks, is really what I want to hear. Not someone 
managing software installations, but an end-user. Why would I want a symlink 
in my home directory, for example?

-- 
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:
> 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. 

http://gnuwin32.sourceforge.net/

Jeez, you're really harsh on those GNU guys.  Most of those programs are 
simple stand-along .exe files.

But that's OK. I understand that you're more into bitching about Windows 
than you are in improving your experience, so carry on.

 > 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).

Well, duh. How well does grep integrate with GNOME?

-- 
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