Command Prompt path change

It used to be that, when I opened the "fake DOS" Command Prompt, it would open to:
C:\>
Now it opens to:
C:\Documents and Settings\My Username\>

I don't remember changing anything, and I can't figure out how to change it back. It's a minor annoyance, I know, but I'd like to have it the original way. Can anyone suggest a way to fix this? (For that matter, can anyone explain why it did this in the first place?)

 

hi acelightning

setting it to what you want: does your new zappy version of Windows let you run a batch file like W98 does? if so you could just put

@echo off
c:
cd \

should do it... at least it would on W98...

why it comes up differently: again I can only give you W98 analogue, but I can get mine to come up all over the place! usually when I've been using Windows Explorer to explore somewhere on another logical drive. If I've been exploring L:\web for instance, start an MS-DOS prompt somewhere on C: and log to drive L: it will appear in L:\web all by itself. I'd guess they've hung onto the way each drive remembers the folder it's logged to, otherwise it wouldn't be very back compatible with DOS...

or, on the properties for this "fake DOS ", is it maybe trying to remember a "working folder" from a previous time you used it?

sorry if I'm off beam, as I know nothing of this new version of Windows. But with luck it might give a idea of things to try even if it doesn't nail it.

best wishes, HJ.

 

Steve, I went into the "Properties" for my existing shortcut and changed the "start in ", and that did the trick! Thanks!

Hugh, before I installed Win2K, I was running Win95. The Win9x operating systems actually had some DOS underpinnings. But Win2K and XP were developed out of NT, which was not based in DOS. The "command prompt" or "DOS window" in 2K/XP is more of a DOS emulator - which can be very frustrating, if you're used to older systems that actually used DOS!

 

acelightning,
yes I'm aware of the non-DOS underpinning, my suggestions were mainly from the logic that any fake DOS would probably try its best to emulate the functionality of true DOS, 'coz the better it does it, the less the likelihood that it won't run somebody's old fave DOS application. But I didn't think of translating "working folder" to "start in "... which was a bit silly as even W98 calls it "start in"

...lots of old DOSsy things needed batch files, so I sort of assumed that the fake DOS would have that ability built into it somewhere somehow - although perhaps called something different now?

does it automatically modify the contents of "start in" from the last thing you ran with it, though? Come to think of it I've never really sussed that one for W98 (yet!)

best wishes all, HJ

 

I would have thought that the "fake DOS" would run batch files. But in Win95, I had a little batch file that would empty the recycle bins, delete everything in the TEMP folders, empty my Netscape cache, and do other cleaning chores. I tried to create an equivalent batch file for Win2K, and the file runs, but nothing happens. So there seems to be something weird about the way the DOS emulator handles batch files.

And I don't know whether it "remembers" the last place you started it from - I don't think that was what changed mine, anyway, because I only ever started it from the root of C:, which is where the (completely useless) cleanup batch file is located.

 

Batch files behave differently in cmd vrs command.

I have some batch files I use to "SORT" lists in text files and to get identical function required different syntax in W98 vrs W2k

(W2K / Xp) As for clearing temp, recycle, cookies etc. you may be running into permission issues AND you may/will have to use eplicit paths to those files. such as;

C:\Documents and Settings\{your user name here}\Cookies\*.*

 

Steve, I'm using cmd.exe - if it's the more powerful of the two, why should I use command.com instead?

Profgab, I do have the complete paths to each directory or file specified. I've tried spelling all the names out in full, and abbreviating them (old DOS style) to 8-dot-3 with ~1, etc. I don't think it's a permission problem, since my logon has full admin privileges (I'm the only person who ever uses this machine). I'd like to know more about how Win2K handles batch files (and DOS-like commands), compared to Win9x. (I'd also like to know more about the differences between cmd.exe and command.com.)

 

Steve, cmd.exe is working just fine now, thanks to your earlier suggestion. It's my "cleanup" batch file that's not working, and I'm convinced that it's a problem with the batch file itself, not with cmd.exe.

 

Ace - post the .bat file here and someone can probably tweak it for you so it will run.

Short answer to the differences bearing in mind that in 2000/2003/XP, the code is totally different for these apps than with earlier versions so none of this applies to other OS versions.

Comnmand.com is a 16Bit app with all the implied limitations such as inability to use big chunks of memory, to deal with long file names, and all the rest. Cmd.exe is a full 32bit app.

In addition (and the tech reasons are beyond me) it seems to not have access to the system environment values that include the pathing information and a few other items.

Also, lots of the behavior switches that are the defaults with cmd.exe have to be manually set in command.com or can't be set at all.

