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

scott <sco### [at] scottcom> wrote:
> >> 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).

  Lucky you.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Heh. I didn't know the shell could do that either. (Although you didn't 
> specify *which* shell - Unix has several...)

  I don't think there's a unix shell in existence that doesn't do file name
pattern expansion. It would be a rather useless shell if it didn't.

  The shell doing the expansion rather than the program is a rather clever
idea. In DOS it was always the program which did the expansion, which meant
that many programs didn't support expansion patterns because the programmers
were lazy. It's also handy because a more advanced shell can support more
complex expansion patterns without the need for the programs to support them.

  The program just ends up seeing a bunch of file names in the command line
(because the shell expands them before even launching the program).

> I'm still not seeing what's so useful about being able to search a file 
> for something.

  Suppose that you have a httpd log file and you want to list all entries
within a specific day. Or the number of requests for a specific file (or
a group of files). Suppose you want to list all entries *except* those
which match a certain pattern (eg. they have a referrer which indicates
that the request was made by a search engine). 'grep' is your tool for that.

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

  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.

> I never have 50 small files.

  Haha. You are quite humorous sometimes.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> 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?

  Because you can write a simple search pattern in a matter of seconds,
while writing the equivalent program would take you minutes at least.

-- 
                                                          - Warp

Post a reply to this message

>  Lucky you.

Computers don't work on luck :-)

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> 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?
> 
>   Because you can write a simple search pattern in a matter of seconds,
> while writing the equivalent program would take you minutes at least.

Um... why? Three lines of text doesn't take "minutes" to write. And 
that's about all it takes to search a folder for a file matching a 
condition. (Obviously, it depends on how complicated the condition is...)

Post a reply to this message

scott wrote:

> Computers don't work on luck :-)

Some days I start to wonder... :-S

Post a reply to this message

Warp wrote:

>   The shell doing the expansion rather than the program is a rather clever
> idea.

Yeah. But then, it's part of the general Unix philosophy of "make each 
tool do one job, and one job well".

With MS-DOS/Windows, the shell's job is basically to launch the 
interactive programs that do all the *real* work. The shell itself is 
pretty poor. (Although not quite as poor as it seems at first...)

>> I'm still not seeing what's so useful about being able to search a file 
>> for something.
> 
>   Suppose that you have a httpd log file and you want to list all entries
> within a specific day. Or the number of requests for a specific file (or
> a group of files). Suppose you want to list all entries *except* those
> which match a certain pattern (eg. they have a referrer which indicates
> that the request was made by a search engine). 'grep' is your tool for that.

Ah, right. I see.

Personally, I'd import the whole log into a relational database, and 
process it that way. (Or maybe even use a webserver that keeps its logs 
in a database in the first place, rather than a huge flat file.) But 
apparently that's just me...

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

On the contrary, figuring out how to work grep vs writing a program in a 
language I already know well is likely to take *slightly* more than 
merely a hundred times longer. (Although you could argue that's a 
one-time cost.)

Personally I just dislike scripting languages. I'd rather use a real 
language with propper error checking and so on and so forth. But I guess 
that's just me.

>> I never have 50 small files.
> 
>   Haha. You are quite humorous sometimes.

Maybe I just don't try to do the same kinds of tasks as you?

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Personally, I'd import the whole log into a relational database, and 
> process it that way. (Or maybe even use a webserver that keeps its logs 
> in a database in the first place, rather than a huge flat file.) But 
> apparently that's just me...

  Talk about an overly complicated solution for a simple problem.

> On the contrary, figuring out how to work grep vs writing a program in a 
> language I already know well is likely to take *slightly* more than 
> merely a hundred times longer. (Although you could argue that's a 
> one-time cost.)

  Writing something like "grep 'hello.*there' file.txt" doesn't require a
lot of time or thinking.

> Personally I just dislike scripting languages. I'd rather use a real 
> language with propper error checking and so on and so forth. But I guess 
> that's just me.

  What's the difference between "a scripting language" and "a real language"?

-- 
                                                          - Warp

Post a reply to this message