Все возможно. Этими алиасами пользуюсь уже больше трех лет и никаких конфликтов ). Ваш подход тоже рабочий и очень даже практичный. Но немного больше настроек.
Алиасы для Git, кстати, можно задавать в настройках самого Git.
Упоминал про это в статье "Еще есть файл под названием .gitconfig, в который можно добавлять алиасы для работы с git.". Не стал расписывать, чтобы не перегружать статью.
P.S. Ваш алиас 'gbd' весьма опасен. Захотите вы запустить отладчик, а вместо этого нечаянно удалите ветку (да ещё и с -D)
Привык пользоваться этой директорией на удаленном сервере. По поводу остальных, что вы назвали затрудняюсь ответить. Подозреваю, что некоторые из них могут быть ограничены по правам.
И зачем делать скрипт, вызывающий другой скрипт, есть же символические ссылки?
Хм, интересный вопрос. С такой ссылкой останется тот же функционал, что я описал в статье?
Да, согласен, есть такое. Но если у вас есть права на запись в файл .bashrc и на удаленном сервере все навтроено верно (каждый пользователь со своими настройками), то не составляет труда перенести туда свои алиасы. Я так и сделал. И не испытываю неудобств
Полностью согласен с вами, что это опасно ) И вы правильно заметили по поводу флага, типа --all и help. Почти так оно сейчас и работает. На хотел перегружать пример лишним кодом. Мне хотелось, чтобы читатель заметил, где можно сделать лучше и что можно еще больше оптимизировать, защитить и т.д. Вы заметили — значит все круто.
Да, вы правы, работает с расширением и можно весь код запихнуть в этот файл. Без расширения, чтобы обращение к файлу выглядело как команда, а не выводило мне всякий раз расширение. По поводу положить весь код в файл gdd. Не делаю так из соображений организации кода. Все подобные файлы располагаются в директории tools, а те файлы которые отвечают за их вызов в директории bin. Плюс ко всему, директория tools находится под git'ом.
Спасибо за перевод. Хорошая статья. Думаю, что первое на что нужно обратить внимание — это пересмотреть количество JavaScript кода, который отдается клиенту. Уверен, что такое простое действие сможет помочь в оптимизации. А дальше уже можно прибегать к тем техникам, что описаны в статье.
По поводу кавычек вы правы. Хотя и спорный вопрос. Тут можно растянуть обсуждение надолго. Если кратко, то желательно использовать двойные кавычки ("") при обращении к переменным. Это предотвратит интерпретацию специальных символов, которые могут содержаться в именах переменных, за исключением $, ` (обратная кавычка) и \ (escape — обратный слэш).
Но опять же, в данном, конкретном случае — это лишнее
Добрый день, Роман.
Спасибо за статью. А скажите, вы делали данный kit на основе уже какого-то существующего или сами верстали, дизайнили, писали js?
Добрый день.
Все возможно. Этими алиасами пользуюсь уже больше трех лет и никаких конфликтов ). Ваш подход тоже рабочий и очень даже практичный. Но немного больше настроек.
Добрый день, Денис.
Спасибо. Этот момент упустил. Обновил статью.
Добрый день, Дмитрий.
Упоминал про это в статье "Еще есть файл под названием
.gitconfig, в который можно добавлять алиасы для работы сgit.". Не стал расписывать, чтобы не перегружать статью.Пока живем с ним мирно =)
Спасибо за замечания. Поправил
Это только мое предположение. Всегда пользовался домашней директорией пользователя
~/bin. Да, ее явно нужно добавлять в$PATH.Да, вы правы, все работает. Только что перепроверил. Спасибо.
Добавлю этот пункт в статью
Может у меня с кармой что-то не так, но без перезапуска не рабоает
Добрый день, Николай.
Привык пользоваться этой директорией на удаленном сервере. По поводу остальных, что вы назвали затрудняюсь ответить. Подозреваю, что некоторые из них могут быть ограничены по правам.
Хм, интересный вопрос. С такой ссылкой останется тот же функционал, что я описал в статье?
Добрый день!
Да, согласен, есть такое. Но если у вас есть права на запись в файл
.bashrcи на удаленном сервере все навтроено верно (каждый пользователь со своими настройками), то не составляет труда перенести туда свои алиасы. Я так и сделал. И не испытываю неудобствПолностью согласен с вами, что это опасно ) И вы правильно заметили по поводу флага, типа
--allи help. Почти так оно сейчас и работает. На хотел перегружать пример лишним кодом. Мне хотелось, чтобы читатель заметил, где можно сделать лучше и что можно еще больше оптимизировать, защитить и т.д. Вы заметили — значит все круто.Добрый день, Алексей.
Да, вы правы, работает с расширением и можно весь код запихнуть в этот файл. Без расширения, чтобы обращение к файлу выглядело как команда, а не выводило мне всякий раз расширение. По поводу положить весь код в файл
gdd. Не делаю так из соображений организации кода. Все подобные файлы располагаются в директорииtools, а те файлы которые отвечают за их вызов в директорииbin. Плюс ко всему, директорияtoolsнаходится под git'ом.Добрый день.
Спасибо за перевод. Хорошая статья. Думаю, что первое на что нужно обратить внимание — это пересмотреть количество JavaScript кода, который отдается клиенту. Уверен, что такое простое действие сможет помочь в оптимизации. А дальше уже можно прибегать к тем техникам, что описаны в статье.
Добрый день, Дарья.
Прочитал несколько раз статью в поисках полезностей. Увы, не нашел. Вы же для хабра пишите.
Наверное опечатка в имени?
Полностью поддерживаю!
Нет уж, извольте
"") при обращении к переменным. Это предотвратит интерпретацию специальных символов, которые могут содержаться в именах переменных, за исключением$,`(обратная кавычка) и\(escape — обратный слэш).Но опять же, в данном, конкретном случае — это лишнее
Добрый день.
Спасибо за ваш комментарий. Добавил в статью упоминание об этом.
Вы частично правы по поводу не используемых знаний. Но это больше мой недочет по тексту. На самом деле, полученная строка дальше и используется
Добрый день, Николай.
Спасибо за ваш комментарий.
Чтобы узнать где находится сам bash
Обновил
Да с
if, whileнемного незадача вышла. Хотя на разных ресурсах предлагаю по-разному. И тот же Google рекоммендуетifв разных вариацияхДобрый день, Владислав.
Спасибо за ваш комментарий. В данном конкретном примере это не критично. Что вас не устроило ?