.profile not being read from $HOME

John Mackin john at basser.oz
Sun Aug 4 02:42:47 AEST 1985


In article <2510 at sun.uucp> guy at sun.uucp (Guy Harris) writes:

> It's a documentation problem.  "sh" is supposed to read .profile from the
> current directory.  This doesn't cause a problem, because you aren't
> supposed to run login shells (i.e., shells with argv[0] equal to "-sh")
> unless you're in the user's home directory.
> 
> > Do other Unix systems have the same problem?  What is the correct behavior?
> 
> All other UNIX systems behave the same way.

When is a bug a bug?  My feeling has long been that the manual entry
was always right.  After all, that was the statement, by the author of
the code concerned, of said code's expected behavior; and it seems to
me VERY unlikely that Steve Bourne didn't know what he really meant
when he wrote ``If the first character of argument zero is -, commands
are first read from $HOME/.profile, if such a file exists.''.  Whereas
every programmer knows how easy it can be to write code that doesn't
really mean what you thought it did.

How do you know what sh is ``supposed'' to do, Guy?  Did you ask Bourne?
It seems to me that code is supposed to do what its manual entry says.
And as far as users being not ``supposed'' to run -sh except in their
home directory, I think there is rather too much supposing going on.
A common idiom on our systems, where /bin/-sh is a link to /bin/sh,
is "exec -sh" to replace the current shell with a new login shell
(for testing a modification to .profile, for instance).  It would
hardly be reasonable to require the user to be in his/her home
directory when doing such or not have their .profile executed.  (Our
sh was fixed long ago to conform to the manual entry; so not ALL
other UNIX systems behave the same way.)



More information about the Comp.unix.wizards mailing list