- Remove From My Forums
-
Вопрос
-
Здраствуйте, Коллеги!
Ситуация, есть ноутбук Toshiba на котором есть предустановленная ОС Microsoft Windows 7 Домашняя.
Нужно было с ноутбука настроить оборудование сетевое. На ноутбуке выполнялось все с учетной записи пользователя с правами локального администратора.
Конечно надо Физические адреса локальной и wifi сетевых карт. Машинально запускаю Command Prompt и даю команду на выполнение «ipconfig /all». Получаю ответ системы: » «ipconfig» не является внутренней или внешней командой, исполняемой программой или пакетным файлом.». 0^_^0Всматриваюсь (-_-) в ту команду что дал на выполнение, с мыслью может по клавиатуре быстро стучу и допустил ошибку, но нет, исключено, все правильно ввел.
Интерфейсы сетевые задействованы. Поэтому в любом случае команды «ping», «ipconfig», «route», «tracert», «nslookup», «telnet» в командной строке должны работать. Но их нет, впрочем как и других. И на команду «help» в той же командной строке получаю все то же сообщение, что эта команда не является внутренней или внешней командой, исполняемой программой или пакетным файлом.
Объясните пожалуйста куда делись сетевые команды командной строки и все остальные? Может где-то это блокируется или выключено принудительно выполнение их. Никогда такого не видел. Получил шок! Как разрешить такую проблему?
С Уважением, bomv
Ответы
-
Такая же как у топикстартера проблема проявилась после установки Microsoft SQL. Компьютер стационарный, Windows 7 Professional. Большинство комманд не работают (help, ping, ipconfig и т.д.), но к примеру «cd C:/temp» работает.
В общем проблему решил следующим образом: ПКМ по «мой компьютер» — свойства — дополнитеные параметры системы — дополнительно — переменные среды — path — изменить — %SystemRoot%system32;%SystemRoot%;%SystemRoot%System32Wbem — Ok. Заработало как
надо.-
Предложено в качестве ответа
20 апреля 2010 г. 14:17
-
Помечено в качестве ответа
Vinokurov Yuriy
13 апреля 2011 г. 5:50
-
Предложено в качестве ответа
Случается такое, когда вы в командную строку (cmd) операционной системы Microsoft Windows вводите, например, какие-то стандартные команды, вроде «ping» или «ipconfig«, и вам выдается сообщение следующего вида: «ping» не является внутренней или внешней командой, исполняемой программой или пакетным файлом. Или же что-то подобное: «ipconfig» не является внутренней или внешней командой, исполняемой программой или пакетным файлом. Т.е. по сути «ping» не работает. В чем же может быть дело?
Самое интересное то, что если ввести полный адрес любой из этих стандартных консольных программ Windows примерно так: C:WINDOWSsystem32ping то, как ни странно, программы заработают, и будут запускаться как положено. Таким образом, мы имеем проблемы с стандартными путями запуска программ. Если же и после указания точного адреса директории запуска стандартные программы отказались работать и по-прежнему «не явлются внутренними или внешними командами», то в этом случае целесообразно проверить присутствие одноименных файлов (ping.exe, ipconfig.exe, netstat, etc) в самой системной папке операционной системы system32. Возможно, их там просто нет, i.e. они были удалены оттуда вследствие каких-то действий.
Если же всё в порядке, файлы там есть и программы отлично запускаются с командной строки при обращении к ним по полному адресу, то проблему, чаще всего, кроется в системной переменной «PATH». Скорее всего, у вас она перезаписана и для стандартной работы штатных программ надо восстановить в ней начальные значения.
Для этого делаем следующий нехитрый набор действий. Добираемся к системным переменным по следующему пути: Свойства системы -> Дополнительно -> Переменные среды, и там в «Системные переменные» смотрим переменную с названием «Path». Открываем её, и заменяем её значение на одно из следующих:
%SystemRoot%system32;%SystemRoot%;%SystemRoot%system32WBEMc:Windows;c:Windowssystem32
А также любые другие директории, откуда хотим запускать в cmd команды без явного указания полного пути.
(В первом примере используются переменные, во втором явное указание абсолютного пути к системной директории Windows).
Т.е. здесь вы прописываете через знак «;» (точка с запятой) все папки откуда хотите по-умолчанию запускать программы непосредственно из командной строки без указания явного адреса. Таким образом указанное название при вызове в cmd будет искаться именно в этих директориях, которые вы прописали в переменной «Path». Вы можете всячески изменять эти параметры для ваших целей. Каждая новая директория пишется в той же строке и отделяется от предыдущей знаком «;» обязательно без каких-либо пробелов.
После всех действий сохраняем изменения, открываем заново командную строку и пробуем вызвать полюбившиеся программы как обычно с помощью указания имени. Теперь, сообщение «команда не является внутренней или внешней командой, исполняемой программой или пакетным файлом» должно исчезнуть, а программы — запускаться как положено.
не работает ipconfig
ping не является внутренней или внешней windows
ipconfig не работает
ping не является внутренней или внешней
ipconfig не является внутренней или внешней
ping не является внутренней или внешней командой
«ping» не является внутренней или внешней командой, исполняемой программой или пакетным файлом
I’d imagine if C:WindowsSystem32 were missing from the path statement, ipconfig not running would be the least of your worries.
C:WindowsSystem32 contains a large number of the executables and dynamic link libraries (DLLs) that allow Windows to function.
An entry in the system Path settings tells the computer to look in that specified location for executables and files that programs are referencing.
While it would seem that a good program would not rely on Path variables but should directly reference the location of any and every file it is dependent on, the Path statement allows multiple similar OSes to coexist on the same drive (Windows XP in the C:WinXP folder, Windows 7 in C:Win7, etc, which would result in different and incompatible .System32 directories), and allows for more easy and flexible upgrading of framework files (look for the newest version of the .Net libraries in a versioned directory where they are installed rather than a central directory where they may overwrite each other in an undersireable way).
So a program looking to use the functions of Windows XP’s built in zip handling would call zipfldr.dll and the OS will return the functions of that executable stored in C:WindowsSystem32zipfldr.dll. If you look through that directory, you should see many files that you’ll probably recognize as common scripting commands or functions critical to the OSes operation.
I’ve never removed the C:WindowsSystem32 entry from my path statement and I don’t think I ever will (though I suppose testing this in a VM with rollback functionality shouldn’t be too hard) and so I cannot say for certain what would happen if it were completely missing.
Suffice it to say, pretty much any batch script would completely not function, and the abilities of your OS would be severely curtailed.
Others have already noted how to add C:WindowsSystem32 to the Path statement if it is missing, and so I’ll not repeat that here. But I would not be surprised, since this is the only function you’ve found to be not working, if there were something else wrong here.
I’d imagine if C:WindowsSystem32 were missing from the path statement, ipconfig not running would be the least of your worries.
C:WindowsSystem32 contains a large number of the executables and dynamic link libraries (DLLs) that allow Windows to function.
An entry in the system Path settings tells the computer to look in that specified location for executables and files that programs are referencing.
While it would seem that a good program would not rely on Path variables but should directly reference the location of any and every file it is dependent on, the Path statement allows multiple similar OSes to coexist on the same drive (Windows XP in the C:WinXP folder, Windows 7 in C:Win7, etc, which would result in different and incompatible .System32 directories), and allows for more easy and flexible upgrading of framework files (look for the newest version of the .Net libraries in a versioned directory where they are installed rather than a central directory where they may overwrite each other in an undersireable way).
So a program looking to use the functions of Windows XP’s built in zip handling would call zipfldr.dll and the OS will return the functions of that executable stored in C:WindowsSystem32zipfldr.dll. If you look through that directory, you should see many files that you’ll probably recognize as common scripting commands or functions critical to the OSes operation.
I’ve never removed the C:WindowsSystem32 entry from my path statement and I don’t think I ever will (though I suppose testing this in a VM with rollback functionality shouldn’t be too hard) and so I cannot say for certain what would happen if it were completely missing.
Suffice it to say, pretty much any batch script would completely not function, and the abilities of your OS would be severely curtailed.
Others have already noted how to add C:WindowsSystem32 to the Path statement if it is missing, and so I’ll not repeat that here. But I would not be surprised, since this is the only function you’ve found to be not working, if there were something else wrong here.