Whats with DEV?

[pjw]

DEV doesnt appear to work with sub-sub-directories if a sub-directory is part of the definition:

If I define DEV thus:

Code: Select all

DEV_USE 1, "win2_"

then I can do DIR DEV1_ and get a list of all files and directories in win2_. So if theres a directory called win2_doc_, then doing DIR dev1_doc_ will list all files and directories in win2_doc_. Now say there is a directory win2_doc_tmp_ that I want to view the contents of, doing a DIR dev1_doc_tmp_ will display its contents. Fine!

However, if I define DEV thus:

Code: Select all

DEV_USE 1, "win2_doc_"

then doing DIR dev1_ works as expected, ie it shows the contents of win2_doc_, but doing DIR dev1_tmp_ does not list the contents of win2_doc_tmp_ as expected, it just gives the basic stats of the drive, same as if one were requesting to list a non-existent directory.

I only noticed this recently, as of SMSQ/E V3.35+, but it could have been this way for a while.. Is this how its meant to be?

[mk79]

Notice the filenames you get out of DEV when you DIR. Unlike the PTH device, DEV is a pure "open-redirector". It opens the new name and gets out of the way completely, it's not even there anymore. So there is no translation of DIR path names! So your wildcard cannot match names as they still contain the base directory names. If you want or need that behaviour, use PTH.

P.S.: Why wild card? DIR always filters the names using the string supplied. So in your example the filenames will always be returned as doc_tmp_xxx no matter how you defined your DEV in the first place. DIR tries to match that against the "tmp" string and will find no name that starts with "tmp".

[pjw]

Hi, Thanks for your comprehensive reply

Notice the filenames you get out of DEV when you DIR. Unlike the PTH device, DEV is a pure "open-redirector". It opens the new name and gets out of the way completely, it's not even there anymore. So there is no translation of DIR path names! So your wildcard cannot match names as they still contain the base directory names. If you want or need that behaviour, use PTH.

..
CROSS-REFERENCE:
The path device is very similar to the DEV device, please read through
DEV_USE to understand the idea behind both devices.

Well, I did that some years ago, and to me they seem very different,
but what do I know.

Ive had run-ins with PTH before, when it first hit the scene, and
while its a great piece of software engineering, Im not fond of it.
DEV seemed just the ticket until I hit the snag with sub-sub-
directories.

P.S.: Why wild card? DIR always filters the names using the string supplied. So in your example the filenames will always be returned as doc_tmp_xxx no matter how you defined your DEV in the first place. DIR tries to match that against the "tmp" string and will find no name that starts with "tmp".

So just as a matter of interest, how do people here solve the
following problem:

Say you have a few different "QL" platforms, but you like to maintain
a single setup. However, the platforms have differences that mean that
in some cases different settings are required. Or you like to keep
your game stats separate to accumulate them rather than just overwrite
them!

So what Ive done til now is at boot time to define different
directories for the different platforms. Just as an abbreviated
example:

Code: Select all

mch = MACHINE
SELect ON mch
 = 18: REMark Q68
       DEV_USE 2, 'fat1_HDW_'
 = 20: REMark SMSQmulator
       DEV_USE 2, 'nfa8_' & EMU_NETNAME$ & '_'
 = 30: REMark QPC2
       DEV_USE 2, 'dos8_' & QPC_NETNAME$ & '_'
END SELect
:
LRESPR 'dev2_FILEINFO2_bin'

Some other programs also need different settings depending on the
platform, and so are configured to find them on dev2_

That means I can backup my entire system from one platform to another
by copying the various drives as complete QLWA files, thus ensuring
that re-organisations, deletions, renames etc are all intact - ie
there is only ONE system. The small settings directories are updated
using a standard file backup operation, taking at most a few seconds.
Each platform's subdirectories get updated normally and they dont
interfere with each other as no two platforms address the same sub-
directory.

But now I have a program that doesnt just need a single file to keep
its platform-differentiated settings. There are a number of files, so
it makes sense to keep them in their own sub-sub-directory. I was
hoping to put them in dev2_xxx_ but that isnt possible. So what is the
solution (short of using yet another extension like PTH)?

(Apologies for the long post (again!))

[Derek_Stewart]

Hi,

I think SUB would be better comparison to DEV, which strips off the
directory tree.

[mk79]

Ive had run-ins with PTH before, when it first hit the scene, and while its a great piece of software engineering, Im not fond of it.

Actually I meant the SUB device, not PTH! Mixed them up, sorry. SUB is more or less like DEV, but has working directory support.

P.S.: Didn't see Derek's post before. But yeah, SUB it is.

[pjw]

Thanks Derek and Marcel,
Yes, SUB would solve my problem. Funny I didnt think of it myself, as the first QL device driver I wrote was functionally similar to the SUB device (I may even have called it DEV?) but Phil Borman pipped me to the post and so I dropped the project before it was properly working. IIRC it was inspired by a project by SNG.
I guess I am just a bit reluctant to clutter my system with yet another device. Perhaps I could just rename SUB to DEV and load it over?
Oh well, thanks again

[pjw]

So the solution I plumped for in the end (at least for a trial period) is:

Code: Select all

mch = MACHINE
SELect ON mch
 = 18: REMark Q68
       DEV_USE 2, 'fat1_': REMark Not sure about this..
 = 20: REMark SMSQmulator
       NFA_USE 8, 'D\QL\HDW\' & EMU_NETNAME$
       DEV_USE 2, 'nfa8_'
 = 30: REMark QPC2
       DOS_DRIVE 8, 'D\QL\HDW\' & QPC_NETNAME$
       DEV_USE 2, 'dos8_'
END SELect
:
LRESPR 'dev2_FILEINFO2_bin'
..

In other words, Im sticking with DEV!

My D:\QL\HDW\ looks something like:

Code: Select all

D:\QL\HDW\Iota
	\MenuConf_INF
	\FileInfo2_bin
	\Qwirc_rsc
	etc
D:\QL\HDW\Labda
D:\QL\HDW\Theta
etc

for all the different platforms, with each of those folders containing the various platform-specific configuration- and data- files.
As can be surmised from the code above, programs are configured to find them at dev2_ or dev2_xyz_
Of course, there are refinements, but this is the general idea.