In my opinion: Don't do it.
It's undefined behaviour and typically untested,
which would explain the weird things you see.

The unspoken assumption of a 'login shell' process is

    [[ $HOME == $(pwd) && -r . && -x . ]]

(We could argue about [[ -w . ]], but I digress)

I believe this is what login does when a shell is invoked.
I believe this is what 'su - ...' does.

Any script or sequence faking a login shell should assure the same.

Cheers,
Henk

On Fri, 05 Nov 2010 12:52 -0400, "Ron Isaacson"
<[email protected]> wrote:
> Hi all,
> 
> This is a strange case, but I think there's a bug in ksh startup when
> a login shell is started in an unreadable directory. One example is
> when using sudo to invoke a login shell from, say, the invoking user's
> mode-700 homedir.
> 
> You can test it with something like this:
> 
>   % mkdir /tmp/unreadable
>   % cd /tmp/unreadable
>   % chmod 000 .
>   % perl -e 'exec { "/bin/ksh" } "-ksh"'
> 
> In my case, ~/.profile sets ENV to a fairly complex script that does a
> bunch of site-specific initialization, and this fails in unpredictable
> ways. Shell variables end up with values that look like partial values
> from other variables, values that run over where I'd expect them to
> terminate (foo=123; bar=456; echo $foo --> "123  456" !), or other
> stuff that suggests pointer management problems. The exact failure is
> consistent, but varies from host to host, and can be completely
> changed (or even eliminated) by inserting an echo statement or turning
> on -x, further suggesting some kind of internal memory management
> problem.
> 
> Before I dig into this any deeper... does this ring any bells, or does
> anyone have a suggestion on where to look? Note this is reproducible
> under all versions I tested, from the one supplied and build by Redhat
> (93q) up to and including the latest 93t+ sources that I built myself.
> 
> Also, in case nobody has any ideas... what incantation can I give to
> "bin/package make" to get a -g build?
> 
> --
> Ron Isaacson
> Morgan Stanley
> [email protected] / (212) 276-1349
> 
> _______________________________________________
> ast-users mailing list
> [email protected]
> https://mailman.research.att.com/mailman/listinfo/ast-users
> 
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users

Reply via email to