Небольшое, но необходимое, дополнение: данная команда проверит уязвимость вашей версии bash, а не вашей текущей оболочки. Если вы запустили данную команду из‐под zsh и увидели «vulnerable», не кидайтесь писать в список рассылки, что zsh уязвим: во‐первых, вы будете как минимум четвёртым таким «умником», во‐вторых вы проверяете не вашу оболочку, а bash.
Если вы запустите busybox, то внутри busybox’а вы сможете запустить ещё одну оболочку busybox именно этой командой. Кроме того, если есть исполняемый файл, называемый busybox, но нет никаких символических ссылок на него, то busybox ash вызовет оболочку.
Уточнение от ValdikSS важно, потому что в busybox может быть встроена ещё один вариант оболочки — hush. Правда когда я попытался использовать powerline в этой оболочки она упала.
Или любая клавиатура + раскладка, на ней не нарисованная. Я так учился печатать на programming dvorak. В качестве первого упражнения набирал свои логин/пароль в /dev/tty1 (<C-A-F1>) на скорость (в Gentoo установлен LOGIN_TIMEOUT в 60 секунд, что означает минуту на ввод пароля перед тем, как вам сообщат, что вход не удался). Правда, я тогда не знал, что есть такая подлянка, но отступать не хотелось :)
Я один раз заказал у них мыльницу (сломается и хрен с ней) с самовывозом (курьер точно не опоздает), так самовывезти удалось только через примерно час после приезда на место. После этого я у них ничего больше не брал.
Относительно терминала: он тут не причём. Просто в испольемом вами шрифте нет нужных символов и fontconfig (или что у вас там) берёт их из другого шрифта. Я не знаю, почему при этом нельзя отмаштабировать символы, чтобы они занимали одну ячейку, но это вопрос к авторам библиотеки, отображающей шрифт, а никак не к терминалу: чтобы исправить эту досадную проблему авторам терминала пришлось бы написать свою библиотеку для отображения текста.
Не писав на C++ (но зная что‐то), ухитрился сдать тест на 9/15. Причём, по моему мнению, должно было быть 11/15:
Скрытый текст
в одном месте при наличии скобки не в том месте я решил нажать на запятую: было выражение вида if(func(a1, a2), a3), нажата вторая запятая; в другом месте я решил нажать на 32 (имея ввиду, что int бессмысленно так сдвигать), а надо было на type cast или оператор: (unsigned long)d << 32
. Поправьте пожалуйста.
Кстати, в этом Quiz идёт нечестное сравнение: я знаю, что ошибка есть, а анализатор нет. Ему труднее :)
«Мера вычитки», насколько мне известно, зависит от опций bs/ibs/obs: они указывают, с какими блоками работать/какими блоками читать/какими блоками писать («какими блоками» = какого размера блоки использовать).
Обычно при организации параллельной работы над непересекающимися вещами используют отдельные ветки и проблема не возникает вообще. А «изменение названия переменной» — не единственная вещь, которая может сломать код, и учесть их все практически невозможно. Поэтому fetch, test, review, rebase или merge, а не что‐то ещё. При отдельных ветках для каждой из таких непересекающихся областей и с нормальными разработчиками (в т.ч. не забывающими обсудить потенциально проблемные изменения) review много времени занимать не должен.
Vim'овские окна! Вам не надо их переключать, все окна на одной вкладке всегда видны одновременно. А «по первым 3-4 символам» вы
— Не увидите код, находящийся в том же файле, но за несколько экранов. Если нужно с ним регулярно сверяться, то окна вам помогут, длинные строки — нет.
— То же самое, но для других файлов.
— Ну и в вашем коде документации нет, а в соседнем окне открыть её можно.
Поэтому лучше разделить экран на четыре окна, чем написать строку на весь экран. В IDE обычно тоже есть разные панельки с информацией (документация/отладчик/дерево классов/...) и на них тоже нужно место.
Когда я купил побольше монитор я стал смотреть код в нескольких окнах сразу (Vim'овские окна), а не писать всё в одну строчку. У вас ведь не один файл в проекте? Так зачем городить длинные строчки, если можно вместо этого открыть рядышком, к примеру, шаблон, CSS и документацию? Такой вариант здорово разгружает мозги: то, что надо было помнить теперь можно просто посмотреть рядом. Но при этом такая разгрузка не ограничена одним файлом, как у вас.
Также тут можно заметить лишний семиколон (точку с запятой). Единственная причина его появления в этом месте — слепое следование правилам стайл-гайда, не понимая его принципов. В многострочных правилах, это действительно необходимо, чтобы добавляемые в конец строки не приводили к изменению уже существующих.
Где здесь автор «считает правильным отсутствие точки с запятой»?
Ёпт, здесь просто иллюстрация к тому, какие строки будут показаны как изменённые при использовании vcs diff после добавления background-image. Т.е. автор показывает, что при полезном изменении всего одной строчки diff выдаст изменения в двух.
Обе конструкции запоминают данный {url} под именем {name}, так что в дальнейшем можно будет писать имя везде, где требуется данный URL. Первая конструкция для git, вторая для mercurial.
Нужно это, если у вас два remote репозитория: например, upstream, из которого вы берёте изменения (и который, скорее всего, вам не доступен на запись), и собственный форк.
Одну вы и сами написали: «нерекомендуемые» микро‐ветки. Вторая: сделать всё это самому, но перед commit просмотреть diff, просмотреть комментарии (а в особо запущенных случаях и diff’ы: актуально, если из пояснения к изменению ничего не понятно или из комментария понятно, что изменение, вероятно, затрагивает ваш код) новых изменений и прогнать тесты.
Правда, где «сотни коммитов» это много — там gc практически не запускается. Но это большинство проектов с моим участием, так что такая мысль не слишком удивительна.
Кстати, я правильно понял, что аналога git config remote.{name}.url {url}/echo $'[paths]\n{name} = {url}' >> .hg/hgrc для связывания URL с именем нет? Я что‐то в документации такого не вижу.
Прежде чем идти дальше, нам надо разобраться с параметром autosync. Если он включен ( «on», или 1 ), то при выполнении команды fossil update будет предпринята попытка получить сначала обновление из удаленного репозитория (pull), а при выполнении fossil commit — сначала pull и update, а сразу после commit — push ( передача изменений в удаленный репозиторий ), причем адресом удаленного репозитория будет указанный в последней выполненной команде clone, push, pull, sync, remote-url.
Это прямо противоречит цели сохранения истории «как она есть». При включении autosync вы получаете автоматический rebase последних изменений, что очевидно является сменой контекста, в котором делались изменения. Особенно, если алгоритм слияния где‐то напортачил (потому что неидеален, или, скорее, от того, что не понимает суть изменений: к примеру, при проведении рефакторинга на одной стороне при автоматическом слиянии вы вполне можете воткнуть в середину блока код с несуществующей переменной из‐за того, что та была переименована на другой стороне, а близкое окружение вашего кода данной переменной не содержало).
И, кстати, вот как себя ведёт mercurial при rebase/histedit/любая другая команда, удаляющая изменения: он вам явно прямо в консоли пишет, где сохранил резервную копию старых коммиттов и не удаляет их автоматически (git иногда сам запускает git gc, после него вы бы ничего не нашли). Авторы git же считают, что про git reflog надо было читать, до того, как вы написали git rebase, а запуск git gc --auto после rebase — это вообще свинство.
busybox ashвызовет оболочку.Уточнение от ValdikSS важно, потому что в busybox может быть встроена ещё один вариант оболочки — hush. Правда когда я попытался использовать powerline в этой оболочки она упала.
if(func(a1, a2), a3), нажата вторая запятая; в другом месте я решил нажать на 32 (имея ввиду, что int бессмысленно так сдвигать), а надо было на type cast или оператор:(unsigned long)d << 32. Поправьте пожалуйста.
Кстати, в этом Quiz идёт нечестное сравнение: я знаю, что ошибка есть, а анализатор нет. Ему труднее :)
bs/ibs/obs: они указывают, с какими блоками работать/какими блоками читать/какими блоками писать («какими блоками» = какого размера блоки использовать).— Не увидите код, находящийся в том же файле, но за несколько экранов. Если нужно с ним регулярно сверяться, то окна вам помогут, длинные строки — нет.
— То же самое, но для других файлов.
— Ну и в вашем коде документации нет, а в соседнем окне открыть её можно.
Поэтому лучше разделить экран на четыре окна, чем написать строку на весь экран. В IDE обычно тоже есть разные панельки с информацией (документация/отладчик/дерево классов/...) и на них тоже нужно место.
vcs diffпосле добавленияbackground-image. Т.е. автор показывает, что при полезном изменении всего одной строчки diff выдаст изменения в двух.{url}под именем{name}, так что в дальнейшем можно будет писать имя везде, где требуется данный URL. Первая конструкция для git, вторая для mercurial.Нужно это, если у вас два remote репозитория: например, upstream, из которого вы берёте изменения (и который, скорее всего, вам не доступен на запись), и собственный форк.
git gcне слишком полезен.git config remote.{name}.url {url}/echo $'[paths]\n{name} = {url}' >> .hg/hgrcдля связывания URL с именем нет? Я что‐то в документации такого не вижу.autosyncвы получаете автоматический rebase последних изменений, что очевидно является сменой контекста, в котором делались изменения. Особенно, если алгоритм слияния где‐то напортачил (потому что неидеален, или, скорее, от того, что не понимает суть изменений: к примеру, при проведении рефакторинга на одной стороне при автоматическом слиянии вы вполне можете воткнуть в середину блока код с несуществующей переменной из‐за того, что та была переименована на другой стороне, а близкое окружение вашего кода данной переменной не содержало).git gc, после него вы бы ничего не нашли). Авторы git же считают, что проgit reflogнадо было читать, до того, как вы написалиgit rebase, а запускgit gc --autoпослеrebase— это вообще свинство.