Stupid Windows Tricks

Hi, all.

This is a strange thing, peripherally related to Clipper / DOS.

A client had his ISP come in and replace his network hub with a router,
which - of course - resulted in the loss of all his drive and printer
mappings. We've got those all working again, but there is one very
peculiar problem involving the "start" command used for running windows
progams from batch files.

Somehow, the "start" command has been disabled... but only in the batch
file used to start the Clipper app.

That is, we can go to a DOS prompt, and hamd-enter the identical line,
and in that case, it works. But from the BATch file, the result is the old
"bad command or file name" line used these many years in place of the
equally informative "huh?". And it IS start that's not working, because we
can replace the actual line with "start notepad", and it does the same
thing (in the batch file). In case the PATH had gotten hosed, we put in
the entire path name, ie, "start c:\windows\system32\notepad.exe" and got
the same "bad command or filename".

Any ideas?


--

I feel like a fugitive from the law of averages.
-- William H. Mauldin

start notepad.exe and start c:\windows\system32\notepad.exe are NOT the same
 thing.

What happens if you try and run start c:\windows\system32\notepad.exe from a
 CMD prompt?
Does it run or fail as well?

Don't *assume* c:\windows is the place to run things from - on our machines 
we
deliberately place the OS on a different drive to C and never in a \windows 
or \winnt
directory - amazing how many nasties this catches out.

On Thu, 25 May 2006 17:14:44 -0500, R D Avant <extralarge23@tahoo.com> wrote
:

>Hi, all.
>
>This is a strange thing, peripherally related to Clipper / DOS.
>
>A client had his ISP come in and replace his network hub with a router,
>which - of course - resulted in the loss of all his drive and printer
>mappings. We've got those all working again, but there is one very
>peculiar problem involving the "start" command used for running windows
>progams from batch files.
>
>Somehow, the "start" command has been disabled... but only in the batch
>file used to start the Clipper app.
>
>That is, we can go to a DOS prompt, and hamd-enter the identical line,
>and in that case, it works. But from the BATch file, the result is the old
>"bad command or file name" line used these many years in place of the
>equally informative "huh?". And it IS start that's not working, because we
>can replace the actual line with "start notepad", and it does the same
>thing (in the batch file). In case the PATH had gotten hosed, we put in
>the entire path name, ie, "start c:\windows\system32\notepad.exe" and got
>the same "bad command or filename".
>
>Any ideas?
John.

Greetings,

If this is an older version of windows, START.EXE is a (separate) file,
not part of the OS:  I would check to see if START.EXE exists on the
Drive in question (DIR START.EXE /S [Enter] from root of Drive) and if
so, does the directory where START.EXE is located appear as part of the
PATH environment variable.

If a newer version of windows, START is part of CMD.EXE:  does the
(shortcut) the user is trying to invoke by any chance reference an
invalid (drive:) letter?  Or maybe the PATH or COMSPEC environment
variables changed to point to (somewere) other than SYSTEM32 / CMD.EXE
?  (IIRC) %systemroot%/system32 should be part of the PATH, COMSPEC
should point to: %systemroot%/system32/cmd.exe

Regards,
Bob

On Fri, 26 May 2006 09:23:01 +1000, ReIncarnated wrote:

> start notepad.exe and start c:\windows\system32\notepad.exe are NOT the
> same thing.

They are if you are in the c:\windows\system32 directory or if your PATH
contains that directory ahead of any other directory with a notepad.exe,
aren't they?


>
> What happens if you try and run start c:\windows\system32\notepad.exe from
> a CMD prompt? Does it run or fail as well?

I meant to imply that in all cases discussed, the command prompt window
works and the batch file fails... even when the full path is given.

>
> Don't *assume* c:\windows is the place to run things from - on our
> machines we deliberately place the OS on a different drive to C and never
> in a \windows or \winnt directory - amazing how many nasties this catches
> out.

I'm making no such assumption. I checked, and the specific .exe files are
in fact in the directories referenced in the command lines... including
the infamous notepad.

Recap: the identical "start xxx" command line fails in a BATch file, but
works in a straight "Command Prompt" window when typed.

My first thought was a "PATH" problem, but I edited the BATch file so that
at the time the "start xxx" was executed, it was actually in the directory
with the executable, e.g.,
c:
cd \windows
start c:\windows\dosprinter.exe /R1 m:\myapp\print.txt

I'm going to check if the ISP doofi diddled with the autoexec.nt or
config.nt - maybe something there... will have to wait a day, though. I'll
let you know.

Thanks for the response.

On Thu, 25 May 2006 19:29:11 -0700, Robert Haley wrote:

> Greetings,
>
> If this is an older version of windows, START.EXE is a (separate) file,
> not part of the OS:  I would check to see if START.EXE exists on the Drive
> in question (DIR START.EXE /S [Enter] from root of Drive) and if so, does
> the directory where START.EXE is located appear as part of the PATH
> environment variable.

This is a Windows XP Pro system, originally from 2003. As near as I can
tell, there is no "start.exe" (not in the /windows directories, anyway),
so I assumed it to be a built-in, like "dir" in dos. I use Total
Commander, which succeeded Windows Commander, which (like Midnight
Commander on *nix machines) is at least an ideological descendant of
Norton Commander... Good ol' ALT-F7...

>
> If a newer version of windows, START is part of CMD.EXE:  does the
> (shortcut) the user is trying to invoke by any chance reference an
> invalid (drive:) letter?  Or maybe the PATH or COMSPEC environment
> variables changed to point to (somewere) other than SYSTEM32 / CMD.EXE ?
>  (IIRC) %systemroot%/system32 should be part of the PATH, COMSPEC should
> point to: %systemroot%/system32/cmd.exe
>
> Regards,
> Bob


Actually, prior to the ham-fisted ISP wonk screwing things up, the system
was running just fine. We didn't change anything.

I'm going to check if he/they diddled with the autoexec.nt or config.nt -
maybe something there... will have to wait a day, though. I'll let you
know.

Thanks for the response.

<<< I meant to imply that in all cases discussed, the command prompt
window works and the batch file fails... even when the full path is
given. >>>

Are you saying that in the _same_ DOS window your batch file fails
while exactly the same commands work fine?

On Fri, 26 May 2006 00:42:27 -0500, R D Avant sez:

> This is a Windows XP Pro system, originally from 2003.

So the hardware and OS have not changed from the time it used to work; the
only thing that has changed is replacing the hub with a router?

I do know that with the advent of NT-based Winduhs systems, COMMAND.COM
doesn't work reliably (vs. CMD.EXE).  On my desktop I have a COMMAND.COM
shortcut and a CMD.EXE shortcut.  The former fails to retain its path from
the command line into a batch file; the latter works as expected.

Try replacing your DOS shell with CMD.EXE instead of COMMAND.COM and see
if the problem goes away.

--
Peter B. Steiger, working on a Linux port of our Clipper applications
Cheyenne, WY
If you must reply by email, you can reach me by placing zeroes
where you see stars: wypbs_**3 at bornagain.com.

On Fri, 26 May 2006 06:03:11 -0700, E. Fridman wrote:

> <<< I meant to imply that in all cases discussed, the command prompt
> window works and the batch file fails... even when the full path is given.
 
>
> Are you saying that in the _same_ DOS window your batch file fails while
> exactly the same commands work fine?

No. I'm saying that the batch file, run from a pif/icon, fails, while the
identical command typed on a command line in a dos box created by the
"Command Prompt" pif/icon works perfectly.

I don't see it as being the PATH environment, because the command
specifies the full path, as shown in preceding message.

I'm going to be at the client's shop shortly, to look at the pif again. I
think we did run the batch file from that "Command Prompt" window, but
it was a bad time, as they were very busy, so we were getting a try on the
machine for a minute or two followed by ten minutes of customers being
waited on... I'm definitely going to investigate the autoexec and config
files pointed to by the pif, and make sure we try executing the batch file
from the "Command Prompt" window.

Thanks for the response.

R D Avant wrote:
> On Fri, 26 May 2006 06:03:11 -0700, E. Fridman wrote:
> 
>
> No. I'm saying that the batch file, run from a pif/icon, fails, while the
> identical command typed on a command line in a dos box created by the
> "Command Prompt" pif/icon works perfectly.
>
> I don't see it as being the PATH environment, because the command
> specifies the full path, as shown in preceding message.
>
> I'm going to be at the client's shop shortly, to look at the pif again. I
> think we did run the batch file from that "Command Prompt" window, but
> it was a bad time, as they were very busy, so we were getting a try on the
> machine for a minute or two followed by ten minutes of customers being
> waited on... I'm definitely going to investigate the autoexec and config
> files pointed to by the pif, and make sure we try executing the batch file
> from the "Command Prompt" window.
>
> Thanks for the response.
>
There are two command processors, command.com and cmd.exe. Which does
your .bat file invoke? If command.com and start.exe isn't there, boom.

You can ensure cmd runs your command by explicitly..

cmd /c start notepad

..should work.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

<<< I'm saying that the batch file, run from a pif/icon, fails, while
the  identical command typed on a command line in a dos box created by
the  "Command Prompt" pif/icon works perfectly. >>>

Then I strongly believe this is "Command.COM" vs "CMD.EXE" issue.  As
already suggested, try "CMD /C START <your batch>".