Re: [cc65] Filenames for POSIX functins on CBM targets

Hi,

> André's idea to have two different chars (I think this was meant this
> way?) would have been a good one, that's why I answered to that.

I see. Thanks for clarifying.

>> > - 8:0:name
>>
>> This would mean unit 8 drive 0.
>
> Yes. But: The computer has to process the "8:" and skip it, sending
> everything else to the drive.

That's the idea.

>> > - 8:@0:name (yes, overwrite-with-at is problematic, I know...)
>>
>> This would mean unit 8 and te rest would behave in the same way
>> "@0:name" would behave today.
>
> Agian, the "8:" has to be skipped by the computer, the rest is processed
> by the drive.

Surely.

>> > - 8:@name
>>
>> This would mean unit 8 and te rest would behave in the same way
>> "@name" would behave today.
>
> Here, again, the "8:" must be skipped by the computer.

Ack.

> I should have had more examples, because I missed some important ones:
>
> - @0:name
> - @name

Those would go as-is to the drive.

> - 0:name
>
> All three of them have to be sent verbatim to the floppy.

This is indeed the interesting one!

My proposal is to re-interpret this as unit 0 and send only "name" (to
unit 0). In order to regain the functionality "0:name" has today one
would have to use "8:0:name". Given that many guys here said that they
don't use drives != 0 at all this seems a rather small sacrifice to
me.

> So, just searching for a colon in the C library would not be sufficient.

With the idea above it _would_ be sufficiet.

> I still like the chdir()/getcwd() proposal:
>
> - chdir("8") --> _curunit = 8;
>
> Of course, it could also be more complicated. This would be optional, it
> would not break existing code and it would not lead to surprises.

The problem with this is that it doesn't solve the problem I started
out with. A single string that contains the "absolue path". Think
about my example of some editor asking for the filename to save. Or
think about a file copy program. It should have two deal with two
strings, the source file and the target file. It shouldn't be
obligated to do two chdir()'s just before each open() in order to open
the files at the right location. This just isn't POSIX style. It's not
much better than having to set _curunit here and there.

> Think about anyone wanting to translate some BASIC program to C. He
> would not only have to translate the statements, but also check each and
> every file name if it has to be translated...
>
> Even formatting (OPEN 1,8,15,"N:NAME,ID") would need a translation.

That's a good question: Are we more after easy conversion of BASIC
programs or are we after easy implementation of cross-target POSIX
style programs?

I know my preference for sure ;-)

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.