Bug(?) in S(uper)BASIC EX command

A place to discuss general QL issues.
Post Reply
User avatar
ql_freak
Gold Card
Posts: 353
Joined: Sun Jan 18, 2015 1:29 am

Bug(?) in S(uper)BASIC EX command

Post by ql_freak »

I have now finally installed C68 (on QPC2) and found a bug in the SBASIC (most probably also in SuperBASIC) EX command.

Directory structure:

WIN1_bin_
WIN1_bin_c68_

c68 is installed in WIN1_bin_c68, the PATH (set with PTH device) is WIN1_bin_;WIN1_bin_c68;...

ex'cc';'hello_c'

executes cpp (the preprocessor) and then it fails with "Compilation failed". Reason is:

The compiler name (c68) is the same as the subdirectory "c68" in "WIN1_bin_". As WIN1_bin_ comes before WIN1_bin_c68_ the EX command tries to execute the directory WIN1_bin_c68_ which of course must fail. If the PATH is changed to WIN1_bin_c68;WIN1_bin_ it will compile. Would be nice if this can be corrected. E.g.the EX command should check the type and if it's a directory, it should search for the name in the directory.


http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX :-)
Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Bug(?) in S(uper)BASIC EX command

Post by Derek_Stewart »

HI Peter,

I do not think this is bug, only your system not being setup correctly, consulting the C68 manual, the C68 compiler defaults can be set with Environmental Variables.

Here is a fragment from my boot file, line numbers omitted:

Set the C68 Environmental varaibles:

Code: Select all

REMark Set variables for C68
SETENV "CC_PATH=win1_c68_"
SETENV "CC_OPTS=-v -lm"
SETENV "CC_CPP=cpp"
SETENV "CC_COMP=c68"
SETENV "CC_ASM=as68"
SETENV "CC_LD=ld"
SETENV "CC_INC=win1_c68_Include_"
SETENV "CC_LIB=win1_c68_Lib_"
Now I set the Path setting:

Code: Select all

REMark setup Path Search
PTH_ADD "win1_"
PTH_ADD "win1_turbo_"
PTH_ADD "win1_asm_"
PTH_ADD "win1_c68_"
Now set the DATAD$ and PROGD$ to PTH1_

Code: Select all

DATA_USE "PTH1_
PROG_USE "PTH1_"

Code: Select all

ex cc;'hello_c -o hello_exe'
Compiles and links the C68 file 'hello_c' and produces an executable called 'hello_exe'

The DATAD$ and PROGD$ could be set to WIN1_ or what ever default device used, the environmental variables take care of the C68 path and defaults.

The C68 defaults can be overridden in the command line or in a make file.


Regards,

Derek
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Bug(?) in S(uper)BASIC EX command

Post by tofro »

This seems to be caused by the way you set up your pth device, but is definitely not a bug in EXEC.

EXEC has no ambitions whatsoever to "repeat until an executable file is found" - If you give it a file name which is not an executable, it will just fail (which is good).

the pth device will search through all its stored directories until it finds a file with a given name - It doesn't promise that file will be of any specific type (it doesn't even know what type you want).

In your case, it finds a file with the required name, which just happens to be a directory, and hands that to EXEC - that one sees it's not an executable file and does what it is expected to: It fails. All good in my opinion.

The secret for making this work is the order of the entries in the pth device driver's search lists. While you might be tempted to order these from coarse to fine (i.e. upper-layer directories first, as you have done), you should instead do that the other way round from fine to coarse (depth-first). Simply reverse the PTH_ADD commands to have pth search the sub-directories first rather than last, and you should be fine.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply