'File name' is not recognized as an internal or external command, operable program

mike henley rsrchstr at hotmail.com
Sat Sep 28 11:18:47 EDT 2002


rsrchstr at hotmail.com (mike henley) wrote in message news:<576c1752.0209271443.1ea61518 at posting.google.com>...
> i am running windows xp which was working fine until the following
> problem occured...
> 
> in the command prompt window (as well as run...), whatever program,
> exe, batch file... etc i enter returns the following message
> 
> 'File name' is not recognized as an internal or external command,
> operable program or batch file
> 
> these are my environment variables
> 
> ComSpec 
> %SystemRoot%\system32\cmd.exe
> Path 
> C:\ruby\bin;C:\Python22;C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
> PATHEXT
> .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys;.RB;.RBW
> 
> previously the command prompt worked just fine... this happened in the
> past few days; my recent installations include activestate's perl,
> python, tcl, pragmatic programmer's ruby, gnu cygwin, apache 2, zope,
> realone player
> 
> does anyone know what i should do to fix this and restore command
> prompt functionality?

problem solved; activestate tcl binary binstallation is the offending
app. windows XP has user specific environmental variables and
universal environmental variables that affect all users, and while all
other applications mentioned above make changes to universal
variables, - as you can see the path above is mostly correct and looks
right when u look at it, but doesn't work, which was puzzling -
activestate's tcl installation makes changes to user specific
environmental variables, which override and make universal variables,
it seems, unusuable, and apparently, not read by the machine, as not
only the command prompt and "start|run..." were not working, but every
other .com, .exe, .bat that is called through them, (.exe would still
work if clicked on from explorer, but not through command prompt or
"start|run...")

the solution that worked was to delete the path and pathtext entries
from the user specific variables that were entered by activestate's
tcl binary installation and move them into the universal variables,
and with this the command prmopt and "start|run..." both worked, as
well as the beloved cygwin bash

i searched the internet, and usenet, for a solution to this problem, i
found none, nothing on microsoft knowledgebase or newsgroups, i even
went on irc to many technical newsgroups and no one knew what to do,
the replies i had on usenet groups, though i thank all who tried to
help, didn't work. (p.s. advising the poster to start a new command
windows for the environmental effects to take place is not a good
reply when the poster said he already restarted the machine, but
thanks anyway to those who suggested it for their wish to help :):)  )

i had to think up the solution myself, which took some time, and i
post it here if anyone encounters this problem in the future, as
windows XP no longer leads you to directly edit autoexec.bat, (that,
and also even if it did, regedit or sysedit no longer work when the
command prompt and start|run no longer work), go to start | control
panel | system | advanced | environmental variables  and look at not
only system variables, which are universal, but notice too the user
specific variables and move any entries not preceded by "documents and
and settings" (well, this is a generalization, it was true in my case,
but may not be so in urs, so try to work out which should belong in
the system variables instaed of the user variables) to the system
variables, restart the machine and see if it works

this seems a rather simple thing, but it is a rather unexpected one,
as system variables look right when you look at them, and if you're
not experienced with windows xp, you may not suspect that user
specific variables override system variables and render them
unreadable


p.s. i'll email this to activestate, but as i heard that most of the
code in activestate distribution is community contributed i post this
to comp.lang.tcl too



More information about the Python-list mailing list