Path syntax

[Anonymous]

In version 14.08, the HELP file seems to clearly specify MS-DOS backslash () as path level separator, but the interpreter wants forward slash (/). Did I overlook something??

paddlewheel

[Rob Hagemans]

Hi paddlewheel,

Within BASIC it should be the case that only backslashes \ are allowed. For instance, LOAD "BASDIR\PROGRAM.BAS" works (for me at least). In INI files the forward slash / is used, as it's recognised correctly by both Windows and Unix. On the command line you should be able to follow your OS's conventions, so on WIndows either forward or backslash should be fine and on Unixes a forward slash should be used.

Can you give me an example of where the backslash doesn't work?
Which release of PC-BASIC and what operating system are you using?

Cheers,
Rob

[Anonymous]

I am running pc-basic-14.08-win32 on XP. Following programs exhibit "backslash and burn" behavior for the OPEN statement. Same for other statements I have tried using directory paths. For these programs, establish directory C:\APLAY\TEMP2 containing text files FILE1.TXT and FILE2.TXT (or edit programs for your test environment).

Program DEMO1.BAS follows:
10 REM pc-basic-14.08-win32: DEMONSTRATE USE OF '/' AND '\' IN PATHS
20 REM THIS PROGRAM IS "DEMO1", USING FIRST FORMAT FOR -OPEN- STATEMENT
30 REM FILES C:\APLAY\TEMP2\FILE1.TXT and C:\APLAY\TEMP2\FILE2.TXT EXIST
40 REM PROGRAM FAILS IF WHICH = 1 (MS-DOS PATH LEVEL SEPARATORS)
50 REM PROGRAM COMPLETES IF WHICH = 2 (UNIX PATH LEVEL SEPARATORS)
60 LET WHICH = 1
70 IF WHICH=1 GOTO 150
80 OPEN "I", #1, "C:/APLAY/TEMP2/FILE1.TXT"
90 LINE INPUT #1, INLINE$
100 PRINT INLINE$
110 CLOSE #1
120 STOP
130 END
140 LET INLINE$ = " "
150 OPEN "I", #1, "C:\APLAY\TEMP2\FILE2.TXT"
160 LINE INPUT #1, INLINE$
170 PRINT INLINE$
180 STOP
190 END

Program DEMO2.BAS follows:
10 REM pc-basic-14.08-win32: DEMONSTRATE USE OF '/' AND '\' IN PATHS
20 REM THIS PROGRAM IS "DEMO2", USING SECOND FORMAT FOR -OPEN- STATEMENT
30 REM FILES C:\APLAY\TEMP2\FILE1.TXT and C:\APLAY\TEMP2\FILE2.TXT EXIST
40 REM PROGRAM FAILS IF WHICH = 1 (MS-DOS PATH LEVEL SEPARATORS)
50 REM PROGRAM COMPLETES IF WHICH = 2 (UNIX PATH LEVEL SEPARATORS)
60 LET WHICH = 1
70 IF WHICH=1 GOTO 140
80 OPEN "C:/APLAY/TEMP2/FILE1.TXT" FOR INPUT AS #1
90 LINE INPUT #1, INLINE$
100 PRINT INLINE$
110 CLOSE #1
120 STOP
130 END
140 LET INLINE$ = " "
150 OPEN "C:\APLAY\TEMP2\FILE2.TXT" FOR INPUT AS #1
160 LINE INPUT #1, INLINE$
170 PRINT INLINE$
180 STOP
190 END

(I have -- don't laugh -- production programs in GW-BASIC which I need to migrate unchanged to Windows 7 without VDM.)

[Rob Hagemans]

Thanks, those are very clear demo programs.

Bizarrely, I cannot reproduce the bug. I'm running a freshly downloaded pc-basic-14.08-win32 on Win XP SP3 (in VirtualBox) and the program runs as expected: if which=1 (the ms-dos backslashes), it prints the contents of FILE2.TXT; if which=2 (forward slashes), it raises File not found in 80.

When you say the program fails, what exactly happens? Does it give an error in BASIC or does PC-BASIC crash?

If it's a BASIC error, which error do you get exactly?

If it's a crash, would you mind trying to run it from the command line with pcbasic --debug, trigger the bug, and paste the full error trace back in the forum? You should see c.10-20 lines of messages from Python if there's a crash, and they would greatly help me to find out what's going on here.

Thanks,
Rob

[Anonymous]

My bad for not providing more info on failure:
DEMO1 and DEMO2 with WHICH=1 fail with "File not found in 150" (line number of OPEN statement). I am running Windows XP, announcing as: "Version 5.1 (Build 2600. xpsp_sp3_qfe.130707_0421)" on three machines, one is XP Professional and two XP home. I have not knowingly tinkered with anything which might change path separator behavior. I have no experience with VirtualBox.

BUT WAIT: Behavior seems to depend on how many path levels are involved. Although we are still reversed on long-path behavior in DEMO1 and DEMO2. I will try to make sort this out and report....

Happy Halloween!
paddlewheel

[Rob Hagemans]

Thanks for that - running in VirtualBox should really not make a difference, though I would try it on an actual Windows machine if I had one at hand (I don't).

I'm still a bit baffled about this bug - don't know what could be causing it and I haven't been able to reproduce so far, so your help is much appreciated (indeed for now you're the only one of us who can find out what's wrong here :)

One thing I have noticed is that PC-BASIC on my systems accepts forward slashes, but only when no drive letter is given. This kind of makes sense as the code replaces the drive letter with a path that uses backslashes; presumably Windows doesn't like mixing forward and backslashes in one path. Backslashes always work for me, but of course that's no help to you.

Just a hypothesis, but perhaps Python depends on some DLL to put in the path separators and that DLL has been replaced with something else? (I use os.path.join to connect paths in a platform independent way).
In any case I'd be interested to know the output on the command line if you run pcbasic --debug and then type the following command into the interpreter: debug import os; print os.path.join('a', 'b')

I don't really understand what you mean by "Although we are still reversed on long-path behavior in DEMO1 and DEMO2" but the more you can find out to narrow down the issue, the better it would be.

Is there any way you could try to run the PC-BASIC python code from git? Your demo programs need no graphics and could run from the command line so you probably wouldn't even need to bother installing PyGame, a bare Python install may well work.

[Rob Hagemans]

Also, do you use any command-line options or have you changed settings in PCBASIC.INI? If so, what are the exact settings?

[Rob Hagemans]

One more thing - I just notice you referred to "establish directory C:\APLAY\TEMP2". Please note that by default (perhaps somewhat confusingly), PC-BASIC maps its C: drive letter to the current working directory, not to the Windows C: drive. If you run PC-BASIC by double clicking in Explorer, the working directory is the install directory. Have you tried putting the APLAY directory and its contents in there?

I'll try and see if I can reproduce your error if I put APLAY directly under C:\ ; I'm not sure why it would work with forward slashes in that case, but it may well be the case.

If you do need access to the Windows C: drive, either use --windows-map-drives (--map-drives in more recent versions) or something like --mount C:C:\\ or set the equivalent entries in PCBASIC.INI .

[Rob Hagemans]

PROBABLY SOLVED

OK, I can now reproduce what's going on. If the directory C:\APLAY exists in Windows, but no mount or map-drives option is given, PC-BASIC won't see it as C:\APLAY because C:\ is mounted to the current working directory. The fact that it does see it if you write C:/APLAY is a strange consequence of the way PC-BASIC manipulates paths, and basically a bug. It only works in this specific circumstance.

I suspect this is where your problem lies; the easiest way to make your program work as you expect is to specify windows_map_drives=True in PCBASIC.INI. (Note that option names aren't stable yet; in the next version that option will simply be called map_drives.)

I'll make clear in the documentation that C: is mounted to the working directory, and ensure forward slashes simply produce an error, to avoid confusing effects like these.

[Anonymous]

Rob -
THANK YOU! I will try this change in PCBASIC.INI and play it against my BASIC programs.

paddlewheel

[Anonymous]

Rob -
With Windows drive mapping, my legacy programs (using backslash in pathnames) all run OK unchanged on 14.08 and 14.10. Thanks again for unraveling this mystery! I am happy and consider this closed vs my needs.

BUT: If I create a virtual drive on Windows (SUBST command), it is not honored in the pathname. Also, under Windows, using slashes (/) some very strange things sometimes happen -- if an output file is opened with a pathname beginning with "/" or "C:/" the file perhaps vanishes although there is no error.... These are not a need or problem for me, but thought I would pass them along.

Please forgive my all-caps BASIC code -- I first encountered BASIC using a Model 35 Teletype, and old habits die hard...

cheers...
paddlewheel

[Rob Hagemans]

Hi, great that it all works for you now.

As for SUBST, are you issuing the command when BASIC is already running? We map the drives that are reported by the win32 api at startup of PC-BASIC, so if you do a SUBST afterwards, it won't be recognised (assuming the API reports SUBSTed drives correctly in the first place). It's not really a scenario I've thought about, I may find a better way of handling this in a later release.

In the latest release, forward slashes are no longer accepted in paths; using a forward slash will simply result in File not found. This solves the strange and undefined behaviour on forward slashes of the older versions. Since forward slashes aren't legal in filenames anyway (neither in Windows nor in Unix) and BASIC programs should be using backslash separators following MS-DOS (which unlike Windows doesn't allow forward slash path separators), I think this is the best solution. (Actually, the error should be Bad file number. Not that that makes sense, but it's the error that GW-BASIC produces in this case.)

All-caps code is fine for GW-BASIC, after all that's how the interpreter formulates it... All-caps isn't quite as bad as the rather annoying Capitalise Every Keyword Separately that things like VB seem to enforce. But maybe that's just to encourage us to steer well clear of VB :)

[Anonymous]

Hi Rob -
Sorry to take so long to get back to you. I cannot replicate the failure to locate files on an XP virtual drive (SUBST command). I can only conclude that this was my bad and I raised a false alarm.

best wishes,
paddlewheel

[Rob Hagemans]

No worries, glad things work all right.

I suspect you may still be able to reproduce if SUBST is executed after starting PC-BASIC - I don't think it will recognise the drive letter in that case. It's a bit of a corner case, but that may be what you did earlier.