Выход из команды с кодом 9009 visual studio
Я получаю следующую ошибку, которую не понимаю. Какие-либо предложения?
Ошибка 1 Команда «xcopy» D: \ Users \ johndoe \ Documents \ Visual Studio 2008 \ Projects \ MyProject \ MyProject.Modules.Ribbon \ bin \ Debug \ MyProject.Modules.Ribbon.dll "" D: \ Users \ johndoe \ Documents \ Visual Studio 2008 \ Projects \ MyProject \ MyProject \ bin \ Debug \ Modules \ "/ Y" завершился с кодом 9009. MyProject.Modules.Ribbon
Нашел свой ответ: в команде был разрыв строки между исходной и целевой строками. Итак, Visual Sudio рассматривала это как две команды. Устранение разрыва строки решило проблему.
Я зафиксировал эту ошибку на сервере сборки TeamCity. Я, наконец, решил это после проверки журнала сборки и обнаружил:
"'xcopy' не распознается как внутренняя или внешняя команда."
Затем я изменил свое заявление на:
C: \ Windows \ System32 \ xcopy "$ (ProjectDir) config \ Web.config. $ (ConfigurationName)" "$ (ProjectDir) Web.config" / Y / R
Перезапустите Visual Studio. Работал на меня
Эта ошибка может возникнуть, если ваша системная переменная среды PATH была установлена неправильно. Путь должен содержать (как минимум)
Установщиком msi, у которого явно есть проблемы.
Наконец, стоит отметить, что многие программы не замечают, если вы обновляете PATH во время их работы, поэтому для того, чтобы восстановленный путь вступил в силу, потребуется закрыть и повторно запустить программы, такие как Visual Studio или окна командной строки.
По какой-то причине ваша команда xcopy не удалась.
Я бы предположил, что либо файл DLL не существует (например, сборка не удалась), либо целевой путь не существует.
Запустите ту же командную строку в командной строке и посмотрите, какую ошибку она выводит.
Спасибо за вашу помощь.
Я дал полный путь к xCopy, и это сработало для меня.
Несмотря на то, что это старый пост, я нашел исправление, которое может кому-то помочь.
Что мне не помогло
Я использую Visual Studio 2013.
Что мне помогло .
Проверьте Переменные среды , проверьте ПУТЬ, есть ли в нем все или ничего или только часть.
Поскольку у меня была резервная копия System PATH, я просто скопировал переменные в
Наконец-то я дал проекту ребилд - вуаля! у меня это сработало.
В основном связано с путем C \ Program files . \ some.exe. Это должно быть "C \ Program files . \ some.exe"
В моем случае: я исправлю это, сделайте следующее: добавьте значение% SystemRoot% \ system32 в переменную Path переменной среды и перезагрузите мой компьютер, перестройте решение , все идет нормально.
AssemblyInfo.cs завершен с кодом 9009
Вы пытались указать полный путь к команде, выполняемой в команде события до или после сборки?
Я получаю ошибку 9009 из-за команды xcopy после сборки в Visual Studio 2008.
Команда "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\" завершилась с кодом 9009.
Однако в моем случае предоставление команды с полным путем решило проблему:
Если у меня нет полного пути, он запускается некоторое время после перезапуска, а затем останавливается.
Обратите внимание, что этот пример с пробелами не тестировался.
Код ошибки 9009 означает, что файл ошибки не найден. Все причины, приведенные в ответах, являются хорошим источником вдохновения, чтобы понять, почему, но сама ошибка просто означает неверный путь.
Это происходит, когда вам не хватает некоторых параметров среды для использования инструментов Microsoft Visual Studio 2010 x86.
Поэтому попробуйте добавить в качестве первой команды на этапах после сборки:
Его следует поместить перед любой другой командой.
Он установит среду для использования инструментов Microsoft Visual Studio 2010 x86.
Скорее всего, у вас есть место в вашем пути.
Вы можете обойти это, заключив в кавычки пути, тем самым оставляя пробелы. Например:
Была ли та же самая переменная после изменения переменной PATH из переменных среды в Win 7. Помогло возвращение к стандартному значению.
У меня была ошибка 9009, когда мой сценарий событий после сборки пытался запустить пакетный файл, который не существует по указанному пути.
Если скрипт действительно выполняет то, что ему нужно, и он просто выдает ошибку об ошибке, которую можно просто добавить:
до конца вашего сценария.
Я вызвал эту ошибку, когда отредактировал переменную окружения Path. После редактирования я случайно добавил Path= в начало строки пути. С такой неверно сформированной переменной пути мне не удалось запустить XCopy в командной строке (команда или файл не найдены), а Visual Studio отказалась выполнить шаг после сборки, сославшись на ошибку с кодом 9009.
XCopy обычно находится в C: \ Windows \ System32. Как только переменная среды Path позволила разрешить XCopy в командной строке DOS, Visual Studio хорошо построила мое решение.
Моя точная ошибка была
The command "iscc /DConfigurationName=Debug "C:\Projects\Blahblahblah\setup.iss"" exited with code 9009.
9009 означает, что файл не найден, но на самом деле не удалось найти часть команды «iscc».
Я исправил это, добавив ";C:\Program Files\Inno Setup 5 (x86)\" в системную переменную среды "path"
сегодня я вызываю интерпретатор python из cron в win32 и беру ExitCode (% ERRORLEVEL%) 9009, потому что системная учетная запись, используемая cron, не имеет пути к каталогу Python.
В моем случае мне пришлось сначала «CD» (сменить каталог) в нужный каталог, прежде чем вызывать команду, поскольку вызываемый мной исполняемый файл находился в каталоге моего проекта.
Проблема в моем случае возникла, когда я попытался использовать команду в командной строке для события Post-build в моей библиотеке классов тестирования. Когда вы используете кавычки, например, так:
или если вы используете консоль:
Это исправило проблему для меня.
Также убедитесь, что в окне редактирования событий после сборки в вашем проекте нет разрывов строк. Иногда копирование команды xcopy из Интернета, когда она многострочная, и вставка ее в VS, вызывает проблемы.
Я добавил «> myFile.txt» в конец строки на этапе предварительной сборки, а затем проверил файл на наличие фактической ошибки.
Для меня дисковое пространство было мало, и файлы, которые не могли быть записаны, должны были появиться позже. В других ответах упоминались отсутствующие файлы (или файлы с неправильным именем /неправильной ссылкой по имени), но основной причиной была нехватка места на диске.
Еще один вариант файла не найден из-за пробелов в пути. В моем случае в скрипте msbuild. Мне нужно было использовать строки & ampquot; в стиле HTML внутри команды exec.
Это довольно просто, у меня была эта проблема, и меня просто смутило.
Приложение использует аргументы командной строки, я удалил их, а затем добавил обратно. Внезапно проект не удалось построить.
Visual Studio -> Свойства проекта -> убедитесь, что вы используете вкладку «Отладка» (а не вкладку «События сборки») -> Аргументы командной строки
Я использовал текстовую область и Post /Pre-build, что неправильно в этом случае.
Для меня это произошло после обновления пакетов nuget с одной версии PostSharp до следующей в большом решении (проект ~ 80). У меня есть ошибки компилятора для проектов, которые имеют команды в событиях PreBuild.
«cmd» не распознается как внутренняя или внешняя команда, работающая программа или командный файл. C: \ Program Files (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): ошибка MSB3073: команда "cmd /c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ PreBuild.cmd ServiceInterfaces "завершен с кодом 9009.
Переменная PATH была повреждена и стала слишком длинной с несколькими повторными путями, связанными с PostSharp.Patterns.Diagnostics. Когда я закрыл Visual Studio и снова открыл его, проблема была исправлена.
Так же, как и другие ответы, в моем случае это было из-за отсутствующего файла. Чтобы узнать, что это за отсутствующий файл, вы можете перейти к окну вывода, и оно сразу покажет вам, что пропало.
Чтобы открыть окно вывода в Visual Studio:
Ответ tfa был отклонен, но на самом деле может вызвать эту проблему. Благодаря Hanzolo я посмотрел в окне вывода и нашел следующее:
После запуска npm install -g gulp я перестал получать эту ошибку. Если вы получаете эту ошибку в Visual Studio, проверьте окно вывода и посмотрите, является ли проблема неустановленной переменной среды.
На самом деле я заметил, что по какой-то причине переменная окружения% windir% иногда стирается. Что мне помогло, так это переустановить переменную среды windir в c: \ windows, перезапустить VS и все. Таким образом вы избавите себя от необходимости изменять файлы решения.
По крайней мере в Visual Studio Ultimate 2013, версия 12.0.30723.00, обновление 3, невозможно отделить оператор if /else от разрыва строки:
Еще одна причина: Если ваше событие перед сборкой ссылается на путь к папке с другими проектами и вы видите эту ошибку при запуске msbuild, но не Visual Studio, то вам нужно вручную расположить проекты в файле * .sln (с текстовым редактором), чтобы проект Таргетирование в событии строится до начала мероприятия. Другими словами, msbuild использует порядок, в котором проекты перечислены в файле * .sln, тогда как VS использует знание зависимостей проекта. Это произошло, когда после wixproj был указан инструмент, который создает базу данных для включения в wixproj.
Я думаю, что в моем случае в пути были русские символы (все проекты были в пользовательской папке). Когда я положил решение в другую папку (прямо на диске), все стало хорошо.
Мое решение было просто: вы пытались выключить и снова включить? Я перезагрузил компьютер, и проблема исчезла.
Моим решением было создать копию файла и добавить шаг в задачу сборки, чтобы скопировать мой файл поверх оригинала.
Я также столкнулся с этой 9009 проблемой при перезаписи.
Как правило, если файл уже существует и вы не указали переключатель /y (который автоматически перезаписывается), эта ошибка может возникать при запуске из сборки.
AssemblyInfo.cs вышел с кодом 9009
ОТВЕТЫ
Ответ 1
Вы пытались указать полный путь к команде, которая выполняется в команде события pre-or post-build event?
Я получал ошибку 9009 из-за команды xcopy post-build event в Visual Studio 2008.
Команда "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\" вышла с кодом 9009.
Однако, в моем случае, при условии, что команда с полным пути решена, проблема:
Если у меня нет полного пути, он запускается некоторое время после перезапуска, а затем останавливается.
Обратите внимание, что этот пример в отношении пробелов не проверен.
Ответ 2
Код ошибки 9009 означает, что файл ошибки не найден. Все основные причины, изложенные в ответах здесь, являются хорошим источником, чтобы понять, почему, но сама ошибка просто означает плохой путь.
Ответ 3
Это происходит, когда вам не хватает некоторых параметров среды для использования инструментов Microsoft Visual Studio x86.
Поэтому попробуйте добавить в качестве первой команды на этапах после сборки:
Для Visual Studio 2010 используйте:
Как уже упоминалось в комментариях @FlorianKoch, для VS 2017 используйте:
Его следует поместить перед любой другой командой.
Он установит среду для использования инструментов Microsoft Visual Studio x86.
Ответ 4
Скорее всего, у вас есть место в результирующем пути.
Вы можете обойти это, указав пути, тем самым позволяя пробелы. Например:
Ответ 5
Имела ту же переменную после изменения переменной PATH из переменных окружения в Win 7. Возвращение к умолчанию помогло.
Ответ 6
У меня была ошибка 9009, когда событие post post script пыталось запустить пакетный файл, который не существовал в указанном пути.
Ответ 7
Я вызвал эту ошибку, когда я отредактировал переменную окружения Path. После редактирования я случайно добавил Path= в начало строки пути. С такой измененной переменной пути мне не удалось запустить XCopy в командной строке (никакая команда или файл не найден), а Visual Studio отказалась запускать шаг после сборки, ссылаясь на ошибку с кодом 9009.
XCopy обычно находится в C:\Windows\System32. Как только переменная окружения Path разрешила XCopy получить разрешение в приглашении DOS, Visual Studio хорошо построила мое решение.
Ответ 8
до конца script.
Ответ 9
Ответ 10
В моем случае перед вызовом команды мне пришлось сначала записать "CD" ( "Изменить каталог" ) в соответствующий каталог, поскольку исполняемый файл, который я вызывал, был в моей директории проектов.
Ответ 11
Моя точная ошибка была
The command "iscc /DConfigurationName=Debug "C:\Projects\Blahblahblah\setup.iss"" exited with code 9009.
9009 означает, что файл не найден, но на самом деле он не смог найти часть "iscc" команды.
Я исправил его, добавив ";C:\Program Files\Inno Setup 5 (x86)\" в переменную системной среды "path"
Ответ 12
Сегодня я вызываю интерпретатор python из cron в win32 и беру ExitCode (% ERRORLEVEL%) 9009, потому что системная учетная запись, используемая cron, не имеет пути к каталогу Python.
Ответ 13
Проблема в моем случае возникла, когда я попытался использовать команду в командной строке для события Post-build в моей тестовой библиотеке классов. Когда вы используете такие кавычки:
или если вы используете консоль:
Это исправило проблему для меня.
Ответ 14
Кроме того, убедитесь, что в окне редактирования событий post build в вашем проекте нет разрывов строк. Иногда копирование команды xcopy из сети, когда она многострочная и вставляет ее в VS, вызовет проблему.
Ответ 15
Я добавил " > myFile.txt" в конец строки на этапе предварительной сборки, а затем проверил файл на фактическую ошибку.
Ответ 16
Тфа ответ был отклонен, но на самом деле может вызвать эту проблему. Благодаря hanzolo я посмотрел в окне вывода и нашел следующее:
После запуска npm install -g gulp я перестал получать эту ошибку. Если вы получаете эту ошибку в Visual Studio, проверьте окно вывода и посмотрите, является ли проблема неустановленной переменной среды.
Ответ 17
Для меня дисковое пространство было низким, и ожидается, что файлы, которые не могут быть записаны, будут представлены позже. В других ответах упоминались недостающие файлы (или неправильно названные/неправильные ссылки на файлы), но основной причиной было отсутствие дискового пространства.
Ответ 18
Еще один вариант файла не найден, из-за пробелов в пути. В моем случае в msbuild script. Мне нужно было использовать строки HTML и ampquot; в команде exec.
Ответ 19
То же, что и другие ответы, в моем случае это было из-за недостающего файла. Чтобы узнать, что является отсутствующим файлом, вы можете перейти в окно вывода, и он сразу покажет вам, что пропало.
Чтобы открыть окно вывода в Visual Studio:
Ответ 20
Я исправил это, просто перезапустив Visual Studio - я только что запустил dotnet tool install xxx в окне консоли, и VS еще не выбрал новые переменные среды и/или параметры пути, которые были изменены, поэтому быстрый перезапуск решил проблему.
Ответ 21
Это довольно просто, я столкнулся с этой проблемой и смущающе провалился.
Приложение использует аргументы командной строки, я удалил их, а затем добавил их обратно. Вдруг проект не смог построить.
Visual Studio → Свойства проекта → убедитесь, что вы используете вкладку "Отладка" (не вкладка "Build Events" ) → Аргументы командной строки
Я использовал текстовую область Post и Pre-build, которая была неправильной в этом случае.
Ответ 22
Для меня это произошло после обновления пакетов nuget от одной версии PostSharp до следующего в большом решении (проект ~ 80). У меня есть ошибки компилятора для проектов, которые имеют команды в событиях PreBuild.
'cmd' не распознается как внутренняя или внешняя команда, операционная программа или командный файл. C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1249,5): ошибка MSB3073: команда "cmd/c C:\GitRepos\main\ServiceInterfaces\DEV.Config\PreBuild.cmd ServiceInterfaces" вышел с кодом 9009.
Переменная PATH была испорчена слишком долго, с несколькими повторяющимися путями, связанными с PostSharp.Patterns.Diagnostics. Когда я закрыл Visual Studio и снова открыл его, проблема была исправлена.
Ответ 23
Мое решение было просто: как вы пытались отключить его и снова? Поэтому я перезапустил компьютер, и проблема исчезла.
Ответ 24
Я также столкнулся с этой проблемой 9009 , столкнувшись с ситуацией перезаписи.
В принципе, если файл уже существует и вы не указали переключатель /y (который автоматически перезаписывается), эта ошибка может возникнуть при запуске из сборки.
Ответ 25
На самом деле я заметил, что по какой-то причине переменная среды% windir% иногда стирается. То, что сработало для меня, было изменено на переменную среды windir на c:\windows, перезапустить VS и что это. Таким образом, вы не можете изменять файлы решений.
Ответ 26
По крайней мере, в Visual Studio Ultimate 2013, версии 12.0.30723.00 Update 3, невозможно разделить оператор if/else с разрывом строки:
Ответ 27
Еще одна причина: Если ваше событие pre-build ссылается на другой путь к bin файлам, и вы видите эту ошибку при запуске msbuild, но не Visual Studio, тогда вам нужно вручную организовать проекты в файле *.sln(с текстовым редактором), чтобы проект нацелены на событие, которое создается перед проектом события. Другими словами, msbuild использует порядок, в котором проекты перечислены в файле *.sln, тогда как VS использует знания зависимостей проекта. Это произошло, когда инструмент, который создает базу данных, которая будет включена в wixproj, была указана после wixproj.
Ответ 28
Я думаю, что в моем случае были русские символы в пути (все проекты были в папке пользователя). Когда я помещал решение в другую папку (прямо на диск), все стало нормально.
Ответ 29
Мое решение состояло в том, чтобы создать копию файла и добавить шаг к заданию сборки, чтобы скопировать мой файл поверх оригинала.
Ответ 30
Для меня это была перезагрузка Visual Studio. У меня была построена gulp с кодом 9009. Я установил gulp, но это не отразилось, пока я не перезапустил Visual Studio.
Я работаю над проектом, который требует, чтобы библиотеки DLL, созданные при создании моего решения, копировались из папки bin в другую папку, обе из которых находятся на моей машине, на моем диске C. Я написал пакетный файл, который использует xcopy для этого, которые вы можете увидеть здесь:
теперь я пробовал множество итераций этого файла, который находится по адресу:
поэтому моя командная строка события после сборки выглядит так:
Я этот пакетный файл сам по себе с двумя текстовыми файлами в папках на моем рабочем столе, и он отлично работает. Я также запустил его как есть с файлами, которые мне нужно скопировать самостоятельно, и это тоже отлично работает. Однако, когда я пытаюсь запустить это как событие после сборки, я получаю этот вывод:
Я провел некоторое исследование и обнаружил, что код ошибки 4 означает, что "произошла ошибка инициализации. Недостаточно памяти или дискового пространства, или вы ввели недопустимое имя диска или недопустимый синтаксис в команде линия."
Я также посмотрел, что такое MSB3073, и на самом деле не нашел многого, что может мне помочь. Итак, мой вопрос в том, что я делаю неправильно? Абсолютные пути все портят? Любая помощь здесь приветствуется.
играя с различными свойствами проекта, я обнаружил, что порядок сборки проекта был проблемой. Проект, который создал файлы, которые я хотел скопировать, был построен второй, но проект, который запускал пакетный файл как событие после сборки, был построен первый, поэтому я просто прикрепил событие сборки ко второму проекту, и он работает просто отлично. Спасибо всем за помощь.
предпочитают задачу MsBuild "копировать" в целевой объект AfterBuild над событием после сборки.
добавьте эту цель в файл проекта и удалите PostBuildEvent.
для чего это стоит, проблема в моем случае была вызвана с помощью '/' в качестве разделителя каталогов в . Необходимо использовать обратные косые черты.
в моем случае dll, которую я создавал, создавая проект, все еще использовался в фоновом режиме. Я убил приложение, а затем xcopy работал нормально, как и ожидалось.
Если проблема все еще сохраняется даже после установки after build в правильном проекте, попробуйте использовать "copy" вместо xcopy. Это сработало для меня.
Это слишком поздно, но публикация моего опыта для людей, смотрящих на него позже:- В MS VS 2010 у меня была такая же проблема. Он был разрешен путем размещения кавычек для публикации команд сборки копирования, которые содержали пробелы .
в свойствах проекта --> свойства конфигурации --> события сборки --> событие после сборки --> командная строка изменена
копировать $(ProjectDir) a\b\c $(OutputPath)
копировать "$(Каталог_проекта)а\б\с" "$(поле "выходной путь")"
указанная ошибка связана с событием post built. Каким-то образом VS tool не может скопировать файлы в папку назначения. Для этого может быть много причин. Чтобы проверить точную причину ошибки, перейдите в инструменты > опция> проект и решение > Built and run и меняем "MSBuild проект сборки вывода многословие "to"Диагностика". Это даст вам достаточно информации, чтобы обнаружить реальную проблему.
Я обнаружил, что проблема возникает, когда у вас есть несколько проектов, строящихся параллельно, и один или несколько проектов пытаются скопировать те же файлы, создавая условия гонки, которые приведут к случайным ошибкам. Так как же ее решить?
есть много вариантов, так как выше просто изменение вещей вокруг может решить проблему для некоторых людей. Были бы более надежные решения.
a. Ограничить копируемые файлы, т. е. вместо xcopy $(TargetDir).". вместо этого сделайте xcopy " $(TargetDir)$(TargetName).*".
b. Поймайте ошибку и повторите попытку i.e
c. Пользователь robocopy вместо xcopy
d. Вероятно, вы не захотите этого делать, так как это увеличит время сборки, но вы можете уменьшить максимальное количество параллельных сборок проекта до 1.
событие после сборки (в разделе События сборки в диалоговом окне Свойства) импортированного проекта имело переменную среды, которая не была определена.
Перейти Control Panel\All Control Panel Items\System\Advanced system settings добавить соответствующие переменная окружения, и не делать больше чем перезапуск VS2017 разрешил ошибку.
Кроме того, следуя от @Seans и другие ответы, касающиеся нескольких гонок/конфликтов проекта, создайте временную папку в выходной папке, например,
и выберите проект, производящий предпочтительный результат:
и build (no rebuild / clean) - это быстрое решение.
Я решил это, сделав следующее: В Visual studio я пошел в Project - > Project Dependencies
Я выбрал XXX.Тестовое решение и сказал ему, что это также зависит от решения XXX, чтобы сделать события после сборки в XXX.Тестовое решение не генерирует эту ошибку (выход с кодом 4).
Есть пример того, что я пробовал как команда VS post / pre-build:
вызов " projdirtest.летучая мышь"
вызовите projdirtest.летучая мышь!--1--> "projdir test.летучая мышь"
projdirтест.летучая мышь!--1-->. Я попробовал projdir как "$(ProjectPath) " и ручной путь.
Я поставил вывод на подробный и нашел следующее:
команда "C:UsersTraubenfuchsAppDataLocalTemp" написано неправильно или его не нашли. (Эта папка действительно существует, но я не знаю, что она хочет сделать.)
то же самое происходит, когда я помещаю команду xcopy в сборку pre/post.
Кто-нибудь знает, что я делаю не так?
недавно я встретил аналогичную проблему.
о вашем событии" hello world " после сборки : попробуйте вызвать powershell напрямую
мое событие предварительной сборки выглядит так:
моя скриптовая дорожка.ps1 выглядит так:
обратите внимание, что без "выхода 0" в конце я получил код возврата 1 из моего скрипта.
У нас была эта проблема из-за" политики ограничения программного обеспечения", настроенной в GPO домена. Похоже, что сборки pre и post создают a .командный файл cmd в папке temp. Вот что показал мне журнал:
cmd.exe (PID = 8456) идентифицировано C:\Users\brian\AppData\Local\Temp\tmp733425d2c0604973a90a0a175c13353e.exec.УМК как запрещено с помощью правила по умолчанию, Guid =
одна из возможных проблем заключается в том, что вы должны использовать $(ProjectDir) вместо $(ProjectPath)
при использовании $(ProjectPath) это на самом деле: "C:\Users\. \Project\MyProject.csproj"
и $(ProjectDir) что: "C:\Users\. \Project\"
обратите внимание, что первая версия указывает на ваш файл проектное решение. что приведет к провалу.
другой - это то, что $(ProjectDir) автоматически добавляет косую черту в пути. т. е. "$(ProjectDir)\test.bat" в итоге приводит к: "C:\Users. \Проект\Тест.летучая мышь"
также вы должны убедиться, что вы заключаете все пути к файлам в двойные кавычки
поэтому правильный вызов будет выглядеть так:
другие вещи, которые нужно проверить, - это убедиться, что каталог, из которого выполняется скрипт, правильный. Смотри так:visual studio 2012, postbuild event, bat-файл не создает новый файл (не выполняется)
вы проверили предложения в этом StackOverflow? Post Build вышел с кодом 1
вы должны закончить любые команды с @exit 0 в противном случае он не думает, что он закончил правильно
Читайте также: