Files and paths, using ENV$() and current working directory

[Wanderer]

I have problems getting file/directory searching to work, and I found several bugs.

FSFIRST/FSNEXT:

This statement seems not to take into account the "attribute" parameter; it returns always everything it finds. Also, in the Windows version there is a strange bug which causes an error when I first search files in a subdirectory and after that try to perform the same search on the parent directory. The following test program demonstrates both bugs:

If android?
  baseDir$ = "/mnt/sdcard/bas"
  PathSepChar$="/"
EndIf
If win32?
  baseDir$ = "C:\develop\x11B"   !'the X11-Basic directory on my system
  PathSepChar$="\"
EndIf
path$ = baseDir$+PathSepChar$+"testDir"
ret%=@ListFiles%(path$)
path$ = baseDir$
ret%=@ListFiles%(path$)
Input x
End

Function ListFiles%(path$)
  Local f$
  Print "PATH = "; path$
  Print "Directories:"
  f$ = fsfirst$(path$, "*", "d")
  While f$<>""
    Print f$
    f$ = fsnext$()
  Wend
  Print "Files:"
  f$ = fsfirst$(path$, "*", "f")
  While f$<>""
    Print f$
    f$ = fsnext$()
  Wend
  Return 0
End Function

(Note: I am accustomed to program all my subroutines as FUNCTIONs, for the following reasons:
- Even if at the beginning it seems not necessary to return a value, later on in development I might find that I want to return one, and then it is easier to use an existing FUNCTION than to convert a PROCEDURE into a FUNCTION.
- The syntax for a FUNCTION is more consistent among different dialects of BASIC, so porting code to other dialects is easier for FUNCTIONs than for PROCEDUREs.)

Output of the above program (Windows version):

PATH = C:\develop\x11B\testDir
Directories:
- test1.txt
- test2.txt
d testDir2
Files:
- test1.txt
- test2.txt
d testDir2
PATH = C:\develop\x11B
Directories:
ERROR at line 19: * File C:\develop\x11B\testDir/xbvm.exe not found
Error within FUNCTION. pc=12, sp=0, FATAL!
ERROR at line 11: Incorrect parameter,  must be number

These errors do NOT appear when I switch the order of the directories to search, i.e. searching first the parent directory and then the subdirectory. Also, they do not appear in the Android version (but the Attribute parameter is there also ignored).

Another remark: It is somewhat inconsistent that the file listing returns a "-" character for normal files, while the syntax for FSFIRST (according to the manual) requires "f".

Relative pathnames, current directory:

I found that the Android version does not work with relative path names (such as "myDir", "./myDir", "../myDir"). On Windows it works, but ONLY if I call X11-Basic from a wrapper program which first sets the current working directory to the one where the .bas program resides. So the problem seems to be not with the path names themselves, but that X11-Basic does not define the current working directory, and neither provides a way to retrieve it from inside the program. There should be a way to retrieve from inside a program the full path of the directory where the ".bas" (or "*.b") file resides, and to set the current working directory to that one. (This would also overcome the limitation that on Android, all the programs must necessarily be stored in /mnt/sdcard/bas.)

FILESELECT:

The list shown in the window for FILESELECT lists only directories, but no filenames to select from. (Both on Windows and Android.)

# character in file operations:

Another problem was that according to the documentation, the statements for file operations such as BGET, BPUT, OPEN, CLOSE, require a # character before the file number. But when I coded them like this, I got error messages (I don't remember whether on Android, on Windows or on both). Writing only the file number without the # fixed the problem.

[Markus Hoffmann]

You are right, something looks strange here. But can you please try to use the slash for pathsepchar even on windows? Maybe it got confused by the backslash.

[Wanderer]

OK, I will try that and report back next time I am here.
I forgot that Windows now accepts the (forward) slash character too; on older versions of Windows this might cause an OS error, but I do not know from which version on they changed this.

[Wanderer]

I'm already back for a moment - I changed the program to use forward slashes also under Windows. The output was exactly the same as before. Except, of course, that the path strings now contained forward slashes.

[Markus Hoffmann]

Confirmed: The windows version behaves strange. Need to investigate...

[Markus Hoffmann]

I found the stupid bug. Its fixed now. The next release 1.23-20 will have that fixed. You can use forward or backward slashes in WINDOWS. Both work.

[Markus Hoffmann]

Current working directory:
set it with CHDIR
get it with
PRINT ENV$("PWD")

[Wanderer]

Thank you! Did not find this in the manual.

(Edit) - but under Windows, it does not work like this. But luckily I found another way how to do it.

ENV$() seems to rely on the OS, but there is no environment variable called "PWD" under Windows. You can retrieve several fixed system paths via environment variables in Windows (Programs directory, temporary files directory, current user's home directory ...), but not the current working directory.

On the other hand, I found that under Windows, if you run an X11-Basic program directly, param$(1) seems to return always the full pathname of the loaded source file (resp. bytecode file); and if you open the interpreter, param$(0) seems to return always the full pathname of xbasic.exe; so this provides a way to retrieve this path. - On the other hand, in the first case, param$(0) may return only "xbasic.exe" (resp. "xbvm.exe") without path; this depends on the exact way the program was started. So the program would have to check both param$(0) and param$(1) in order to find its own path.

However, this did not work under Android. When opening the interpreter, param$(0) returns only "xbasic". I could not test direct opening of programs, since on my device the installation did not associate *.bas files with xbasic, and I do not know how to do this manually. When I try to open a *.bas file, I get an error "Incompatible file type" and no applications to choose from.
ENV$("PWD") seems not to exist on Android either.

[Markus Hoffmann]

I have implemented DIR$() now.

PRINT DIR$(0)
will give you the current working directory unter Windows and linux. In Android this results in an empty string, this is because Android apps do not have a current working directory by design of the operating system. This is also the reason, why ENV$("PWD") does not return anything useful.

[Markus Hoffmann]

To stay compatible with GFA-BASIC it should be a function:
DIR$
Syntax: DIR$(n)
Action: Names the active directory for drive 'n'
'n' is drive number (1=A:, 2=B: ...).

Where the parameter n would be ignored.

[Markus Hoffmann]

Filesel€ct:
what was the exact command you used? Have you set the mask to "*"?

[Wanderer]

Thank you, I see now what I did not understand about FILESELECT: I had put the "*" into the "default file" parameter, and this did not work. Now, when I appended the filemask to the path, it worked correctly.

[Markus Hoffmann]

# charackter: was it a constant or a variable? Only constants like #3 or #77 take the # charackter.

[Wanderer]

I think it was a variable. Most other dialects of BASIC I know (QBasic, PowerBasic, FreeBasic) use the # character consistently before both constants and variables. I think FreeBasic accepts the statement both with and without the #.
Is BPUT 3, (... etc) also allowed, or is the # required in this case?

I think the syntax should be consistent, either requiring # in both cases or doing without in both cases. - Actually, I think the use of the # comes from the fact that most other BASIC dialects use the same statements (GET, PUT) for both graphics and File I/O, so there had to be some way to distinguish the one from the other. But X11-Basic uses different statements, so I think there would not be any need anyway to use the #.

[Markus Hoffmann]

Yes, you are right, the syntax is not consistent. e.g. with OPEN you have to use a constant with # or a variable without. LINEINPUT always needs the #. I'll try to fix it.