A biggie for me is the ability with cmd.exe to hit the up arrow key and recall a previous command. A REAL biggie is the ability to edit a command before running it. With command.com your only choice is really to wipe it out and do another or possibly delete all the command string back to the place you want to change. With cmd.exe you can edit a line just like you would in a text editor.

 

Okay, here's the batch file that doesn't work:

Code:

del C:\WINNT\SHELLICONCACHE
del C:\WINNT\OFFLINE WEB PAGES\*.*
del C:\PROGRAMFILES\ICQ\ATEBROWSER\icqnumber\CACHE\*.*
del C:\DOWNLOAD\*.*
del D:\NETSCAPE\USERS\username\CACHE\*.*
del D:\NETSCAPE\USERS\username\NETSCAPE.HST
exit

What am I doing wrong here?

 

Maybe play with some switches?

Code:

Deletes one or more files.

DEL [/P] [/F] [/S] [/Q] [/A[[:]attributes]] names
ERASE [/P] [/F] [/S] [/Q] [/A[[:]attributes]] names

  names         Specifies a list of one or more files or directories.
                Wildcards may be used to delete multiple files. If a
                directory is specified, all files within the directory
                will be deleted.

  /P            Prompts for confirmation before deleting each file.
  /F            Force deleting of read-only files.
  /S            Delete specified files from all subdirectories.
  /Q            Quiet mode, do not ask if ok to delete on global wildcard
  /A            Selects files to delete based on attributes
  attributes    R  Read-only files            S  System files
                H  Hidden files               A  Files ready for archiving
                -  Prefix meaning not

If Command Extensions are enabled DEL and ERASE change as follows:

The display semantics of the /S switch are reversed in that it shows
you only the files that are deleted, not the ones it could not find.

The /Q /S switch might help.

Also maybe put an "ECHO - Step #x" in between each line to see where it is hanging up.

(just a few quick ideas.)

(Edit
BTW - for what you are trying to do, if it were in W9x it would require using "DELTREE /y" for any of those locations that might contain subdirectories.

 

Okay, here's what I have now:

Code:

del /Q C:\WINNT\ShellIconCache
del /Q C:\Program Files\ICQ\AteBrowser\{ICQnumber}\cache\*.*
del /Q C:\Download\*.*
del /Q D:\NETSCAPE\USERS\{username}\netscape.hst
del /Q D:\NETSCAPE\USERS\{username}\CACHE\*.*
exit

For diagnostic purposes, I've been running it directly from the command prompt window, and I've deleted the "exit" so I can see what it does.

It responds to

Code:

del /Q C:\WINNT\ShellIconCache

with "Could Not Find C:\WINNT\ShellIconCache "
The file does exist, and that is the correct path.

It responds to

Code:

del /Q C:\Program Files\ICQ\AteBrowser\{ICQnumber}\cache\*.*

with "The system cannot find the path specified. "
I've checked that also, and the path is exactly what it says there.

The other commands seem to work now - thanks for the clues!

 

Ace - the shelliconcache file is hidden by default and I'm not sure cmd will delete it that way.

Try adding a attrib command and unhiding it first and see if it works then.

 

Newt, what's the syntax for removing the "hidden" attribute? I tried the old DOS command "attrib -h C:\WINNT\ShellIconCache ", but it didn't make any difference - it still couldn't find the file.

 

I tried putting the long path name in quotes. While I was at it, I also put back the line "attrib -h C:\WINNT\ShellIconCache ", before the line to delete it. Now, when I tried the "attrib" command before, the cmd.exe window said it couldn't find the file to remove the attribute. But somehow, it works now. And putting the long string in quotes also worked. In short, my whole little cleanup batch file now works the way it's supposed to! Thanks, everyone!

 

acelightning, Steve,
it's the space in the middle of Program Files which makes the quotes imperative, more so than the length...
whitespace - space(s) and/or tab(s) - is used as the delimiter, it's what splits a command line into command verb and parameter(s). The only way to stop a space splitting a string like Program Files is to enclose the string within quotes. This is far more general than just Microsoft OS, same sort of rules on VAX/VMS for example.
as for the length mattering, that may or may not require the quotes, perhaps dependent on the OS, I dunno...

W98 can get away with
C:\Program Files>cd windowsupdate
C:\Program Files\WindowsUpdate>

but you have to use quotes for
C:\>cd "Program Files "
C:\Program Files>

no-one can get away with
C:\>cd Program Files

because cd takes one, and only one parameter, it will error out with "too many parameters"
...'coz Files has been parsed as a second parameter

sometimes if you do put quotes you have to be more cautious with case-sensitivity though; and that might well be OS dependent

hope that helps rather than making it more confusing.

best wishes, HJ.