DATA_USE

[dilwyn]

A quick&dirty little sketch of how you can find the parent directory:

Code: Select all

100 MAKE_DIR ram1_test
110 MAKE_DIR ram1_test_abc_xyz
120 dir$ = "ram1_test_abc_xyz"
130 :
140 FOR i = LEN(dir$) TO 5 STEP -1
150   IF dir$(i) = "_" THEN
160     IF FTEST(dir$(1 TO i)) = 0 THEN
170       IF FTYP(\dir$(1 TO i)) = 255 THEN EXIT i
180     END IF
190   END IF
200 END FOR
210 dir$ = dir$(1 TO i)
220 :
230 PRINT dir$

Thank you Marcel. I had to write something similar in my Q-Trans file handler, only your routine is much more concise.

[pjw]

My take on it is: Let the OS do the hard work:

Code: Select all

100 DEFine FuNction DirUp$(dir$)
110 LOCal ch, l%, dr$(36)
120 l% = LEN(dir$)
130 IF l% <= 5: RETurn dir$
150 l% = l% - 1 - (dir$(l%) = '_')
160 IF l% = 5: RETurn dir$(1 TO l%)
170 ch = FOP_DIR(dir$(1 TO l%))
180 dr$ = FNAME$(#ch): CLOSE#ch
190 IF LEN(dr$) = 0: RETurn dir$(1 to 5)
200 RETurn dir$(1 to 5) & dr$ & '_'
210 END DEFine DirUp$
220 :

[dilwyn]

In the sources for Q-Trans, I have a little note that in versions of SMSQ/E prior to v2.99, there was a little funny in that FNAME$ applied to a DOS directory name didn't work - it was me who reported it to Marcel at the time. According to the note, this was QPC2 v3.03 and earlier.

Probably far enough back to ignore, though!

[mk79]

My take on it is: Let the OS do the hard work:

That would have been my solution if I had remembered that FNAME$ exists

[mk79]

In the sources for Q-Trans, I have a little note that in versions of SMSQ/E prior to v2.99, there was a little funny in that FNAME$ applied to a DOS directory name didn't work - it was me who reported it to Marcel at the time. According to the note, this was QPC2 v3.03 and earlier.

Similarly, OPEN_DIR on the filename to open the parent directory didn't work until fairly recently in QemuLator and SMSQmulator if I remember correctly. But it's all fixed now.

[pjw]

My take on it is: Let the OS do the hard work:

That would have been my solution if I had remembered that FNAME$ exists

Sadly, on the DOS device, the OS doesnt do the work. I adapted this routine hastily from and old routine of mine. It does the job on traditional Qdos devices and, it turns out, sort of works with SMSQmulator's HFS (but not quite). So your routine wins out

[mk79]

Sadly, on the DOS device, the OS doesnt do the work.

The OS never does the work, it's always the responsibility of the driver (and a pretty non-obvious one to boot). But as far as I can see DOS does fine?

Code: Select all

make_dir 'dos1_temp_xxx'
save dos1_temp_xxx_yyy_zzz
open_dir#3,dos1_temp_xxx_yyy_zzz
print fname$(#3)
"temp_xxx"

[pjw]

Sadly, on the DOS device, the OS doesnt do the work.

The OS never does the work, it's always the responsibility of the driver (and a pretty non-obvious one to boot).

I was just being lazy. But now youre being pedantic

But as far as I can see DOS does fine?

Code: Select all

make_dir 'dos1_temp_xxx'
save dos1_temp_xxx_yyy_zzz
open_dir#3,dos1_temp_xxx_yyy_zzz
print fname$(#3)
"temp_xxx"

Yes, but my trick in DirUp$ of just removing a single letter to cause a mismatch, thus fooling the driver into assuming it is the directory level above that is wanted, doesnt work with the DOS driver.
Perhaps this is one of those cases where relying on the quirks of the system causes all kinds of problems. However, I never really thought about this feature as a quirk.

[mk79]

I was just being lazy. But now youre being pedantic

I'm known for being pedantic But in this case I think the distinction is important. If it was a feature of the OS it would either work or not. As it's a driver feature every driver has to implement them separately, so what works for one driver might not work for another, as you have experienced.

Yes, but my trick in DirUp$ of just removing a single letter to cause a mismatch, thus fooling the driver into assuming it is the directory level above that is wanted, doesnt work with the DOS driver.
Perhaps this is one of those cases where relying on the quirks of the system causes all kinds of problems. However, I never really thought about this feature as a quirk.

I have never seen a specification where it says that this is supposed to happen, most features are defined "de facto" by TT's reference code. This makes it very difficult to be 100% compatible when creating something from scratch like the DOS device. I think I have fixed it, but who knows if I haven't broken two other obscure use-cases in the process

Cheers, Marcel

[pjw]

The definition is implied, IMHO. FNAME$ returns the name of the file. In
Qdos & co, unfortunately, the path happens to be part of the file name:

Code: Select all

ch = fop_in(<dev><dir><filename>): print fname$(#ch)

This prints the name of the file, ie <dir><filename>

A directory is special, but it is also just a file, so that

Code: Select all

 ch = fop_dir(<dev><dir>): print fname$(#ch)

and

Code: Select all

 ch = fop_in(<dev><dir>): print fname$(#ch)

Both print <dir>, and so does, normally

Code: Select all

ch = fop_dir(<dev><dir><filename>): print fname$(#ch)

ie, it prints <dir>

Surely, this must be considered the normal - and expected - behaviour?
Arguably, FNAME$ should really only return the actual name of the file,
sans the directory, but oh well.

But this I do find unusual and unexpected:

Code: Select all

ch=fop_dir("dos2_QL_Win_Win_SMSQE332_WIN"): print fname$(#ch):close
rem Prints QL_Win_Win - Good!
ch=fop_dir("dos2_QL_Win_Win_SMSQE332_W"): print fname$(#ch):close
rem Prints QL_Win_Win - Good!
ch=fop_dir("dos2_QL_Win_Win_SMSQE332_"): print fname$(#ch):close
rem Prints QL_Win_Win - Good!
ch=fop_dir("dos2_QL_Win_Win_SMSQE332"): print fname$(#ch):close
rem Prints QL_Win_Win_SMSQE322 - Hmpf!

Qdos and co havent exactly provided us with any easy solutions to parsing
file names or reading directories (yes, I know: Qdos & co device
drivers). Its pretty much peek and poke here, and each man
for himself! We could really do with a break here! Consistency, even
where things may be in that grey area of "not specified", would be a great
help - and much appreciated!

Goes without saying: IMHO!

PS: I started this before I saw your [mk79] response that it has been fixed!
Thank you very much for that! However, I'll let my message stand, as it
may shed some light on the issue for those less acquainted with
programming under Qdos & co.