Have @dir in a compiled program point to current directory?

[jeroen_soutberg]

[Windows 11, BBC BASIC for SDL]
In a simple program, I used OSCLI "*DIR *.jpg > filelist.txt" to get a list of jpg files currently available in the directory in which the program resides.

That works as expected, but compiling the program fails, as the exe refers to the temporary directory that was used in compiling (which then generates a bad command because that temporary directory does not exist anymore).

What would be the correct way to make the exe use the directory in which it actually resides (not known at time of compiling) as @dir?

[Hated Moron]

In a simple program, I used OSCLI "*DIR *.jpg > filelist.txt" to get a list of jpg files currently available in the directory in which the program resides.

What would be the correct way to make the exe use the directory in which it actually resides (not known at time of compiling) as @dir?

This should work:

Code: Select all

      OSCLI "*DIR """ + @dir$ + "*.jpg"" > filelist.txt"

You might also like to consider using FN_dirscan() in the filedlg.bbc library, which is provided specifically for this purpose (and is a cross-platform solution, whilst yours will work only in Windows):

"This function scans a specified directory and returns the files (and sub-directories, if appropriate) it contains in a string array".

[jeroen_soutberg]

Many thanks for pointing me in the right direction, especially to the FN. Will work on that this afternoon.

[jeroen_soutberg]

I have now tried both options in very simple test programs,using a test folder D:\OSCLItest containing some jpg files and the test programs, and both programs exhibit the same behaviour: running them using the Run command they do exactly as expected, but when I try to compile them, that fails:

The FN_dirscan-program is

Code: Select all

      INSTALL @lib$+"dlglib"
      INSTALL @lib$+"sortlib"
      INSTALL @lib$+"stringlib"
      INSTALL @lib$+"filedlg"
      DIM imageList$(300)
      numberofImages% = FN_dirscan(imageList$(),"dir *.*",".jpg","","")
      PRINT numberofImages%
      END

When trying to compile this, it fails with the message
Couldn't copy 'D:\OSCLItest\*.jpg'

In the compiler window, I unchecked all optimization options. The utility lists the following Embedded files:
@lib$+"dlglib"
@lib$+"sortlib"
@lib$+"stringlib"
@lib$+"filedlg"
@dir$ *.jpg

The OSCLI-program is

Code: Select all

      OSCLI "*DIR """ + @dir$ + "*.jpg"" > filelist2.txt"
      PRINT"After OSCLI"
      END

Again I unchecked all optimization options in the compiler window. As expected, the utility now lists as Embedded file only
@dir *.jpg

and this also fails with the message
Couldn't copy 'D:\OSCLItest\*.jpg'

I would be grateful for an explanation of what happens here, and a possible solution.

[Hated Moron]

I would be grateful for an explanation of what happens here, and a possible solution.

There seem to be a couple of issues. Firstly, you can't (currently, at least) specify a wildcard in the list of embedded files, so this isn't valid:

Code: Select all

 @dir$ *.jpg

In a case such as this you should specify the embedded files explicitly using one or more REM!Embed directives. The option to include a wildcard is something that I could consider for a future release.

Secondly, your program still suffers from the same issue as your previous attempt, in that it assumes that the current directory is the same as the directory containing the executable, and although that will usually be the case when a program is run from the IDE it generally won't be when 'compiled'.

So when referencing files in the same directory as the executable you need to do so explicitly:

Code: Select all

      numberofImages% = FN_dirscan(imageList$(),"dir """ + @dir$ + "*.*""",".jpg","","")

Indeed in this case (where you are only interested in files with a .jpg extension) it would be better to filter them earlier (in the DIR command):

Code: Select all

      numberofImages% = FN_dirscan(imageList$(),"dir """ + @dir$ + "*.jpg""","","","")

If I try compiling this program it works for me (with images I happen to have in the same directory):

Code: Select all

      REM!Embed @lib$+"sortlib", @lib$+"stringlib", @lib$+"filedlg"
      REM!Embed @dir$+"colosseum.jpg", @dir$+"virtual.jpg", @dir$+"freed.jpg"

      INSTALL @lib$+"sortlib"
      INSTALL @lib$+"stringlib"
      INSTALL @lib$+"filedlg"

      DIM imageList$(300)
      numberofImages% = FN_dirscan(imageList$(),"dir """ + @dir$ + "*.jpg""","","","")

      PRINT numberofImages%
      END

[Hated Moron]

The option to include a wildcard [in a REM!Embed directive] is something that I could consider for a future release.

As this would clearly be a valuable feature, I can confirm that (barring unexpected side-effects) I will add this capability to the next release of BBC BASIC for SDL 2.0. Thank you for alerting me to this possibility, which I have considered previously but hasn't risen to the 'top of the pile'.

[jeroen_soutberg]

Thank you very much for the explanation. Indeed, if I embed only one jpg file explicitly the compiler finishes without errors, and the exe, when moved to the directory where I keep some 200 jpg files for an anniversary celebration, generates exactly the list of those 200-something I need.

For a more general list, it would indeed be great to have the possibility you describe above (saw that only after posting the first version of the present post).

[jeroen_soutberg]

In hindsight, I think what I would very much like to have is the possibility to use a variable similar to @dir$ that behaves as @dir$ in the compiled program (i.e. contains the directory in which the exe lives when it is executed, not the directory in which it was compiled).

[Hated Moron]

In hindsight, I think what I would very much like to have is the possibility to use a variable similar to @dir$ that behaves as @dir$ in the compiled program (i.e. contains the directory in which the exe lives when it is executed, not the directory in which it was compiled).

Sorry, I don't understand; what do you mean by "the directory in which it was compiled"?

The purpose of @dir$ is to provide a 'starting point' from which your program can locate the resource files it needs, so for example image files might be in @dir$ + "resources/images/" and sound files in @dir$ + "resources/sounds/" etc.

Here's a snippet from a large program (David Williams' 'Forces of Darkness') showing how he loads sub-modules:

Code: Select all

      INSTALL @dir$+"Resources/Lib/PROC/PROCInitNewGame.bbc"
      INSTALL @dir$+"Resources/Lib/PROC/PathHandlers.bbc"
      INSTALL @dir$+"Resources/Lib/PROC/PROCDrawNasty.bbc"
      INSTALL @dir$+"Resources/Lib/PROC/PROCDrawNastyShadow.bbc"
      INSTALL @dir$+"Resources/Lib/PROC/PROCHandleNasty.bbc"

This ensures that the program will run correctly wherever it is installed.

What do you want to do that you cannot do now?

[jeroen_soutberg]

I would like to be able to use @dir$ in a compiled program in the same way as I can use it in the original program, e.g., having PRINT @dir$ printing the directory in which the program/the exe is run.