Has anyone on the development team had a chance to look into this yet? I posted this a few weeks back.

{----------------------------------------------------------------------------}

Um, I must be missing something real obvious because this makes no sense... does chdir have a problem when compiling win32 targets? I know, sounds dumb but it doesn't _seem_ to be working. Try compiling this:

Program CDir;
var
  Answer : string;
BEGIN
  writeln;
  write ('Change to dir?: ');
  readln (Answer);
  if Answer = '' then exit;
  {$I-}
    chdir (Answer);
  {$I+}
  if ioresult  0 then writeln ('Error changing to ',Answer);
END.

go32 targets work fine, but win32's don't change the directory (and it doesn't give any errors either). I must be missing something but for the life of me I can't figure it out. Can anyone else?

TIA,
Jim

IIRC there was already an answer.

The path is only changed for the process of your application and not for the parent process (the process that has started your executable).

You are indeed correct; someone found out that the chdir was 'happening', but that when the program exited it was (for lack of a better word) undone. That was helpful because it provided insight, but that didn't solve the problem -- I really need a solution. Since go32 targets work it would appear to me that the problem is related to the Win32 RTL. Correct?

Jim

No, it's how win32 (and also linux) works.

No, it's how win32 (and also linux) works.

Really?! So there is no way to do a "permanent" chdir in Win32? Somehow that doesn't seem likely -- even M$ can't be that screwed up. And Linux too??

Jim

Well, in a multiprocessing enviornment there's no permanent dir as all processes run separate. When you change dir for one process, it cannot affect others as it would (think about it) wreak havoc with all others.

How process A which forked process B should know that process B's chdir's should affect it as well? Keep in mind that in Linux and Win32 to certain extent, processes have parent-child relationships, and in Linux the ultimate parent is init. You wouldn't want your chdir to change init's wd, do you?

It's not a brokennes, it's a feature. DOS is broken in this respect, pal.

Kuba

No permanent dir? Huh? I can jump to a DOS prompt, type CD\dirname and have the command interpreter change directories for me. I don't understand how that could wreak any havoc.

I suppose it's a matter of perspective. Personally, if I issue a chdir command I'd like to have it actually change the directory, buddy.

Jim

From:
Subject: Re: [fpc-pascal]chdir problem? -- 2nd request To:
Date sent: Fri, 5 Jan 2001 11:51:41 -0500
Send reply to:

No permanent dir? Huh? I can jump to a DOS prompt, type CD\dirname and have the command interpreter change directories for me. I don't understand how that could wreak any havoc.

CD is an internal command within the command interpreter, no external program.

The directory _is_ changed - but it's changed within you program, not within its parent process.

Tomas

With all the confusion I seem to have created perhaps the problem is that I haven't properly stated my intentions. This is what I'm trying to do:

I have a command line (text-mode) filefind type of program that I developed. You know; search by date, time, size, attribs, etc. One of the options is 'goto directory' of the found file. So, you can search for anyfile.name and have it find the file, CD into the directory where the file is and then exit (leaving you at the DOS prompt, but in the directory of the file you were searching for). The go32 targets work just fine, but the Win32 targets leave you in the directory that the program was launched from and not the directory where the file was found.

HTH...

Regards,
Jim Wilson

are you running the win32 target from a DOS window or by double clicking an icon? I don't know for sure... but in theory if you run it from a DOS window it should work as you want it to. If all else fails... can you use the go32 binary? I know it won't see long filenames, but at least it will work.

- Matt

are you running the win32 target from a DOS window or by double clicking

an

icon? I don't know for sure... but in theory if you run it from a DOS

window

it should work as you want it to. If all else fails... can you use the

go32

binary? I know it won't see long filenames, but at least it will work.

I run it from a DOS window, not from an icon. I could use the go32 target but then I loose LFN's, and that's not something I want to have happen (I have very descriptive file names, and for network searching LFN's are an absolute must).

BTW; I'm running NT4 with SP5. I've tried this using cmd.exe and command.com -- both leave you at the original directory, and not in the directory of the found file. I don't have any Win9x machines to try it on though...

Jim

are you running the win32 target from a DOS window or by double clicking an icon? I don't know for sure... but in theory if you run it from a DOS window it should work as you want it to. If all else fails... can you use the go32 binary? I know it won't see long filenames, but at least it will work.

The go32 binary will see long filenames :-)

Forget this, I also forgot NT.

And that's how it's meant to be since in DOS (say go32) your program affects the currently running copy of DOS in the particular virutal machine.

The windows executable runs SEPARATE from the DOS virtual machine and whatever you change in it stays there and ONLY there. Windows executable doesn't even know (or care) if it was fired from DOS window or by exec call.

That's about multiprocessing. DOS doesn't have a hint about it, and please bear this in mind. Don't expect Linux and Windows to emulate brokenness of DOS. Nuff said.

Cheerz.
Kuba

Thanks for the tip! I'll get a copy and see what it does.

I'm certainly no C expert, but perhaps I can look over the code and see how he accomplishes it.

Jim

Hmmm.. if you make your program launch a new CMD.EXE just before it exits (after changing path) - that new "command promt" should point to the desired directory?!?

I use the following function
     exec (getenv ('COMSPEC'),concat (' /C ',Command,' "',FileName,'"'));

Command is whatever was requested from the command line -- attrib, del, view, etc. -- while FileName is... well you should know what that one means. :-)

Since this program can be used on DOS, Win9x, NT or 2000 I can't specifically say cmd.exe for the command interpreter, but what I'm doing above should probably be enough (well, on everything but NT and 2000 it is anyway).

Jim

You're correct, I would prefer not to have to resort to such a thing. Besides, when you do type EXIT my file-find program continues where it left off, which is not only distracting but litters the display with what is effectively two screens of information (the original one and whatever remains from the second copy of cmd.exe). Certainly not very elegant. I guess I'll continue to explore my options. :-(

Jim