www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Filename expansion under DOS box?

reply AEon <aeon2001 lycos.de> writes:
When reading the arguments from the console for code like this:

int main (char[][] args)
{
}

args used to do a filename expansion automatically. Well it worked for 
ANSI C and Cygwin and under Linux.

What I mean is this:

dir *.log

b.log c.log
 aepar.exe *.log

args[1] = a.log args[2] = b.log args[3] = c.log D take the above litterally:
 aepar.exe *.log

args[1] = *.log Any way to fix this? AEon
Mar 31 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 01 Apr 2005 07:05:50 +0200, AEon <aeon2001 lycos.de> wrote:
 When reading the arguments from the console for code like this:

 int main (char[][] args)
 {
 }

 args used to do a filename expansion automatically. Well it worked for  
 ANSI C

Not to my knowledge it doesn't.
 and Cygwin and under Linux.

It works on Linux due to the shell, bash, the shell expands the wildcard and then calls your program passing the arguments.
 What I mean is this:

  >dir *.log
 	a.log
 	b.log
 	c.log

  > aepar.exe *.log
 -> args[0] = aepar.exe
     args[1] = a.log
     args[2] = b.log
     args[3] = c.log

 D take the above litterally:

  > aepar.exe *.log
 -> args[0] = aepar.exe
     args[1] = *.log

 Any way to fix this?

No. You program needs to handle the wildcard itself. IIRC recls will help you here. Regan
Mar 31 2005
next sibling parent reply AEon <aeon2001 lycos.de> writes:
Regan Heath wrote:

 Not to my knowledge it doesn't.
 
 and Cygwin and under Linux.

It works on Linux due to the shell, bash, the shell expands the wildcard and then calls your program passing the arguments.

Right... I had that confused... It can well be that I never tested the windows aestats outside of the cygwin (bash) shell. i.e. never in the dosbox. Thus the wildcard expansion is indeed due to the shell...
 Any way to fix this?

No. You program needs to handle the wildcard itself. IIRC recls will help you here.

Would probably be a goo idea to do it in the program. But would that not start confliciting with a call on a bash-like shell? Or would I only need to code this for the DOS version, and skip it for the linux version? AEon
Mar 31 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 01 Apr 2005 08:41:57 +0200, AEon <aeon2001 lycos.de> wrote:
 Not to my knowledge it doesn't.

 and Cygwin and under Linux.

wildcard and then calls your program passing the arguments.

Right... I had that confused... It can well be that I never tested the windows aestats outside of the cygwin (bash) shell. i.e. never in the dosbox. Thus the wildcard expansion is indeed due to the shell...
 Any way to fix this?

help you here.

Would probably be a goo idea to do it in the program. But would that not start confliciting with a call on a bash-like shell?

If you program runs in a bash like shell it will never see a wildcard, so as long as the code handles both: [windows args] *.log [bash-like args] a.log b.log c.log without borking you're fine. I expect passing recls a wildcard of "a.log" finds exactly 1 match "a.log". So while it may be a little pointless invoking recls for a non wildcard, it should still handle it ok. (I am guessing).
 Or would I only need to code this for the DOS version, and skip it for  
 the linux version?

Yes. What version block is executed if you run a windows application in cygwin? I imagine the "Windows" block is executed. If so, I would suggest instead of skipping based on OS, skip based on parameters i.e. if you see a parameter with a wildcard in it, eg "*" or "?" call recls and add all matches to a char[][] array. Otherwise just add the parameter to the char[][] array. Regan
Apr 01 2005
parent reply AEon <aeon2001 lycos.de> writes:
Regan Heath wrote:

 I expect passing recls a wildcard of "a.log" finds exactly 1 match  
 "a.log". So while it may be a little pointless invoking recls for a non  
 wildcard, it should still handle it ok. (I am guessing).

Will test that...
 Or would I only need to code this for the DOS version, and skip it 
 for  the linux version?

Yes. What version block is executed if you run a windows application in cygwin? I imagine the "Windows" block is executed.

Actually only my old AEstats code (ANSI C, gcc) was developped under cygwin. Since I noted that gdc under cygwin is not as up to date as dmd. I am developping everying under windows dmd using dosbox for everything. IIRC should I use cywin's bash and compile under cygwin, that the version command would detect a unix system. And not a windows system. The idea behind cygwin was to create a complete unix-like environment.
 If so, I would suggest instead of skipping based on OS, skip based on  
 parameters i.e. if you see a parameter with a wildcard in it, eg "*" or  
 "?" call recls and add all matches to a char[][] array. Otherwise just 
 add  the parameter to the char[][] array.

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. AEon
Apr 01 2005
parent reply SeeSchloss <ng seeschloss.org> writes:
On Sat, 02 Apr 2005 03:19:08 +0200, AEon 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 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". And you end up with "aepar a.log b.log a.log b.log *.log" :) OK that's not a likely situation, but aren't '*' and '?' forbidden in filenames under Windows ? If so, then if you see one of them under Windows it can only be a wildcard, while it's most likely a real filename under Linux... Just to say that IMHO it would be better to do this only for the Windows version :) SeeSchloss
Apr 01 2005
parent reply AEon <aeon2001 lycos.de> writes:
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 :)) So below IMO is a non-case.
 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.
 And you end up with "aepar a.log b.log a.log b.log *.log" :)
 
 OK that's not a likely situation, but aren't '*' and '?' forbidden in
 filenames under Windows ? If so, then if you see one of them under Windows
 it can only be a wildcard, while it's most likely a real filename under
 Linux...

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.
 Just to say that IMHO it would be better to do this only for the Windows
 version :)

Obviouly... since linux will expand the wildcards for me :) AEon
Apr 01 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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.
Apr 02 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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. Regan
Apr 02 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Apr 02 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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.

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
Apr 02 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Apr 03 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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.


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.


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.

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

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.


Right. Usually it means out-dated.

Nah, you're not outdated ;) (again, no offence intended, I applogise if I have over-stepped) Regan
Apr 03 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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.


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.


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.

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

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.


Right. Usually it means out-dated.

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

Apr 03 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
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!
Apr 04 2005
prev sibling parent SeeSchloss <ng seeschloss.org> writes:
 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).
Apr 10 2005
prev sibling parent reply Justin C Calvarese <jcc7 cox.net> writes:
Regan Heath wrote:
 On Fri, 01 Apr 2005 07:05:50 +0200, AEon <aeon2001 lycos.de> wrote:

  >dir *.log
     a.log
     b.log
     c.log

  > aepar.exe *.log
 -> args[0] = aepar.exe
     args[1] = a.log
     args[2] = b.log
     args[3] = c.log


 D take the above litterally:


 Any way to fix this?

No. You program needs to handle the wildcard itself. IIRC recls will help you here. Regan

In my experience, recls is great for tasks like this. That's what I'd probably use for processing files and directory using wildcards. 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) or compile the latest version yourself (http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Phobos/StdRecls). Hopefully, Walter and Matthew will be able to work out their differences soon since recls is a handy library, and it'd be great if DMD could use it "right-out-of-the-box" with the appropriate docs. -- jcc7 http://jcc_7.tripod.com/d/
Mar 31 2005
parent reply AEon <aeon2001 lycos.de> writes:
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
Apr 07 2005
next sibling parent J C Calvarese <jcc7 cox.net> writes:
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
Apr 07 2005
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
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
Apr 07 2005