Re: [PATCH] Fix hang if $OLDPWD points to inaccessible directory

[L A Walsh]

Eduardo � wrote:
> On Fri, Sep 29, 2017 at 12:51:37AM -0700, L A Walsh wrote:
>   
> > Why does bash clear OLDPWD when a child script is started?
> > OLDPWD is exported and passed to any children, but bash apparently clears
> > OLDPWD whenever a child script is started...
> > GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
> > Can bash be fixed to preserve the value of any OLDPWD in its initial
> > environment, like it does with PWD?
> >     
> Eh, 4.1? That's ~8 years old.
> Check the commit I linked, there's the fix you're asking for.
>   
Check the bug report you linked in your initial response.
I read the report as listed as the 'reason' for the change.  The above was
a quote from the bug report.  Are you saying you saying the
reason given was invalid?
> > Requires console access, but changing /etc/profile to
> > insert a bad OLDPWD to a known down network location might not be
> > considered a trivial occurrence to someone stressed out and trying to log
> > in and find out why everyone logging in is hanging...
> >     
>
> Why would logins hang? 
Simple -- OLDPWD is set in /etc/profile to a bad value.  That causes 
problems
for everyone logging in, including root.  Granted it is a rare event, and
granted it needs root-console access, but the paragraph described an
annoying situation where someone set the value of OLDPWD in /etc/profile
to a dead-network connection.  Even as someone w/root access tries logging
in to fix the problem, they are hit by the same problem -- which I was
guessing might cause stress -- especially to the one trying to fix it.


> To which the solution is: unmount the network share properly.
>   
Obviously that's the end goal, I was pointing out how annoying it would be
if someone modified /etc/profile to set OLDPWD to a hung-network connection.

I was thinking about the remote possibility of that happening and the 
consequent
"annoyed sysadmin" vs. the original bug report you cited being given as 
a reason
for not clearing it upon startup.  I'm not heavily for or against it, 
but would
lean toward initializing it to a known value, at least, when starting a 
login shell.