[Top][All Lists]

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

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

From: L A Walsh
Subject: Re: [PATCH] Fix hang if $OLDPWD points to inaccessible directory
Date: Fri, 29 Sep 2017 04:53:41 -0700
User-agent: Thunderbird

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]