Regan Heath wrote:
> On Sat, 2 Apr 2005 06:44:43 -0500, Ben Hinkle <ben.hinkle@gmail.com> wrote:
> 
>> "AEon" <aeon2001@lycos.de> wrote in message
>> news:d2kter$2184$1@digitaldaemon.com...
>>
>>> SeeSchloss wrote:
>>>
>>>>> ...
>>>>> Right... that was exactly what I planned to do, check for the *
>>>>> wildcard. And then work on it. That should then work in any case, as  you
>>>>> pointed out, under any unix-like shell my program would never see the
>>>>> wildcard.
>>>>
>>>>
>>>> And what if a file is named *.log ? :P
>>>
>>>
>>> I am not aware of any OS where *.log would be a valid file name (neither
>>> DOS, Linux nor Amiga :))
>>
>>
>> I can create and delete *.log on Linux (and any Unix) just fine
>> touch \*.log
>> rm \*.log
>> by escaping character so the shell doens't expand them.
> 
> 
> Right. So in conclusion:
> 
> 1. You cannot guarantee on any Unix system that you will not get "*.log"  (either passed as Ben has shown, or by a shell which does not do wildcard  expansion).
> 
> 2. If you get "*.log" on a unix system it might really be a filename.
> 
> So.. I propose that you are going to have to stat the string, i.e. check  whether a file by that name exists. If the file doesn't exist you call  recls on it. You can do this on both Unix and Windows, no need for version  blocks IMO.

Don't stat it.

The unix way of thinking is that a program never does expansions itself. So, if it gets *.log, then it is supposed to assume there actually is a file with that name.

And, as with everything else, whatever file name it gets, _may_ still be non-existent. As in "myprog foo bar" when there is no "foo" file.

Why they do it this way, is that this gives consistent behavior. It is for the shell to prepare (expand, modify, whatever) the command line before the program starts.

------------------------------

To illustrate how this is only the top of the iceberg representing the (to many unseen) profoundness of the differences between windows and unix, one might try the following on both:

In a windows command window, and at the unix command prompt, do the following:

 - First, create some directory and cd to there.

    mkdir krap
    cd krap

 - Create some files and a folder.

    echo a > a
    echo b > b
    echo c > c
    mkdir myfolder

 - On windows write:

    copy *

 - On unix write:

    cp *

 - Look at the directory (unix: ls -l)(windows: dir).

The difference you've noticed so far is, windows gave you an error message, on unix nothing seems to have happened.

 - Then, on both look at the myfolder directory.

On windows, myfolder is empty, but on unix it contains copies of a, b, and c.

--------------------------

The above result is not a spurious thing, it really reflects a number of details of the very basics of the unix philosophy -- which pervade the entire operating system -- versus those (or lack of them) in windows.

--------------------------

To Walter and others: porting to unix really should be done "right". This means listening carefully to the things and opinions unix gurus may present. However surprising, unimportant, or nit picking they might sound at first.

And to any developer who wants to write for both:

  If there ever is a difference in something between
  windows and unix, one should consider unix as What's
  Right by default. Not the other way around.

(Typical example: many windows folks seemed to think that not being able to write to string litrals in Linux was a bug (in DMD or Linux), or at least a deficiency. Well, you don't write to literals, it's like peeing in your own living room. And therefore, it can't be done in unix.)

Unix was up and conquering the Academia and government machine rooms at the time Bill Gates was too young to get a driver's licence.

On Sat, 02 Apr 2005 18:46:45 +0300, Georg Wrede <georg.wrede@nospam.org> wrote:
> Regan Heath wrote:
>> On Sat, 2 Apr 2005 06:44:43 -0500, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>>
>>> "AEon" <aeon2001@lycos.de> wrote in message
>>> news:d2kter$2184$1@digitaldaemon.com...
>>>
>>>> SeeSchloss wrote:
>>>>
>>>>>> ...
>>>>>> Right... that was exactly what I planned to do, check for the *
>>>>>> wildcard. And then work on it. That should then work in any case, as  you
>>>>>> pointed out, under any unix-like shell my program would never see the
>>>>>> wildcard.
>>>>>
>>>>>
>>>>> And what if a file is named *.log ? :P
>>>>
>>>>
>>>> I am not aware of any OS where *.log would be a valid file name (neither
>>>> DOS, Linux nor Amiga :))
>>>
>>>
>>> I can create and delete *.log on Linux (and any Unix) just fine
>>> touch \*.log
>>> rm \*.log
>>> by escaping character so the shell doens't expand them.
>>   Right. So in conclusion:
>>  1. You cannot guarantee on any Unix system that you will not get "*.log"  (either passed as Ben has shown, or by a shell which does not do wildcard  expansion).
>>  2. If you get "*.log" on a unix system it might really be a filename.
>>  So.. I propose that you are going to have to stat the string, i.e. check  whether a file by that name exists. If the file doesn't exist you call  recls on it. You can do this on both Unix and Windows, no need for version  blocks IMO.
>
> Don't stat it.
>
> The unix way of thinking is that a program never does expansions itself. So, if it gets *.log, then it is supposed to assume there actually is a file with that name.
>
> And, as with everything else, whatever file name it gets, _may_ still be non-existent. As in "myprog foo bar" when there is no "foo" file.

