Posts Tagged → shell

Pip, update all

Хотелось бы, да? А нету. Нашлось вот такое решение:

import pip
import sys
from subprocess import call

def pip_ver():
    if sys.version_info.major == 3:
        return "pip3"
    else:
        return "pip"

cmd_line = pip_ver() + " install --upgrade "

for dist in pip.get_installed_distributions():
    call(cmd_line + dist.project_name, shell=True)

Использовать просто:

python script_name.py

Делать файл исполнимым не стал, т.к. при явном вызове Python можно указать нужную версию 2.X или 3.X

Переменные окружения в OSX

Отловил странный то ли глюк, то ли фичу. Изначальная задача следующая: необходимо добавить переменные окружения таким образом, что бы они были доступны всем запускаемым процессам, т.е. не только тем, что были запущены из командной строки, но и UI-приложениям.

Стандартный путь довольно прост: необходимо вписать в файл /etc/launchd.conf новые пути, следующим способом.

setenv PATH /new/path/a:/new/path/b

Собственно, я так делал всегда и все было нормально. Но, внезапно, а может и не очень, к примеру после какого-то обновления, ряд приложений (тот же Eclipse и Wireshark) перестал видеть что-либо за пределами переменных, прописанных в /etc/launchd.conf. В итоге, по мнению этого ряда приложений “исчезло” все, VJM, dir, ls да совсем-совсем все.

Гугла подсказала, что пользовательские переменные, которые должны стать доступны всем, можно добавить еще в пару файлов, например в /private/etc/paths. Формат файла прост: одна линия – один путь.

/new/path/a
/new/path/b

Clear Case –> Git

Во время работы в ЛК мне казалось, что Perforce это одно из воплощений Песца на земле. Ну что сказать, я сильно ошибался, и теперь, видимо в наказание за мои заблуждения, мне приходится работать с Clear Case. Причем, типичная тут схема работы это основная машина на Венде, на которой разработчик все пишет и сборочная машина на Linux. Доступ к исходникам осуществляется посредством шареных сетевых папок. В целом схема рабочая, но, во-первых, сборка идет довольно медленно, во-вторых, сборку приходится периодически перезапускать из-за сетевых ошибок, таких как broken pipe, input/output error.
Вдоволь намучившись с подобной работой я решил что так дальше жить нельзя и надо что-то делать. Самым лучшим вариантом, пришедшим мне в голову, оказалось использование Git для собственного контроля версий в процессе разработки.
Continue reading →

Синхронизация рабочих настроек

На всех своих рабочих/домашних UNIX* машинах я использую одни и те же конфигурационные файлы для VIM-a, Gdb, Zsh и прочего. После того как в один из них вносится изменение, хочется “легко и изящно” получить его на всех остальных машинах. С учетом того, что облачные хранилища получили очень широкое распространение, это сделать проще простого. Пишем небольшой bash скрипт и добавляем его в cron:

#!/bin/sh
# set -x-
FLAGS=-lzuogthvr
SYNC_LIST=".vim .vimrc .gdbinit .gdb_stl .zshrc confsync.sh"
SOURCE_DIR=~
EXCLUDE_LIST=""
EXCLUDE_COMMAND=""

if [ -z "$BACK_UP_DIR" ]; then
    BACK_UP_DIR=~/Dropbox/backup/
fi

if [ ! -d "$BACK_UP_DIR" ]; then
    mkdir "$BACK_UP_DIR"
else
    rsync $FLAGS --update --progress $BACK_UP_DIR/ $SOURCE_DIR
fi

for s in $EXCLUDE_LIST; do
    EXCLUDE_COMMAND="$EXCLUDE_COMMAND --exclude "$s""
done

for d in $SYNC_LIST; do
    rsync $FLAGS --update --progress $d $BACK_UP_DIR $EXCLUDE_COMMAND
done

Ищем быстро. Очень быстро.

Незнаю кто как, но я обычно пишу код в Vim, отлаживаюсь в GDB, ищу Grep. Если первые два пункта не вызывают никаких нареканий, но вот Grep на больших объемах данных, например на проекте с 1GB исходных кодов, несколько нерасторопен.
Решение проблемы довольно простое: надо скрестить Spotlight с Grep и получить шустрый и удобный в работе механизм. Для zsh это можно сделать так:

g()

{
mdfind -onlyin . $1 -0 | xargs -0 grep -n --color=always $1
}