Jeremie Courreges-Anglas kirjoitti 10/31/17 klo 16:23:
> On Mon, Oct 30 2017, Lari Rasku <lari.ra...@elisanet.fi> wrote:
>> or how it might be worked around.
>
> case $- in *i*) ...;; esac
>
> See /etc/ksh.kshrc.
Thanks, this spares me some irritation.
> ENV is checked on purpose. Whether it should use sh -i is another
> question.
Having plucked the courage to read the security source - if the goal is
to inspect root's login environment, it would seem more straightforward
to just run `ksh -lic 'echo PATH=$PATH; umask'` than to programmatically
determine the files it sources and then analyze them individually. But
perhaps it's done this way for a reason.
Another way to "fix" this issue would be just to remove the warnings in
ksh. Looking at the code, the "cannot bind, not a tty" print is
controlled by a x_tty flag with no other purpose, set unconditionally in
x_init_emacs():
$ cd /usr/src/bin/ksh; grep -C2 x_tty *.c
emacs.c-static int xlp_valid;
emacs.c-/* end from 4.9 edit.h } */
emacs.c:static int x_tty; /* are we on a tty? */
emacs.c-static int x_bind_quiet; /* be quiet when binding
keys */
emacs.c-static int (*x_last_command)(int);
--
emacs.c- char in[LINE + 1];
emacs.c-
emacs.c: if (x_tty == 0) {
emacs.c- bi_errorf("cannot bind, not a tty");
emacs.c- return (1);
--
emacs.c-x_init_emacs(void)
emacs.c-{
emacs.c: x_tty = 1;
emacs.c- ainit(AEDIT);
emacs.c- x_nextcmd = -1;
Where x_init_emacs() is called through x_init() if the shell is
interactive. This looks like vestigial code, since the kb_add()s in
x_init_emacs() go through just fine whether a tty is attached or not.
I can prepare a patch for this if desired.
