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

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

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

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/

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

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

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

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

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

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