Message-Id: <1.5.4.32.19970930133200.006a400c@dce03.ipt.br>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 30 Sep 1997 10:32:00 -0300
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: Cesar Scarpini Rabak <csrabak AT dce03 DOT ipt DOT br>
Subject: Re: libc functions handling of UNCs
Cc: djgpp AT delorie DOT com
Precedence: bulk

At 13:27 30/09/97 +0200, Eli Zaretskii wrote:
>
>On Mon, 29 Sep 1997, Cesar Scarpini Rabak wrote:
>
>> >Btw, why did you at all tried to call `ls' with the UNC?  "ls f:"
>> >should have worked, AFAIK, and that is how `ls' and other DJGPP
>> >programs are supposed to work.
>> 
>> In the last paragraph of my post, I mentioned that this was the same
>> behaviour I 'm experiencing when we use fnsplit and fnmerge, where the
>> problem was detected at first at all.
>
>The same question pertains to `fnsplit': why not use the usual DOS
>d:/path syntax?  What's so special in the UNC that you needed to use
>it in this case?
>
>(`fnsplit' is a compatibility function anyway, it was never meant to
>handle UNCs at all.)
>

The code we created does the following:
    .
    .
    .
    char                szDrive[MAXDRIVE],
                        szPath[MAXDIR],
                        szFile[MAXFILE],
                        szBuff[MAXPATH];
        
    fnsplit(argv[0], szDrive, szPath, szFile, NULL);
    fnmerge(szBuff, szDrive, szPath, szFile, ".ini");   
    .
    .
    .
Then szBuff is used to open and read an initialization file. The libc
function that bring the UNC to the argv[0].

Hope this is more explicit now... 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cesar Scarpini Rabak                      E-mail: csrabak AT ipt DOT br
DME/ASC                                   Phone: 55-11-268-3522 Ext.350
IPT - Instituto de Pesquisas Tecnologicas Fax:   55-11-268-5996
Av. Prof. Almeida Prado, 532.  Sao Paulo - SP 05508-901 BRAZIL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~