@dir$ equivalent in Compiled program

[mavison]

I have a small 'utility' program compiled using BBC SDL.

It runs in a user directory on another disc, well away from C:\Users because it contains a set of user files and programs that I have no control over.
The utility program needs to be able to process a list of the sub-directories and files in that user directory to produce a summary of the files - and the user directory is not a fixed name.

However, although it is easy to find the location using @dir$ or @cmd$ when running interactively, that does not work when running compiled, as they have to refer to the temporary location of the extracted program. (see thread Have @dir in a compiled program point to current directory?)

Passing a parm to the program does not work.

The only way I have found is to run a cmd file which writes the current directory (%~dp0) to a file in %appdata%/BBCBasic/
It then starts the BBC BASIC program, which reads that file from %usr$ to obtain the location.

This method does work, but I cannot help thinking that there must be a better way ... can anyone suggest one?

[Richard Russell]

It runs in a user directory on another disc, well away from C:\Users because it contains a set of user files and programs that I have no control over.

If there's a directory which your program needs to access, but it's neither at a fixed location relative to the root, nor relative to @usr$, @dir$ or @tmp$, your only option is to supply the name of that directory as an input to the program. It's just like any other 'variable' data that the program requires as input, the fact that it happens to be a directory name isn't significant.

It could for example be entered by the user (and perhaps then stored so he doesn't have to enter it again), or read from a configuration file, or read from a registry entry etc. It could even be read from the internet!

It's admittedly unfortunate that you cannot straightforwardly use the command line to pass information such as this, when you 'compile' to a standalone Windows exe. You can if you use the alternative approach of creating a Zip archive which is unpacked in the installation directory. In that case you can pass a switch (starting with a hyphen) to the executable and it will appear in @cmd$.

So one possibility would be to use that alternative method of 'compiling', if you don't mind the end user having to extract a zip. Ideally I should investigate the possibility of making the @cmd$ feature work with a standalone exe too, but I don't know how practical that is.

[Richard Russell]

Ideally I should investigate the possibility of making the @cmd$ feature work with a standalone exe too, but I don't know how practical that is.

I think I can do that, except that @cmd$ would contain a lot more than just the command-line switch(es), and you would have to look for a hyphen to identify where the switches begin.

For example running a 'compiled' BBCSDL program as myprog.exe -test would set @cmd$ to "-test" when built as a .zip, but to something like "C:\Users\richa\AppData\Local\Temp\BBC6DF3.tmp\myprog.bbc -test" when built as a standalone exe.

Could you live with that?

[mavison]

alternative approach of creating a Zip archive

That only seems available for Linux, not Windows?
And a switch to me implies a binary yes/no value, but a string value may be possible.

But it presumably would still need a command file to start the exe file with the switch?

So, thanks for the suggestion, but I think I will probably stick with using a cmd file to creating a file & start the exe to read it.

[mavison]

Could you live with that?

If the cmd file could contain one of

Code: Select all

start /B %~dp0exe/RPCEsetup.exe   -%~dp0
start /B %~dp0exe/RPCEsetup.exe   -dir %~dp0

then it would simplify the cmd file and remove the file processing.
But if -test is just a yes/no fixed switch, then it would not really help.

And I still cannot find how to compile to a zip (though I do already put the exe into a zip with some other stuff).

[Richard Russell]

That only seems available for Linux, not Windows?

Nope, Windows too. From the BBCSDL documentation:

"By default the filename of the application bundle is set to be the same as the name of your BASIC program, but with the extension '.exe', '.dmg', '.zip' or '.bbb' rather than '.bbc' (or '.bas'). However you can change the name and/or the directory path (folder) by entering them directly, by clicking on the Browse button or by using the REM!Exefile compiler directive. In Windows you can create a '.zip' archive as an alternative to '.exe'".

And a switch to me implies a binary yes/no value

That's not what 'the internet' says: "A command-line switch is a modifier that can be added to an .exe file. For example, to add a command-line switch to Microsoft Outlook, you can use the following startup file: outlook.exe /nopreview". I'm using it in that sense, synonymous with 'command line parameter' or 'command line flag'. It can be any string.

[jgharston]

You are "supposed" to refer to switches and options, but I never remember to get them right, so I tend to just call them all command line parameters.

[jgharston]

This method does work, but I cannot help thinking that there must be a better way ... can anyone suggest one?

A batch file containing:
pathtoprogram\myprogram.exe %0

Run the batch file and the %0 gets replaced with the path and name of the actual batch file itself, so just fn_path() it to get the directory the batch file is in. I use this method in my Make system.

Compile this test program and run it from a batch file with the above content, and you'll see what it does:
10PRINT @cmd$

[mavison]

Having relaxed my own definition of 'switch', and found how to create a zip bundle, I have found that a command file containing

Code: Select all

start /B myprogram.exe -%0

results in @cmd$ holding the full path of the cmd file - just as it does when running interactively (with the bbc file).

Many thanks to Richard and JGHarston for pushing me in the right direction!
And as it no longer creates a temporary exe file, I think it also avoids my other problem with redundant Registry entries!

However, although the REM!Exefile directive affected the file name, it ignored the zip suffix and was always exe, so zip had to be manually set.

[Richard Russell]

I have updated the Windows editions (only) of BBCSDL to version 1.40b. These now append the command line 'tail' (flags / options / parameters / switches) to @cmd$, allowing them to be read by the BASIC program.

However since @cmd$ still contains the path to the .bbc file it will be necessary to use INSTR to search for an introductory character to identify the parameter(s). In Windows oblique stroke (/) is commonly used for that purpose, but I don't recommend it in a cross-platform context because of its use as a directory delimiter in MacOS and Linux.

So a hyphen / dash (-) is probably a better choice because it should be acceptable and unambiguous on all the relevant Operating Systems.

If you want to extract command line parameters not introduced by a special character, you could probably search @cmd$ for the .bbc and consider anything after that to be the 'tail':

Code: Select all

      CmdLine$ = @cmd$
      dotbbc% = INSTR(CmdLine$, ".bbc ", LEN(@dir$))
      IF dotbbc% CmdLine% = MID$(CmdLine$, dotbbc%+5)