Qbasicnews.com

QBasic => QB Discussion & Programming Help => Topic started by: Agamemnus on July 15, 2003, 12:13:15 PM



Title: dir command >> exe?
Post by: Agamemnus on July 15, 2003, 12:13:15 PM
I've been using DOS's DIR to locate files in a dir, and now DIR to get the path.

HOWEVER, DIR is probably not supported at all by XP, and not entirely supported in win2000.

I was thinking of doing this without the dir program somehow, but it's more convenient to just paste in the dir program......

So, my question is, where can I find the exe that allows dir? (I looked for dir.exe, doesn't exist)

Or..?


Title: dir command >> exe?
Post by: Antoni Gual on July 15, 2003, 12:22:07 PM
Dir is supported by W2000 AFAIK.
DIR is an internal command.com command, it is not a sepparate file.


Title: dir command >> exe?
Post by: na_th_an on July 15, 2003, 12:30:29 PM
Dir works OK in WinXP, but doesn't show long file names when called from within QB, as it did on Win9X. That can be a problem sometimes.


Title: dir command >> exe?
Post by: Antoni Gual on July 15, 2003, 01:24:10 PM
With "from QB" do you mean "From a DOS box"?

In W2000 dir  works ok, only the undocumented /z has been substituted by the documented /x


Title: dir command >> exe?
Post by: Plasma on July 15, 2003, 01:26:47 PM
Quote
I've been using DOS's DIR to locate files in a dir, and now DIR to get the path.


Bah, forget shelling DIR. Join the big boys and use interrupts. Faster and more reliable.


Title: More reliable? It's never failed for me.
Post by: Glenn on July 15, 2003, 01:30:48 PM
.


Title: From QB.
Post by: Agamemnus on July 15, 2003, 01:32:29 PM
Well, I'd be great if anyone knew the 100% working and foolproof interrupt forms of the following:

Code:

SHELL "dir *.xyz > list.dir": OPEN "list.dir" FOR INPUT AS #1
LINE INPUT #1, temp$: LINE INPUT #1, temp$: LINE INPUT #1, temp$:
LINE INPUT #1, temp$
rts.dir$ = MID$(temp$, 15) + "\"
CLOSE : KILL "list.dir"


and:

Code:

SUB load.filelist (dir$)
option.amount% = 0
CHDIR dir$: SHELL "dir *.txt /b /On /L >list.dir": CLOSE
OPEN "list.dir" FOR INPUT AS #1
DO
IF EOF(1) THEN EXIT DO
option.amount% = option.amount% + 1
LINE INPUT #1, temp$
LOOP
CLOSE
OPEN "list.dir" FOR INPUT AS #1
REDIM option.list$(1 TO option.amount%)
FOR i% = 1 TO option.amount%
LINE INPUT #1, option.list$(i%)
option.list$(i%) = SHRTFN$(data.units.dir$ + option.list$(i%))
NEXT i%
CLOSE : KILL "list.dir"
END SUB


Title: dir command >> exe?
Post by: Plasma on July 15, 2003, 02:46:25 PM
Here ags...

Code:
DEFINT A-Z
'$DYNAMIC
'$INCLUDE: 'QB.BI'

DECLARE FUNCTION DIR2$ (FileSpec$, Attr)
DECLARE FUNCTION CurrentPath$ ()
DECLARE FUNCTION FileList (Path$, Spec$, List$())

CLS
DIM List$(0)

PRINT CurrentPath$
Num = FileList(CurrentPath$, "*.*", List$())
PRINT Num; "Files"
FOR i = 1 TO Num
  PRINT List$(i),
NEXT

FUNCTION CurrentPath$

  DIM Regs AS RegTypeX
 
  Regs.ax = &H1900
  INTERRUPTX &H21, Regs, Regs
  Drive$ = CHR$((Regs.ax AND 255) + 65)

  Path$ = SPACE$(65)
  Regs.ax = &H4700
  Regs.dx = 0
  Regs.ds = VARSEG(Path$)
  Regs.si = SADD(Path$)
  INTERRUPTX &H21, Regs, Regs
  Path$ = LEFT$(Path$, INSTR(Path$, CHR$(0)) - 1)
  IF Path$ <> "" THEN Path$ = Path$ + "\"
 
  CurrentPath$ = Drive$ + ":\" + Path$

END FUNCTION

FUNCTION DIR2$ (FileSpec$, Attr) STATIC
 
  'Settings for Attr: (may be combined)
  '
  ' &H40 Device
  ' &H20 Archive
  ' &H10 Directory
  ' &H8  Volume Label
  ' &H4  System File
  ' &H2  Hidden File
  ' &H1  Read-Only File
  '
  ' use &H10 for any directory
  ' use &H27 for any file

  DIM DTA AS STRING * 44
  FileSpecZ$ = FileSpec$ + CHR$(0)

  DO

    DIM Regs AS RegTypeX

    Regs.ax = &H1A00
    Regs.ds = VARSEG(DTA)
    Regs.dx = VARPTR(DTA)
    INTERRUPTX &H21, Regs, Regs

    IF FileSpecZ$ <> CHR$(0) THEN
      Regs.ax = &H4E00
      Regs.cx = Attr
      Regs.ds = VARSEG(FileSpecZ$)
      Regs.dx = SADD(FileSpecZ$)
    ELSE
      Regs.ax = &H4F00
    END IF

    INTERRUPTX &H21, Regs, Regs

    IF Regs.flags AND 1 THEN
      DIR2$ = ""
      EXIT FUNCTION
    ELSE
      RealAttr = ASC(MID$(DTA, 22, 1))
      IF RealAttr AND Attr THEN
        Null = INSTR(31, DTA, CHR$(0))
        DIR2$ = MID$(DTA, 31, Null - 31)
        EXIT FUNCTION
      ELSE
        FileSpecZ$ = CHR$(0)
      END IF
    END IF

  LOOP

END FUNCTION

FUNCTION FileList (Path$, Spec$, List$())

  File$ = DIR2$(Path$ + Spec$, &H27)
  DO WHILE LEN(File$)
    FileCount = FileCount + 1
    File$ = DIR2$("", &H27)
  LOOP

  REDIM List$(1 TO FileCount)
 
  File$ = DIR2$(Path$ + Spec$, &H27)
  DO WHILE LEN(File$)
    i = i + 1
    List$(i) = File$
    File$ = DIR2$("", &H27)
  LOOP

  FileList = FileCount

END FUNCTION


As for reliability, I've seen plenty of n00bs do a SHELL "DIR >TEMP.TXT". Now what if my current drive/directory is a CD-ROM? Oops, can't write the tempfile. Ok, use C: then. It IS possible not to have a C: drive with NT/2K/XP. Ok, use %TEMP% then. Not always defined...


Title: I fail to see what your comment about reliability...
Post by: Glenn on July 15, 2003, 03:05:18 PM
has to do with the reliability of SHELL or DIR.  No interrupt call is going to correct for false assumptions about hardware made by careless people.  (There is no way to make carelessness reliable.)  If it did, that carelessness wouldn't cause a problem when SHELL and DIR are used because DIR likely just uses that interrupt call in the first place.


Title: dir command >> exe?
Post by: Agamemnus on July 15, 2003, 03:10:51 PM
command.com is different.

Thanks, Plasma, I'll try to put that in ASAP.


Title: What is command.com different from?
Post by: Glenn on July 15, 2003, 03:35:08 PM
If you think INT 21 isn't fundamentally important to how command.com operates, well, as usual, you're confused again.  :)


