Комментарии 86
> компании Силиконовой долины
Долина Кремниевая, поправьте.
Долина Кремниевая, поправьте.
Приятно было почитать.
Сам размышлял над подобным вопросом, хотя у меня и стаж не тот, конечно.
Сам размышлял над подобным вопросом, хотя у меня и стаж не тот, конечно.
«Лично я бы заплатил за мою свободу, вместо того, чтобы жил бы в пиксельном, с весело выпрыгивающими окошками, подземелье типа Windows.»
Пожалуйста, верните на место шутку с поиском «who» по запущенным процессам.
Улыбнуло.
Сам линуксоид.
НЛО прилетело и опубликовало эту надпись здесь
В командной строке мне нравится реальное общение с компьютером. Я задаю ему вопрос, он пишет ответ. Никакой гуй этого не может.
а мне лаконичность и четкость гибкость и мощь. Гуи — это ограниченный набор кнопок и менюшек. Организованных кем-то кто думал что «так для меня лучше». А вот и неправда. Есть глубоко закрытые менюшки нужные мне постоянно. Большинство же кнопок, тулбаров, элементов меню и индикаторов — мне совсем не нужны. Они лишь пожирают мое внимание. Они постоянно предлагают нажать, посмотреть — превращают работу с компом — в аттракцион.
Консоль — для тех кто знает чего хочет. Консоль сама ничего не предлагает, не танцует перед тобой, не переливается цветами. Ты приходишь в нее сделать нечто, делаешь это и все. Быстро, четко, лаконично.
Консоль — для тех кто знает чего хочет. Консоль сама ничего не предлагает, не танцует перед тобой, не переливается цветами. Ты приходишь в нее сделать нечто, делаешь это и все. Быстро, четко, лаконично.
Это можно сделать и в гуях, но делают редко. Например, сравните менеджеры беспроводных сетей wicd и NetworkManager. Оба с гуями, первый написан так, как это сделал бы юниксоид, второй — для удовлетворения перебежчиков с винды.
Гибкость и мощь как раз и достигаются огромными выразительными средствами языка оболочки, команд и регулярных выражений. Именно язык позволяет вам ёмко формулировать свои требования. В гуе для этого понадобилось бы сделать столько кнопок, сколько слов в языке, и в результате всё равно бы получилась консоль.
так сексуально о консоли
Сколько раз в холиварах на Хабре я обвинял виндовс в вечно выпрыгивающих окошках, все отвечали, что у них ничего не выпрыгивает. Теперь есть куда давать пруфлинк. ;)
Автор очень верно подметил о реактивной работе. Работая в видновс складывается ощущение, что ты не рассказываешь системе, что тебе надо сделать, а отвечаешь на серию наводящих вопросов, результатом которых иногда является то чего ты хотел. И в семёрке, за двенадцать лет с момента написания статьи, это не исправили и, похоже, не собираются.
Автор очень верно подметил о реактивной работе. Работая в видновс складывается ощущение, что ты не рассказываешь системе, что тебе надо сделать, а отвечаешь на серию наводящих вопросов, результатом которых иногда является то чего ты хотел. И в семёрке, за двенадцать лет с момента написания статьи, это не исправили и, похоже, не собираются.
НЛО прилетело и опубликовало эту надпись здесь
А мне удобнее делать всё это в консоли. Есть свои плюсы, есть минусы. Некоторые задачи удобнее всего выполнять в двухпанельнике типа mc или total commander.
Кстати, под линукс существует офигенная утилита «unp», которая распаковывает любой архив без необходимости дополнительных параметров. Если же у вас виндовс, то и ежу понятно, что консоль там совершенно неюзабельная.
Кстати, под линукс существует офигенная утилита «unp», которая распаковывает любой архив без необходимости дополнительных параметров. Если же у вас виндовс, то и ежу понятно, что консоль там совершенно неюзабельная.
НЛО прилетело и опубликовало эту надпись здесь
Раз сто эту команду набирал, раз тысячу копипастил, но для меня всё равно быстрее, чем писать «tar --help» и скроллить многоэкранную справку, запустить из той же консоли file-roller — ну никак не могу зазубрить эти ключи.
А на велосипеде работает моторная память, а не «интеллектуальная» — если начнёшь думать как двигать телом, чтобы не упасть, то обязательно упадёшь — проверено после 15 лет перерыва :)
А на велосипеде работает моторная память, а не «интеллектуальная» — если начнёшь думать как двигать телом, чтобы не упасть, то обязательно упадёшь — проверено после 15 лет перерыва :)
Надо просто себе объяснить, как она работает и все. Я немного переставил аргументы: tar -xvzf <file>
x — сначала действие, я хочу распаковать (eXtract)
v — хочу видеть, как она это делает
z — тип .gz
f <file> — файл с именем <file>.
Т.е. ключи xvzf у меня в мозгу формируются в предложение: «распакуй, чтобы я видел прогресс, архив .gz с именем файла <file>»
По аналогичной схеме запоминается уже и
tar cvzf — создай архив .gz
tar xvjf — распакуй архив .bz2 и т.п.
x — сначала действие, я хочу распаковать (eXtract)
v — хочу видеть, как она это делает
z — тип .gz
f <file> — файл с именем <file>.
Т.е. ключи xvzf у меня в мозгу формируются в предложение: «распакуй, чтобы я видел прогресс, архив .gz с именем файла <file>»
По аналогичной схеме запоминается уже и
tar cvzf — создай архив .gz
tar xvjf — распакуй архив .bz2 и т.п.
Не смущайте людей %) «z» уже лет 5-7 как нигде уже не нужна.
протанцевать к директориям у меня получается быстрее всего в консоли (в баше). разархивировать впринципе всё равно, а скрипты мне удобнее писать в гуишном текстовом редакторе :)
Поинтересуйтесь как-нибудь ради интереса, как работают люди в современных шеллах типа zsh, fish или хоть сколько-нибудь адекватно настроенный bash с completions. Возможно, Вам будет интересно узнать, что запоминание нужных аргументов, в общем, практически не требуется, порядок расстановки — стандартизован и логичен, для ввода очередной команды обычно нужно в среднем нажать 5-6 клавиш…
Как я мог забыть? :)
$ tar [TAB]
A — append to an archive
c — create a new archive
f — specify archive file or device
t — list archive contents
u — update archive
v — verbose output
x — extract files from an archive
(это zsh)
$ tar [TAB]
A — append to an archive
c — create a new archive
f — specify archive file or device
t — list archive contents
u — update archive
v — verbose output
x — extract files from an archive
(это zsh)
$ tar A c d r t u x
(это bash в Ubuntu)
# tar
.bash_history .gnupg/ .profile .viminfo
.bashrc .htoprc
(это bash в Debian)
Наверное стоит посмотреть на этот zsh — он «из коробки» такой умный?
(это bash в Ubuntu)
# tar
.bash_history .gnupg/ .profile .viminfo
.bashrc .htoprc
(это bash в Debian)
Наверное стоит посмотреть на этот zsh — он «из коробки» такой умный?
чёрт парсер съел :(
Поставьте хотя бы пакет типа bash-completion — должно сильно полегчать…
Это ещё что!
$ scp 192.168.1.2:/etc/X11/<TAB>
Sessions/ config* xdm/ xorg.conf.backup
app-defaults/ gdm/ xinit/ xorg.conf.example
chooser.sh* startDM.sh* xorg.conf xorg.conf.orig.vgl
Чтобы сделать его таким умным надо поставить пакет zsh-completion. Вот мои .zsh*: ompldr.org/vNWwxcQ/.zsh.tar.bz2
Поправьте под себя .zshcomprc и .zshrc
$ scp 192.168.1.2:/etc/X11/<TAB>
Sessions/ config* xdm/ xorg.conf.backup
app-defaults/ gdm/ xinit/ xorg.conf.example
chooser.sh* startDM.sh* xorg.conf xorg.conf.orig.vgl
Чтобы сделать его таким умным надо поставить пакет zsh-completion. Вот мои .zsh*: ompldr.org/vNWwxcQ/.zsh.tar.bz2
Поправьте под себя .zshcomprc и .zshrc
>хоть сколько-нибудь адекватно настроенный bash с completions.
В Ubuntu из коробки можно его считать адекватно настроенным? Что он как-то настроен, по сравнению даже с Debian, это точно: то, что считал, работая в Ubuntu, неотъемлемыми свойствами bash, в Debian не работает. Например, после apt-get Ubuntu выдаёт список операций apt-get, а Debian — список файлов в текущем каталоге, а главное Ubuntu после операции выдаёт по Tab ещё и список доступных/установленных пакетов, Debian не выдаёт :(. Аналогично la и ll — Debian не знает что это такое.
Имхо, не «как работают люди в современных шеллах», а «как работают люди, которые знают и используют многие возможности современных шеллов». Сомневаюсь, что я смогу обходиться 5-6 клавишами, даже если установлю zsh или fish, но не потрачу день-неделю-месяц-год (скорее последнее, чем первое) на изучение (и освоение на практике, что очень важно, по-моему — просто прочтение «запоем» умных книжек или распечаток доков толку мало даст, проверено) их возможностей или, хотя бы, это же время не потрачу на изучение того, как реализовано в Ubuntu то, чего мне не хватает в Debian, когда работаю с ним по ssh, а там глядищь появятся мысли как реализовать и то, чего нет в Ubuntu.
P.S. Я чувствую, что я как-то не так подхожу к освоению линуксового CLI, но методы проверенные на многих ЯП, от нескольких ассемблеров до Python, VB.Net и сейчас вот Lisp, тут почему-то не срабатывают. Грубо говоря, как работал 20 лет назад в COMMAND.COM, также и работаю в bash, разве что активно пользуюсь стрелочками вверх-вниз и Tab, и то, начал пользоваться ими, кажется, в винде, когда ещё сама мысль поставить на десктоп юникс казалась святотатством (по отношению к юниксу, а не десктопу :) )
В Ubuntu из коробки можно его считать адекватно настроенным? Что он как-то настроен, по сравнению даже с Debian, это точно: то, что считал, работая в Ubuntu, неотъемлемыми свойствами bash, в Debian не работает. Например, после apt-get Ubuntu выдаёт список операций apt-get, а Debian — список файлов в текущем каталоге, а главное Ubuntu после операции выдаёт по Tab ещё и список доступных/установленных пакетов, Debian не выдаёт :(. Аналогично la и ll — Debian не знает что это такое.
Имхо, не «как работают люди в современных шеллах», а «как работают люди, которые знают и используют многие возможности современных шеллов». Сомневаюсь, что я смогу обходиться 5-6 клавишами, даже если установлю zsh или fish, но не потрачу день-неделю-месяц-год (скорее последнее, чем первое) на изучение (и освоение на практике, что очень важно, по-моему — просто прочтение «запоем» умных книжек или распечаток доков толку мало даст, проверено) их возможностей или, хотя бы, это же время не потрачу на изучение того, как реализовано в Ubuntu то, чего мне не хватает в Debian, когда работаю с ним по ssh, а там глядищь появятся мысли как реализовать и то, чего нет в Ubuntu.
P.S. Я чувствую, что я как-то не так подхожу к освоению линуксового CLI, но методы проверенные на многих ЯП, от нескольких ассемблеров до Python, VB.Net и сейчас вот Lisp, тут почему-то не срабатывают. Грубо говоря, как работал 20 лет назад в COMMAND.COM, также и работаю в bash, разве что активно пользуюсь стрелочками вверх-вниз и Tab, и то, начал пользоваться ими, кажется, в винде, когда ещё сама мысль поставить на десктоп юникс казалась святотатством (по отношению к юниксу, а не десктопу :) )
Человек, который ничего не знает о компьютерах, потратит примерно одинаковое время на изучение возможностей какого-нибудь Windows Explorer (или как он там сейчас называется?), Mac Finder, File Roller, FAR, Midnight Commander или zsh. При этом вся разница будет в скорости: даже какие-то тривиальные действия с файлами опытный человек в шелле сделает на порядок быстрее, чем в Explorer-Finder-подобных интерфейсах.
Примерно такая же фигня с текстовыми редакторами: человек, владеющий emacs или vi, успеет сделать даже какую-то простую операцию быстрее, чем человек с большой IDE или каким-нибудь офисным пакетом.
Вообще Вы натолкнули на мысль: может быть и правда сделать некий обзор приемов работы с shell…
Примерно такая же фигня с текстовыми редакторами: человек, владеющий emacs или vi, успеет сделать даже какую-то простую операцию быстрее, чем человек с большой IDE или каким-нибудь офисным пакетом.
Вообще Вы натолкнули на мысль: может быть и правда сделать некий обзор приемов работы с shell…
На изучение возможностей вероятно такое же, а вот освоить использование этих возможностей на практике… На довольно большой выборке могу судить, что мышку люди (независимо от возраста кстати) осваивают куда быстрее клавиатуры, не то что там какие-то «секретные» приёмы работы в шелле, а банально свой логин/пароль вводят годами одним пальцем со скорость знаков 20-30 знаков в минуту (правда теряя несколько секунд на перемещение мышкой фокуса с логина на пароль и нажатие ОК). То есть чтобы набрать команду типа cp file.ext file.bak потратят секунд 30 минимум. В GUI, я думаю, побыстрее будет.
А обзор было бы интересно почитать, особено для таких как я, кто по тем или иным причинам консолью пользуется, признавая в теории что ещё многое лучше делать в ней, но вот на практике тратить часы на поиски не то, что метода что-то конкретно ускорить/сделать удобнее, а и вообще только узнать, что это можно ускорить. Вот из комментов к этому топику узнал, что существует возможность не только показывать по таб варианты завершения команды но и описание этих вариантов, до этого даже мысли такой не было, что это возможно, максимум о чём мечтал, чтобы список вариантов во всех командах работал (хотя нет, мечтал о каком-то подобие тултипов в IDE)
А обзор было бы интересно почитать, особено для таких как я, кто по тем или иным причинам консолью пользуется, признавая в теории что ещё многое лучше делать в ней, но вот на практике тратить часы на поиски не то, что метода что-то конкретно ускорить/сделать удобнее, а и вообще только узнать, что это можно ускорить. Вот из комментов к этому топику узнал, что существует возможность не только показывать по таб варианты завершения команды но и описание этих вариантов, до этого даже мысли такой не было, что это возможно, максимум о чём мечтал, чтобы список вариантов во всех командах работал (хотя нет, мечтал о каком-то подобие тултипов в IDE)
powershell ;)
В Gnome/KDE/..., а тем более в MacOS (DE Aqua?) окошек выпрыгивает меньше? :)
Статья написана больше 10 лет назад, одна фраза «Половина окон – это терминалы с командной строкой или консольным редактором vi, который там запущен.» о многом говорит (хотя у самого сейчас открыто две консоли, одна из них с vim, но я не типичная «домохозяйка» или «манагер»).
Сейчас, когда самая распространённая на десктопах и лаптопах *nix ось является по совместительству и самой «гламурной» (или, если угодно, «свистопердящей»), a в виндовс появились приличные (судя по отзывам) средства работы в командной строке, противопоставлять, имхо, нужно не виндовс/юникс, а cli/gui, текстовые конфиги/«какие-то другие конфиги» и т. п. Да и то следует ли их противопоставлять, кто-то не использует gui (есть такие ещё, интересно? :) ), кто-то cli, а многие (в том числе и я) комбинируют их, пускай и в разных пропорциях, но вряд ли кто читает этот топик через консольный браузер ;)
Статья написана больше 10 лет назад, одна фраза «Половина окон – это терминалы с командной строкой или консольным редактором vi, который там запущен.» о многом говорит (хотя у самого сейчас открыто две консоли, одна из них с vim, но я не типичная «домохозяйка» или «манагер»).
Сейчас, когда самая распространённая на десктопах и лаптопах *nix ось является по совместительству и самой «гламурной» (или, если угодно, «свистопердящей»), a в виндовс появились приличные (судя по отзывам) средства работы в командной строке, противопоставлять, имхо, нужно не виндовс/юникс, а cli/gui, текстовые конфиги/«какие-то другие конфиги» и т. п. Да и то следует ли их противопоставлять, кто-то не использует gui (есть такие ещё, интересно? :) ), кто-то cli, а многие (в том числе и я) комбинируют их, пускай и в разных пропорциях, но вряд ли кто читает этот топик через консольный браузер ;)
А я сначала подумал, что статья будет связана с менеджером группы, который упоминается в начале, ну там типа чудесным образом с помощью литературы стал UNIX'оидом.
А статья интересная, спасибо.
А статья интересная, спасибо.
$ if test -z `ps -fe | grep КТО`
> then
> echo ^G
> fi
bash: test: слишком много аргументов
Шутка не шутится
> then
> echo ^G
> fi
bash: test: слишком много аргументов
Шутка не шутится
он сам написал, что там не совсем верный синтаксис
не совсем верный синтаксис, как говорит автор, в примере с меню и креветками (cat меню | grep креветки | test -lt $10...) т.к. перед test -lt $10 нужно сперва на awk отделить колонку с ценой от остальных колонок.
А эту шутку все равно не понял…
КО, помоги!
А эту шутку все равно не понял…
КО, помоги!
«Нет человека, который был бы как Остров, сам по себе, каждый человек есть часть Материка, часть Суши; и если волной снесёт в море береговой Утёс, меньше станет Европа, и так же, если смоет край мыса или разрушит Замок твой или друга твоего; смерть каждого Человека умаляет и меня, ибо я един со всем Человечеством, а потому не спрашивай, по ком звонит колокол: он звонит по Тебе». (Эрнест Хемингуэй)
В данном скрипте ищутся все процессы с фразой КТО, т.е. по КОМ звонит колокол. Прикол видимо в том, что находится только процесс этого же скрипта, т.е. колокол звонит по тебе.
echo ^G — символ звонка, т.е. будет издан звук из PC Speaker по идее. Как я понял, в скрипте ошибка — нужно использовать -n вместо -z. Сам скрипт как я его понял — написал ниже
В данном скрипте ищутся все процессы с фразой КТО, т.е. по КОМ звонит колокол. Прикол видимо в том, что находится только процесс этого же скрипта, т.е. колокол звонит по тебе.
echo ^G — символ звонка, т.е. будет издан звук из PC Speaker по идее. Как я понял, в скрипте ошибка — нужно использовать -n вместо -z. Сам скрипт как я его понял — написал ниже
echo ^G — символ звонкаНе просто «звонка». Точнее будет «bell character».
Скорее всего, автор не имел в виду того, что найдется сам процесс. Скорее всего, автор писал в своем эссе этот скрипт от балды, не проверяя. Скорее всего автор в возрасте, когда собственные ляпы его не особо тревожат. Кроме того, не нужно исключать возможность того, что в старых юниксах ключ "-ef" имел другое значение, т.к. команда «ps» в разных юниксах сильно отличается, особенно в ранних bsd/sysv.
Скорее всего, автор имел в виду, что он ищет кого-то (процесс), греп его не находит (-z тестирует на пустую строку), и звонит колокол (этот кто-то умер: процесс умер, колокол звонит по мертвому). В английском «for whom the bell tolls». Дословно: по умершему who звонит bell, «for who[m] the bell tolls».
Я позволил себе перевести «who» как КТО, в духе перевода аргумента команды grep в другом месте статьи, основываясь на умозаключениях выше.
Ваш комментарий изобличает в вас юниксоида, за что и физкульт-привет!
Скорее всего, автор имел в виду, что он ищет кого-то (процесс), греп его не находит (-z тестирует на пустую строку), и звонит колокол (этот кто-то умер: процесс умер, колокол звонит по мертвому). В английском «for whom the bell tolls». Дословно: по умершему who звонит bell, «for who[m] the bell tolls».
Я позволил себе перевести «who» как КТО, в духе перевода аргумента команды grep в другом месте статьи, основываясь на умозаключениях выше.
Ваш комментарий изобличает в вас юниксоида, за что и физкульт-привет!
И вам привет! То что от балды писал — это точно, но статья очень понравилась. Но всё же не соглашусь с вами по поводу трактовки этого скрипта — ведь там явно указано, что этот скрипт — «literary reference», т.е. ссылка на литературу (что отлично вписывается в аналогию статьи между писателем и пользоватем консоли). Комментарий в конце "# Let's see for whom the bell tolls." приводит нас к Хемингуэю, а «whom» — это скорее «по_ком», но так будет два слова. Так что останусь при своей точке зрения, но не могу не усмотреть в вашем комментарии живость ума, так часто присущую юниксоидам :)
if [ -n "`ps -fe | grep KTO`" ]; then
echo ^G
fi
echo ^G
fi
нужна опция -n а не -z. опция -n это строка _не_ пустая. и так как параметро строка, то надо её в кавычки заключить, иначе будет «слишком много аргументов»
if test -n "`ps -fe|grep WHO`"; then echo ^G; fi
Очень верно все подмечено.
Интересно было бы узнать мнение автора о COM + PowerShell в последних версиях Windows…
Интересно было бы узнать мнение автора о COM + PowerShell в последних версиях Windows…
По-моему, довольно точно подмечена основная причина любви/ненависти к CLI/GUI:
Команды и ключи ещё можно запомнить (хотя и сложнее, имхо, чем «где-то тут было окошко, а где-то в нём галочка делающая то, что мне нужно»), но вот ошибиться при их наборе куда проще, чем при «проставлении галочек», если при наборе смотришь на клавиатуру, а при работе мышью на экран — нет мгновенной обратной связи (навыки слепого кликанья мышью у многих развиты куда лучше навыков слепой или безошибочной печати, да ещё не на родном языке). Если же после каждого нажатия клавиши каждый раз переводить взгляд с клавиатуры на экран, для этой обратной связи, то скорость набора команд упадёт катастрофически.
Если нет хороших навыков печати (а также знания команд и ключей, структуры ФС и т. п.), то аргумент «не надо отрывать руки от клавиатуры превращается в контраргумент „надо отрывать руку от мыши“, т. к. в GUI при таких условиях многое делается в разы, а то и на порядки быстрее.
Один неверный символ, и всё надо начинать сначала.… Общей нитью было “писачество”: подозрительно большой процент моих коллег-юниксоидов в ходе карьерного роста уже обзавелся навыками работы с текстом и словами.
Команды и ключи ещё можно запомнить (хотя и сложнее, имхо, чем «где-то тут было окошко, а где-то в нём галочка делающая то, что мне нужно»), но вот ошибиться при их наборе куда проще, чем при «проставлении галочек», если при наборе смотришь на клавиатуру, а при работе мышью на экран — нет мгновенной обратной связи (навыки слепого кликанья мышью у многих развиты куда лучше навыков слепой или безошибочной печати, да ещё не на родном языке). Если же после каждого нажатия клавиши каждый раз переводить взгляд с клавиатуры на экран, для этой обратной связи, то скорость набора команд упадёт катастрофически.
Если нет хороших навыков печати (а также знания команд и ключей, структуры ФС и т. п.), то аргумент «не надо отрывать руки от клавиатуры превращается в контраргумент „надо отрывать руку от мыши“, т. к. в GUI при таких условиях многое делается в разы, а то и на порядки быстрее.
P.S. Cужу по личному опыту, пользуюсь CLI только когда не знаю другого выхода (может он есть, а может нет, но на глаза меню/окошко/галочка с нужной функцией не попадалась) или когда точно знаю, как что-то в CLI можно сделать быстрее, чем в GUI. Не просто знаю, что это можно сделать быстрее, а уже знаю как это можно сделать быстрее. Простой пример, для поиска файлов пользуюсь GUI, хотя точно знаю, что есть мощные команды grep, find, locate и т. п., но быстрее нажать F3 и ввести маску файла и маску искомого выражения, чем разбираться с командами и ключами. В то же время, если надо рестартануть веб-сервер или СУБД после изменения конфигов (в GUI), то проще и быстрее открыть консоль и набрать /init.d/lighttpd restart) чем смотреть есть ли GUI средства для этого, т. к. а) работает авдополнение в путях; б) имя команды чётко связано с объектом, на который предполагается воздействовать и тоже работает автодополнение; в) ключ к команде «по-русски» звучит
> Команды и ключи ещё можно запомнить (хотя и сложнее, имхо, чем «где-то тут было
> окошко, а где-то в нём галочка делающая то, что мне нужно»), но вот ошибиться при
> их наборе куда проще, чем при «проставлении галочек»
ВСЕ часто употребляемые команды и последовательности команд с ключами оформлены у меня в виде скриптов, все мои скрипты начинаются со знака подчеркивания, затем имя скрипта по типу иерархического меню с разделителем — подчеркиванием. В комбинации с дописыванием по ТАБ, это дает гораздо большую скорость работы, чем лазание по менюшкам/иконкам мышкой.
> окошко, а где-то в нём галочка делающая то, что мне нужно»), но вот ошибиться при
> их наборе куда проще, чем при «проставлении галочек»
ВСЕ часто употребляемые команды и последовательности команд с ключами оформлены у меня в виде скриптов, все мои скрипты начинаются со знака подчеркивания, затем имя скрипта по типу иерархического меню с разделителем — подчеркиванием. В комбинации с дописыванием по ТАБ, это дает гораздо большую скорость работы, чем лазание по менюшкам/иконкам мышкой.
Надо будет попробовать, но как окажешься за голой машиной, так, наверное, как без рук себя будешь чувствовать
Ну, базовые команды все равно приходится помнить, зато не нужно помнить пути к менюшкам, иконкам и галочкам.
И скопировать скрипты и подправить путь на новую машину, это самый быстрый путь переноса привычного окружения на любую новую машину, особенно если сеть работает.
У меня и в графическом окружении сделано все на dmenu, xbindkeys и скриптах, так, чтобы быть независимым от десктопного окружения и переносить на другую машину простым копированием.
И скопировать скрипты и подправить путь на новую машину, это самый быстрый путь переноса привычного окружения на любую новую машину, особенно если сеть работает.
У меня и в графическом окружении сделано все на dmenu, xbindkeys и скриптах, так, чтобы быть независимым от десктопного окружения и переносить на другую машину простым копированием.
Так вроде и статья отчасти об этом — что есть определённый тип людей, которым свобода/мощь консольных команд намного больше по душе, чем окошки и галочки.
Проблема оконных систем в том, что как только что-то там меняется (убирается галочка, радио-батончики становятся менюшкой и прочие изменения-переезды) — так сразу надо учиться(привыкать) заново, каждый раз матерясь, зачем они перевезли эту опцию из одного диалога в другой.
Да, на юниксе тоже бывает и конфиги по-разному называются и новые версии сервисов работают по-другому итд итп. Но есть уверенность, что (а) практически всегда можно вернуться к предыдущей знакомой версии и (б) с помощью хелпа и манула найти как это делается по-новому и слегка перенастроить какой-нибудь свой скриптик. И как запускал скрипт conf_service_xxx, так и запускаешь дальше.
Что делать если какая-то опция из гуя была убрана _совсем_ для меня загадка. Реестр разве что.
Проблема оконных систем в том, что как только что-то там меняется (убирается галочка, радио-батончики становятся менюшкой и прочие изменения-переезды) — так сразу надо учиться(привыкать) заново, каждый раз матерясь, зачем они перевезли эту опцию из одного диалога в другой.
Да, на юниксе тоже бывает и конфиги по-разному называются и новые версии сервисов работают по-другому итд итп. Но есть уверенность, что (а) практически всегда можно вернуться к предыдущей знакомой версии и (б) с помощью хелпа и манула найти как это делается по-новому и слегка перенастроить какой-нибудь свой скриптик. И как запускал скрипт conf_service_xxx, так и запускаешь дальше.
Что делать если какая-то опция из гуя была убрана _совсем_ для меня загадка. Реестр разве что.
Свобода и мощь мне тоже по душе :) Проникаюсь восхищением к авторам, когда вижу в каком-то howto как одной строчкой (пускай и 500+ символов) установить и настроить, например, AMP. Но практичнее кажутся либо «окошки и галочки» (для действий, которые нужны раз в году), либо скрипты/программы на обычных ЯП (для действий, которые нужно выполнять 100 раз в день). Очень не нравится в CLI (с которыми встречался) единая глобальная «область видимости» — в моем /usr/bin/ сейчас 2038 файлов никак не структурированных, двойной Tab в чистой строке ввода говорит «Display all 3087 possibilities? (y or n)». Как в этом можно ориентироваться, даже просто хотя бы понять какие из этих команд тебе могут когда-нибудь потребоваться, а какие напрямую никогда запускать не будешь? О_о
Если какой-то опции, например MySQL, нет в GUI я открываю консоль и пишу «sudo gedit /etc/init.d/mysql/my.conf» :) А в GNOME чуть ли не полный аналог regedit сделали зачем-то :-/
Если какой-то опции, например MySQL, нет в GUI я открываю консоль и пишу «sudo gedit /etc/init.d/mysql/my.conf» :) А в GNOME чуть ли не полный аналог regedit сделали зачем-то :-/
Ну я приобрел навыки слепой печати на кириллице и латинице до того как перешел на Linux, поэтому для меня «не отрывать руки от клавиатуры» — достоинство)
И еще, CLI очень хорош, когда записываешь действия. Просто берешь и копируешь в запись последовательность команд. Это на порядок быстрее, чем записать последовательность кликания по меню.
Я бы написал сюда, что думаю о командной строке в UNIX, но не люблю повторяться — zahardzhan.github.com/2010/integrated-environment-and-linux-on-desktop.html
Пожинаете плоды файлопомойки в $HOME ;) Поиск, что в хроме, что find или locate вообще не нужен в идеале, но если содержать порядок уже поздно:
find -name sicp.pdf | xargs evince
Если вы всё время пользуетесь хромом — то вам удобнее хром, т.к. в консоли придётся читать маны. Если вы всё время пользуетесь консолью — то консоль удобнее, например, я вообще не нашёл в своём хроме никакого командного интерфейса. Тратить 12 минут на чтение man chromium?
find -name sicp.pdf | xargs evince
Если вы всё время пользуетесь хромом — то вам удобнее хром, т.к. в консоли придётся читать маны. Если вы всё время пользуетесь консолью — то консоль удобнее, например, я вообще не нашёл в своём хроме никакого командного интерфейса. Тратить 12 минут на чтение man chromium?
Кхм… Я говорил о командном интерфейсе поисковой строки на сайте Google.com и о поиске в Сети. Командная строка хрома — это «адресная строка», которая дублирует функции той, что на google.com.
Я содержу порядок в своём «доме» ~. Да толку-то — найти нужный файл оказывается проще тупо используя автодополнение шелла — особенно если знаешь какой файл где и как он называется.
Смысл в том, что для простого домашнего использования полностью автоматизированный умный (с элементами ИИ) поиск гораздо (гораздо!) удобнее и уместнее, чем мощный, точный, сложный и в большинстве неудобный поиск стандартными средствами UNIX а'ля find, locate и иже с ними.
>Если вы всё время пользуетесь консолью — то консоль удобнее
Имеется в виду, что на дцатый раз поиска файла с известным именем «man find» уже не надо будет набирать, так как в голове отложится? :) И набирать надо будет только когда понадобится файл с неизвестным именем, но заведомо содержащим какую-то подстроку?
>я вообще не нашёл в своём хроме никакого командного интерфейса. Тратить 12 минут на чтение man chromium?
Я тоже, плюс:
$ man chromium
Нет справочной страницы для chromium
Имеется в виду, что на дцатый раз поиска файла с известным именем «man find» уже не надо будет набирать, так как в голове отложится? :) И набирать надо будет только когда понадобится файл с неизвестным именем, но заведомо содержащим какую-то подстроку?
>я вообще не нашёл в своём хроме никакого командного интерфейса. Тратить 12 минут на чтение man chromium?
Я тоже, плюс:
$ man chromium
Нет справочной страницы для chromium
Хм… попробовал в Хромиуме написать SICP — выдал мне URL'ы сайтов, которые я на этой неделе посещал, но вовсе не сам файл (его я предварительно в evince закрыл). Поиск в локальных файлах — это фишка Хрома?
А вот «путь UNIX» именно так у меня и выглядит, включая учебник для системных администраторов и две консоли — одна с маном, другая с попытками использовать команду :) И тоже исключая простые команды, с которыми познакомился ещё под CP/M и MSX-DOS (не путать с MS-DOS :) )
А вот «путь UNIX» именно так у меня и выглядит, включая учебник для системных администраторов и две консоли — одна с маном, другая с попытками использовать команду :) И тоже исключая простые команды, с которыми познакомился ещё под CP/M и MSX-DOS (не путать с MS-DOS :) )
Нет же. Хром не ищет в локальных файлах.
Тогда вот этого не понял:
Печатаем «SICP». Хром выдает список с вариантом «SICP PDF». Дважды вниз, один Enter.
Похоже, 4-ый результат — это то, что надо.
Тык.
Печатаем «SICP». Хром выдает список с вариантом «SICP PDF». Дважды вниз, один Enter.
Похоже, 4-ый результат — это то, что надо.
Тык.
Стандартная процедура поиска гуглом.
Так это поиск в вебе, а не поиск локального (пускай когда-то уже найденного и скаченного) файла? То есть задачу «найти и открыть файл на винте» не решаем, а заменяем её на «найти файл в вебе, открыть его, найти ссылку на нужный файл, скачать его на винт (уже второй экземпляр) и открыть»?
Это можно сделать и в консоли:
$links google.ru/search?q=SICP%20pdf
Это можно сделать и в консоли:
$links google.ru/search?q=SICP%20pdf
MSX-DOS — школьная ямаха, чтоли?
Интересная мысль (я про «нужно больше думать, и меньше распознавать»). Пожалуй, соглашусь. Особенно, когда речь идёт о каком-то крупном и сложном решении.
Условно говоря, сравните настройку IPSec под Windows и под линукс. Где нужно больше знать и решать, а где нужно больше рыться по менюшкам в поисках «вроде бы это может помочь»?
Условно говоря, сравните настройку IPSec под Windows и под линукс. Где нужно больше знать и решать, а где нужно больше рыться по менюшкам в поисках «вроде бы это может помочь»?
По теме — The Shell Haters Handbook shellhaters.heroku.com/#1
Ох, как красиво и поэтично написано! Видно что автор романтик )
Романтик, как и я…
Романтик, как и я…
if test -z `ps -fe | grep who`
Это не надо было переводить, ибо это, как говорят правила перевода, имена собственные и команды unix не переводятся.
who здесь ни имя собственное, ни команда.
не команда, потому что who отрабатывает очень быстро, и в списке процессов ее поймать нереально. Стало быть, ее искать не имеет технического смысла. Логического смысла искать тоже не имеет, т.к. «who | more» возможно и найдется, но, Холмс, для чего???
не команда, потому что who отрабатывает очень быстро, и в списке процессов ее поймать нереально. Стало быть, ее искать не имеет технического смысла. Логического смысла искать тоже не имеет, т.к. «who | more» возможно и найдется, но, Холмс, для чего???
не команда, потому что who отрабатывает очень быстро, и в списке процессов ее поймать нереально.
Именно! Если не запущено ни одного процесса who, то звякнуть колокольчиком. Вполне хемингуэйно.
Я протестую. Колокол звонит по тому кто жил, жил, жил, и умер. Чтобы те кто знали того, кто жил, теперь узнали, что то, к чему они привыкли, больше не так. Колокол не звонит по комарам.
процесс who и не пожил. Жил named. Жил mysqld. Жил даже httpd, хотя он живет вечно. Who — не жил!!!
Хемингуэй не разменивается по комарам!
процесс who и не пожил. Жил named. Жил mysqld. Жил даже httpd, хотя он живет вечно. Who — не жил!!!
Хемингуэй не разменивается по комарам!
Характерный пример UNIX-гуманитария в Рунете — Алексей Федорчук! :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Элементы стиля: UNIX как литература