Comments 143
Вот так живешь, считаешь себя не плохим таким знатоком Linux, а тут раз и калькулятор в баше.
А вообще, спасибо за статью, открыл несколько новых вещей для себя.
А вообще, спасибо за статью, открыл несколько новых вещей для себя.
Калькулятор в баше кстати необходимая вещь!)
Поначалу использовал python для подсчетов, пока не узнал про калькулятор. Сейчас смешно…
Может, зря смеетесь. Я пробовал bc — не понравился.
В итоге считаю на питоне. И конверсии в системы счисления есть и многое другое.
разницы между
не так и много, а при вызове repl — тем более.
В итоге считаю на питоне. И конверсии в системы счисления есть и многое другое.
разницы между
echo 4*4|bc
echo 'print 4*4'|python
не так и много, а при вызове repl — тем более.
Ubuntovod скорее имел в виду вот такую подстановку:
i=$(( (i + 1) % 5 ))
node -p 4*4
UFO just landed and posted this here
bash: bc: command not found
не в баше.
не в баше.
В баше тоже есть, только маленький и неудобный :)
prok@prok-nb ~ $ echo $((72*12345679))
888888888
prok@prok-nb ~ $ echo $((72*12345679))
888888888
Ну так установите его…
Наверное потому, что Bash только интерпретатор команд, а внешние утилиты устанавливаются самостоятельно…
echo $SHELL
/bin/bash
bc
bc 1.06.95
...
$which bc
/usr/bin/bc
Это внешняя утилита. В Ubuntu ставится вместе с системой. Умеет много, свой внутренний язык. Например вычисляем Pi с точностью до 40 символов после запятой:
echo «scale=40; 4*a(1)» | bc -l
3.1415926535897932384626433832795028841968
/usr/bin/bc
Это внешняя утилита. В Ubuntu ставится вместе с системой. Умеет много, свой внутренний язык. Например вычисляем Pi с точностью до 40 символов после запятой:
echo «scale=40; 4*a(1)» | bc -l
3.1415926535897932384626433832795028841968
Важную команду забыли — chattr, с помощью нее можно сделать, например, файл неудаляемым. Еще несколько опций полезных наличествует.
Калькулятор не в bash. Это отдельная программа.
я apcalc использую. выглядит следующим образом:
calc
C-style arbitrary precision calculator (version 2.12.4.4)
Calc is open software. For license details type: help copyright
[Type "exit" to exit, or "help" for help.]
; 2^3
8
;
Огромное спасибо за статью, форкнул репозиторий, нашёл неточности перевода, сделаю pull request.
А теперь немного чистой, незамутнённой ненависти!
В оригинальном тексте, как и во всех переводах, строки длиной по несколько метров!
Если бы там был какой-нибудь plain text это можно было бы не простить, но хотя бы понять. Ну то есть автор хотел, чтобы ширина строки адаптировалась к ширине окна. Но там же маркдаун. Который при просмотре строки склеивает! Специально созданный в том числе для этого!
Какого лешего! Как вышло так, что автор, рассказывающий об искусстве владения командной строкой отформатировал текст так, что при исправлении опечатки в одном слове, гит считает изменённым весь абзац целиком? Файл, внутри которого содержится рекомендация изучить и использовать vim, нельзя нормально редактировать с помощью этого текстового редактора, это как? Такого тонкого глумежа я не видал уже давно!
А теперь немного чистой, незамутнённой ненависти!
В оригинальном тексте, как и во всех переводах, строки длиной по несколько метров!
Если бы там был какой-нибудь plain text это можно было бы не простить, но хотя бы понять. Ну то есть автор хотел, чтобы ширина строки адаптировалась к ширине окна. Но там же маркдаун. Который при просмотре строки склеивает! Специально созданный в том числе для этого!
Какого лешего! Как вышло так, что автор, рассказывающий об искусстве владения командной строкой отформатировал текст так, что при исправлении опечатки в одном слове, гит считает изменённым весь абзац целиком? Файл, внутри которого содержится рекомендация изучить и использовать vim, нельзя нормально редактировать с помощью этого текстового редактора, это как? Такого тонкого глумежа я не видал уже давно!
Банально, раз уж репозиторий располагается на GithHub'е, то, скорее всего, данный текст забивался в редакторе этого самого Github'а, в котором удобнее просто редактировать поток текста, не разбивая его самостоятельно на многие строки. И не во всех ситуациях ведь Vim теперь использовать, можно иногда и что-то другое)
Насчёт того, что Git потом считает изменение в одной букве как изменение всего блока текста….Ну считает и считает, простите это ему) Это же не смертельно. Самое страшное, что может случиться из-за этого — это придётся 15-20 секунд потратить на ручное слияние одновременных исправлений от двух разных людей в одном блоке.
Насчёт того, что Git потом считает изменение в одной букве как изменение всего блока текста….Ну считает и считает, простите это ему) Это же не смертельно. Самое страшное, что может случиться из-за этого — это придётся 15-20 секунд потратить на ручное слияние одновременных исправлений от двух разных людей в одном блоке.
Самое страшное, что может случиться из-за этого — это придётся 15-20 секунд потратить на ручное слияние одновременных исправлений от двух разных людей в одном блоке.
Да щас :). Если поправить 2 — 3 опечатке в строке и отправить пулл реквест автору, то просмотрщик диффов покажет только, что строка именена. Целиком. И дальше играем в игру — найди неизвестно сколько отличий в двух почти идентичных строках длиной с бассейн Амазонки и засеки сколько времени это займёт. Никак не 15 — 20 секунд :).
Вот как раз линк на такой пулл реквест. github.com/olegberman/the-art-of-command-line/pull/3/files?diff=split. И это, кстати, исправления от одного человека. О разруливании конфликтов речи пока не идёт.
я, пожалуй, приложу картинку i.imgur.com/gds06ek.png
Ну да, я как раз об этом. Без специального вьюера тут не обойтись.
Так этих вьюверов не один и не два.
i.imgur.com/uFdBGs7.png
www.maketecheasier.com/file-comparison-tools-for-linux
Никто не мешает использовать что-то более удобное, чем стандартный diff.
i.imgur.com/uFdBGs7.png
www.maketecheasier.com/file-comparison-tools-for-linux
Никто не мешает использовать что-то более удобное, чем стандартный diff.
Есть некоторая разница между «не мешает» и «вынуждает». Кроме того, git add -p как делать в таком случае? Слать лесом часть git workflow из-за ничем не мотивированного наличия длинных строк?
git diff --color-words
Его можно как-то совместить с git add -p?
Гм. Спросим то же самое, но по другому.
После того, как пишешь git add -p, появляется окошко с редактором, в котором виден текущий чанк. И, если он слишком большой, есть возможность разбить текущий чанк на чанки поменьше. Если чанк представляет из себя очень длинную строку, можно будет разбить его на части?
После того, как пишешь git add -p, появляется окошко с редактором, в котором виден текущий чанк. И, если он слишком большой, есть возможность разбить текущий чанк на чанки поменьше. Если чанк представляет из себя очень длинную строку, можно будет разбить его на части?
Можно же настроить
_http://jeetworks.org/setting-up-git-to-use-your-diff-viewer-or-editor-of-choice/
_http://jeetworks.org/setting-up-git-to-use-your-diff-viewer-or-editor-of-choice/
Я честно не понимаю, к чему весь этот сыр-бор, когда вам уже ведь дали картинку, как можно легко, в один клик, увидеть все различия между оригиналом и pull-request'ом:
github.com/olegberman/the-art-of-command-line/pull/3/files?diff=split&short_path=2e086f3#diff-2e086f36ff961aa4d1079c87cde14d8d
Всё там прекрасно видно, никаких дополнительных телодвижений не нужно. Ну и что тут дальше-то обсуждать?
Понятно, что через консоль это может занять времени чуть больше, но зачем в данном случае вообще использовать консоль, когда все эти действия доступны на расстоянии одного клика в веб-интерфейсе Github'а? Это банально придирка к какой-то мелочи.
И еще раз повторюсь: в редакторе Github'а намного удобнее пользоваться сплошными потоками текста, а не текстом, оформленным через ручную расстановку переносов. И в данной ситуации этот текст и гитхабовская репа просто используются как место для удобного хранения статьи с полезной информацией. Эту репу даже клонировать на свой компьютер нет особой нужды: просто возьмите и отредактируйте текст через редактор Гитхаба и прямо там же и оформите свой Pull-request, не усложняйте жизнь себе и другим) И воспринимайте это как обычный текст, а не как исходный код.
github.com/olegberman/the-art-of-command-line/pull/3/files?diff=split&short_path=2e086f3#diff-2e086f36ff961aa4d1079c87cde14d8d
Всё там прекрасно видно, никаких дополнительных телодвижений не нужно. Ну и что тут дальше-то обсуждать?
Понятно, что через консоль это может занять времени чуть больше, но зачем в данном случае вообще использовать консоль, когда все эти действия доступны на расстоянии одного клика в веб-интерфейсе Github'а? Это банально придирка к какой-то мелочи.
И еще раз повторюсь: в редакторе Github'а намного удобнее пользоваться сплошными потоками текста, а не текстом, оформленным через ручную расстановку переносов. И в данной ситуации этот текст и гитхабовская репа просто используются как место для удобного хранения статьи с полезной информацией. Эту репу даже клонировать на свой компьютер нет особой нужды: просто возьмите и отредактируйте текст через редактор Гитхаба и прямо там же и оформите свой Pull-request, не усложняйте жизнь себе и другим) И воспринимайте это как обычный текст, а не как исходный код.
Я отписался по теме длинных строк автору. Создал ишью. Вот оно github.com/jlevy/the-art-of-command-line/issues/167. Кому не лень и кто согласен с тем, что это мрак и ужас, поддержите просьбу, пожалуйста.
Создайте issue в оригинальном репозитории и опишите проблему. Возможно, автору покажутся разумными ваши доводы и он отформатирует текст в соответсвии с вашими пожеланиями.
UFO just landed and posted this here
Напомню, что md файл представляет из себя исходник, который потом преобразуется в нужный формат. В процессе преобразования строки склеиваются и в зависимости от целевого формата определённым образом подгоняются вод ширину экрана. Поэтому читать строки в виде грустных столбиков никому не придётся.
Кроме того, напомню, что системы контроля версий (по крайней мере git) считают изменения в файле построчно и при изменении одного символа в строке изменённой будет считаться вся строка. Смотреть изменения, сделанные в коммите, как unified diff становится очень неудобно. Исключать изменения, которые делать не нужно — тоже.
Markdown это не обычный текст, это исходник, с которым предполагается работать с помощью системы контроля версий. Это многое меняет.
Кроме того, напомню, что системы контроля версий (по крайней мере git) считают изменения в файле построчно и при изменении одного символа в строке изменённой будет считаться вся строка. Смотреть изменения, сделанные в коммите, как unified diff становится очень неудобно. Исключать изменения, которые делать не нужно — тоже.
Markdown это не обычный текст, это исходник, с которым предполагается работать с помощью системы контроля версий. Это многое меняет.
«Грустный столбик слева в 75-85 букв шириной» — это так называемый книжный формат, которым является стандартом форматирования серьезных текстов уже сотни лет.
Чтобы заменить все нахождения подстроки в одном или нескольких файлах
Имхо, удобнее sed дёргать.
$ cat file | sed 's/first/second/g'
$ man sed
Ожидал в статье увидеть ещё, что можно вйти с помощью ctrl-d. Открыл для себя nohup, была проблема с остановкой процессов из-за закрытия терминала.
Имхо, удобнее sed дёргать.
$ cat file | sed 's/first/second/g'
Согласен. Только
cat излишен.$ sed 's/first/second/g' fileА вообще, не понимаю, чем это новомодное руководство лушче The Linux Command Line,The Command Line Crash Course, Learn Linux The Hard Way или какого-нибудь Bash Cheatsheet.
Согласен. Только cat излишен.угу, а в связке с find вообще убойная сила
find ./ -name '*.txt' -type f -exec sed -i '.bak' 's/first/second/g' {} \;
Я вот тоже хотел сказать, что всю статью (изначальную, а не труд переводчика) можно свести к четырем буквам.
RTFM!
RTFM!
Только тогда
sed -i --follow-symlinks 's/first/second/g' files*
Еще лучше sed -i.bak 's/first/second/g'
Выучите основы Баша. Просто возьмите и напечатайте man bash в терминале и хотя бы просмотрите его; он довольно просто читается и он не очень большой. Другие шеллы тоже могут быть хороши, но Баш – мощная программа и Баш всегда под рукой (использование исключительно zsh, fish и т.д., которые наверняка круто выглядят на Вашем ноуте во многом Вас ограничивает, например Вы не сможете использовать возможности этих шеллов на уже существующем сервере).
На сервере может не быть и Bash, к примеру, в достаточно узкоспециализированной системе может быть в наличии только /bin/busybox sh.
Выучите хотя бы один консольный редактор текста. Идеально Vim (vi), ведь у него нет конкурентов, когда вам нужно быстренько что-то подправить (даже если Вы постоянно сидите на Emacs/какой-нибудь тяжелой IDE или на каком-нибудь модном хипстерском редакторе)
Серьезно? А я-то все время Nano пользуюсь…
Вроде, не хипстерский и полегче, чем Vim, когда надо именно быстро что-то поправить.
Но для навигации по конфигам или правки кода/скриптов на удаленной машине vim куда удобнее. И обычно устанавливается одной командой при provisioning (тот же vim-minimal или elvis не люблю, не удобно оно).
Vim нужно изучить по двум причинам:
— навигация в man и less сделана по мотивам vi
— если он внезапно установлен как редактор по умолчанию (например, в git для ввода комментариев постфактум), то чтобы хотя бы знать, как из него выйти
А так, nano вполне рулит.
— навигация в man и less сделана по мотивам vi
— если он внезапно установлен как редактор по умолчанию (например, в git для ввода комментариев постфактум), то чтобы хотя бы знать, как из него выйти
А так, nano вполне рулит.
Шутка про «зашел в vi, не смог выйти» уже настолько стара, что кажется все, кто имеет хотя бы минимальную вероятность зайти в vi, как минимум как выйти знают.
Да щас. Сценарий для новичка:
— поставил git на венду — само собой поставилоСЬ git shell (тюнингованный баш)
— в командной строке, строго по инструкциям со стековерфлоу и т.п., накатил какую-нибудь репу
— там же, в командной строке, по тем же инструкциям доброхотов, написал git log
Вуаля, попал внутрь less.
— поставил git на венду — само собой поставилоСЬ git shell (тюнингованный баш)
— в командной строке, строго по инструкциям со стековерфлоу и т.п., накатил какую-нибудь репу
— там же, в командной строке, по тем же инструкциям доброхотов, написал git log
Вуаля, попал внутрь less.
Основная проблема «выйти из vim» была не в том, как выйти корректно, а как выйти вообще.
Когда новичок попадает в vim не в эмуляторе терминала, который легко закрыть вместе с окном, а в терминале. И при этом не знает как зайти в другой терминал. Представьте весь ужас человека, который потерял управление компьютером и от любых действий тот только пищит и наверняка всё портит!
Другого компа с мануалами под рукой нет и единственный способ хоть как-то прекратить этот кошмар — выключить компьютер. И ведь выключали, иногда даже вырывая вилку из розетки.
Сейчас таких проблем уже не встретить.
Когда новичок попадает в vim не в эмуляторе терминала, который легко закрыть вместе с окном, а в терминале. И при этом не знает как зайти в другой терминал. Представьте весь ужас человека, который потерял управление компьютером и от любых действий тот только пищит и наверняка всё портит!
Другого компа с мануалами под рукой нет и единственный способ хоть как-то прекратить этот кошмар — выключить компьютер. И ведь выключали, иногда даже вырывая вилку из розетки.
Сейчас таких проблем уже не встретить.
Раньше был ужас-ужас-ужас, а сейчас тьфу-чёрт.
Закрыл терминал с неубиваемым лессом, и снова Win+R, cmd, cd my\long\way\to\tipperary, git log… OH SHI!
(Для линукса сценарий такой же; разве что терминал открыть попроще).
Закрыл терминал с неубиваемым лессом, и снова Win+R, cmd, cd my\long\way\to\tipperary, git log… OH SHI!
(Для линукса сценарий такой же; разве что терминал открыть попроще).
Нифига. когда-то тоже зашел пришлось гуглить. Если еще раз зайду… придется долго вспоминать или снова гуглить. Старые не используемые знания имеют тенденцию вытесняться…
Большинство утилит какой-то нераспространённый новодел не лучшего качества. На мой взгляд, так:
-- iostat, sysstat, sar, glances, iftop ++ atop -- slurm ++ speedometer -- 7z ++ xz ++ pxz, pigz, pbzip2 - многопоточные компрессоры, на многопроцессорных системах творят магию моментально. совместимы с их однопоточными предшественниками xz, gz, bzip2
Поддерживаю pxz, pigz и pbzip2. Кстати, какой лучше, хотя бы чисто субъективно?
pxz явный лидер. им и исходники на kernel.org жмут, и на практике он сжимал мне образ виртуалки (OpenVZ simfs) c 24GB до 1,62GB, базу 1С c 17GB до 3,8GB (на всех процессорах, максимальное сжатие).
htop очень хороша утилита, мне нравится.
Заголовок спойлера
iostat/iotop/iftop вполне удобны для того чтобы посмотреть здесь и сейчас, что творится. Хотя, почитав чуток статей, понимаешь, что тот же disk utilization или iowait мало что реально говорят о нагрузке на io.
Не увидел в первых двух строчках htop. Имхо, за ++.
Спасибо за труд и популяризацию unix и bash.
Я так понимаю, где-то половины из описанного в linux не стоит «из коробки».
Тогда логичнее описать coreutils, так как
К примеру, в тексте ни слова о pwd и basename, а они, порой, гораздо важнее в скриптах, чем, например, factor, и входят в те самые coreutils.
~$ m4
The program 'm4' is currently not installed. You can install it by typing:
sudo apt-get install m4
~$ pv
The program 'pv' is currently not installed. You can install it by typing:
sudo apt-get install pv
Я так понимаю, где-то половины из описанного в linux не стоит «из коробки».
Тогда логичнее описать coreutils, так как
The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system.(отсюда)
These are the core utilities which are expected to exist on every operating system.
К примеру, в тексте ни слова о pwd и basename, а они, порой, гораздо важнее в скриптах, чем, например, factor, и входят в те самые coreutils.
Меня больше удивляет, сколько людей не знает про getent и грепают /etc/passwd и /etc/group
Ещё веселее докер, который их парсит принципиально (чтобы не завязываться на glibc), что приводит к тому, что не видится группа docker, которая раздаётся централизовано (например, через sssd+ldap). Но issues libcontainer закрыли, соответственно в кэше гугла содержит только сам тикет, но не переписку. Ещё кусок обсуждения в PR.
UFO just landed and posted this here
% getent passwd valdikss
valdikss:x:1000:100::/home/valdikss:/usr/bin/zshСоздать группу, если ее не существует:
% getent group nonexistent || groupadd nonexistentUFO just landed and posted this here
grossws выше хороший пример привел — совершенно не обязательно пользователь должен быть локальный, есть еще тот же LDAP. Записи о пользователе в /etc/passwd не будет, но использовать-то его можно.
Ну, или представьте, что у вас пользователь называется home. Чтобы избежать совпадение grep по домашнему пути, который, как правило, начинается с /home/, вам уже нужно будет писать regexp.
Ну, или представьте, что у вас пользователь называется home. Чтобы избежать совпадение grep по домашнему пути, который, как правило, начинается с /home/, вам уже нужно будет писать regexp.
Туда же можно добавить
getmntent (3). Это функция библиотеки, но утилиту из неё сделать несложно. Больше не придётся грепать/парсить руками fstab/mtab.Долго читал оригинал на github'е, т. к. в процессе отправил 6 PR.
Чтобы заменить все нахождения подстроки в одном или нескольких файлах:
perl -pi.bak -e 's/old-string/new-string/g' my-files-*.txt
Проще и быстрее
sed -i 's/old-string/new-string/g' my-files-*.txt
Опечатки, которые бросились в глаза:
аббривиатур
директории (и поддерикториях)
Насчёт vim автор тоже погорячился. Во-первых, он есть не везде. Во-вторых, vi и vim требуют искейпа для выхода из режима редактирования. Поэтому самый универсальный редактор — ed, с ним можно работать в терминалах без клавиши ESC.
Во-вторых, vi и vim требуют искейпа для выхода из режима редактирования.^С
зачем запускать монстр sed, если есть tr?
Когда-то я очень любил bash. Но потом меня загнали вод винды, и я понял, что PowerShell круче, хотя completition в нем не слишком удобный.
Жаль, что он под Unix не портирован…
Жаль, что он под Unix не портирован…
Эм… а разве PowerShell не создавался изначально как этакая копия мощной командной строки Unix? Когда у них был только убогий дос… А потом внезапно появился PowerShell, когда стало ясно, что одними оконными свистопердами ни одному админу не обойтись. Понятно, что в чем-то он круче, т.к. возможно создавался с учетом успешных примеров
В Powershell встроены скриптовые вызовы некоторых системных функций, не более того. В качестве универсального языка программирования он практически неприменим.
unix shell же является классическим функциональным языком программирования, bash — его развитие (расширение).
unix shell же является классическим функциональным языком программирования, bash — его развитие (расширение).
Конвеер в PowerShell более развит, чем в bash. Работа со строками проще. Синтаксис чище.
Проигрывает он только в интерактивности.
Проигрывает он только в интерактивности.
Это не так, потому что смотреть нужно не в сами команды конвейера, а в то, как устроена сама система. В Linux практически каждое устройство, каждый процесс имеет абстракцию в виде имени файла на виртуальной файловой системе, из-за чего перенаправлять в именованные потоки и дескрипторы можно ГОРАЗДО шире, чем в виндовсе будет возможно даже в обозримом будущем.
По поводу удобства синтаксиса нужно смотреть на возможности. Например те, кто думает, что gzip странный, потому что не может сжать два файла, возможно не понимают в чем преимущество потокового архиватора.
По поводу удобства синтаксиса нужно смотреть на возможности. Например те, кто думает, что gzip странный, потому что не может сжать два файла, возможно не понимают в чем преимущество потокового архиватора.
В PowerShell в конвеер объединяются функции, которые получают потоки как аргументы. Вместо глобальных именованных каналов используются локальные переменные.
Как echo Hello перенаправить в USB устройство в Windows?
Как echo Hello перенаправить в bash пользователя, который подключился удаленно в Windows?
Я же вам сказал, что преимущество перенаправлений в Линукс заключается в том, что сама система спроектирована так, что перенаправление возможно практически между любой сущностью системы, включая процессы и устройства, что расширяет возможности того, что можно автоматизировать на коленке, в командной строке, одной-двумя командами, без создания 100-строчного скрипта с объявлением классов, объектов и т.д., причем не уверен что с классами и объектами можно будет выполнить два примера, которые я указал выше.
Как echo Hello перенаправить в bash пользователя, который подключился удаленно в Windows?
Я же вам сказал, что преимущество перенаправлений в Линукс заключается в том, что сама система спроектирована так, что перенаправление возможно практически между любой сущностью системы, включая процессы и устройства, что расширяет возможности того, что можно автоматизировать на коленке, в командной строке, одной-двумя командами, без создания 100-строчного скрипта с объявлением классов, объектов и т.д., причем не уверен что с классами и объектами можно будет выполнить два примера, которые я указал выше.
Галопом по европам, но хозяйке на заметку. Спасибо!
А перевод, конечно, грязноват, и советы местами странноваты.
m4 — «простенький» макропроцессор :)))
Надо бы, конечно, освоить, а то всё awk (да python в тяжёлых случаях).
Кстати, awk — в отличие от m4 — из коробки. А штука-то достаточно мощная и полезная…
Перед тем, как давать совет «man anything», нужно давать совет «как выйти из мана». Это, всё-таки, недо-vi.
За «инпут» и «аутпут» — зла не хватает. Не поленился транскрибировать, а на перевод уже сил не осталось, или это и есть перевод?
*(надевает красную повязку с чёрной буквой G на белом круге)*
А перевод, конечно, грязноват, и советы местами странноваты.
m4 — «простенький» макропроцессор :)))
Надо бы, конечно, освоить, а то всё awk (да python в тяжёлых случаях).
Кстати, awk — в отличие от m4 — из коробки. А штука-то достаточно мощная и полезная…
Перед тем, как давать совет «man anything», нужно давать совет «как выйти из мана». Это, всё-таки, недо-vi.
За «инпут» и «аутпут» — зла не хватает. Не поленился транскрибировать, а на перевод уже сил не осталось, или это и есть перевод?
*(надевает красную повязку с чёрной буквой G на белом круге)*
UFO just landed and posted this here
… Например, alt-. бежит по предыдущим аргументам команды, а alt-* расширяет глоб.??Тут и в источнике почему-то ошиблись (2 раза). Разбор манов вот о чём говорит:
superuser.com/questions/215950/how-to-expand-on-bash-command-line
ss64.com/bash/syntax-keyboard.html
en.wikipedia.org/wiki/Glob_%28programming%29
Т.е. в итоге эту фразу я переписал на (прочитать начисто статью со всеми 10050 правками):
Например, alt-. вставляет последний аргумент предыдущей команды, а ctrl-x * разворачивает глоб.
И в оригинале:
...For example **alt-.** inserts last argument of previous command, and **ctrl-x *** [expands a glob](...)(правда, проверить не на чем). Тут, если совсем точно, то «ctrl-x *» надо ещё настроить в ~/.inputrc (по первой ссылке).
Я б добавил ещё watch, позволяющий периодически (по умолчанию — раз в 2 с) выполнять любую команду и отображать её вывод в полноэкранном режиме, например:
watch ps xw
Всем спасибо за пулл-реквесты, советы по улучшению и помощь! PR'ы все просмотрю сегодня после работы (у нас со многими из вас очень разный часовой пояс).
Пара моментов: не нужно писать мне в личку забыли X, лучше использовать Y. Это – результат коллективного труда и вы можете сами влиять на материал как хотите. Только если добавляете новые команды, пожалуйста добавляйте их в английскую версию (желательно перед этим открыть тикет в оригинальном репе и посмотреть, согласно ли сообщество с вами). Из английской версии переводчики переведут во все остальные. Если в английскую отправлять не хотите можете открывать тикет в моем форке на русском, и я переведу этот тикет на английский и переотправлю его Джошу в оригинальный реп (опять-же, только если ваше дополнение того стоит).
Если же вы вносите изменения именно в перевод (исправление опечаток, изменения формулировок, то не важно куда вы отправляете PR (мне в форк или Джошу в оригинальный реп). У меня уже куча пулл-реквестов, всем огромное спасибо. Русскоязычному сообществу нужно плотнее интегрироваться в Github.
Кто-то заметил проблему длинных строк, она решабельна, но тогда скорее всего сломается git diff, поэтому пока что советую в редакторе, в котором вы редактируете маркдаун включить перенос строк.
Кстати, почему на Хабре до сих пор нет маркдауна? Местная разметка — убогий отстой. OMG, Emoji тут тоже не поддерживаются
Пара моментов: не нужно писать мне в личку забыли X, лучше использовать Y. Это – результат коллективного труда и вы можете сами влиять на материал как хотите. Только если добавляете новые команды, пожалуйста добавляйте их в английскую версию (желательно перед этим открыть тикет в оригинальном репе и посмотреть, согласно ли сообщество с вами). Из английской версии переводчики переведут во все остальные. Если в английскую отправлять не хотите можете открывать тикет в моем форке на русском, и я переведу этот тикет на английский и переотправлю его Джошу в оригинальный реп (опять-же, только если ваше дополнение того стоит).
Если же вы вносите изменения именно в перевод (исправление опечаток, изменения формулировок, то не важно куда вы отправляете PR (мне в форк или Джошу в оригинальный реп). У меня уже куча пулл-реквестов, всем огромное спасибо. Русскоязычному сообществу нужно плотнее интегрироваться в Github.
Кто-то заметил проблему длинных строк, она решабельна, но тогда скорее всего сломается git diff, поэтому пока что советую в редакторе, в котором вы редактируете маркдаун включить перенос строк.
Кстати, почему на Хабре до сих пор нет маркдауна? Местная разметка — убогий отстой. OMG, Emoji тут тоже не поддерживаются
Уточню насчет того что сказал
> не нужно писать мне в личку забыли X, лучше использовать Y.
Это только потому, что после такого сообщения мне самому придется попробовать X и Y и сравнить с тем что есть и оценить, достойны ли они быть в подборке. В случае, когда вы это делаете напрямую в Github, кто-то в сообществе наверняка уже пробовал X и Y и интегрировать дополнения тогда мы сможем намного быстрее. Мне конечно интересно попробовать ваши XY, но последнее время работа занимает столько времени, что становится страшного от того, что ни на что другое времени нет
> не нужно писать мне в личку забыли X, лучше использовать Y.
Это только потому, что после такого сообщения мне самому придется попробовать X и Y и сравнить с тем что есть и оценить, достойны ли они быть в подборке. В случае, когда вы это делаете напрямую в Github, кто-то в сообществе наверняка уже пробовал X и Y и интегрировать дополнения тогда мы сможем намного быстрее. Мне конечно интересно попробовать ваши XY, но последнее время работа занимает столько времени, что становится страшного от того, что ни на что другое времени нет
Кто-то заметил проблему длинных строк, она решабельна, но тогда скорее всего сломается git diff, поэтому пока что советую в редакторе, в котором вы редактируете маркдаун включить перенос строк.
Я создал ишью в оригинальном репе по этому поводу. Надеюсь автор что-нибудь с этим сделает.
Кстати, почему на Хабре до сих пор нет маркдауна? Местная разметка — убогий отстой. OMG, Emoji тут тоже не поддерживаются
Пятьдесят раз да! Тысячу раз да! Вы, кстати, как статьи пишете? Я пишу в маркдауне, потом конвертирую в html, вставляю в хабраредактор и правлю.
Аналогично, md -> html и небольшой постпроцессинг (для кусков кода, картинок и т. п.). Но мой старый опрос (за который меня ещё и чуток слили) показал, что большинству достаточно html и остальное нафиг не сдалось.
(xargs) Еще -I{} – полезная штука.
Это глупость, которую с find'а притащили. Зачем лишние символы печатать? Можно использовать любой символ, я обычно использую I капсом, чтобы меньше думать и быстрее печатать.
ls -1 |xargs -I I echo The I was here.
Это глупость, которую с find'а притащили. Зачем лишние символы печатать? Можно использовать любой символ, я обычно использую I капсом, чтобы меньше думать и быстрее печатать.
ls -1 |xargs -I I echo The I was here.
Недавно развлекался в баше раскрашивая себе PS1 в зависимости например от того в каком проекте находишься, в какой ветке репозитория и в какой папке.
Развлекаться еще можно так:
(на Маке, должны быть установлены jot, jq, wget)
rand=$(jot -r 1 1 100); wget -qO- http://shortiki.com/export/api.php\?format\=json\&type\=top\&amount\=100 | jq ".[$rand].content" | say --voice=Milena -i
(на Маке, должны быть установлены jot, jq, wget)
Класс, работает.
Не знал что на маке есть такая классная команда say и куча голосов и для русского языка в том числе.
Макбук — лучший ноутбук (со старым добрым диском HD)
Не знал что на маке есть такая классная команда say и куча голосов и для русского языка в том числе.
Макбук — лучший ноутбук (со старым добрым диском HD)
Спасибо, много полезного материала, собранного в кучку.
Но есть непроверенные или нераскрытые до конца вещи, которые в такой краткой подаче могут только запутать. Некоторые из них:
> Будьте знакомы с работой с процессами в Bash: &, ctrl-z, ctrl-c, jobs, fg, bg, kill, и т.д.
Процессы (processes) и задачи (tasks) — разные вещи.
Эти команды (fg, bg, jobs) управляют именно задачами, и относятся к работе самой оболочки. Нужно не путать задачи и процессы. То есть любая задача — процесс, но не любой процесс — задача.
> найте про heredoc-синтаксис в Баше, работает он вот так cat <<EOF…
Он работает не совсем так. Вместо EOF правильно писать delimiter, потому что тут может быть любое сочетание букв (EOF — это просто привычная аббревиатура). После чего можно ввести многострочный текст, а закончить его опять delimiter в пустой строке. Правильный пример:
cat << delimiter
…
…
delimiter
> В Баше много типов пространства переменных. Проверить, существует ли переменная – ${name:?error message}.
конструкция ${variablename:[cmd][text]} имеет четыре [cmd]: -=+?
— просто вывести наш [text], если variablename==null
= присвоить variablename значение [text], если variablename==null и вывести variablename
+ вывести [text], если variablename != null
? вернуть ошибку и вывести [text]
Просто проверить существует ли переменная, это [ -n ${var} ]. То есть не раскрыта конкретная тема, почему именно {$name:?error}, которая на самом деле не просто проверит существует ли переменная, но еще и выдаст ошибку (и соответственно завершит наш скрипт).
> Для того, чтобы выполнить определенную команду с привилегиями, используйте sudo (для рута) и sudo -u (для другого пользователя). Используйте su или sudo bash для того чтобы запустить шелл от имени этого пользователя. Используйте su — для того, чтобы симулировать свежий логин от рута или другого пользователя.
su -u не полноценно симулирует свежий логин от другого юзера. Во многих случаях могут остаться мусорные переменные окружения. Ну и нужно правильно настроить sudoers, чтобы иметь возможность использовать sudo. Тут вообще тема не очень раскрыта. Например не упомянуто, что некорректно логиниться от root, лучше вообще иметь пользователя root с пустым паролем и запретить логин с пустым паролем. А права суперпользователя наследовать через su/sudo — это современная практика.
> Сложно, но полезно
Было бы неплохо этот список отсортировать по алфавиту, для удобства.
Но есть непроверенные или нераскрытые до конца вещи, которые в такой краткой подаче могут только запутать. Некоторые из них:
> Будьте знакомы с работой с процессами в Bash: &, ctrl-z, ctrl-c, jobs, fg, bg, kill, и т.д.
Процессы (processes) и задачи (tasks) — разные вещи.
Эти команды (fg, bg, jobs) управляют именно задачами, и относятся к работе самой оболочки. Нужно не путать задачи и процессы. То есть любая задача — процесс, но не любой процесс — задача.
> найте про heredoc-синтаксис в Баше, работает он вот так cat <<EOF…
Он работает не совсем так. Вместо EOF правильно писать delimiter, потому что тут может быть любое сочетание букв (EOF — это просто привычная аббревиатура). После чего можно ввести многострочный текст, а закончить его опять delimiter в пустой строке. Правильный пример:
cat << delimiter
…
…
delimiter
> В Баше много типов пространства переменных. Проверить, существует ли переменная – ${name:?error message}.
конструкция ${variablename:[cmd][text]} имеет четыре [cmd]: -=+?
— просто вывести наш [text], если variablename==null
= присвоить variablename значение [text], если variablename==null и вывести variablename
+ вывести [text], если variablename != null
? вернуть ошибку и вывести [text]
Просто проверить существует ли переменная, это [ -n ${var} ]. То есть не раскрыта конкретная тема, почему именно {$name:?error}, которая на самом деле не просто проверит существует ли переменная, но еще и выдаст ошибку (и соответственно завершит наш скрипт).
> Для того, чтобы выполнить определенную команду с привилегиями, используйте sudo (для рута) и sudo -u (для другого пользователя). Используйте su или sudo bash для того чтобы запустить шелл от имени этого пользователя. Используйте su — для того, чтобы симулировать свежий логин от рута или другого пользователя.
su -u не полноценно симулирует свежий логин от другого юзера. Во многих случаях могут остаться мусорные переменные окружения. Ну и нужно правильно настроить sudoers, чтобы иметь возможность использовать sudo. Тут вообще тема не очень раскрыта. Например не упомянуто, что некорректно логиниться от root, лучше вообще иметь пользователя root с пустым паролем и запретить логин с пустым паролем. А права суперпользователя наследовать через su/sudo — это современная практика.
> Сложно, но полезно
Было бы неплохо этот список отсортировать по алфавиту, для удобства.
Например не упомянуто, что некорректно логиниться от root, лучше вообще иметь пользователя root с пустым паролем и запретить логин с пустым паролем. А права суперпользователя наследовать через su/sudo — это современная практика.
Проще и надёжнее в поле пароля (в базе паролей) указать символ звёздочки.
случайный совет, альтернативная реализация через xmllint и html2text (у меня с xmlstarlet не работало — были проблемы с кодировкой):
function taocl() {
curl -s https://raw.githubusercontent.com/jlevy/the-art-of-command-line/master/README-ru.md |
pandoc -f markdown -t html -s |
xmllint --format --recover --dropdtd --html --xpath "(html/body/ul/li[count(p)>0])[$RANDOM mod last()+1]" - 2>/dev/null |
html2text -utf8 |
fmt -80
}Когда создателя Баша спосили, как вы видите развитие Bash, он сказал «хочу чтобы он поскорее перестал использоваться, давно пора написать, что-то отвечающее современным реалиям».
Для того, чтобы получить более наглядный вывод json, можно использовать:
cat json.json | python -mjson.tool
Просмотр environment уже запущенного процесса:
cat /proc/`pidof someapp`/environ | tr '\0' '\n'
Конвертирование единииц исчисления байты, мегабайты, мибибайты и прочее:
numfmt --to=iec-i ...
Извините, лень письмо писать:
«file glob expansion with * (and perhaps? and {…}),» — явно недопереведено
«безпарольной аунтефикации» — беспарольная аутентификация (а лучше «проверка подлинности»)
«file glob expansion with * (and perhaps? and {…}),» — явно недопереведено
«безпарольной аунтефикации» — беспарольная аутентификация (а лучше «проверка подлинности»)
i7z надо бы добавить
ctrl-u для того, что бы удалить команду полностью
ctrl-k для того, чтобы прыгнуть к концу строкиПо умолчанию у bash-а эмаксовские keybindings, ctrl+u удаляет до начала строки, ctrl-k удаляет до конца строки, а прыгнуть к концу строки — ctrl+e.
Идеально Vim (vi), ведь у него нет конкурентов, когда вам нужно быстренько что-то подправить (даже если Вы постоянно сидите на Emacs...Не хочу разводить holy war, но справедливости ради стоит отметить, что так было лет 20 назад. На текущий момент даже GNU Emacs довольно лёгкий (по сравнению с джавовскими ide), консольная версия стартует моментально и для быстрого редактирования одной строчки подходит не хуже vim-а, который сейчас наворотили так, что весит он побольше многих Emacs-ов. К тому же GNU Emacs-ом мир не ограничивается, openbsd-шный mg ещё легче.
del
Спасибо, про set -o vi не знал… Давно такое хотел.
Sign up to leave a comment.
Искусство командной строки