apt-get требует root прав. То, что для их получения sudo по‐умолчанию спрашивает пароль пользователя — это фишка sudo. Про пароль root в этой ветке до вас не говорил никто, только про права.
Кстати, с разработчиками дистрибутива можно договариваться и для freeware, и даже для платных продуктов. Во всяком случае, я в основном дереве portage (Gentoo) видел все три варианта: тут есть Opera (старая), chrome, nero, пачка игрушек. Но, боюсь, что договориться будет сложнее (разве что вы подпишетесь на самостоятельную поддержку пакета) или невозможно по идеологическим причинам (для дистрибутивов вроде gNewSense).
If a comma-separated sequence of key/datum pairs is given, they are evaluated from left to right to define the entries of the dictionary: each key object is used as a key into the dictionary to store the corresponding datum. This means that you can specify the same key multiple times in the key/datum list, and the final dictionary’s value for that key will be the last one given.
. То же самое написано в документации для Python 3.4.0. Так что нормальный способ. Только учтите, что вычисляться будут все выражения. Без lambda это ни в коем случае не замена switch.
Постоянно вижу этот знак внутри креста. Только не припомню, чтобы видел его без креста. Аптек с красным крестом не помню вообще, но помню A5 без чаш, змей и крестов вообще.
. Впрочем, если ваш парсер будет считать, что тут есть присваивание, то это вряд ли кого огорчит.
Я сейчас подумал и понял, что тут дело не в «не додумались». Если в первом случае можно просто написать if eval(condition), то во втором вы можете захотеть написать execute line_number . 'append' и потом собственно добавляемые строки. Правда это не отменяет тех фактов, что, во‐первых, добавляемые строки можно засунуть в execute и, во‐вторых, я ни разу не видел, чтобы кто‐то использовал append (правда, я уверен, что кто‐то его использует). Так что, возможно, незавершённый append не запрещён, чтобы кому‐то не пришлось возиться с line continuation и кучей дополнительных символов (кавычки, \n и точка для объединения строк).
Три факта во вред append:
подсветка синтаксиса для него предполагает, что завершающая точка должна находиться строго в начале строки (на самом деле она может находиться также на одном уровне отступа с командой append). Также подсветка не работает с execute 'append'
при вставке отступ сохраняется
при использовании append! (с восклицательным знаком) не решает проблему с отступом, и впридачу не позволяет использовать отступ перед точкой
Это я к тому, что нормальный разработчик обычно предпочтёт не использовать append, так как с высокой вероятностью ему придётся либо переделывать отступ у вставляемого append текста, либо нарушать отступы в своём тексте. Впрочем, такое останавливает далеко не всех.
Для VimL нельзя составить синтаксический парсер: значение символов | и новой строки зависит от контекста выполнения. Сделать хак для парсера, чтобы он нормально это обрабатывал ещё можно, но это не всё: значение тех же символов (особенно первого) также зависит и от состояния интерпретатора, а именно от того, как определена пользовательская команда (если, конечно, именно она стоит до данных символов). То есть вы не можете распарсить строчку «Foo abc|let a=1» пока не выполните предыдущую, так как она может содержать command! -nargs=1 -bar Foo :echo <q-args>, а может command! -nargs=1 Foo :echo <q-args>.
Это не единственная проблема, но вторую можно просто игнорировать:
execute 'if '.condition
echo 'True'
endif
делает именно то, что вы подумали. Правда, явно запрещён в документации. Что не додумались запретить, так это
execute 'append'
let b=1
.
. Впрочем, если ваш парсер будет считать, что тут есть присваивание, то это вряд ли кого огорчит.
Я пока не припоминаю никаких других проблем, но они наверняка найдутся, если вы начнёте писать транслятор.
Я слышал ещё про другое решение: просто изменить хэш‐функцию с old(secret) на new(old(secret)).
Если вы используете вариант с изменением хэша при логине, то вы получаете сразу две проблемы: во‐первых, пользователи, которые к вам более не заходят, лишаются защиты, во‐вторых, вам нужно сильнее изменить код, занимающийся авторизацией. В моём варианте нужно просто один раз изменить базу и изменить функцию хэширования, не добавляя более никакой логики.
Точнее все проекты, поддерживающие запуск на python3 можно установить для python3, python2 или (за исключением некоторых) вообще для всех поддерживаемых версий python сразу, включая pypy и jython (правда, поддержку последних часто не указывают, даже если на них всё работает). У меня в /usr/lib/python-exec/python3.3 находятся 55 скриптов. Таже 56 у python3.2, 57 у python2.6 и 59 у python2.7, что говорит о хорошей поддержке третьего python среди используемых мною пакетов (их 19, 20, 21 и 22 соответственно для 3.3, 3.2, 2.6 и 2.7). И всё, что есть в /usr/lib/python-exec, установлено emerge.
Правда, я не вижу Gentoo в продакшене. Но в её репозиториях всё есть — факт :)
“Странные звёздочки с дефисами” — это, кажется, аналог modelines для какого‐то редактора (emacs?). Можно с тем же успехом использовать ́# vim: fileencoding=utf-8. С python3 не нужно и того (вы либо пишете в UTF-8, либо вас посылают с SyntaxError).
Хотя «привет мир» без звёздочек с дефисами и вообще без не‐ASCII можно очень легко сделать: просто сразу скажите новичку, как использовать gettext и писать многоязычные приложения :) Разумеется, все сообщения в коде будут на английском.
Проблемы есть, но они решаются. И их меньше, чем во многих других языках. Есть отличная практика, которая убережёт вас от минусов за разжигание священных войн: как только вам захочется написать подобное не соответствующее теме сообщение (не важно, насколько оно правдиво), возьмите какой‐нибудь shell скрипт длиною хотя бы в десяток строк и перепишите его для работы на tcsh. Уверяю, после данного действия все прочие скриптовые языки станут казаться верхом совершенства.
Так движок же открытый. Можно держать собственную ветку и организовать кампанию по пропихиванию патчей из этой ветки в upstream. Тем более, что и новой Opera эти патчи могут быть небесполезны: сколько их уже пилят за выделение ссылок. А тут кто‐то за них напишет, так что может помогут с пропихиванием. Если сможет и захочет, конечно. Но чтобы это узнать надо спросить. Можно ещё спросить разработчиков движка, зная Google, я на них не надеюсь.
Разумеется, речь идёт о QtWebEngine. Не знаю, правда, насколько «основан» будет означать совместимость патча с Blink.
Кстати, мне на почте говорили, что эти самые заказные и ценные идут дольше из‐за необходимости регистрировать перемещения таких отправлений. Из этого я сделал вывод, что никакими роботами не пахнет в большинстве отделений (что меня не удивило), а человеку от наличия базы ни жарко, ни холодно: быстрее посмотреть на конверте.
Конечно, на конверте может быть неразборчиво написано, но во множестве отделений при приёме заказных и ценных ничего, кроме индекса, в базу не заносится.
И ещё: где вы видели занесение адреса в БД? Я не раз смотрел, как оператор набивает данные и видел везде одну и ту же программу с одними и теми же полями: тип отправления, номер отправления, индекс, (поле, заполняющееся из индекса автоматически), способ пересылки (наземная/самолётом), получатель, масса, ценность (для ценных), доп. услуги (уведомления, наклейка марок, поиск индекса, …).
А как его ещё можно произвести? Я кроме time для замеров раньше ничего больше не использовал. На малых файлах time ожидаемо показывает нули, pv показывает чушь.
Терминал тут не причём. Подозреваю hilite — это программа для покраски stderr в красный цвет. Подозреваю, что hilite также причастна к неработающему mc и bash, стартующему в неинтерактивном режиме по‐умолчанию. Так как mc мне не нужен, bash’у можно сказать -i, а почти всё остальное работает (т.к. проверяет stdout, а не stderr, на принадлежность терминалу, который никто не трогал), исправлять я ничего не пытался. Во всяком случае, запуск pv не из оболочки работает штатно. Наверное, надо попробовать stderred.
Какая к чёрту разница, с какой скоростью pv успевает считать нули? Вы не получите такой разницы на реальных файлах, даже если они находятся в памяти.
И ещё: вы сознательно игнорируете аргумент про загрузку файла в память cat’ом? Я заметил, что pv почему‐то считает, что stderr — не терминал (наверное, из‐за hilite), поэтому для того, чтобы он что‐то показал, нужен ключ -f. Так вот: cat file | grep abc | pv -af > /dev/null работает всегда быстрее, чем grep abc file | pv -af > /dev/null, если файл бинарный (т.е. grep надо только определить наличие шаблона, но не вывести строки) или отсутствует в кэше. Скорость отличается примерно на 20—30 %, если файл в кэше присутствует (проверялось на файлах размером 600 МиБ и 14 МиБ).
На мелких же файлах (я проверял на 45 КиБ), присутствующих в кэше, различие в скорости от запуска к запуску при обоих методах настолько велико¹, что говорить о какой‐либо разнице между методами смешно. Так что в большинстве случаев вы просто предлагаете заняться тем, что называется «предварительная оптимизация». То, что мы пишем, начнёт называться говнокодом не раньше, чем либо разница между временем работы вашей и нашей версии станет заметна человеческому глазу, либо чем нашу версию окажется сложнее читать.
¹ От 11,5 МиБ/с до 1,05 ГиБ/с — cat file | sed 's/abc/def/' | pv -af > /dev/null; от 26,1 МиБ/с до 1,02 ГиБ/с — sed 's/abc/def/' file | pv -af > /dev/null.
Зачем? Файлы находятся на диске и скорость считывания с диска или из кэша будет определяющей, с данными примерами вы её не померяетее. Кроме того, grep обрабатывает данные медленнее pv, так что данный тест никак не противостоит аргументам fshp. Также он никак не противостоит аргументу «изменять regex так проще».
Кстати, а что pv должен вывести? У меня он не выводит ничего.
Я тоже использую сокращённые формы при наборе в командной строке. Только если бы мне требовалось часто менять настройку ignorecase, то я использовал бы привязку и там была бы полная версия. Но когда нужно мне обычно легче использовать \c/\C (в основном потому, что я представляю, сколько авторов дополнений забывают учитывать ignorecase, но не хочу проверять, чем мне это грозит в тех дополнениях, которые я использую).
Относительно ignorecase: эта настройка влияет на matchstr()/match()/matchlist()/matchend(), substitute(), search()/searchpair()/searchpairpos()/searchpos(), :substitute/:smagic/:snomagic, операторы сравнения для строк (=~/!~, ==/!=, is/isnot (если оба операнда — строки), </>/<=/>= (аналогично)), /, ?, :/, :?, *, #. Множество авторов пишут неправильные операторы сравнения (правильные — это те же самые, но с добавлением # или? на конце), зависимость функций от значения ignorecase же игнорируется почти всеми. Даже я не уверен, что у меня во всех дополнениях все функции работают правильно.
Спасает только то, что чаще всего входные данные таковы, что значение ignorecase не влияет на выходные. Однако мне не нравится полагаться на это соображение.
Кстати, с разработчиками дистрибутива можно договариваться и для freeware, и даже для платных продуктов. Во всяком случае, я в основном дереве portage (Gentoo) видел все три варианта: тут есть Opera (старая), chrome, nero, пачка игрушек. Но, боюсь, что договориться будет сложнее (разве что вы подпишетесь на самостоятельную поддержку пакета) или невозможно по идеологическим причинам (для дистрибутивов вроде gNewSense).
{1: 1, 1: 2, 1: 3}не в CPython. PyPy-2.0.2 и jython-2.5.3-r3 выдают{1: 3}.. То же самое написано в документации для Python 3.4.0. Так что нормальный способ. Только учтите, что вычисляться будут все выражения. Без lambda это ни в коем случае не замена switch.
А, вот: stackoverflow.com/questions/10629397/how-to-disable-http-strict-transport-security: тоже говорится никак не о чистке истории.
if eval(condition), то во втором вы можете захотеть написатьexecute line_number . 'append'и потом собственно добавляемые строки. Правда это не отменяет тех фактов, что, во‐первых, добавляемые строки можно засунуть вexecuteи, во‐вторых, я ни разу не видел, чтобы кто‐то использовалappend(правда, я уверен, что кто‐то его использует). Так что, возможно, незавершённыйappendне запрещён, чтобы кому‐то не пришлось возиться с line continuation и кучей дополнительных символов (кавычки,\nи точка для объединения строк).Три факта во вред
append:append). Также подсветка не работает сexecute 'append'append!(с восклицательным знаком) не решает проблему с отступом, и впридачу не позволяет использовать отступ перед точкойЭто я к тому, что нормальный разработчик обычно предпочтёт не использовать
append, так как с высокой вероятностью ему придётся либо переделывать отступ у вставляемогоappendтекста, либо нарушать отступы в своём тексте. Впрочем, такое останавливает далеко не всех.|и новой строки зависит от контекста выполнения. Сделать хак для парсера, чтобы он нормально это обрабатывал ещё можно, но это не всё: значение тех же символов (особенно первого) также зависит и от состояния интерпретатора, а именно от того, как определена пользовательская команда (если, конечно, именно она стоит до данных символов). То есть вы не можете распарсить строчку «Foo abc|let a=1» пока не выполните предыдущую, так как она может содержатьcommand! -nargs=1 -bar Foo :echo <q-args>, а можетcommand! -nargs=1 Foo :echo <q-args>.Это не единственная проблема, но вторую можно просто игнорировать: делает именно то, что вы подумали. Правда, явно запрещён в документации. Что не додумались запретить, так это. Впрочем, если ваш парсер будет считать, что тут есть присваивание, то это вряд ли кого огорчит.
Я пока не припоминаю никаких других проблем, но они наверняка найдутся, если вы начнёте писать транслятор.
old(secret)наnew(old(secret)).Если вы используете вариант с изменением хэша при логине, то вы получаете сразу две проблемы: во‐первых, пользователи, которые к вам более не заходят, лишаются защиты, во‐вторых, вам нужно сильнее изменить код, занимающийся авторизацией. В моём варианте нужно просто один раз изменить базу и изменить функцию хэширования, не добавляя более никакой логики.
Точнее все проекты, поддерживающие запуск на python3 можно установить для python3, python2 или (за исключением некоторых) вообще для всех поддерживаемых версий python сразу, включая pypy и jython (правда, поддержку последних часто не указывают, даже если на них всё работает). У меня в /usr/lib/python-exec/python3.3 находятся 55 скриптов. Таже 56 у python3.2, 57 у python2.6 и 59 у python2.7, что говорит о хорошей поддержке третьего python среди используемых мною пакетов (их 19, 20, 21 и 22 соответственно для 3.3, 3.2, 2.6 и 2.7). И всё, что есть в /usr/lib/python-exec, установлено emerge.
Правда, я не вижу Gentoo в продакшене. Но в её репозиториях всё есть — факт :)
# vim: fileencoding=utf-8. С python3 не нужно и того (вы либо пишете в UTF-8, либо вас посылают с SyntaxError).Хотя «привет мир» без звёздочек с дефисами и вообще без не‐ASCII можно очень легко сделать: просто сразу скажите новичку, как использовать gettext и писать многоязычные приложения :) Разумеется, все сообщения в коде будут на английском.
Проблемы есть, но они решаются. И их меньше, чем во многих других языках. Есть отличная практика, которая убережёт вас от минусов за разжигание священных войн: как только вам захочется написать подобное не соответствующее теме сообщение (не важно, насколько оно правдиво), возьмите какой‐нибудь shell скрипт длиною хотя бы в десяток строк и перепишите его для работы на tcsh. Уверяю, после данного действия все прочие скриптовые языки станут казаться верхом совершенства.
Разумеется, речь идёт о QtWebEngine. Не знаю, правда, насколько «основан» будет означать совместимость патча с Blink.
Конечно, на конверте может быть неразборчиво написано, но во множестве отделений при приёме заказных и ценных ничего, кроме индекса, в базу не заносится.
И ещё: где вы видели занесение адреса в БД? Я не раз смотрел, как оператор набивает данные и видел везде одну и ту же программу с одними и теми же полями: тип отправления, номер отправления, индекс, (поле, заполняющееся из индекса автоматически), способ пересылки (наземная/самолётом), получатель, масса, ценность (для ценных), доп. услуги (уведомления, наклейка марок, поиск индекса, …).
Терминал тут не причём. Подозреваю hilite — это программа для покраски stderr в красный цвет. Подозреваю, что hilite также причастна к неработающему mc и bash, стартующему в неинтерактивном режиме по‐умолчанию. Так как mc мне не нужен, bash’у можно сказать
-i, а почти всё остальное работает (т.к. проверяет stdout, а не stderr, на принадлежность терминалу, который никто не трогал), исправлять я ничего не пытался. Во всяком случае, запуск pv не из оболочки работает штатно. Наверное, надо попробовать stderred.И ещё: вы сознательно игнорируете аргумент про загрузку файла в память cat’ом? Я заметил, что pv почему‐то считает, что stderr — не терминал (наверное, из‐за hilite), поэтому для того, чтобы он что‐то показал, нужен ключ -f. Так вот:
cat file | grep abc | pv -af > /dev/nullработает всегда быстрее, чемgrep abc file | pv -af > /dev/null, если файл бинарный (т.е. grep надо только определить наличие шаблона, но не вывести строки) или отсутствует в кэше. Скорость отличается примерно на 20—30 %, если файл в кэше присутствует (проверялось на файлах размером 600 МиБ и 14 МиБ).На мелких же файлах (я проверял на 45 КиБ), присутствующих в кэше, различие в скорости от запуска к запуску при обоих методах настолько велико¹, что говорить о какой‐либо разнице между методами смешно. Так что в большинстве случаев вы просто предлагаете заняться тем, что называется «предварительная оптимизация». То, что мы пишем, начнёт называться говнокодом не раньше, чем либо разница между временем работы вашей и нашей версии станет заметна человеческому глазу, либо чем нашу версию окажется сложнее читать.
¹ От 11,5 МиБ/с до 1,05 ГиБ/с —
cat file | sed 's/abc/def/' | pv -af > /dev/null; от 26,1 МиБ/с до 1,02 ГиБ/с —sed 's/abc/def/' file | pv -af > /dev/null.Кстати, а что pv должен вывести? У меня он не выводит ничего.
\c/\C(в основном потому, что я представляю, сколько авторов дополнений забывают учитывать ignorecase, но не хочу проверять, чем мне это грозит в тех дополнениях, которые я использую).Относительно ignorecase: эта настройка влияет на matchstr()/match()/matchlist()/matchend(), substitute(), search()/searchpair()/searchpairpos()/searchpos(), :substitute/:smagic/:snomagic, операторы сравнения для строк (=~/!~, ==/!=, is/isnot (если оба операнда — строки), </>/<=/>= (аналогично)), /, ?, :/, :?, *, #. Множество авторов пишут неправильные операторы сравнения (правильные — это те же самые, но с добавлением # или? на конце), зависимость функций от значения ignorecase же игнорируется почти всеми. Даже я не уверен, что у меня во всех дополнениях все функции работают правильно.
Спасает только то, что чаще всего входные данные таковы, что значение ignorecase не влияет на выходные. Однако мне не нравится полагаться на это соображение.