Sure.  But isn't it true there are unix shells which do not expand *?

> Why they do it this way, is that this gives consistent behavior.

Windows shell behaviour is just as consistent. It's just different.

> It is for the shell to prepare (expand, modify, whatever) the command line before the program starts.

I have used both windows and unix shells, I prefer windows.

> ------------------------------
>
> To illustrate how this is only the top of the iceberg representing the (to many unseen) profoundness of the differences between windows and unix, one might try the following on both:
>
> In a windows command window, and at the unix command prompt, do the following:
>
>   - First, create some directory and cd to there.
>
>      mkdir krap
>      cd krap
>
>   - Create some files and a folder.
>
>      echo a > a
>      echo b > b
>      echo c > c
>      mkdir myfolder
>
>   - On windows write:
>
>      copy *
>
>   - On unix write:
>
>      cp *
>
>   - Look at the directory (unix: ls -l)(windows: dir).
>
> The difference you've noticed so far is, windows gave you an error message, on unix nothing seems to have happened.
>
>   - Then, on both look at the myfolder directory.
>
> On windows, myfolder is empty, but on unix it contains copies of a, b, and c.

On unix it expanded "cp *" to "cp a b c myfolder", right?
Meaning copy a b and c to myfolder.
Is it guaranteed to list the folder last?
Would it list more than one folder if there was more than one?
Would it then copy all the files into all the folders?
or all the files and folders into the last folder listed?

It appears to me that the unix behaviour is less obvious, and therefore I prefer the windows behaviour which requires you to specify explicitly where to copy things to.

> --------------------------
>
> The above result is not a spurious thing, it really reflects a number of details of the very basics of the unix philosophy -- which pervade the entire operating system -- versus those (or lack of them) in windows.
>
> --------------------------
>
> To Walter and others: porting to unix really should be done "right". This means listening carefully to the things and opinions unix gurus may present. However surprising, unimportant, or nit picking they might sound at first.
>
> And to any developer who wants to write for both:
>
>    If there ever is a difference in something between
>    windows and unix, one should consider unix as What's
>    Right by default. Not the other way around.

I prefer "If there ever is a difference in something between windows and unix, one should consider the difference and decide what is right and what is wrong". Lets assume unix is correct is just as bad as lets assume windows is correct. IMO.

> (Typical example: many windows folks seemed to think that not being able to write to string litrals in Linux was a bug (in DMD or Linux), or at least a deficiency. Well, you don't write to literals, it's like peeing in your own living room. And therefore, it can't be done in unix.)

Using my rule above I quickly decided that linux was correct in this case. Not because it was linux, because it was correct.

> Unix was up and conquering the Academia and government machine rooms at the time Bill Gates was too young to get a driver's licence.

Old does not necessarily mean correct.

Regan

Regan Heath wrote:
> On Sat, 02 Apr 2005 18:46:45 +0300, Georg Wrede <georg.wrede@nospam.org>  wrote:
>> And, as with everything else, whatever file name it gets, _may_ still be  non-existent. As in "myprog foo bar" when there is no "foo" file.
> 
> Sure.  But isn't it true there are unix shells which do not expand *?

I don't know. But in 25 years of unix (later Linux) usage, I've never even heard rumors of one.

If you don't want something expanded, then you quote it on the command line. (type 'man bash', for info.) And it's "always" been done like that.

>> Why they do it this way, is that this gives consistent behavior.
> 
> Windows shell behaviour is just as consistent. It's just different.

Well, say you found "copy *" to not appear to do anything, and then found copies of your files in myfolder. Wouldn't you suspect a bug?

And I can imagine if you reported it, they'd fix it to work like it currently does. Nice. But, nobody in this chain ever looked at the bigger picture.

>> It is for the shell to prepare (expand, modify, whatever) the command  line before the program starts.
> 
> I have used both windows and unix shells, I prefer windows.

(This is not offendingly or personally meant, but) there are people who really and honestly prefer Citroen 2CV cars. (I can't eat monkey brains even if offered, but I'm probably the only one here who can eat /mämmi/. (A traditional Finnish Easter food, that both looks like and tastes like manure.) So, it's all in one's background.

And hey, who am i to tell everyone what to prefer. :-)

>> ------------------------------
>>
>> To illustrate how this is only the top of the iceberg representing the  (to many unseen) profoundness of the differences between windows and  unix, one might try the following on both:
>>
>> In a windows command window, and at the unix command prompt, do the  following:
>>
>>   - First, create some directory and cd to there.
>>
>>      mkdir krap
>>      cd krap
>>
>>   - Create some files and a folder.
>>
>>      echo a > a
>>      echo b > b
>>      echo c > c
>>      mkdir myfolder
>>
>>   - On windows write:
>>
>>      copy *
>>
>>   - On unix write:
>>
>>      cp *
>>
>>   - Look at the directory (unix: ls -l)(windows: dir).
>>
>> The difference you've noticed so far is, windows gave you an error  message, on unix nothing seems to have happened.
>>
>>   - Then, on both look at the myfolder directory.
>>
>> On windows, myfolder is empty, but on unix it contains copies of a, b,  and c.

(Heh, ever ask yourself why copy is a longer word than md (for mkdir) on windows, but on unix cp is shorter than mkdir (no md on unix)?

> On unix it expanded "cp *" to "cp a b c myfolder", right?
> Meaning copy a b and c to myfolder.

yes

> Is it guaranteed to list the folder last?

no

> Would it list more than one folder if there was more than one?

yes

> Would it then copy all the files into all the folders?

no

> or all the files and folders into the last folder listed?

no!


"cp source[...] dest"

Cp couldn't care less about how or why it gets its arguments. And it's none of its business. By the specs, whatever comes last on the command line is the destination. (Of course the cp spec says also that if there are multiple source files, then the last argument has to be a directory. Which, btw, ought to be clear anyhow, if one thinks about it. But learning to think is not a windows thing. There one just has to learn "oh, ok, this is done like this -- here in this case.")

And this cp example is not sloppines or something, it just is the best combination of flexibility and usability -- and not cp specific, but just a small manifestation of the bigger overall philosophy.

Instead of learning all that by heart, one should try to grasp the ideology behind this. Once done, (and it is essential before you can even remotely start to feel "at home" there) you can start to Discuss with the Spirit within a unix machine. (See my other post recently.) Before that, it is expected behavior to prefer the windows command line.

When I was 3 years old and tried to learn to bike, I remember thinking, why the hell can't all bikes be with 3 wheels? Now I have to learn this stupid thing. 2 make it just unnecessarily hard. -- Would anybody switch to 3 wheels today?

> It appears to me that the unix behaviour is less obvious, and therefore I  prefer the windows behaviour which requires you to specify explicitly  where to copy things to.

You should transcend from the explicit. But that needs confidence. Which needs internalising the philosophy. (Gee, sounded Zen like. :-) )

>> The above result is not a spurious thing, it really reflects a number of  details of the very basics of the unix philosophy -- which pervade the  entire operating system -- versus those (or lack of them) in windows.
>>
>> --------------------------
>>
>> To Walter and others: porting to unix really should be done "right".  This means listening carefully to the things and opinions unix gurus may  present. However surprising, unimportant, or nit picking they might  sound at first.
>>
>> And to any developer who wants to write for both:
>>
>>    If there ever is a difference in something between
>>    windows and unix, one should consider unix as What's
>>    Right by default. Not the other way around.
> 
> 
> I prefer "If there ever is a difference in something between windows and  unix, one should consider the difference and decide what is right and what  is wrong". Lets assume unix is correct is just as bad as lets assume  windows is correct. IMO.

IN GENERAL, you're right. Unix being the exception, which I tried to illustrate in the OP (both above, and below).

Point being, unix has been both used and _continuously_ developed by Users Who Care, and are Capable. And it's been so for so long, that it's safe to assume any behavior you may encounter (even if counter intuitive at first sight), is On Purpose. (And not because the microserf had to go home early, or nobody in Redmond gave a crap about the Big Picture or Responsible and Sustainable Development.)

I know what I'm talking. During my 25 years, there've been several things I "fought against" in unix. But one after another, I've suddenly understood why they are there. Some even during the last 5 years. And then I've felt so dumb, because they have suddenly become obvious, and just right. Luckily people smarter than I have been around to pave the way. :-)

>> (Typical example: many windows folks seemed to think that not being able  to write to string litrals in Linux was a bug (in DMD or Linux), or at  least a deficiency. Well, you don't write to literals, it's like peeing  in your own living room. And therefore, it can't be done in unix.)
> 
> Using my rule above I quickly decided that linux was correct in this case.  Not because it was linux, because it was correct.

Case in point!

>> Unix was up and conquering the Academia and government machine rooms at  the time Bill Gates was too young to get a driver's licence.
> 
> Old does not necessarily mean correct.

Right. Usually it means out-dated.

On Sun, 03 Apr 2005 13:06:19 +0300, Georg Wrede <georg.wrede@nospam.org> wrote:
> Regan Heath wrote:
>> On Sat, 02 Apr 2005 18:46:45 +0300, Georg Wrede <georg.wrede@nospam.org>  wrote:
>>> And, as with everything else, whatever file name it gets, _may_ still be  non-existent. As in "myprog foo bar" when there is no "foo" file.
>>  Sure.  But isn't it true there are unix shells which do not expand *?
>
> I don't know. But in 25 years of unix (later Linux) usage, I've never even heard rumors of one.

I must have imagined it. I could have sworn I ran into one while telnetting to a customers machine. It was a very basic piece of work, such that I immediately invoked "bash" :)

> If you don't want something expanded, then you quote it on the command line. (type 'man bash', for info.) And it's "always" been done like that.

Sure, like Ben said.

>>> Why they do it this way, is that this gives consistent behavior.
>>  Windows shell behaviour is just as consistent. It's just different.
>
> Well, say you found "copy *" to not appear to do anything, and then found copies of your files in myfolder. Wouldn't you suspect a bug?
>
> And I can imagine if you reported it, they'd fix it to work like it currently does. Nice. But, nobody in this chain ever looked at the bigger picture.

What do you believe the "bigger picture" to be?

I suspect you're not seeing *their* bigger picture, which was an OS for the everyday user and/or consistency/continuity with previous versions of the same thing. I don't think you can argue that windows has failed, it holds a majority of the desktop user market, which was specifically what it was designed to do. It's only recently that linux has even attempted to appeal to ordinary desktop users.

You may be thinking at this point that because it was designed for the desktop user it is in some way inferior (in fact I am almost positive you think this), and you may be right, for you, but my point here is that you (and I) are not in the majority of desktop user types, we have more unique needs and goals.

Further, the windows shell fulfils all my needs in a shell, if I need more complex solutions I use a scripting language or even write something in C. It means less "languages" I have to learn in order to "talk" to my computer. Lets be honest the unix shell is a "lanugage" all of it's own.

> (Heh, ever ask yourself why copy is a longer word than md (for mkdir) on windows, but on unix cp is shorter than mkdir (no md on unix)?

No, why?

>> On unix it expanded "cp *" to "cp a b c myfolder", right?
>> Meaning copy a b and c to myfolder.
>
> yes
>
>> Is it guaranteed to list the folder last?
>
> no
>
>> Would it list more than one folder if there was more than one?
>
> yes
>
>> Would it then copy all the files into all the folders?
>
> no
>
>> or all the files and folders into the last folder listed?
>
> no!

But that's what you said it did above. Copy a b and c (all the files/folders) into the folder myfolder (the last folder listed).

> "cp source[...] dest"
>
> Cp couldn't care less about how or why it gets its arguments. And it's none of its business. By the specs, whatever comes last on the command line is the destination. (Of course the cp spec says also that if there are multiple source files, then the last argument has to be a directory. Which, btw, ought to be clear anyhow, if one thinks about it.

So, what you're saying is that unix shell, when you type "cp *" will do different things depending on the contents of the directory and the (random? / order stored in directory file) order in which the shell decides to expand a wildcard?

If by chance it lists the files and lists a directory last it will copy all the files into that directory. If by chance it lists a file last it will.. give an error?

> But learning to think is not a windows thing. There one just has to learn "oh, ok, this is done like this -- here in this case.")

I've seen this argument/POV applied also to politics. I have a friend who says that because the government legislates to enforce a standard for education that it's stopping people from thinking for themselves. Providing a "standard" solution does not stop people exploring opportunities, it simply saves them from having to do so if it's not important to them.

> And this cp example is not sloppines or something, it just is the best combination of flexibility and usability -- and not cp specific, but just a small manifestation of the bigger overall philosophy.

Sure, I can see and agree that having a shell expand wildcards is more powerful, but, it's also more dangerous and less obvious (even if you know and understand the philosophy behind it).

Whose to say it's the "best" combination, it might be for you, but not for another (i.e. me). If I need this power I'll use a scripting language. I prefer the simplicity of the windows shell.

> Instead of learning all that by heart, one should try to grasp the ideology behind this. Once done, (and it is essential before you can even remotely start to feel "at home" there) you can start to Discuss with the Spirit within a unix machine. (See my other post recently.)

I am perfectly at home on a unix machine. I read your post on the "Spirit" of a unix machine, I mean no offence but to me it seemed somewhat... odd, like you've been taking too many mind altering drugs. (my opinion of course, feel free to ignore it).

> Before that, it is expected behavior to prefer the windows command line.

By this you're implying anyone who prefers a windows shell is inferior in understanding. I disagree, I have made an informed choice which happens to differ to your own. Ever asked yourself why windows holds the desktop market.. I'd bet less than 5% of them actually use the shell.

> When I was 3 years old and tried to learn to bike, I remember thinking, why the hell can't all bikes be with 3 wheels? Now I have to learn this stupid thing. 2 make it just unnecessarily hard. -- Would anybody switch to 3 wheels today?

2 wheeled bikes and 3 wheeled bikes are different, each serve a different purpose for different reasons. You'll find 3 and even 4 wheeled bikes on farms and other less level terrain, for that reason. There is no "right" choice in all situations for everyone.

>> It appears to me that the unix behaviour is less obvious, and therefore I  prefer the windows behaviour which requires you to specify explicitly  where to copy things to.
>
> You should transcend from the explicit. But that needs confidence. Which needs internalising the philosophy. (Gee, sounded Zen like. :-) )

Again, you're implying my position to be 'lower' than your own. I prefer 'explicit', I dislike a computer (aka another programmer) guessing what I want because they are typically bad at it. I re-iterate I understand the linux shell, I just dislike the choices made.

>>> The above result is not a spurious thing, it really reflects a number of  details of the very basics of the unix philosophy -- which pervade the  entire operating system -- versus those (or lack of them) in windows.
>>>
>>> --------------------------
>>>
>>> To Walter and others: porting to unix really should be done "right".  This means listening carefully to the things and opinions unix gurus may  present. However surprising, unimportant, or nit picking they might  sound at first.
>>>
>>> And to any developer who wants to write for both:
>>>
>>>    If there ever is a difference in something between
>>>    windows and unix, one should consider unix as What's
>>>    Right by default. Not the other way around.
>>   I prefer "If there ever is a difference in something between windows and  unix, one should consider the difference and decide what is right and what  is wrong". Lets assume unix is correct is just as bad as lets assume  windows is correct. IMO.
>
> IN GENERAL, you're right. Unix being the exception, which I tried to illustrate in the OP (both above, and below).

I think you've been smoking something ;) (humourous banter, no insult intended).

> Point being, unix has been both used and _continuously_ developed by Users Who Care, and are Capable. And it's been so for so long, that it's safe to assume any behavior you may encounter (even if counter intuitive at first sight), is On Purpose.

Rest assured I do. But, and heres the point I have been trying to make, the solution chosen is not always the "best" solution for everyone in all situations.

> (And not because the microserf had to go home early, or nobody in Redmond gave a crap about the Big Picture or Responsible and Sustainable Development.)

You have an obvious hatred for M$ and windows. Personally I couldn't care less about them, or linus torvalds (how do you spell his name) I just use whatever does the job. Currently it is windows, in future it may be linux, or another unix based OS. But, it won't be because I have begun talking to my computer ;) It will be because it does the job.

> I know what I'm talking. During my 25 years, there've been several things I "fought against" in unix. But one after another, I've suddenly understood why they are there. Some even during the last 5 years. And then I've felt so dumb, because they have suddenly become obvious, and just right. Luckily people smarter than I have been around to pave the way. :-)

There are many ways to do things. Seldom is one way "right" for everyone.

>>> (Typical example: many windows folks seemed to think that not being able  to write to string litrals in Linux was a bug (in DMD or Linux), or at  least a deficiency. Well, you don't write to literals, it's like peeing  in your own living room. And therefore, it can't be done in unix.)
>>  Using my rule above I quickly decided that linux was correct in this case.  Not because it was linux, because it was correct.
>
> Case in point!

Err... I hope you're not arguing that because linux is right in this *one* case it prooves your "linux is always right" rule? are you?

>>> Unix was up and conquering the Academia and government machine rooms at  the time Bill Gates was too young to get a driver's licence.
>>  Old does not necessarily mean correct.
>
> Right. Usually it means out-dated.

Nah, you're not outdated ;)
(again, no offence intended, I applogise if I have over-stepped)

Regan

Georg,

Our little conversation has drifted waaay off topic. Now, I'm enjoying it and all (but other may not be).It's perhaps not suitable for this "learn" NG? My email address is valid.

One last thing Georg... I hope you don't mind me joking with you. Let me know if you do and I will cease and desist immediately.

I'm off to bed for the night, it's 11:54pm here in New Zealand.

Regan

On Sun, 03 Apr 2005 23:52:45 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> On Sun, 03 Apr 2005 13:06:19 +0300, Georg Wrede <georg.wrede@nospam.org> wrote:
>> Regan Heath wrote:
>>> On Sat, 02 Apr 2005 18:46:45 +0300, Georg Wrede <georg.wrede@nospam.org>  wrote:
>>>> And, as with everything else, whatever file name it gets, _may_ still be  non-existent. As in "myprog foo bar" when there is no "foo" file.
>>>  Sure.  But isn't it true there are unix shells which do not expand *?
>>
>> I don't know. But in 25 years of unix (later Linux) usage, I've never even heard rumors of one.
>
> I must have imagined it. I could have sworn I ran into one while telnetting to a customers machine. It was a very basic piece of work, such that I immediately invoked "bash" :)
>
>> If you don't want something expanded, then you quote it on the command line. (type 'man bash', for info.) And it's "always" been done like that.
>
> Sure, like Ben said.
>
>>>> Why they do it this way, is that this gives consistent behavior.
>>>  Windows shell behaviour is just as consistent. It's just different.
>>
>> Well, say you found "copy *" to not appear to do anything, and then found copies of your files in myfolder. Wouldn't you suspect a bug?
>>
>> And I can imagine if you reported it, they'd fix it to work like it currently does. Nice. But, nobody in this chain ever looked at the bigger picture.
>
> What do you believe the "bigger picture" to be?
>
> I suspect you're not seeing *their* bigger picture, which was an OS for the everyday user and/or consistency/continuity with previous versions of the same thing. I don't think you can argue that windows has failed, it holds a majority of the desktop user market, which was specifically what it was designed to do. It's only recently that linux has even attempted to appeal to ordinary desktop users.
>
> You may be thinking at this point that because it was designed for the desktop user it is in some way inferior (in fact I am almost positive you think this), and you may be right, for you, but my point here is that you (and I) are not in the majority of desktop user types, we have more unique needs and goals.
>
> Further, the windows shell fulfils all my needs in a shell, if I need more complex solutions I use a scripting language or even write something in C. It means less "languages" I have to learn in order to "talk" to my computer. Lets be honest the unix shell is a "lanugage" all of it's own.
>
>> (Heh, ever ask yourself why copy is a longer word than md (for mkdir) on windows, but on unix cp is shorter than mkdir (no md on unix)?
>
> No, why?
>
>>> On unix it expanded "cp *" to "cp a b c myfolder", right?
>>> Meaning copy a b and c to myfolder.
>>
>> yes
>>
>>> Is it guaranteed to list the folder last?
>>
>> no
>>
>>> Would it list more than one folder if there was more than one?
>>
>> yes
>>
>>> Would it then copy all the files into all the folders?
>>
>> no
>>
>>> or all the files and folders into the last folder listed?
>>
>> no!
>
> But that's what you said it did above. Copy a b and c (all the files/folders) into the folder myfolder (the last folder listed).
>
>> "cp source[...] dest"
>>
>> Cp couldn't care less about how or why it gets its arguments. And it's none of its business. By the specs, whatever comes last on the command line is the destination. (Of course the cp spec says also that if there are multiple source files, then the last argument has to be a directory. Which, btw, ought to be clear anyhow, if one thinks about it.
>
> So, what you're saying is that unix shell, when you type "cp *" will do different things depending on the contents of the directory and the (random? / order stored in directory file) order in which the shell decides to expand a wildcard?
>
> If by chance it lists the files and lists a directory last it will copy all the files into that directory. If by chance it lists a file last it will.. give an error?
>
>> But learning to think is not a windows thing. There one just has to learn "oh, ok, this is done like this -- here in this case.")
>
> I've seen this argument/POV applied also to politics. I have a friend who says that because the government legislates to enforce a standard for education that it's stopping people from thinking for themselves. Providing a "standard" solution does not stop people exploring opportunities, it simply saves them from having to do so if it's not important to them.
>
>> And this cp example is not sloppines or something, it just is the best combination of flexibility and usability -- and not cp specific, but just a small manifestation of the bigger overall philosophy.
>
> Sure, I can see and agree that having a shell expand wildcards is more powerful, but, it's also more dangerous and less obvious (even if you know and understand the philosophy behind it).
>
> Whose to say it's the "best" combination, it might be for you, but not for another (i.e. me). If I need this power I'll use a scripting language. I prefer the simplicity of the windows shell.
>
>> Instead of learning all that by heart, one should try to grasp the ideology behind this. Once done, (and it is essential before you can even remotely start to feel "at home" there) you can start to Discuss with the Spirit within a unix machine. (See my other post recently.)
>
> I am perfectly at home on a unix machine. I read your post on the "Spirit" of a unix machine, I mean no offence but to me it seemed somewhat... odd, like you've been taking too many mind altering drugs. (my opinion of course, feel free to ignore it).
>
>> Before that, it is expected behavior to prefer the windows command line.
>
> By this you're implying anyone who prefers a windows shell is inferior in understanding. I disagree, I have made an informed choice which happens to differ to your own. Ever asked yourself why windows holds the desktop market.. I'd bet less than 5% of them actually use the shell.
>
>> When I was 3 years old and tried to learn to bike, I remember thinking, why the hell can't all bikes be with 3 wheels? Now I have to learn this stupid thing. 2 make it just unnecessarily hard. -- Would anybody switch to 3 wheels today?
>
> 2 wheeled bikes and 3 wheeled bikes are different, each serve a different purpose for different reasons. You'll find 3 and even 4 wheeled bikes on farms and other less level terrain, for that reason. There is no "right" choice in all situations for everyone.
>
>>> It appears to me that the unix behaviour is less obvious, and therefore I  prefer the windows behaviour which requires you to specify explicitly  where to copy things to.
>>
>> You should transcend from the explicit. But that needs confidence. Which needs internalising the philosophy. (Gee, sounded Zen like. :-) )
>
> Again, you're implying my position to be 'lower' than your own. I prefer 'explicit', I dislike a computer (aka another programmer) guessing what I want because they are typically bad at it. I re-iterate I understand the linux shell, I just dislike the choices made.
>
>>>> The above result is not a spurious thing, it really reflects a number of  details of the very basics of the unix philosophy -- which pervade the  entire operating system -- versus those (or lack of them) in windows.
>>>>
>>>> --------------------------
>>>>
>>>> To Walter and others: porting to unix really should be done "right".  This means listening carefully to the things and opinions unix gurus may  present. However surprising, unimportant, or nit picking they might  sound at first.
>>>>
>>>> And to any developer who wants to write for both:
>>>>
>>>>    If there ever is a difference in something between
>>>>    windows and unix, one should consider unix as What's
>>>>    Right by default. Not the other way around.
>>>   I prefer "If there ever is a difference in something between windows and  unix, one should consider the difference and decide what is right and what  is wrong". Lets assume unix is correct is just as bad as lets assume  windows is correct. IMO.
>>
>> IN GENERAL, you're right. Unix being the exception, which I tried to illustrate in the OP (both above, and below).
>
> I think you've been smoking something ;) (humourous banter, no insult intended).
>
>> Point being, unix has been both used and _continuously_ developed by Users Who Care, and are Capable. And it's been so for so long, that it's safe to assume any behavior you may encounter (even if counter intuitive at first sight), is On Purpose.
>
> Rest assured I do. But, and heres the point I have been trying to make, the solution chosen is not always the "best" solution for everyone in all situations.
>
>> (And not because the microserf had to go home early, or nobody in Redmond gave a crap about the Big Picture or Responsible and Sustainable Development.)
>
> You have an obvious hatred for M$ and windows. Personally I couldn't care less about them, or linus torvalds (how do you spell his name) I just use whatever does the job. Currently it is windows, in future it may be linux, or another unix based OS. But, it won't be because I have begun talking to my computer ;) It will be because it does the job.
>
>> I know what I'm talking. During my 25 years, there've been several things I "fought against" in unix. But one after another, I've suddenly understood why they are there. Some even during the last 5 years. And then I've felt so dumb, because they have suddenly become obvious, and just right. Luckily people smarter than I have been around to pave the way. :-)
>
> There are many ways to do things. Seldom is one way "right" for everyone.
>
>>>> (Typical example: many windows folks seemed to think that not being able  to write to string litrals in Linux was a bug (in DMD or Linux), or at  least a deficiency. Well, you don't write to literals, it's like peeing  in your own living room. And therefore, it can't be done in unix.)
>>>  Using my rule above I quickly decided that linux was correct in this case.  Not because it was linux, because it was correct.
>>
>> Case in point!
>
> Err... I hope you're not arguing that because linux is right in this *one* case it prooves your "linux is always right" rule? are you?
>
>>>> Unix was up and conquering the Academia and government machine rooms at  the time Bill Gates was too young to get a driver's licence.
>>>  Old does not necessarily mean correct.
>>
>> Right. Usually it means out-dated.
>
> Nah, you're not outdated ;)
> (again, no offence intended, I applogise if I have over-stepped)
>
> Regan

Regan Heath wrote:
> Georg,
> 
> Our little conversation has drifted waaay off topic. Now, I'm enjoying it  and all (but other may not be).It's perhaps not suitable for this "learn"  NG? My email address is valid.

Awww, it's not that important anyway. It kind of got out of hand. ;-)

> One last thing Georg... I hope you don't mind me joking with you. Let me  know if you do and I will cease and desist immediately.

I did have quite a few giggles at your quips!

(But it was good that you said each time they were not offenses!)

I guess this thread has been both entertaining, and informative to many others too. But you're right, if somebody didn't get the picture already, they're not going to, so it's already served its purpose.

PS, my compliments, Regan: those who ask hard and long are the ones I've seen become better professionals!

Justin C Calvarese wrote:
> Unfortunately with the latest version of DMD, you'll either need to
> ignore the Phobos docs (which are for the wrong version of recls) and
> figure out how to use it the hard way (hint: std\recls.d) ...

Has anyone got a simple working example of on how to use recls?

As was pointed out:

FileSearch s = new std.recls.FileSearch( path, wild, RECLS_FLAG.FILES);
	foreach(Entry e; s)
	{
	    if(e.size < 2000)
	    {
	      writef(e.path);       // e.g. "/Digital_Mars_C++/STL"
	      writef(e.directory);  // e.g. "/Digital_Mars_C++/STL"
	      writef(e.file);       // e.g. "stlport.zip"
	      writef(e.fileName);   // e.g. "stlport"
	       writef(e.fileExt);    // e.g. "zip"
	     }
	}

does not compile, since the function FileSearch() does not exist.

The function of interest (std\recls.d) seems to be

public recls_rc_t Search_Create(in char[] searchRoot, in char[] pattern, in int flags, out hrecls_t hSrch)

but I have no idea what hSrch requires as anargument.

Just noted that recls lib (at least according to the online docs), will actually let you retrieve the time/date stamp of a file... that would also be very handy indeed.

AEon

In article <d33b10$23i7$1@digitaldaemon.com>, AEon says...
>
>Justin C Calvarese wrote:
>> Unfortunately with the latest version of DMD, you'll either need to
>> ignore the Phobos docs (which are for the wrong version of recls) and
>> figure out how to use it the hard way (hint: std\recls.d) ...
>
>Has anyone got a simple working example of on how to use recls?

This used to work: http://www.dsource.org/tutorials/index.php?show_example=27

(It should still work with the version of recls in Phobos, but I haven't tested
it recently.)


jcc7

On Thu, 07 Apr 2005 15:02:22 +0200, AEon <aeon2001@lycos.de> wrote:
> Justin C Calvarese wrote:
>> Unfortunately with the latest version of DMD, you'll either need to
>> ignore the Phobos docs (which are for the wrong version of recls) and
>> figure out how to use it the hard way (hint: std\recls.d) ...
>
> Has anyone got a simple working example of on how to use recls?
>
> As was pointed out:
>
> FileSearch s = new std.recls.FileSearch( path, wild, RECLS_FLAG.FILES);
> 	foreach(Entry e; s)
> 	{
> 	    if(e.size < 2000)
> 	    {
> 	      writef(e.path);       // e.g. "/Digital_Mars_C++/STL"
> 	      writef(e.directory);  // e.g. "/Digital_Mars_C++/STL"
> 	      writef(e.file);       // e.g. "stlport.zip"
> 	      writef(e.fileName);   // e.g. "stlport"
> 	       writef(e.fileExt);    // e.g. "zip"
> 	     }
> 	}
>
> does not compile, since the function FileSearch() does not exist.
>
> The function of interest (std\recls.d) seems to be
>
> public recls_rc_t Search_Create(in char[] searchRoot, in char[] pattern, in int flags, out hrecls_t hSrch)
>
> but I have no idea what hSrch requires as anargument.
>
> Just noted that recls lib (at least according to the online docs), will actually let you retrieve the time/date stamp of a file... that would also be very handy indeed.

Replace FileSearch with Search above. Replace RECLS_FLAG.FILES with RECLS_FLAG.RECLS_F_FILES. Capitalise the first letter on the properties to 'e'. IIRC the version of recls in phobos is older than the docs on digitalmars.com. If I was Matthew, I would ask to remove recls from phobos and simply supply it as a seperate lib.

I am in the process of writing my own recls. After doing all the above I got some strange message about a missing lib, which I could not find on my system, I assume it's a lib Matthew wrote which is not shipped with phobos?

Regan

>> Let's say you have the files a.log, b.log and *.log in a directory.
>> 
>> You launch "aepar *.log" under a real shell, which appears as "aepar a.log b.log *.log" to the program, since you detect a '*', you use recls to expand this "*.log" to "a.log b.log *.log".
> 
> Ahem... if you mean a unix-like shell, to any program it would appear as
> 
> "a.log b.log"
> 
> there would be no *.log, since it was expanded.

Did you try it ? I did.

> As mentioned above, * is not a valid char in filename under linux. It is a shell based wildcard character. If for some sick reason you actually can rename a file to *.log, then linux really is asking for trouble.

I wish I would have been there sooner to answer myself... but as Ben Hinkle said, '*' *is* a valid char in most filesystems supported by Linux. Actually, at least for ext2/3 and reiserfs, only '/' is invalid (for obvious reasons).