Разница между bin, sbin, usr/bin, usr/sbin
Я заметил, что в busybox ссылки разложены по этим четырём директориям.
Есть ли какое-то простое правило, чтобы определить, в какой директории какая из ссылок должна лежать…
К примеру, kill лежит в /bin, а killall — в /usr/bin… Я не вижу никакой логики в таком разделении.
Вы, наверное, знаете, что Кен Томпсон и Дэннис Ритчи создали Unix на PDP-7 в 1969-ом. Так вот, примерно в 1971 они проапгрейдились до PDP-11 с парой дисков RK05 (по 1,5 мегабайта каждый).
Когда операционная система разрослась и перестала помещаться на первом диске (на котором была расположена корневая ФС), они перенесли часть на второй, где располагались домашние директории (поэтому точка монтирования называлась /usr — от слова user). Они продублировали там все необходимые директории ОС (/bin, /sbin, /lib, /tmp . ) и складывали файлы на новый диск, потому что на старом кончилось место. Потом у них появился третий диск, они примонтировали его в директории /home и перенесли туда домашние директории пользователей, чтобы ОС могла занять всё оставшееся место на двух дисках, а это были целых три мегабайта (огого!).
Разумеется, им пришлось ввести правило, что «когда операционная система загружается, она должна быть в состоянии примонтировать второй диск в директорию /usr, поэтому не надо класть программы типа mount на второй диск в /usr, а то получим проблему курицы и яйца». Вот так просто. И это относилось к Unix V6 35 лет назад.
Разделение /bin и /usr/bin (и всех подобных директорий) — это последствие тех событий, деталь реализации из 70-х, которая до сих пор, в течение десятилетий, копировалась бюрократами. Они никогда не задавали вопрос почему, они просто делали так. Это разделение перестало иметь смысл ещё до того, как Linux был создан, по нескольким причинам:
- При загрузке используется initrd или initramfs, который берёт на себя проблемы типа «этот файл нам нужен раньше чем тот». Таким образом, у нас уже есть временная файловая система, которая используется для загрузки всего остального.
- Разделяемые библиотеки (которые были добавлены в Unix ребятами из Berkley) не позволяют вам независимо менять содержимое /lib и /usr/lib. Эти две части должны соответствовать друг другу, иначе они не будут работать. Этого не происходило в 1974-ом, поскольку тогда у них была некоторая независимость из-за статической линковки.
- Дешёвые жёсткие диски преодолели барьер в 100 мегабайт где-то в 1990-ом и примерно в то же время появились программы для изменения размера разделов (partition magic 3.0 вышла в 1997-ом).
Разумеется, поскольку разделение есть, некоторые люди придумали правила, которые его оправдывают. Типа, корневой раздел нужен для всяких общих штучек ОС, а в /usr надо класть свои локальные файлы. Или в / помещают то, что распространяет AT&T, а в /usr — то, что твой дистрибутив, IBM AIX, или Dec Ultrix, или SGI Irix добавили, а в /usr/local лежат файлы, специфичные для твоей системы. А потом кто-то решил, что /usr/local — это не подходящее место, чтобы туда устанавливать новый софт, так что давайте ещё добавим /opt! Не удивлюсь, если появится ещё и /opt/local…
Разумеется, за 30 лет из-за такого разделения появлялись и исчезали всякие интересные специфичные для отдельных дистрибутивов правила. Например, «/tmp очищается при перезагрузке, а /usr/tmp — нет». (И в Ubuntu /usr/tmp нет в принципе, а в Gentoo /usr/tmp — это символическая ссылка на /var/tmp, на который теперь распространяется то правило, и он не очищается при перезагрузке. Да, это всё было ещё до tmpfs. А ещё бывает, что корневая ФС доступна только на чтение, и тогда в /usr тоже не надо ничего писать, а надо писать в /var. Или в / в основном нельзя писать, не считая того, что в /etc, которую иногда пытались перенести в /var. )
Бюрократы вроде Linux Foundation (которые поглотили Free Standards Group во время расширения годы назад) с радостью документируют и усложняют эти правила, даже не пытаясь понять, почему они появились. Они не догадываются, что Кен и Дэннис просто перенесли часть ОС в их домашнюю директорию, из-за того, что диск RK05 на PDP-11 был слишком мал.
Я практически уверен, что в busybox просто помещает файлы так же, как это исторически сложилось. Нет никакой реальной причины делать так до сих пор. Лично я просто делаю /bin, /sbin и /lib ссылками на аналогичные директории в /usr. Ведь люди, которые работают со встраиваемым софтом, стараются разбираться и упрощать…
Источник
Почему Python в Linux требует строку #! / Usr / bin / python?
Довольно простой вопрос: в Linux почему Python требует строку
в начале файла python, так как Windows не работает?
Что это значит делать? потому что описание «Ссылки на Python» немного расплывчато .
6 ответов
Вы указали указанную строку, чтобы сообщить компьютеру, какую программу / интерпретатор использовать при непосредственном запуске файла / скрипта, и любые аргументы, которые должны быть переданы этой программе при запуске скрипта. Это, однако, не требование Python, это требование ядра / системы linux, если вы намереваетесь напрямую запускать скрипт (а не передавать его на Python с помощью синтаксиса ниже).
не требуется, если вы собираетесь выполнять python script.py или аналогичные. Это необходимо, только если вы намереваетесь напрямую запускать скрипт / файл, не предоставляя также интерпретатору (например, python).
Для сценария Bash это будет иметь что-то вроде этого:
Это указывает на систему, которая при ее запуске должна запускаться через /bin/bash, которая является одним из языков shell / shell-script в системе .
Для кода Python, здесь, вы захотите, чтобы исполняемый файл выполнялся через Python, поэтому вы рассказываете, какой интерпретатор вы намереваетесь запустить в нем.
Это, как и для Bash, указывает, что следует использовать /usr/bin/python (это, вероятно, Python 2 или Python 3, в зависимости от ваших индивидуальных конфигураций системы).
Таким образом, вы можете запускать ./filename.py или ./executable или ./scripttorun напрямую.
Без этой строки в начале и при условии, что вы установили файл / script, чтобы быть исполняемым и предполагая, что вы работаете с скриптом Python, вам нужно будет запустить python filename.py или подобное, если у вас не было t он #!/usr/bin/python. (Для сценария Bash вам нужно будет делать bash script.sh или аналогично для других скриптов / языков, таких как Perl, Ruby и т. Д.)
Выделение синтаксиса выше относится к языку в каждом разделе, хотя это не имеет большого значения.
называется «shebang» и указывает путь к двоичному интерпретатору, который будет использоваться для интерпретации остальных команд в файле. Обычно это первая строка скрипта.
Таким образом, строка #!/usr/bin/python указывает, что содержимое файла будет интерпретировано двоичным файлом python, расположенным в /usr/bin/python.
Обратите внимание, что строка shebang анализируется на ядро, а затем скрипт будет в конечном итоге вызываться как аргумент:
Аналогично в случае #!/bin/bash:
Технически это не требует. Для этого требуется путь к среде, в которой выполняется ваш скрипт. Ваши будущие сценарии будут лучше включать / usr / bin / env, а затем указать python. Эти грантополучатели, что ваш скрипт работает в среде python независимо от того, где установлен python. Вы хотите сделать это по соображениям совместимости, вы не можете быть уверены, что следующий человек, которому вы делитесь своим кодом, будет иметь python, установленный в usr / bin / python, или что у них будут разрешения на эти системные файлы.
Вот аналогичный Q & amp; A из переполнения стека.
То, что выглядит в вашем скрипте:
Я также вижу некоторую озабоченность как указать python3. Вот как это сделать:
в Linux, Python могут или не могут требовать [ф10] линия (притон). Это зависит от того, как Питон коды обрабатываются, либо работает коды в интерактивном режиме Python или в скрипт Python.
интерактивный режим Python позволяет пользователю вводить и запускать Python-коды, которые не требуют линии притон. Для запуска в интерактивном режиме, откройте терминал и введите на [F11] для Python 2.X или [ф12] для Python 3.Х.
в интерактивном режиме питона позволяет пользователям писать и сохранять на Python коды в текстовый файл, затем запустить позже коды. Это может или не может потребовать от линии притон. Однако, есть два известных причин, когда линия притон требуется для использования скрипта Python в Linux.
для запуска Python коды в исполняемый скрипт, т. е. определяет, как эти коды должны работать и через какой переводчик; для запуска Python кодов применительно к конкретной версии Python, т. е. работать коды, совместимые с питона 2.Х или Python 3.X только
практика с Python скрипты
ниже приведены список и содержимое файлов, которые я использовал, чтобы показать, что случаи [от f13] линия (притон) требуется или не требуется.
[Ф2] [ф14] содержится исходный код только. [Ф3] [ф15] содержит исходный код и линия притон. [Ф4] [ф16] содержит так же, как [f17 в] и сделать его исполняемым. [ф18] содержит так же, как [зг19], кроме того, адаптировано для работы с Python 3 путем переименования первой линии [20 фунтов]. [клавиши f21] содержит так же, как [ф22] и сделать его исполняемым. [ф23] содержит так же, как [ф24] и сделать его исполняемым, за исключением сохранен с опцией [f25 привод датчика] в текстовом редакторе, т. е. коврик.
после этого, пользователю будет представлен с двумя методами для запуска скриптов Python. Оба метода были продемонстрированы как ниже.
практика с Python скрипты
ниже перечислены команды и выход при работе исходный код с Python 2 и Python 3.
обе версии Python удалось успешно запустить скрипт. Следовательно, линия притон не требуется при запуск скрипта Python через [ф26] или команды python3.
способ 2: запуск скрипта Python
ниже перечислены команды и выход при работе исходный код с линией притон, которые адаптированы к ни, Python 2 и Python 3, в том числе и неисполняемые и исполняемые случаях.
первый скрипт уже не удалось, потому что эти сценарии не являются исполняемыми, независимо от наличия линии притон или нет (для обслуживания доказательство см. в способ 2: запуск скрипта Python ниже). Последние два скрипта есть строка притон и исполняемый.
судя по всему, сценарий, который был сделан исполняемым, в сущности, бесполезно без линии притон. Следовательно, нужны линии хижина и скрипт должен быть исполняемым при запуске кодов Python в исполняемый скрипт.
когда притон не работает
[и D40]в моем подготовлен и протестирован примеру, работа [ф28] как исполняемый скрипт не удалось, и возвращается сообщение об ошибке.[!и D40] [ф7] [dрайвер d41]это известное ограничение, что притон не работает или становится недействительным. Когда файл сохранен в кодировке Юникод спецификации (метка порядка байтов), он не сможет нормально запустить как исполняемый скрипт Python.[!dрайвер d41] [d43 см.]когда притон не работает[!d43 см.]
этот дополнительный пример должна рассматриваться как поддерживает только доказательство. Пользователь должен избегать этот пример, хотя результат безвреден.
я создал еще один файл с названием hello1e.py, который содержит так же, как [f30 С] и сделать его исполняемым. Запустив этот скрипт вернул ошибку синтаксиса.
при запуске этого скрипта, во-первых, курсор мыши изменится на знак «плюс», а не по внешнему виду. Ошибки не будут показаны, пока я не сделал кнопкой мыши на рабочем столе или окне терминала. Затем этот скрипт создает файл [ф31] в том же каталоге, что и скрипт.
в [f32 из файла] был идентифицирован как PostScript-файл, без расширения файла. Этот файл может быть открыт в окне просмотра документа, т. е. выказывают, а файл на самом деле содержится скриншот окна, которое я щелкнул раньше. По моему опыту, файл может достигать нескольких мегабайт.
опять потребовалось линии хижина и скрипт должен быть исполняемым при запуске скрипта Python в исполняемый скрипт. В противном случае, скрипт будет безобразничать, как описано выше.
термин «сделать исполняемым» или «должен быть исполняемый» ссылается на разрешение на запуск скрипта. Это делается путем выполнения команды chmod +x FILENAME в терминале, или включите опцию «разрешить этому файл для запуска программы» или что-то подобное в Примечания[!окна д51], в файловый менеджер.
[о d54]в то время как другие существующие ответы были охвачены практически все, этот ответ занял другой подход с использованием практических примеров, чтобы объяснить дело. Синтаксис кода были написаны с осторожностью, такой, что примеров может выполняться либо на Python 2 и Python 3, так как он.[!о d54]
Питон коды были адаптированы из известное ограничение и используя Python на платформах Unix, с дополнительными одну строку кода в строку «Здравствуй, мир!» программа.
все коды и команды были полностью протестированы и работает в системе xubuntu в 14.04, которая в Python 2.7 и Python 3.4 установлен по умолчанию.
Источник
Как исправить проблему с «Sub-process /usr/bin/dpkg returned an error code»?
sudo apt-get autoremove
И проблема решена.
Судя по всему, когда-то ты пытался установить пакет от 32 битной системы и вместе с ним, в зависимостях устнанавливался libkrb5support0, но установился некорректно — система-то у тебя 64 битная.
Указанная команда удалит все уже не нужные пакеты, в том числе и этот.
Конкретный список пакетов тебе подсказывает система:
The following packages were automatically installed and are no longer required:
gcc-5-base:i386 libasyncns0:i386 libaudio2:i386 libbsd0:i386
libcdparanoia0:i386 libdbus-1-3:i386 libdrm2:i386 libedit2:i386 libelf1:i386
libexpat1:i386 libffi6:i386 libglib2.0-0:i386 libgmp10:i386 libgnutls30:i386
libhogweed4:i386 libice6:i386 libidn11:i386 libjbig0:i386
libjpeg-turbo8:i386 libjpeg8:i386 libjson-c2:i386 libkrb5support0:i386
liblcms2-2:i386 libmng2:i386 libnettle6:i386 libogg0:i386 libp11-kit0:i386
libpng12-0:i386 libsamplerate0:i386 libsm6:i386 libsqlite3-0:i386
libssl1.0.0:i386 libstdc++6:i386 libtasn1-6:i386 libtxc-dxtn-s2tc0:i386
libwrap0:i386 libx11-6:i386 libxau6:i386 libxcb1:i386 libxdamage1:i386
libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxshmfence1:i386 libxss1:i386
libxt6:i386 libxv1:i386 libxxf86vm1:i386
Источник
Почему библиотека requests не работает при проверке статуса кода в Python?
Писал скрипт, который проверяет статус сервера в таком варианте все работало:
> python3 requester.py ya.ru
[200] Все хорошо: https://ya.ru
> python3 requester.py ya.ru/bgdtrubi
[404] Страница отсутствует: https://ya.ru/bgdtrubi
Но код ответа не всегда соответствует заданным, по этому я отредактировал, что бы понимать какой код возвращает скрипт:
При вводе существующего домена вывод терминала такой:
> python3 requester.py ya.ru
[200] Все хорошо: ya.ru
> python3 requester.py ya.ru/bgdtrubi
[404] Не все хорошо: ya.ru/bgdtrubi
Traceback (most recent call last):
File «/home/usr/.local/lib/python3.6/site-packages/urllib3/connection.py», line 157, in _new_conn
(self._dns_host, self.port), self.timeout, **extra_kw
File «/home/usr/.local/lib/python3.6/site-packages/urllib3/util/connection.py», line 61, in create_connection
for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
File «/usr/lib/python3.6/socket.py», line 745, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File «/home/usr/.local/lib/python3.6/site-packages/urllib3/connectionpool.py», line 672, in urlopen
chunked=chunked,
File «/home/usr/.local/lib/python3.6/site-packages/urllib3/connectionpool.py», line 387, in _make_request
conn.request(method, url, **httplib_request_kw)
File «/usr/lib/python3.6/http/client.py», line 1264, in request
self._send_request(method, url, body, headers, encode_chunked)
File «/usr/lib/python3.6/http/client.py», line 1310, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File «/usr/lib/python3.6/http/client.py», line 1259, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File «/usr/lib/python3.6/http/client.py», line 1038, in _send_output
self.send(msg)
File «/usr/lib/python3.6/http/client.py», line 976, in send
self.connect()
File «/home/usr/.local/lib/python3.6/site-packages/urllib3/connection.py», line 184, in connect
conn = self._new_conn()
File «/home/usr/.local/lib/python3.6/site-packages/urllib3/connection.py», line 169, in _new_conn
self, «Failed to establish a new connection: %s» % e
urllib3.exceptions.NewConnectionError: : Failed to establish a new connection: [Errno -2] Name or service not known
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File «/home/usr/.local/lib/python3.6/site-packages/requests/adapters.py», line 449, in send
timeout=timeout
File «/home/usr/.local/lib/python3.6/site-packages/urllib3/connectionpool.py», line 720, in urlopen
method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
File «/home/usr/.local/lib/python3.6/site-packages/urllib3/util/retry.py», line 436, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host=’yqqqqa.ru’, port=80): Max retries exceeded with url: / (Caused by NewConnectionError(‘: Failed to establish a new connection: [Errno -2] Name or service not known’,))
During handling of the above exception, another exception occurred:
Источник