Title: dir command >> exe?
Post by: Agamemnus on July 15, 2003, 03:40:03 PM
What I meant is:

command.com is different across windoze versions, and in some cases may not exist.

EDIT: I patched up your routine a bit, Plasma, and got it to work with the program. :)


Title: dir command >> exe?
Post by: Plasma on July 15, 2003, 03:42:25 PM
I never said there was anything wrong with SHELL or DIR. I did point out that the common solution of SHELL "DIR >somefile.txt" is not reliable, due to the fact that a temporary file has to be created, and the current directory is not always writeable. Most people who use this method do not assure that this temporary file can be created, they just assume it can be.

I'm not a freaking moron, I know how DIR works. :P


Title: I knew what you meant, Plasma357,...
Post by: Glenn on July 15, 2003, 04:14:44 PM
But as I said, that doesn't relate to the reliability of using SHELL and DIR.  It relates to the reliability of careless assumptions (which is an oxymoron).  There is no need to assume that the current directory resides on a disk that is writable or to write the file to the current directory.  People trying to program who don't even know what disks they have that are writable shouldn't be trying.  (I have a few more years experience than you catering to people trying to use computers who don't have the basic qualifications to be trying in the first place.  It's not as easy or painless as you make it sound.  :)  )

(And I never said  that you did say it was wrong to use SHELL and DIR.  I never, for the record, said it was wrong to just use the interrupt call directly either.  :)  )

And Agamemnus, I've never used any version of windows that didn't at least provide a command.com for DOS programs to work.  If you're using such an implementation/installation, what are you doing trying to run DOS programs with it?  (And the differences between different command.com's are irrelevant in regard to this context.  If anything, DIR works *better* with the newer versions of windows.)


Title: dir command >> exe?
Post by: na_th_an on July 15, 2003, 04:20:29 PM
Quote from: "Antoni Gual"
With "from QB" do you mean "From a DOS box"?


Nope. I mean from QB. The command

Code:
shell "dir"


will show short filenames (~n stuff)

dir typed directly in a DOS box works correctly


Title: dir command >> exe?
Post by: Plasma on July 15, 2003, 04:28:14 PM
Glenn, I understand what you're saying, but I don't know why you're saying it. If you agree that I was not talking about the reliability of DIR and SHELL themselves, then why are you rambling on about them?

My point was: using interrupts to get a directory list is more reliable than a simple SHELL "DIR >bleh.txt". I think you agree. No need to give me your life story.


Title: dir command >> exe?
Post by: Agamemnus on July 15, 2003, 04:33:22 PM
cleaner too.

Killing things isn't pleasant.


Title: It would never occur to me that...
Post by: Glenn on July 15, 2003, 04:34:13 PM
anyone on this planet would be interested in my life story.  (Trust me, you haven't heard it.)  Why are *you* rambling?  Go reread what I wrote and  then maybe you'd resolve the confusion.  I think I've made it clear that I *don't* agree that there's anything unreliable (or less reliable) about using SHELL and DIR.  The unreliability you're talking about has nothing to do with SHELL or DIR.  *That's* the point.  It was never about whether or not to use SHELL and DIR.  (If you aren't interested in the point, that's *your* business.  :)  )


Title: dir command >> exe?
Post by: Antoni Gual on July 15, 2003, 04:38:27 PM
Nathan:
 :o
I never noticed it... It happens in W2000 also. Nice feature..
Is as if dir was invoked with /-n...and it does'nt let you use /n...


Title: dir command >> exe?
Post by: Plasma on July 15, 2003, 04:45:32 PM
Listen, Glenn, I know how you like to nitpick. It doesn't matter what I say, because you're always going to be correct. I know you know what I'm saying, but you choose to nitpick. Fine, whatever. Have fun talking to yourself. :P


Title: And you apparently like to miss really trivial points...
Post by: Glenn on July 15, 2003, 04:54:04 PM
and blame other people for your failure to grasp them.


Title: dir command >> exe?
Post by: Agamemnus on July 15, 2003, 05:03:30 PM
Hey Glenn, why is your sig "I Hold This Place Together"? :)


Title: dir command >> exe?
Post by: Moneo on July 15, 2003, 07:54:46 PM
After following this entire thread, I have to agree with Glenn. :D  If all of you agree that  the use of SHELL and DIR is relaible and that many people have been using it successfully, then why not use them as such?

