переменные окружения в виртуальном терминале

dangerr

Недавно обновил виртуальный терминал. Теперь при запуске строка приветствия баша выглядит как "sh-4.1$" и алиасы из .bashrc не работают пока я не сделаю source /etc/profile && source ~/.bashrc
В обычной консоли всё работает нормально, потом я запускаю startx, а там уже терминал. Всегда считал, что переменные окружения и алиасы наследуются от родительского процесса, а тут получается, что нет. Поэтому не могу понять чем проблема вызвана и кому багрепортить. Проблема усугубляется тем, что этим терминалом пользуются полтора человека, а разрабочики его считают demo-приложением к библиотеке vte. Так что надеяться, что проблема решится сама собой не стоит.

Dasar

> Недавно обновил виртуальный терминал.
если все с нуля поставить, проблема есть или проблемы нет?

Serab

при запуске строка приветствия баша выглядит как "sh-4.1$"
Это должно наводить на мысли :grin: Что запускается он как /bin/sh. Откуда ноги ростут надо выяснять, может в конфигах этого вашего терминала явно задано, что надо запустить. Поэтому он и не читает .bashrc и пр.

dangerr

Что именно всё? Всю систему пересобрать? Или совсем с нуля систему поставить?
В чём принципеальная разница обновления по сравнению с удалением-установкой?

dangerr

Да, видимо так и есть... набрал в текстовой консоли просто sh и увидел такое же приглашение. Но у терминала нет настроек, всё передаётся только через опции командной строки:

vte --help
Usage:
vte [OPTION...] - test VTE terminal emulation

Help Options:
-?, --help Show help options
--help-all Show all help options
--help-gtk Show GTK+ Options

Application Options:
-A, --antialias Disable the use of anti-aliasing
-B, --background Specify a background image
-C, --console Watch /dev/console
-D, --dingus Highlight URLs inside the terminal
-S, --shell Disable spawning a shell inside the terminal
-T, --transparent Enable the use of a transparent background
-2, --double-buffer Disable double-buffering
-a, --audible Use visible, instead of audible, terminal bell
-c, --command Execute a command in the terminal
-d, --debug Enable various debugging checks
-f, --font Specify a font to use
-g, --geometry=GEOMETRY Set the size (in characters) and position
-h, --highlight Enable distinct highlight color for selection
-i, --icon-title Enable the setting of the icon title
-k, --keep Live on after the window closes
-n, --scrollback-lines Specify the number of scrollback-lines
--cursor-blink=MODE Cursor blink mode (system|on|off)
-r, --color-cursor Enable a colored cursor
--cursor-shape Set cursor shape (block|underline|ibeam)
-s, --scroll-background Enable a scrolling background
-t, --termcap Specify the terminal emulation to use
-w, --working-directory Specify the initial working directory of the terminal
--reverse Reverse foreground/background colors
-G, --no-geometry-hints Allow the terminal to be resized to any dimension, not constrained to fit to an multiple of characters
-W, --scrolled-window Use a GtkScrolledWindow as terminal container
-P, --scrollbar-policy Set the policy for the vertical scroolbar in the scrolled window (always|auto|never; default:always)
-N, --object-notifications Print VteTerminal object notifications
--output-file Save terminal contents to file at exit
--pty-flags PTY flags set from default|no-utmp|no-wtmp|no-lastlog|no-helper|no-fallback
--display=DISPLAY X display to use

кстати, несмотря на то, что им пользуется полтора человека, есть он у всех гномеров, так как является бекэндом для gnome-terminal (а также xfce-terminal, lxterminal и многих других).
Печаль в том, что я поставил sakura (один из таких терминалов) и в ней проблема не воспроизвелась. То есть мои опасения, что это никому кроме меня не надо подтвердились....

Serab

ну запускай с ключом -c /bin/bash :grin:
Говоришь загадками :) Нельзя посмотреть лог изменений кода там? Ты же знаешь, между какими версиями изменилось? Ну или просто version history, ну я не знаю короче.

Serab

а, не загадками, vte, что-то от меня эти буквы ускользали.

dangerr

Ну вот тут git-репозиторий:
http://git.gnome.org/browse/vte/
там два бранча: vte-0-24 и vte-0-26. Между ними и было обновление.
Как сравнить их последние версии я не нашёл... хотя боюсь это мало что даст, туда наверное столько всего понакомитили, что это как найти иголку в стоге сена будет....
Сейчас проверил: даунгрейд до 0.24 проблему убирает. Обратный апгрейд - возвращает.

dangerr

Самое печальное, что я уже как-то этим ребятам писал багрепорт.
Они сказали, что это никому не надо, пользуйтесь gnome-terminal и пометили как будто это вообще не баг. :crazy:
http://bugzilla.gnome.org/show_bug.cgi?id=610064
Так что видимо ждать от них милости без указания: вот здесь две буковки подставьте не стоит.... :( :( :(

dangerr

ну запускай с ключем -c /bin/bash :grin:
Ну да, так работает.... только это не значит ли, что он запускает один баш в другом?

Serab

ну это же легко проверить, возьми ps

dangerr

да, точно, я pstree проверил! :)
Не запускает он дополнительный bash

Serab

ну я себе поставил эти две версии, у меня такое же поведение, если тебя это успокоит. Старая причем запускает именно shell пользователя (у меня выбран zsh). Т.е. это очень странно, ладно бы они железный bash заменили на железный sh, так тут вроде бы логично брался шелл пользователя, а стал браться именно sh, т.е. вроде как урезали функциональность.

dangerr

мда, надо попробвать-таки запостить им багрепорт.
Может соизволят исправить :)
Вообще меня гномосеки убивают: им настолько на всё насрать.... нигде с таким отношением не встречался. Я конечно понимаю, что никто никому ничего не должен, но блин... (это не только в отношении этого бага, я и другие туда постил).

Serab

читал?

Serab

ща, я тебе все отдебужу, погоди

Serab

Ну короче, не то, чтобы я все это время дебужил эту прожку (есть и другие дела но вот.
Там у них был большой рефакторинг, они обобщали код, который запускает команды и шеллы. В итоге не смогли справиться, появилась забавная строчка
                        if (command == NULL)
command = "/bin/sh"; // FIXMEchpe

ну блин. Как минимум это можно исправить на

command = vte_terminal_get_user_shell; // FIXMEchpe

Бля, я хз как там эти патчи делать, но вот диффы с гентушной версией 0.26.2:

% for i in *diff; do echo $i && cat $i; done
vteapp.c.diff
988c988
< command = "/bin/sh"; // FIXMEchpe
---
> command = vte_terminal_get_user_shell; // FIXMEchpe
vte.c.diff
3452c3452
< * _vte_terminal_get_user_shell:
---
> * vte_terminal_get_user_shell:
3461,3462c3461,3462
< static char *
< _vte_terminal_get_user_shell (void)
---
> char *
> vte_terminal_get_user_shell (void)
3514c3514
< argv2 = __vte_pty_get_argv(command ? command : (shell = _vte_terminal_get_user_shell
---
> argv2 = __vte_pty_get_argv(command ? command : (shell = vte_terminal_get_user_shell
vte.h.diff
259a260,261
> char* vte_terminal_get_user_shell(void);
>

Тут по сути просто используется их функция, которая у них там появилась как раз в этих новых версиях, изменения в побочных файлах для того, чтобы ее можно было вызвать снаружи. Наверняка это им и не нравилось, потому что типа нарушение инкапсуляции (хотя какое нахуй, функция вполне самодостаточна). В принципе можешь пользовать -c либо железно заменить, либо спросить прямым текстом, что за нахуй в этой строчке, пофиксите этот FIXME, есть же функция get_user_shell...

Serab

ну и если уж ты этой штукой так пользуешься, то прочитай тред из альта, на который я дал ссылку, воодушевись и доведи эту багу до исправления. Потому что (опять же читай тред) мне это не надо. Но вот о результатах напиши тут, хочется узнать, почему они так поступили.
Ну кстати, там кроме этого какие-то баги странные появились, вот у zsh почему-то теперь в этой проге два промта появляются вначале при запуске, с другими шеллами не наблюдается, в старой версии тоже, разбираться не хочу :grin:

Serab

разбираться не хочу
ну, наводки есть, кстати, в старой версии отличается поведение при -c zsh и без параметров, эти вещи делаются по-разному, т.е. новая себя ведет ровно как если бы было -c /bin/sh, а старая как-то похитрее. Глючно у них в этом месте написано в общем.

Serab

// FIXMEchpe
Кстати, Bachan, Что могут значить вот эти буквы на конце: chpe?

dangerr

Блин, чуве, ты крут, меня бы такое заломало :cool:
Спасибо, я тогда займусь политической стороной вопроса (проведением патча в апстрим).

dangerr

Хм, вообще говоря vte.c - это часть уже самой библиотеки. Её изменения точно туда не примут (я бы сам не принял :) ). Это сломает ABI, а существует много других терминалов использующих эту библиотеку.
Я наверное признаюсь: я не очень хорошо знаю Си :(
Что дало убирание нижнего подчёркивания у функции?
static char * нелья привести к char * (или какой там тип у переменной command, я вообще не нашёл где она объявляется) ?
И вообще как ты скомпилил свои изменения потом? Обратно запаковал в архив и положил в distfiles?

serega1604

>Хм, вообще говоря vte.c - это часть уже самой библиотеки.
ващет FIXME и /bin/sh - в vteapp.c, а это вряд ли библиотека, скорее всего как раз твой терминал.

Dasar

>Кстати, Бачан! Что могут значить вот эти буквы на конце: chpe?
ник чела?

dangerr

Помимо изменений в vteapp.c там есть изменения в vte.c, а это библиотека. То есть изменения связаны с изменением её ABI. Если такой патч подсунуть гномеру, то у него может не работать после этого gnome-terminal.

serega1604

ты может не понял? я не предлагал менять vte.c, я предлагал сделать изменения в vteapp.c в соответсвии с изменениями vte.c
а вообще подчеркивание в начале названия переменной/функции вроде как обычно обозначает, что этим пользоваться не стоит, (и из хидеров её убрали, что тоже символизирует).

dangerr

Насколько я понимаю, если функции нет в h-файле, то её использовать извне и нельзя.

serega1604

с чего это вдруг?

dangerr

Как я уже говорил, Си я знаю не очень, так что... ни с чего...
В любом случае мы с тобой говорим об одном и том же. Я спросил у именно то как бы сделать так, чтобы менять vte.c не пришлось, а только vteapp.c
Ты же на это говоришь, что vte.c менять не надо. А я и так знаю, что не надо, но в патче-то он меняется!

Serab

Это не static char*, это static вся функция: ее имя не экспортируется, поэтому ее нельзя использовать снаружи, из других единиц компиляции (.c файлов). Поэтому я ее и вынес. Ну я так и написал, что они, скорее всего, поэтому и написали FIXME, что не хотят так напрямую эту функцию вызывать, хотя функция — общего назначения. Ладно, может получше способ придумаю, но тут два варианта: 1) править vte.c без правки vte.h и следовательно ABI, они так точно сами хотят сделать; 2) скопировать эту функцию в vteapp.c: будет дублирование кода этой функции, а со временем все равно сделают по пути 1) и надо будет удалять обратно.
Компилирую командой ebuild. Делаешь ebuild /usr/portage/.../....ebuild unpack, идешь в /var/tmp/portage/..../work/.../ там правишь, потом ebuild /usr/portage/.../..../ compile install qmerge. Ну там я еще не особо привык, там какая-то лажа с правами и еще файлы .compiled и .installed надо удалять, иначе он перекомпилять при изменениях не хочет.

Serab

Хотя все-таки нет. Тот способ у них как раз deprecated. Типа они теперь хотят, чтобы библиотечке давали команду, а она ее выполняла, без лишнего автоматизма. Т.е. надо реально скопировать ту функцию, которая определяет пользовательский шелл, в vteapp.c, стопудово. А из vte.c ее (теоретически) должны удалить. Ну как теоретически, deprecated — могут удалить :grin: Поэтому надо тупо сделать так:
% cat vteapp.c.diff
30a31
> #include <pwd.h>
536a538,579
> /*
> * _vte_terminal_get_user_shell:
> *
> * Uses getpwd to determine the user's shell. If that fails, falls back
> * to using the SHELL environment variable. As last-ditch fallback, returns
> * "/bin/sh".
> *
> * Returns: a newly allocated string containing the command to run the
> * user's shell
> */
> static char *
> _vte_terminal_get_user_shell (void)
> {
> struct passwd *pwd;
> char *command;
>
> pwd = getpwuid(getuid;
> if (pwd != NULL) {
> command = g_strdup (pwd->pw_shell);
> _vte_debug_print(VTE_DEBUG_MISC,
> "Using user's shell (%s).\n",
> command ? command : "(null)");
> }
> if (command == NULL) {
> if (g_getenv ("SHELL" {
> command = g_strdup (g_getenv ("SHELL";
> _vte_debug_print(VTE_DEBUG_MISC,
> "Using $SHELL shell (%s).\n",
> command);
> } else {
> command = g_strdup ("/bin/sh");
> _vte_debug_print(VTE_DEBUG_MISC,
> "Using default shell (%s).\n",
> command);
> }
> }
>
> g_assert (command != NULL);
>
> return command;
> }
>
988c1031
< command = "/bin/sh"; // FIXMEchpe
---
> command = _vte_terminal_get_user_shell; // FIXMEchpe

Теперь метод убеждения немного изменился: типа пофигсите этот FIXME, бла-бла, есть же функция, но так как перешли на vte_terminal_fork_command_full, то теперь из либы с этим помощи ждать не приходится, надо получать шелл из vteapp.c, дальше либо копировать эту функцию, либо перемещать в какое-то общее место. Типа хорошего общего места не нашлось. А так как она нужна только для deprecated-функций, то вроде можно и скопировать. Но не нравится мне это, конечно (т.е. люди и сами бы до такого додумались, но все равно напиши багрепорт, это же FIXME, может чего и решат там в обсуждении) :grin:

sergey_m

если все с нуля поставить, проблема есть или проблемы нет?
Старая windows-школа :lol:

Serab

бугага, а я заинтересовался этим эмулятором!
Vte is different from other terminal emulators in that instead of hard
coding behavior of a few select terminals, it can emulate any terminal
simply by reading its terminfo capabilities file. The idea being that
if applications can communicate with any terminal by reading its
capabilities, the emulation widget can also behave like any terminal by
reading that file. Well, that's just the idea :).
А ты им пользуешься только из-за легковесности (хотя судя по описанию легковесность условная)?

dangerr

А ты им пользуешься только из-за легковесности (хотя судя по описанию легковесность условная)?
Я им пользуюсь из-за того, что он самый легковесный из vte-based. А только в vte-based терминалах (из всех, что я проверял) не съезжают хоткеи.

Serab

съезжают хоткеи.
куда? :grin:
rxvt-unicode forever!

dangerr

ctrl-c на ctrl-i например съезжает.
Мы по-моему как-то с тобой этот вопрос здесь обсуждали. Ты считаешь странным хотеть одновременно удобных хоткеев и удобную раскладку. Я же хочу всего сразу :)
В результате мирюсь с большим количеством других неудобств, но это уже нюансы :grin:

Serab

ну да, т.е. ты все еще хочешь, чтобы на двораке ^C был как ^J?

BondarAndrey

Ну да, так работает.... только это не значит ли, что он запускает один баш в другом?
exec bash

Serab

а он там писал в треде про багрепорт про команды с параметрами. Хотя вроде вот я в коде видел вызовы g_shell_parse_argv, так что можно постетить, может и заработало. Ну т.е. exec-то уже не должен заработать, потому что exec — это builtin и чтобы его вызвать надо запускать какой-то шелл. Ну хотя можно в скрипте навернуть, да...

apl13

Ы-ы-ы. Я придумал способ, как все чинить. Если у вас что-то не работает, то:
если у вас установлена Windows(rtm перезагрузиться. Если не работает, переустановить. Если все равно не работает, купить другой компьютер;
если у вас установлена GNU/Linux. То. Раздобыть исходники не работающей программы и грепать в них слово FIXME. Найденное пофиксить;
FIXME: если у вас установлена другая ОС, то кинуть ексепшен.

Serab

ну не всегда же места помечены FIXME. Кстати, я грепал не FIXME, а /bin/sh :grin:

dangerr

Разобрался с применением и компиляцией - проверил, всё работает!
Создал баг http://bugzilla.gnome.org/show_bug.cgi?id=640179
Им конечно тут же не понравился формат патча :grin:
Ещё сказали, что либа никогда эту функцию не экспортировала, теперь я читаю исходники старой версии, пытаясь понять как было сделано там...
А вот это
 
It returns a new string, so this patch leaks it.
Я вообще не понял. Само собой возвращается новая строка, как же иначе-то? :confused:

Serab

Ещё сказали, что либа никогда эту функцию не экспортировала, теперь я читаю исходники старой версии, пытаясь понять как было сделано там...
ну да, не экспортировалась, ну ты же сказал, что они не захотят ее экспортировать, хотя там есть баг (на него дали ссылку).
It returns a new string, so this patch leaks it.
ну даа, надо делать в конце free, потому что там выделяется память для строки. Я об этом подумал, но забыл написать. В общем, у них в эту сторону есть мысли, я думаю, поправят скоро.

dangerr

ну ты же сказал, что они не захотят ее экспортировать
А ты сказал, что тот способ deprecated.
Не, ну если захотят, то ещё проще.
ну даа, надо делать в конце free, потому что там выделяется память для строки. Я об этом подумал, но забыл написать. В общем, у них в эту сторону есть мысли, я думаю, поправят скоро.
а, ну да, в си же пипец с памятью :) Я совсем забыл
Ну тогда видимо в конец блока if (shell) {} (978-1014 строки) на 1013 строку поставить free(command м?

Serab

ну да

Serab

А ты сказал, что тот способ deprecated.
Не, ну если захотят, то ещё проще.
вот именно, что есть два способа, у каждого свои недостатки, пускай сами решают.

dangerr

Хорошо, значит добавлю в твой первый патч освобождение памяти и попробую его оформить в формате гита. :)

Serab

Ну для этого надо сделать git clone, применить туда мой патч командой diff (желательно на ту же ветку) и вызвать соответствующую команду (с git работал только в теории).

Serab

Но вряд ли это им уже нужно, потому что патч по первому пути есть во втором баге, а вторым путем они идти не хотят.

dangerr

Ну там только для экспорта этой функции. Так что надо ещё и для vteapp.c, чтоб они не забыли. :)

Filan

Создал баг http://bugzilla.gnome.org/show_bug.cgi?id=640179
Им конечно тут же не понравился формат патча :grin:
А diff -u не пробовал? Не думаю, что в git что-то "более лучшее" придумали.

tokuchu

А diff -u не пробовал? Не думаю, что в git что-то "более лучшее" придумали.
Может они там и не diff вызывают, но формат именно такой, да.

dangerr

Может они там и не diff вызывают, но формат именно такой, да.
То есть отсылать им пачти в формате diff -u и не будет никто жаловаться на формат?

Filan

То есть отсылать им пачти в формате diff -u и не будет никто жаловаться на формат?
Это я всего лишь предположил, т.к. почти везде именно Unified diff формат используется.

Filan

Может они там и не diff вызывают, но формат именно такой, да.
Думаешь стали изобретать велосипед? Или просто вырезали кусок из diff, и добавили его в git?

germafrodita

слишком крутой тред
чото даже не верится как-то

ava3443

у них должна быть четкая процедура приема патчей, поищи её.

tokuchu

Думаешь стали изобретать велосипед? Или просто вырезали кусок из diff, и добавили его в git?
Ну хз как оно на самом деле — меня это сейчас мало волнует. :)
Просто у них там специфические потребности есть вроде разрешения конфликтов и т.п., поэтому не исключено, что может быть своя реализация.
Оставить комментарий
Имя или ник:
Комментарий: