SCRIPT_PATH=$(cd $(dirname $0); pwd -P)
2015-01-25, Хрень
2015-01-25, Хрень
function console.log { echo "$(date +'[%Y-%m-%d %H:%M:%S]') $1"; }
unzip
for file in `ls *.zip`; do unzip $file -d `echo $file | cut -d . -f 1`; done
unrar
for file in `ls *.rar`; do mkdir `echo $file | cut -d . -f 1`; unrar x $file `echo $file | cut -d . -f 1`; done
WARNING: с пробелами в именах файлов у нас пока что проблемы.
2015-01-04, Хрень
Стандартные рецепты из гугла почему-то не сработали. Чтобы найти скрипт, рассылающий спам, воспользовался командами:
exim -bp # Выводит список писем в очереди на отправку exim -Mvh XXXXXX-XXXXXX-XX # Выводит заголовок письма по его ID exim -Mvb XXXXXX-XXXXXX-XX # Выводит тело письма по его ID exim -Mvl XXXXXX-XXXXXX-XX # Выводит лог письма по его ID
2015-01-04, Хрень
exim -bp|grep -o '[0-9a-zA-Z]\{6\}-[0-9a-zA-Z]\{6\}-[0-9a-zA-Z]\{2\}'|xargs -L1 exim -Mrm
2014-08-19, Хрень
for i in {1..10}; do dig +trace site.ru -tANY; done
Ошибка
Can't open file '/root/.subversion/servers'
возникла у меня из-за того, что пользователь, под которым я пытался запустить svn (из php скрипта) не имел доступа к шеллу. Команда su username при этом просто не выполнялась. Дело было под FreeBSD.
Хотя, нет. Не из-за этого. Или частично из-за этого. Поскольку под шеллом команда стала выполняться, а из-под апача все равно нет. Пришлось добавить параметр
--config-dir /home/username/data/.subversion
чтобы эта хрень заработала как надо. Подробности тут.
Apache / mod_python doesn't read in shell environment of the user account which apache is running on. Thus for examle no $HOME is seen by mod_python when apache is running under some real user ( not nobody )
Now 'svn co' has a flag --config-dir which points to configuration directory to read params from. By default it is $HOME/.subversion, i.e. it corresponds to the user account home directory. Apparently when no $HOME exists mod_python goes to root home dir ( /root) and tries to fiddle with .subversion content over there - which is obviously fails miserably.
2013-06-01, Рекомендую
.bashrc
genpwd()
{
openssl rand -base64 $1|tr -d '\n'|{ read in; echo ${in:0:$1}; }
}
Пример использования:
$ genpwd 8
vBu8waCQ
$ genpwd 16
heitMPgrsMgKR1yk
2013-04-24, Ошибок причины
Только больной мудак мог придумать, что по команде
php script.php arg1 arg2 /path/to/files/* arg4
скрипт получит в $argv хуеву тучу аргументов и arg4 будет находиться не в $argv[4], а в $argv[10393]. Это мог придумать только больной мудак. Нет, я бы еще мог понять, если б bash выполнял скрипт построчно. Пофайлово. Я бы еще мог понять. Но вот это - это просто пиздец. Ну отдай, отдайт ты этот ёбаный /path/to/files/* в программу в конце концов, пусть она сама вызовет glob и прочешет директорию как ей надо. Два часа я искал ошибку в своем коде, даже не предполагая что блядь такое ВОЗМОЖНО. Логика? Здравый смысл? Не, не слышали.
2013-01-21, Ошибок причины
UPD: новое решение, украденное со стаковерфлооу.
gnome-terminal --execute /bin/bash -c "/bin/bash /home/space1000/horse_fucking_a_parrot.sh; exec /bin/bash -i"
Старый текст поста:
Как оставить gnome-terminal открытым после выполнения программы? Очень простым и очевидным даже самому глупому юзеру путем:
1. Создать файлик keep_terminal_open.sh
2. Дать ему права на выполнение в качетсве программы.
3. Впендюрить туда следующий текст:
#! /bin/sh
$1
bash
4. Вызывать нужную команду примерно таким образом (в моем случае это node.js)
cmd = 'gnome-terminal --execute '
+ __dirname + '/keep_terminal_open.sh '
+ '"node ' + __dirname + '/runme.js"'
console.log(cmd)
require('child_process').exec(cmd)
в bash это выглядит примерно так:
gnome-terminal --execute /home/user/test616/keep_terminal_fucking_open.sh "node /home/user/test616/runme.js"
5. Радоваться полчаса. А все потому, что gnome-terminal косячный, хоть и очень красивый.
Roses are red
Violets are blue
The title is in English...
Use google translate, you!