Why look for a sofisticated but complicated interrupt solution of about 70 lines of code, that most people will not understand? Are any of you qualified or willing to test and debug this interrupt solution?

If this interrupt solution was a proven function in a reliable library, then go ahead and use it if youe really prefer not using SHELL and DIR.
*****


Title: dir command >> exe?
Post by: Agamemnus on July 15, 2003, 08:00:04 PM
Quote

Why look for a sofisticated but complicated interrupt solution of about 70 lines of code, that most people will not understand? Are any of you qualified or willing to test and debug this interrupt solution?

Because killing files isn't my thing, because most people don't need to understand (only I do), because I am willing to test and debug this interrupt solution and have already implemented it.


Title: dir command >> exe?
Post by: na_th_an on July 15, 2003, 08:18:40 PM
Quote from: "Agamemnus"
Hey Glenn, why is your sig "I Hold This Place Together"? :)


WC added that rank when I reached 750 posts.


Title: dir command >> exe?
Post by: Moneo on July 15, 2003, 08:32:25 PM
Quote from: "Agamemnus"
Quote

Because killing files isn't my thing...

Are you concerned with having to clean up and kill the temporary file generated by the DIR? I fail to see the problem. If the file was generated by the DIR, and then you read its contents, what's the problem wilh killing it?
*****


Title: dir command >> exe?
Post by: Agamemnus on July 15, 2003, 08:36:23 PM
files are like human beings......

EDIT:

See, not having DIR is important, when one doesn't have a full "dir" (Megaman doesn't have command.com, but dir command still works a little..)


Title: dir command >> exe?
Post by: Rokkuman on July 16, 2003, 12:06:23 AM
Agamemnus told me to post that I don't have Command.com... which I don't...


Title: dir command >> exe?
Post by: Moneo on July 16, 2003, 02:18:33 PM
MEGAMAN,

I'm running WinXP and command.com is in \windows\system32.
What version of Windows are you running that does not have command.com?

I have to agree with the following comment by Glenn:
"... I've never used any version of windows that didn't at least provide a command.com for DOS programs to work. If you're using such an implementation/installation, what are you doing trying to run DOS programs with it? ..."
*****


Title: dir command >> exe?
Post by: Agamemnus on July 16, 2003, 06:48:59 PM
Well, my program with dir didn't work before on his computer, and now it does..


Title: dir command >> exe?
Post by: Moneo on July 16, 2003, 09:22:47 PM
Quote from: "Agamemnus"
Well, my program with dir didn't work before on his computer, and now it does..


Well team, seems like time to fall back 10 and punt.
*****


Title: dir command >> exe?
Post by: Rokkuman on July 18, 2003, 06:23:16 AM
Quote from: "Moneo"
MEGAMAN,

I'm running WinXP and command.com is in \windows\system32.
What version of Windows are you running that does not have command.com?

I have to agree with the following comment by Glenn:
"... I've never used any version of windows that didn't at least provide a command.com for DOS programs to work. If you're using such an implementation/installation, what are you doing trying to run DOS programs with it? ..."
*****


Well, sorry if I'm too late, I'm not really part of this conversation, but I'm running Windows 2000...


Title: dir command >> exe?
Post by: na_th_an on July 18, 2003, 02:36:49 PM
You should have COMMAND.COM, or you wouldn't have been able to run almost *any*  DOS program, mainly couse 99.99% of DOS program make extensive use of DOS interrupts and/or services, which are set up by COMMAND.COM itself. In fact, when you click any QB executable from your windows explorer, COMMAND.COM is ran and on the top of it your EXE is ran.

Plus, W2000 and WXP come with CMD.EXE which is a command prompt simmilar to COMMAND.COM command-wise, but it is not MSDOS itself, such as COMMAND.COM. Anyhow, COMMAND.COM *should* be in your hard disk somewhere. Maybe you haven't found it 'cause Windows is hiding it for you: Windows hides system files by default (for a strange reason), and you have to configure it not to.