[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy regarding /etc/profile.d



On 15/10/14 00:17, Santiago Vila wrote:
> etc/profile.d/vte.sh                                    libs/libvte-2.90-common
> etc/profile.d/vte-2.91.sh                               libs/libvte-2.91-common

These ones, at least, are for non-essential functionality: the "New
Window" and "New Tab" options in gnome-terminal are meant to chdir() to
the same place as the current tab's shell before they execute the new
shell, and vte obtains this information by altering the shell prompt to
include an escape code that tells it the current directory. People
complain when this stops working, so it's obviously a desired feature,
but at the same time its absence doesn't break the terminal.

(In principle perhaps vte on Linux could use /proc/$shell_pid/cwd for
this, but that's not what upstream implemented, and it probably differs
in some corner cases.)

> etc/profile.d/bash_completion.sh
shells/bash-completion

How else should bash-completion hook into shell startup? By adding
specific knowledge of bash-completion to the bash package?

> Do we need a paragraph in policy saying explicitly "you should not use profile.d"?

For some packages, like bash-completion and
packagekit-command-not-found, the whole point of the binary package is
to hook into shell startup and reconfigure the shell. What would you
suggest that they should do instead?

    S


Reply to: