Сценарий Python не будет запускаться без предшествующего файла сценария в командной строке с помощью «python3». Ошибка: «команда не найдена» (18.04) [dубликат]

Question 1

В нашей школьной системе мы можем запускать файлы сценариев без ввода bash или csh или того, что у вас нет, указывая, какой тип скрипта он есть. Однако на Ubuntu мне нужно ввести bash script.bash, например. Это всегда необходимо в Ubuntu, или это какая-то настройка, которую я могу изменить?

Question 2

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 3

Question 4

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 5

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 6

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 7

Question 8

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 9

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 10

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 11

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 12

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Question 13

Question 14

Убедитесь, что вы запускаете скрипт с помощью ./ script или полного пути или чего-то еще. Сценарий может не работать (он работает, если каталог находится в $ PATH , например / usr / bin ), так как в системах UNIX это не
Убедитесь, что сценарий является исполняемым, например: chmod + x script будет создан это исполняемый файл.
Убедитесь, что у вас есть #! / bin / bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно использовать / bin / bash , если вы используете функции bash, также / bin / sh [ ! d7] был привязан к / bin / bash , но теперь-в-днях (насколько я заметил) он символически связан с тире , который не обеспечит совместимость с bash, только POSIX sh . Это очень важно, даже у довольно дорогого программного обеспечения у нашей фирмы есть эта проблема: скрипты содержат #! / Bin / sh в качестве первой строки, но также зависят от функциональности bash.

Question 15

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 16

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 17

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 18

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 19

Question 20

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 21

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 22

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 23

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 24

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 25

Question 26

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 27

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 28

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 29

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 30

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 31

Question 32

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 33

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 34

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Question 35

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Question 36

Альтернативным, сильно обескураженным способом является добавление . к PATH .

  PATH = ".: $ PATH"

или

  PATH = "$ PATH :."

Проблема с этим подходом заключается в том, что в первом случае любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены. [ ! d8]

Рассмотрим следующее:

Файл: ls

  #! / bin / bash ./my_malicious_script & amp; gt; / dev / null / bin /  ls "$ @"

Скорее всего, вы даже не заметили бы, пока не стало слишком поздно.

Question 37

Question 38

Убедитесь, что первая строка файла читается:

  #! / bin / bash

Если shebang - #! / bin / sh , вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если / bin / sh является символической ссылкой на bash , bash будет работать в режиме совместимости POSIX при запуске как sh, отключив некоторые (но не все) bash-функции. [ ! d5]

Вы также должны убедиться, что скрипт является исполняемым, конечно.

muru · Accepted Answer · 23 July 2018 в 09:00

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

Поэтому мне придется запускать его так: ./script, как я обнаружил. Это лучше, чем необходимость набирать «bash». каждый раз, и это имеет смысл. Кажется, я знал это раньше, это просто проскользнуло. Ну, спасибо, спасибо! — muttley91, 10 February 2011 в 21:25
Теоретически вы можете поместить текущий рабочий каталог в переменную PATH, чтобы вы могли использовать только «скрипт». вместо "./ script & quot; но я предупреждаю вас: это действительно не привычка к UNIX-системам, и это может быть проблема безопасности! Также в школе нехорошо учиться чему-то, что никогда не было решением для UNIX-систем, поэтому я бы избегал этого решения ... — LGB, 11 February 2011 в 12:26
Или, предпочтительно, #!/usr/bin/env bash, который немного более портативен. — Sparhawk, 9 March 2014 в 20:46

muru · Accepted Answer · 23 July 2018 в 09:45

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

muru · Accepted Answer · 23 July 2018 в 09:49

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

muru · Accepted Answer · 31 July 2018 в 17:02

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

muru · Accepted Answer · 2 August 2018 в 10:03

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

muru · Accepted Answer · 3 August 2018 в 08:49

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

muru · Accepted Answer · 5 August 2018 в 00:07

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

muru · Accepted Answer · 6 August 2018 в 16:28

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

muru · Accepted Answer · 8 August 2018 в 20:39

Убедитесь, что вы запускаете скрипт с помощью ./script или полного пути или чего-то еще. Просто script может не работать (он работает, если каталог находится в $PATH, например /usr/bin), так как в системах UNIX это не привычка иметь текущий каталог на вашем пути (по соображениям безопасности, и это хорошо! ) Убедитесь, что сценарий выполним, например: chmod +x script сделает его исполняемым. Убедитесь, что у вас есть #!/bin/bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \ r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно иметь /bin/bash, если вы используете функции bash, также /bin/sh был привязан к /bin/bash, но теперь-в-днях (насколько это возможно Я заметил), он символически связан с dash, который не обеспечит совместимость с bash, только POSIX sh. Это очень важно, даже довольно дорогое программное обеспечение в нашей фирме имеет эту проблему: скрипты содержат #!/bin/sh в качестве первой строки, но также зависят от функциональности bash.

muru · Accepted Answer · 14 August 2018 в 10:27

Убедитесь, что вы запускаете скрипт с помощью ./ script или полного пути или чего-то еще. Сценарий может не работать (он работает, если каталог находится в $ PATH , например / usr / bin ), так как в системах UNIX это не
Убедитесь, что сценарий является исполняемым, например: chmod + x script будет создан это исполняемый файл.
Убедитесь, что у вас есть #! / bin / bash в качестве первой строки в вашем скрипте. Также убедитесь, что он не редактируется с помощью какого-либо редактора Windows, поскольку они часто используют «тип DOS» для eol (конец строки), который отличается от UNIX (если контрольный список выше в порядке, но вы получили «плохое» интерпретатор: нет такого файла или каталога "или так, даже если это / bin / bash, это часто является причиной, так как непечатаемый - так что вы обычно этого не видите - \r будет рассматриваться как часть путь переводчика)

Другие уже упомянули: важно использовать / bin / bash , если вы используете функции bash, также / bin / sh [ ! d7] был привязан к / bin / bash , но теперь-в-днях (насколько я заметил) он символически связан с тире , который не обеспечит совместимость с bash, только POSIX sh . Это очень важно, даже у довольно дорогого программного обеспечения у нашей фирмы есть эта проблема: скрипты содержат #! / Bin / sh в качестве первой строки, но также зависят от функциональности bash.

Поэтому мне придется запускать его так: ./script, как я обнаружил. Это лучше, чем необходимость набирать «bash». каждый раз, и это имеет смысл. Кажется, я знал это раньше, это просто проскользнуло. Ну, спасибо, спасибо! — muttley91, 10 February 2011 в 21:25
Теоретически вы можете поместить текущий рабочий каталог в переменную PATH, чтобы вы могли использовать только «скрипт». вместо "./ script & quot; но я предупреждаю вас: это действительно не привычка к UNIX-системам, и это может быть проблема безопасности! Также в школе нехорошо учиться чему-то, что никогда не было решением для UNIX-систем, поэтому я бы избегал этого решения ... — LGB, 11 February 2011 в 12:26
Или, предпочтительно, #! / Usr / bin / env bash , который немного более портативен. — Sparhawk, 9 March 2014 в 20:46

geirha · Answer 11 · 23 July 2018 в 09:00

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 12 · 23 July 2018 в 09:00

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 13 · 23 July 2018 в 09:45

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 14 · 23 July 2018 в 09:45

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 15 · 23 July 2018 в 09:49

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 16 · 23 July 2018 в 09:49

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 17 · 31 July 2018 в 17:02

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 18 · 31 July 2018 в 17:02

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 19 · 2 August 2018 в 10:03

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 20 · 2 August 2018 в 10:03

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 21 · 3 August 2018 в 08:49

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 22 · 3 August 2018 в 08:49

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 23 · 5 August 2018 в 00:07

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 24 · 5 August 2018 в 00:07

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 25 · 6 August 2018 в 16:28

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 26 · 6 August 2018 в 16:28

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 27 · 8 August 2018 в 20:39

Убедитесь, что первая строка файла читается:

#!/bin/bash

Если shebang - #!/bin/sh, вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если /bin/sh является символической ссылкой на bash, bash будет работать в режиме совместимости с POSIX при запуске как sh, отключив некоторые (но не все) функции bash.

Вам также нужно будет сделать конечно скрипт исполняемый, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

nyuszika7h · Answer 28 · 8 August 2018 в 20:39

Альтернативный, сильно обескураженный способ добавляет . к PATH.

PATH=".:$PATH"

или

PATH="$PATH:."

Проблема с этим подходом заключается в том, что в первом case, любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены.

Рассмотрим следующее:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo, например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед /bin. Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

nyuszika7h · Answer 29 · 14 August 2018 в 10:27

Альтернативным, сильно обескураженным способом является добавление . к PATH .

  PATH = ".: $ PATH"

или

  PATH = "$ PATH :."

Проблема с этим подходом заключается в том, что в первом случае любая системная команда может быть переопределена исполняемыми файлами из текущего каталога, а в последнем случае неизвестные команды все равно могут быть переопределены. [ ! d8]

Рассмотрим следующее:

Файл: ls

  #! / bin / bash ./my_malicious_script & amp; gt; / dev / null / bin /  ls "$ @"

Скорее всего, вы даже не заметили бы, пока не стало слишком поздно.

Выбор слов немного вводит в заблуждение. Команды не будут отменены. Если у вас есть команда в текущем рабочем каталоге, которая имеет то же имя, что и тот, кто живет в системных каталогах, скажем, echo , например, тот, который находится в вашем каталоге, будет использоваться просто потому, что этот каталог установлен в переменной PATH перед / bin . Shell просто ищет команды в определенных каталогах в зависимости от их порядка в PATH и не отменяет / не уничтожает ничего. Но да, это имеет последствия — Sergiy Kolodyazhnyy, 22 July 2018 в 11:14

geirha · Answer 30 · 14 August 2018 в 10:27

Убедитесь, что первая строка файла читается:

  #! / bin / bash

Если shebang - #! / bin / sh , вы не должны использовать какие-либо специфичные для bash функции, только функции POSIX. Даже если / bin / sh является символической ссылкой на bash , bash будет работать в режиме совместимости POSIX при запуске как sh, отключив некоторые (но не все) bash-функции. [ ! d5]

Вы также должны убедиться, что скрипт является исполняемым, конечно.

Нет, я все равно решил, что это просто по привычке. — muttley91, 10 February 2011 в 19:24

Сценарий Python не будет запускаться без предшествующего файла сценария в командной строке с помощью «python3». Ошибка: «команда не найдена» (18.04) [dубликат]

30 ответов

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls

Другие вопросы по тегам:

Похожие вопросы:

Сценарий Python не будет запускаться без предшествующего файла сценария в командной строке с помощью «python3». Ошибка: «команда не найдена» (18.04) [dубликат]

30 ответов

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] #!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@" Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls

Другие вопросы по тегам:

Похожие вопросы:

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.

Файл: ls [ ! d5] `#!/bin/bash ./my_malicious_script &>/dev/null /bin/ls "$@"`
Скорее всего, вы даже не заметите, пока не станет слишком поздно.