Re: *term -ls, a summary

[Isaac To <kkto@csis.hku.hk>]

>>>>> "Ian" == Ian Zimmerman <itz@speakeasy.org> writes:

    Isaac> Consider pdmenu.  If one runs a program in X using pdmenu, X has
    Isaac> already created the login environment, so there is no need to
    Isaac> re-initialize things.

    Ian> No, not in general.  It depends on your .xsession file, just like
    Ian> the ssh case depends on your .ssh/environment file.

Then your .xsession is broken.  Your shell created with Emacs will have
wrong setting, you will have no choice than to execute login shell in X
terminals, your http_proxy settings will be wrong for programs executed from
the menu, etc.  All that will be fixed by simply making sure your .xsession
will establish an environment, in whatever way you choose: fix things
directly in .xsession, source in .profile in .xsession, etc.  But only
.profile sourcing is really clean: otherwise you are bounded to modify many
files whenever you change anything.

    Isaac> Note that what this bug report aims for is a *lack of* special
    Isaac> case.  Whenever I run a program as user, I want to be sure that
    Isaac> I've inherited some login environment from some program that I've
    Isaac> executed before, and that I've established that environment only
    Isaac> once from the path that where the "init" program starts.

    Ian> But what if I _don't_ want to run "as a user"?  What if my .profile
    Ian> contains interactive bits, for example, as is quite common?  Even
    Ian> Norbert mentions that case ...

All shells provide command to test whether you are executing interactively.
E.g., in bash and sh, the $- variable will contain the character "i" if and
only if it is running interactively.  So your interactive commands should
always be guarded by it:

  case $- in
  *i*)
    # your interactive commands
    ;;
  esac

And for tcsh:

  if ($?prompt == 0) then
    # your interactive commands
  endif

Also the shell provide command-line arguments that allow you to force it
into running interactively (-i) and running a login shell (-l)
independently.  So much for your idea about login shell = interactive shell.

One more problem of your idea: if you type "bash", the program is
interactive, but is not a login shell.

    Ian> Yes.  IMO login => interactive.

    Isaac> This does not work well in practice, since then nothing else will
    Isaac> be able to make sure that your environment is properly set.

    Ian> Nothing?  That must be hyperbole, as your message makes it clear
    Ian> that you know about the environment file.

I'm talking conceptually, rather than implementationally, when I say
"nothing".

    Ian> Same answer as above: you _can_ do what you want.  It is merely a
    Ian> matter of (in)convenience, editing another dotfile.  Is that really
    Ian> worth breaking the non-interactive case?

You can make a lot of guards that makes sure your settings works in your
environment, for the programs you use.  But if you don't have a clue about
what conceptual framework you are using, when you start using another
program and the shell does not operate that way, you don't know whether it's
the problem of your old scripts or the problem of the new program that you
start using.

Nobody is going to break the non-interactive case.  Non-interactive and
login are orthogonal.

    Ian> But that is not the only situation.  Another is su. cron and at yet
    Ian> another.  Etc.

If they provide no easy way to make sure a good environment is set, they are
broken too.  There is a primary difference of attitude between us here: when
I see something wrong, my answer is "change it", or at least "understand
that it is wrong".  When you see something wrong, your answer is "live with
it, only the implementation says the truth".

    Isaac> Where is the easy ssh way to say "I want you to establish a
    Isaac> complete session in the server"?

    Ian> Okay, here you may be right.  Perhaps there should be a flag to
    Ian> distinguish the two cases.  But _don't force me_ to execute my
    Ian> profile when I want to execute a single noninteractive command.

Again, interactiveness and login are orthogonal.

Anyway, I don't have high hope on this thread, as there are millions of
people with broken setup like you, and they will not like it even if I say
"you can guard your interactive commands by a simple test".  People should
look for (or work on) a user-controllable environment PAM module instead.

Regards,
Isaac.