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

Re: *term -ls, a summary



On Sat, Sep 07, 2002 at 10:29:51AM +0800, Isaac To wrote:
> 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

Or if you check the files in /etc/skel, you will see in .bashrc:
# If running interactively, then:
if [ "$PS1" ]; then

Of course that makes absolutely no sense, since the bashrc is only ever
executed from interacive non-login shells.. :)  There is the case where
you source the .bashrc from your .profile, but the check should really
be in .profile, so that you dont even source the .bashrc if you are not
in an interactive shell..

> 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.

Yes, the man pages for bash and ash make it clear that login shells can
be interactive and non-interactive.

> 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".

I really cant imagine why you would not want to be able to set the
environment.  Of course ssh has the .environment file, thogh that wasnt
always there either.  However what the real point is that ssh has just
about as much of a right to set my environment as say xterm does.  That
is to say that ssh shouldnt do it just as xterm doesnt..

Having a special case for every program is an unecessary pain..  For
instance cron allows you to set variables right in your crontab file.
The functianality shouldnt be removed, but cron too should start
programs in a non-interactive login shell, if it doesnt now..

> 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.

Well I think that making it a configurable option is reasonable.

Thanks,

Norbert

Attachment: pgpsKAXTqrWMf.pgp
Description: PGP signature


Reply to: