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


	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?

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.


  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?


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.


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


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


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