Проблема возникла уже давненько, сейчас вот решил разобраться, и ничего не смог найти в сети, так что обращаюсь за помощью к сообществу.
Используется lubuntu 10.10, правда несколько модифицированная, в плане состава софта и так по мелочам. Суть проблемы в следующем, для примера:
1
2
3
4
5
6
7
|
$ xdg-mime query filetype incoming/gridwars_lin.zip
application/zip; charset=binary
$ xdg-mime query default application/zip
file-roller.desktop
$ xdg-open incoming/gridwars_lin.zip
Warning: unknown mime-type for "/usr/share/applications/file-roller.desktop" -- using "application/octet-stream"
Error: no such file "/usr/share/applications/file-roller.desktop" |
Далее, как я понял, запускается sensible-browser, в данном случае это опера, которая предлагает открыть этот файл в программе на выбор.
При этом файл, который согласно ошибке "не найден" на самом деле существует:
1
2
|
$ ls -la /usr/share/applications/file-roller.desktop
-rw-r--r-- 1 root root 1567 2010-09-28 02:51 /usr/share/applications/file-roller.desktop |
Причём xdg-open так работает почти для любых типов файлов.
Помогите люди добрые, ежели кто знает в чём тут может быть дело.
Update. Нашёлся баг-репорт с патчем, где всё это исправлено. Заодно оформил баг-репорт на ланчпаде. Как оказалось, скрипт чувствителен к GREP_OPTIONS, сообщил об этом разработчикам.
-
xdg-open обычный шелл скрипт, попробуйте протрейсить и посмотреть где спотыкается. Как-нибудь так:
sh -x `which xdg-open` incoming/gridwars_lin.zip
-
-
Ага, спасибо большое. Но яснее не стало. Смотрите, вот код относящийся к делу:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
for x in `echo "$xdg_user_dir:$xdg_system_dirs" | sed 's/:/ /g'`; do
file="$x/applications/$default"
if [ -r "$file" ] ; then
command="`grep -E "^Exec(\[[^]=]*])?=" "$file" | cut -d= -f 2- | first_word`"
command_exec=`which $command 2>/dev/null`
if [ -x "$command_exec" ] ; then
$command_exec "$1"
if [ $? -eq 0 ]; then
exit_success
fi
fi
fi
done |
А вот фрагмент трейса, полученного через sh -x:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
+ echo /home/tigr/.local/share:/etc/xdg/lubuntu:/usr/share/Lubuntu:/usr/local/share/:/usr/share/:/usr/share
+ sed s/:/ /g
+ file=/home/tigr/.local/share/applications/file-roller.desktop
+ [ -r /home/tigr/.local/share/applications/file-roller.desktop ]
+ file=/etc/xdg/lubuntu/applications/file-roller.desktop
+ [ -r /etc/xdg/lubuntu/applications/file-roller.desktop ]
+ file=/usr/share/Lubuntu/applications/file-roller.desktop
+ [ -r /usr/share/Lubuntu/applications/file-roller.desktop ]
+ file=/usr/local/share//applications/file-roller.desktop
+ [ -r /usr/local/share//applications/file-roller.desktop ]
+ file=/usr/share//applications/file-roller.desktop
+ [ -r /usr/share//applications/file-roller.desktop ]
+ file=/usr/share/applications/file-roller.desktop
+ [ -r /usr/share/applications/file-roller.desktop ]
+ [ -f /etc/debian_version ] |
Последняя строчка - это уже произошёл выход из процедуры, уже выполнение вернулось в предыдущую процедуру. Далее он уже начинает пытаться сделать с файлом "хоть что-то", и это "хоть что-то" выливается в итоге в запуск sensible-browser.
Почему на предпоследней строчке трейса он не входит в условие я не понял. Если в sh сделать
if [ -r /usr/share/applications/file-roller.desktop ]; then echo working; fi;
то всё работает.
Что-то я перестал что-либо понимать. Права на файле: -rw-r--r--, всё должно читаться любым пользователем системы...
Как такое вообще возможно?
-
-
Гм, действительно непонятно. Предлагаю рандомные танцы с бубном:
for shell in bash dash;do $shell `which xdg-open` incoming/gridwars_lin.zip; done
Попробовать заменить в xdg-open некорректно срабатывающее условие на -f или -e.
-
-
Всё попробовал, всё бесполезно. Втыкал в цикл ls, cat. cat не может найти файл. ls - если показывать только директорию, то она показывается, файл в ней виден. А если указывать прямой путь к файлу, то его словно нет. -f -e - ноль эмоций. whoami запущенный внутри процедуры показывает, что работает от моего пользователя.
Зато sudo xdg-open работает.
-
strace -e trace=file sh -vx `which xdg-open` incoming/gridwars_lin.zip
-
-
Есть!
1
2
3
|
+ file=/usr/share/applications/file-roller.desktop
+ [ -r /usr/share/applications/file-roller.desktop ]
stat64("/usr/share/applications/\33[m\33[Kfile-roller.desktop", 0xbf844600) = -1 ENOENT (No such file or directory) |
Вот так работает:
GREP_OPTIONS="" xdg-open incoming/gridwars_lin.zip
Поменял GREP_OPTIONS="--color=always" на auto, сообщил разработчикам о чувствительности к GREP_OPTIONS.
-
-
Знаете, это не бага, а сочетание не совсем корректных конфигов.
- Выставляя color=always надо понимать, к чему это вообще может приводить
- Стандартный убунтовый ~/.bashrc реализует расцвечивание grep'а через
alias grep='grep --color=auto'
При задании --color=always через alias проблема бы не возникла
- Полагаю, GREP_OPTIONS вы задавали в ~/.bashrc. Вроде бы предполагается, что для гуёвых программ source ~/.bashrc не должен происходить, по крайней мере так стал себя вести мой арч после какого-то апдейта. Окружение для иксовых прог задаётся в ~/.xprofile. Видимо на проблему вы наткнулись при работе с какими-то иксовыми прогами, а значит или лубунту у вас некорректно по-умолчанию сорсит для иксовых программ ~/.bashrc, или вы сами как-нибудь добились такого неканоничного поведения, например, прописыванием source ~/.bashrc в ~/.xprofile. В каноничном случае проблема опять-таки не возникла бы
-
-
Интересно, что во многих скриптах встречается unset GREP_OPTIONS (типа того же apt).
1. По идее, это ни к чему не должно приводить. Если бы это было иначе, в мане грепа было бы предупреждение.
2. Не знаю как сейчас, но эту строчку в .bashrc я добавил ещё тогда, когда дефолтный .bashrc в Ubuntu был почти пустым, и подсветки там точно не было.
3. У меня .xprofile вообще не существует. Но вообще нет, в этом отношении я тут ни с чем не шаманил. Значит, это глюк Lubuntu?
-
-
Занятно, я когда писал предыдущий комментарий во многом исходил из того, что unset GREP_OPTIONS в скриптах не встречается, даже проверил, сделав grep -iR GREP_OPTIONS /etc/rc.d.
- Да вот как раз примерно к тому, на что вы наткнулись, и приводит:
1
2
|
$ for coloring in --color={always,auto}; do echo 'abcdef' | grep $coloring bcd | grep def; done
abcdef |
Если бы не приводило, то abcdef напечаталось 2 раза
- Упоминая про дефолтное содержимое ~/.bashrc я хотел сказать, что гуру считают раскрашивание через alias более правильным. Плохо выразился.
- Кроме ощущения, что "это как-то не совсем правильно", у меня нет оснований утверждать, что сорсинг ~/.bashrc для иксовых прог - баг.
-
-
Ясно. Тогда, видимо, я ССЗБ, и, видимо, единственная проблема в том, что в мане нет предупреждения.
Насчёт "многих скриптов" я погорячился. В нескольких встречается.
|
|
|
  |
|
Последние посты
|
|
|
Последние комментарии
|
|
|
Изменения
|
   |
|
Черновики (все)
|
|
|
Избранное (всё)
|
|
|
Есть проблема! — [решено] xdg-open в lubuntu не находит .desktop файлы
