Christian Jones wrote:
> A minor, even trivial, perhaps pointless issue---but I'm curious:
> 
> /etc/skel/.profile includes the line
> export PATH HOME TERM
> 
> This appears to be unnecessary;  login(1) places all three into the
> environment.  Simple testing with ksh and sh reveal no changes
> resulting from the removal of this line.  A bit of archive searching
> makes it looks like this hasn't been asked, googling resulted in no
> help, and a quick glance at cvs shows this was in the initial import.
> 
> Is there a reason this is here?  (I'm not suggesting there's
> necessarily a reason to remove it.)  Is this used by other shells in
> ports, or by any sh in the works?  Just noticed it, got curious, and
> decided to waste some time figuring it out---hope I haven't wasted too
> much of yours. ;-)

You make the assumption that a ".profile script" is always called
.profile, and that it is always run by login(1).  What if you are
testing scripts to see if they work as you intended?  In that case, you
would be executing them from something other than login(1), and you
wouldn't necessarily be calling them ".profile".

Plus, there is a measure of style.  Sure, OpenBSD's login(1) behaves as
you specify..but can you say that of every Unix-like OS?  Can you say
that will always be true?  (maybe it always was true and likely always
will be, but it sure ain't worth MY time to go looking.)  Is it worth
making assumptions over 20 little bytes?  For most script applications,
the export would be REQUIRED, .profile on login is an exception.  Do you
really want to live off an exception?

How about people using the existing code as example code for some other
non-.profile script?

How about if you want to set a variable that ISN'T exported by login?
   PATH=bla:bla/bla:bla/bla/bla
   HOME=/home/bla
   BLA="bla bla bla"
   TERM=bla220
   export BLA
doesn't that look a little strange?  How likely would someone be to
actually remember to do that if they needed to?  (gotta keep in mind,
one of our criteria is how irritating people will be when they screw
something up. :)

Unnecessarily code != evil code. :)

Nick.

Reply via email to