Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
Еще одна статья про ls?
Под OS X некоторые команды не работают. Например, ls -X или find без аргументов. Видимо, версии GNU и BSD несколько отличаются.
Консоль мощнее, но для повседневной работы эта мощь, имхо, излишня, а простоты IDE не хватает. Предпочитаю IDE, а консоль в качестве вспомогательного средства, прежде всего для работы с vcs.
Нет нет нет и ещё раз нет.
Вы просто не понимаете что может дать консоль. И, впрочем, никогда не сможете понять если относитесь к этому с такими взглядами. Известно, что в консольке работает гигантское количество людей. И хотя бы один этот факт должен говорить о том, что в чем-то вы заблуждаетесь.
Вы просто не понимаете что может дать консоль. И, впрочем, никогда не сможете понять если относитесь к этому с такими взглядами. Известно, что в консольке работает гигантское количество людей. И хотя бы один этот факт должен говорить о том, что в чем-то вы заблуждаетесь.
Я тоже только в ней могу работать при необходимости. Могу в ней делать всё то же самое, что и в IDE. Но это медленнее. Вот нужно мне сейчас файл отредактировать. В IDE я его открыл за 4 одинарных клика и 1 двойной, в консоли — 16 нажатий клавиш. И это при условии, что путь к файлу из корня проекта помню наизусть, на самом деле их было больше, несколько лишних нажатий Tab чтобы получить список вариантов, плюс перевод взгляда с рук на экран и обратно. Собственно отсутствие постоянной обратной визуальной связи, плюс постоянная необходимость набирать то, что уже видишь на экране (вместо того чтобы кликнуть мышкой) и замедляет постоянно работу.
И, вроде бы, с GUI работает куда большее число людей, архигигантское получается. Вы считаете, что все они заблуждаются?
И, вроде бы, с GUI работает куда большее число людей, архигигантское получается. Вы считаете, что все они заблуждаются?
Обычных программистов больше ведь, чем лучших). Это я про «архигигантское».
Конечно все написаное мной справедливо, если:
1) слепой метод печати
2) хотя бы 220-250 символов в минуту (у меня ~450, программистских (с запятыми, кавычками, слешами и тп)). Клавогонки и все такое). Даже при 16 символах в секунду, ваши нажатия все в 1 секунду уложаться. 4 клика мышкой, учитывая что к ней надо тянуться и между кликами двигать — будут дольше.
3) vim /etc/cron.d/somefile => vim /e/c/somefile. Так умеет, например, zsh. Это не просто экономия на нажатиях табов, в /etc может быть несколько папок начинающихся с «c», но zsh автоматически возьмёт cron.d, при условии что somefile есть только там.
Работа с консолью со временем становится все быстрее и быстрее и быстрее.
По поводу п1 стоит отдельно заметить, что т.к. это вообще полезное умение при работе связанной с программированием, то его при работе с консолью навык работать с клавиатурой целиком вслепую придет быстрее =).
Не понтов ради, но сейчас для меня необходимость тянуться к мышке иногда уже является сильным замедляющим фактором. Хотя я ничего специально нигде не пытаюсь ускорять в своём workflow. Просто с течением времени все само собой так получается.
Ну и последнее замечание — открытие нужного файла в консоли — никто же не говорит, что это не может быть аналог GUI, но в текстовом варианте. У меня в виме есть возможность открывать файлы через встроенный файл-менеджер (ну типа :e folder/file.txt — напрямую, а если :e folder, то потом нужно лишь файл выбрать в списке). Действительно бывает удобно какие-то файлы выбирать, а не печатать. И никто не говорит тут о том чтобы бросаться в крайности и никогда такого не делать. Можно в какой-то момент дергать mc, если опять же это нужно. Всегда есть выбор. А если разработка завязана на консольке. то значит в этот момент она уже открыта и вероятно в нужном месте (как правило, в корне проекта).
Просто IDE все стремится засосать в себя. А консоль стремится быть клеем всего и вся.
Пример: есть virtualenv для питона. И сейчас IDE научились его эмулировать. Хотя сам virtualenv уже года 2 существует, IDE дошли до него только сейчас. И эта поддержка ими не может быть полной по определению. В итоге многие используют virtualenv отдельно а IDE отдельно. А такое дробление (часть делаем в консольке — часть в IDE) тоже не позволяет прочувствовать мощь консоли целиком.
Конечно все написаное мной справедливо, если:
1) слепой метод печати
2) хотя бы 220-250 символов в минуту (у меня ~450, программистских (с запятыми, кавычками, слешами и тп)). Клавогонки и все такое). Даже при 16 символах в секунду, ваши нажатия все в 1 секунду уложаться. 4 клика мышкой, учитывая что к ней надо тянуться и между кликами двигать — будут дольше.
3) vim /etc/cron.d/somefile => vim /e/c/somefile. Так умеет, например, zsh. Это не просто экономия на нажатиях табов, в /etc может быть несколько папок начинающихся с «c», но zsh автоматически возьмёт cron.d, при условии что somefile есть только там.
Работа с консолью со временем становится все быстрее и быстрее и быстрее.
По поводу п1 стоит отдельно заметить, что т.к. это вообще полезное умение при работе связанной с программированием, то его при работе с консолью навык работать с клавиатурой целиком вслепую придет быстрее =).
Не понтов ради, но сейчас для меня необходимость тянуться к мышке иногда уже является сильным замедляющим фактором. Хотя я ничего специально нигде не пытаюсь ускорять в своём workflow. Просто с течением времени все само собой так получается.
Ну и последнее замечание — открытие нужного файла в консоли — никто же не говорит, что это не может быть аналог GUI, но в текстовом варианте. У меня в виме есть возможность открывать файлы через встроенный файл-менеджер (ну типа :e folder/file.txt — напрямую, а если :e folder, то потом нужно лишь файл выбрать в списке). Действительно бывает удобно какие-то файлы выбирать, а не печатать. И никто не говорит тут о том чтобы бросаться в крайности и никогда такого не делать. Можно в какой-то момент дергать mc, если опять же это нужно. Всегда есть выбор. А если разработка завязана на консольке. то значит в этот момент она уже открыта и вероятно в нужном месте (как правило, в корне проекта).
Просто IDE все стремится засосать в себя. А консоль стремится быть клеем всего и вся.
Пример: есть virtualenv для питона. И сейчас IDE научились его эмулировать. Хотя сам virtualenv уже года 2 существует, IDE дошли до него только сейчас. И эта поддержка ими не может быть полной по определению. В итоге многие используют virtualenv отдельно а IDE отдельно. А такое дробление (часть делаем в консольке — часть в IDE) тоже не позволяет прочувствовать мощь консоли целиком.
16 символов в секунду — это 960 в минуту. Какое здесь «даже при»?
В Vim очень удобно использовать Command-T для открытия файлов. Впрочем, это не единственное дополнение на эту тему: есть также FuzzyFinder, Unity, ku, LustyExplorer, … А автодополнение файлов в Vim убого. Я как‐то сделал аналог автодополнения файлов в zsh (причём, в zsh автодополнение именно файлов оказалось несколько хуже), но Command-T оказался ещё удобнее, поэтому проект заглох несмотря на несколько очевидных проблем.
Относительно virtualenv: “workon env” не работает в Vim (в смысле, если запустить workon и затем Vim, встроенная поддержка python будет игнорировать виртуальное окружение, но запущенные из Vim команды игнорировать не будут). Приходится использовать github.com/jmcantrell/vim-virtualenv.
В Vim очень удобно использовать Command-T для открытия файлов. Впрочем, это не единственное дополнение на эту тему: есть также FuzzyFinder, Unity, ku, LustyExplorer, … А автодополнение файлов в Vim убого. Я как‐то сделал аналог автодополнения файлов в zsh (причём, в zsh автодополнение именно файлов оказалось несколько хуже), но Command-T оказался ещё удобнее, поэтому проект заглох несмотря на несколько очевидных проблем.
Относительно virtualenv: “workon env” не работает в Vim (в смысле, если запустить workon и затем Vim, встроенная поддержка python будет игнорировать виртуальное окружение, но запущенные из Vim команды игнорировать не будут). Приходится использовать github.com/jmcantrell/vim-virtualenv.
От мании величия я вроде бы уже избавился, как бы не перебрал :)
1) Слепой метод мне не даётся, как и, например, переключение передач не глядя на рукоятку или выключение сцепления не глядя на педаль. Вернее не так, не глядя на руки или ногу.
2) Я могу печатать ~200 знаков в минуту на клавиатуре где знаки стёрты, но мне нужно видеть свои руки, не глядя на руки 60-80 максимум (если без шифтов), слишком долго представлять движения пальцев и не то что годами, а десятилетиями этот показатель не меняется, хотя бывало две недели только Соло проходил по 12 часов в сутки (5 клавиатур разбил как-то за отпуск).
3) Нужно знать путь и название файлов, я их узнаю когда вижу их на экране, а те что помню наизусть (типа /etc/php5/cli/php.ini) редко приходится набирать, как правило только при установке новой системы.
Насчёт последнего замечания — я только рад был бы, если бы для моих языков существовали полноценные IDE в TUI. Но, увы, никто их не разрабатывает, а vim/emacs не тянут ввиду, прежде всего, отсутствия синтаксических анализаторов для интеллектуального автодополнения или навигации типа «перейти к определению метода».
А насчёт дробления — я же говорил, что консоль мощнее IDE, но мощь эта, имхо, не востребована на типичных задачах, превносит оверхид. Универсальный клей хорошо когда часто приходится клеить разные материалы, а когда одни и те же, то лучше взять узкоспециализированный. Например, можно использовать grep чтобы найти файл, содержащий
IDE стремится засосать в себя только то, что нужно для разработки, отсекая, например, то, что нужно для администрирования.
1) Слепой метод мне не даётся, как и, например, переключение передач не глядя на рукоятку или выключение сцепления не глядя на педаль. Вернее не так, не глядя на руки или ногу.
2) Я могу печатать ~200 знаков в минуту на клавиатуре где знаки стёрты, но мне нужно видеть свои руки, не глядя на руки 60-80 максимум (если без шифтов), слишком долго представлять движения пальцев и не то что годами, а десятилетиями этот показатель не меняется, хотя бывало две недели только Соло проходил по 12 часов в сутки (5 клавиатур разбил как-то за отпуск).
3) Нужно знать путь и название файлов, я их узнаю когда вижу их на экране, а те что помню наизусть (типа /etc/php5/cli/php.ini) редко приходится набирать, как правило только при установке новой системы.
Насчёт последнего замечания — я только рад был бы, если бы для моих языков существовали полноценные IDE в TUI. Но, увы, никто их не разрабатывает, а vim/emacs не тянут ввиду, прежде всего, отсутствия синтаксических анализаторов для интеллектуального автодополнения или навигации типа «перейти к определению метода».
А насчёт дробления — я же говорил, что консоль мощнее IDE, но мощь эта, имхо, не востребована на типичных задачах, превносит оверхид. Универсальный клей хорошо когда часто приходится клеить разные материалы, а когда одни и те же, то лучше взять узкоспециализированный. Например, можно использовать grep чтобы найти файл, содержащий
class UserRepository, и открыть его в vim, но проще кликнуть в строке $repo = new UserRepository(); и нажать Ctrl+B. IDE стремится засосать в себя только то, что нужно для разработки, отсекая, например, то, что нужно для администрирования.
Есть огромная куча дополнений к Vim разной степени работоспособности для различных языков, предоставляющих возможность перехода к определению и интеллектуального автодополнения. Дополнения, использующие синтаксические анализаторы тоже есть, но VimL не даёт (точнее, требует медленных и неприглядных решений) довольно большого количества возможностей их интеграции.
Grep обычно делается из Vim, а не из консоли в этом случае, так переход к найденному можно осуществить гораздо быстрее.
Grep обычно делается из Vim, а не из консоли в этом случае, так переход к найденному можно осуществить гораздо быстрее.
То есть vim превращаем в IDE путем установки дополнений? Вот чем мне ещё нравятся IDE так тем, что скачал и можно работать, не читая мануалов и хелпов (всё равно толком ни разу не помогло их чтение, либо сразу понятно, либо проще из консоли сделать), процентов 90 потребностей будет покрыто «из коробки», ещё 5 путем настройки.
А оставшиеся 5, видимо, не могут быть покрыты в принципе.
Мне лично проще жить с более плохим автодополнением, чем настроить IDE под себя: слишком много придётся настраивать, причём значительная часть из этого «много» является либо одной из основных возможностей Vim, либо предоставляется чужими дополнениями с небольшой настройкой. Оставшееся написано самостоятельно.
Мне лично проще жить с более плохим автодополнением, чем настроить IDE под себя: слишком много придётся настраивать, причём значительная часть из этого «много» является либо одной из основных возможностей Vim, либо предоставляется чужими дополнениями с небольшой настройкой. Оставшееся написано самостоятельно.
Сторонние дополнения существуют не только для vim. И потом, есть же ещё консоль :)
Получается, дополнения надо ставить и туда, и туда. Но у меня список дополнений описан в vimrc и для того, чтобы их поставить надо выполнить всего четыре действия:
Vim-addon-manager далее затем сам установит всё, что нужно. Причём первый и третий шаги можно объединить с помощью submodules (я так не сделал, потому что VAM у меня установлен пакетным менеджером) либо поместив в vimrc код, который делает третий шаг (код можно просто скопировать из документации). Конечно, нужен по крайней мере git, но он нужен и с IDE.
- Клонировать репозиторий с настройками.
- Создать в нужном месте символические ссылки.
- Клонировать vim-addon-manager.
- Запустить Vim.
Vim-addon-manager далее затем сам установит всё, что нужно. Причём первый и третий шаги можно объединить с помощью submodules (я так не сделал, потому что VAM у меня установлен пакетным менеджером) либо поместив в vimrc код, который делает третий шаг (код можно просто скопировать из документации). Конечно, нужен по крайней мере git, но он нужен и с IDE.
Такой способ и в IDE можно применить, я думал что из коробки какой-то репозиторий есть.
Изкоробочное решение не может обладать универсальностью: я не хочу иметь один способ восстановления для IDEVim, другой для zsh, третий для браузера. Вопрос здесь в том, как хранятся эти самые настройки? Не трогал файлы IDE, но с firefox, насколько мне известно, простое копирование файлов в другое место легко может и не пройти. Легко получить различия двух разных версий sqlite базы данных, в которой он и хранит настройки, точно не выйдет (правда, мне это почти никогда не нужно).
И ещё — пакетный менеджер там действительно увидев несоответствие между списком дополнений и тем, что реально установлено, начнёт установку недостающих частей? Или придётся заталкивать туда и сами дополнения? VAM, в частности, удобен тем, что если я использую свой vimrc на arm нетбуке, то он загрузит и скомпилирует Command-T. Писать дополнительный код для его компиляции или иметь репозиторий с бинарниками с неправильной архитектурой не требуется.
И ещё — пакетный менеджер там действительно увидев несоответствие между списком дополнений и тем, что реально установлено, начнёт установку недостающих частей? Или придётся заталкивать туда и сами дополнения? VAM, в частности, удобен тем, что если я использую свой vimrc на arm нетбуке, то он загрузит и скомпилирует Command-T. Писать дополнительный код для его компиляции или иметь репозиторий с бинарниками с неправильной архитектурой не требуется.
Ну а мне собственно только от IDE настройки и нужны, остальное и не вспомню что настраиваю. По ходу дела разбираюсь: открыл программу, увидел что непривычно себя ведёт — настроил.
Установит вряд ли дополнения, хотя не экспериментировал.
Установит вряд ли дополнения, хотя не экспериментировал.
У меня основной используемой программой является редактор, но всё же потеря других настроек (zsh, Opera, mplayer, mercurial) была бы весьма неприятной. Особенно zsh и Opera, остальное легко восстановить.
Впрочем, в случае Opera одним репозиторием дело не ограничивается — так как я с самого начала рассматривал возможность сделать его публичным при необходимости, то пароли есть только в резервных копиях.
Впрочем, в случае Opera одним репозиторием дело не ограничивается — так как я с самого начала рассматривал возможность сделать его публичным при необходимости, то пароли есть только в резервных копиях.
У нас очень разные сценарии использования софта, видимо. bash, vim, sublime, mercurial, браузеры, офис и прочее я практически не настраиваю (если не считать установку расширений к браузеру). Я считаю себя среднестатистическим пользователем этих продуктов, которого должны устраивать настройки из коробки. Только минимальная персонификация в виде ввода мыла, логинов и паролей. Возможно я просто слишком поздно открыл для себя бесплатные хранилища, которым мог бы доверять свою информацию годами, не переживая за то, что она будет утрачена хотя бы из-за того, что я к хранилищу N дней/месяцев/лет не обращался.
Кстати:
скачалЗачем вы скачали то, что у вас уже должно стоять довольно давно?
Новый комп, переустановка ОС (вернее обновление через снов и установку новой), работа в новом месте.
Хорошо, скачали. А куда делся репозиторий с настройками? Или ваши IDE принципиально не позволяют иметь такой?
Эм… Ни разу не слышал, чтобы у IDE или редактора был репозиторий с настройками. Хотя, наверное, можно написать плагин, который после записи настроек будет коммитить файлы, а потом их пушить куда-нибудь на битбакет, а при запуске пуллить. Только стоит ли овчинка выделки?
У редактора или IDE его и так нет. Он есть у меня, и там хранятся все настройки, не только редактора. Кроме того, странно, что вы не слышали: на github 20 449 репозиториев, названных «dotfiles». Значительное количество подобных репозиториев названо по‐другому (у меня — config, но на bitbucket и скрытый).
И это разве сложно? Как раз удобно — хранить настройки в репозитории, чтобы при переустановке ОС/покупке нового компьютера/… не начинать с нуля.
Если также сохранить и /etc (+ аналог /var/lib/portage/world из Gentoo со списком установленных пакетов) (и сделать резервные копии всего из $HOME, что не вошло в репозиторий с настройками), то у вас будет вся информация, необходимая для восстановления системы или отката при неверно выполненной настройке.
И это разве сложно? Как раз удобно — хранить настройки в репозитории, чтобы при переустановке ОС/покупке нового компьютера/… не начинать с нуля.
Если также сохранить и /etc (+ аналог /var/lib/portage/world из Gentoo со списком установленных пакетов) (и сделать резервные копии всего из $HOME, что не вошло в репозиторий с настройками), то у вас будет вся информация, необходимая для восстановления системы или отката при неверно выполненной настройке.
Обладаю:
1. Полностью слепым методом печати (за исключением когда моторика сбивается и вместо «привет» печатается «ротает» что является смещением на одну букву на клавиатуре левее)
2. В автомобиле всегда смотрю только на дорогу или на любимую девушку справа и никогда на педали (ноги) или ручную коробку передач(руки)
Являюсь только начинающим программистом. Раньше занимался системным администрированием.
Насчет консоли и IDE:
Программирование это не просто набивание символов на клавиатуре что позволяет с легкостью и быстротой выполнять консоль, а еще и поиск по гуглу, стаковерфлоу и другим ресурсам, в некоторых случаях бывает даже копипаст какого-то кода, а потом долгие потуги разобрать его и подогнать под свой проект. А это уже проще делать в ГУИ IDE чем скролить пейдж ап энд даун консольку.
Палка о двух концах.
1. Полностью слепым методом печати (за исключением когда моторика сбивается и вместо «привет» печатается «ротает» что является смещением на одну букву на клавиатуре левее)
2. В автомобиле всегда смотрю только на дорогу или на любимую девушку справа и никогда на педали (ноги) или ручную коробку передач(руки)
Являюсь только начинающим программистом. Раньше занимался системным администрированием.
Насчет консоли и IDE:
Программирование это не просто набивание символов на клавиатуре что позволяет с легкостью и быстротой выполнять консоль, а еще и поиск по гуглу, стаковерфлоу и другим ресурсам, в некоторых случаях бывает даже копипаст какого-то кода, а потом долгие потуги разобрать его и подогнать под свой проект. А это уже проще делать в ГУИ IDE чем скролить пейдж ап энд даун консольку.
Палка о двух концах.
Вот как раз у Vim одна из самых совершенных систем навигации внутри файла (за исключением штук вроде «перейти к объявлению», не работающих без дополнений). Никаких PageUp/PageDown, работа с Vim вообще не предполагает перемещение рук куда‐либо с основного блока клавиатуры.
Кроме того, зачастую нужно сделать «command|xclip -i» и затем нормально вставлять вывод команды куда угодно средней кнопкой мыши. Можно сразу отправить текст на pastebin. Если вывод длиннее одной строчки, а запуск команды два раза быстр и производит одинаковый текст, то в GUI это будет сложнее сделать. Отдельно про SO: у меня есть
, в Vim можно сделать привязку для того же (а можно просто выделить текст и сделать «>gv>», затем вставить). Интересно услышать, как вы копируете код из GUI.
Копирование откуда‐то ещё тривиальнее.
Кроме того, зачастую нужно сделать «command|xclip -i» и затем нормально вставлять вывод команды куда угодно средней кнопкой мыши. Можно сразу отправить текст на pastebin. Если вывод длиннее одной строчки, а запуск команды два раза быстр и производит одинаковый текст, то в GUI это будет сложнее сделать. Отдельно про SO: у меня есть
alias +4='sed "s/^/ /" | xclip -i', в Vim можно сделать привязку для того же (а можно просто выделить текст и сделать «>gv>», затем вставить). Интересно услышать, как вы копируете код из GUI.
Копирование откуда‐то ещё тривиальнее.
я не очень понял, а как синхронизировать изменения в файловой системе и VCS? Например, я добавил в проект несколько файлов — как не перечисляя поимённо добавить их под контроль VCS? На всякий случай напомню, что IDE это отслеживают.
В целом поддерживаю. Сам разрабатываю в основном в консоли, хотя текст пишу в GUI редакторах. Но grep/find/ls/git всегда под рукой.
Насчёт поиска файлов изменённых за последние N дней. Чаще требуется найти все файлы с некоего коммита. Делается это просто:
Можно указать как commitFrom, например HEAD~5 и получить список файлов изменённых с последних 5 коммитов + если есть не незакомиченные изменения. И если добавить commitTo, то можно ограничить поиск. Например, HEAD. Если нужно сформировать патч и отправить только исправленные файлы в виде архива, можно сделать так:
А если делать подобное подручными графическими средствами? Сколько потребуется телодвижений?
Насчёт поиска файлов изменённых за последние N дней. Чаще требуется найти все файлы с некоего коммита. Делается это просто:
git diff --name-only [commitFrom] [commitTo]Можно указать как commitFrom, например HEAD~5 и получить список файлов изменённых с последних 5 коммитов + если есть не незакомиченные изменения. И если добавить commitTo, то можно ограничить поиск. Например, HEAD. Если нужно сформировать патч и отправить только исправленные файлы в виде архива, можно сделать так:
git diff --name-only HEAD~5 HEAD | xargs zip update.zipА если делать подобное подручными графическими средствами? Сколько потребуется телодвижений?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Unix как IDE: Файлы