Fixes for ipython unhandeled OSError exception on failure of os.getcwdu()

[dhananjaysathe]

IPython.utils.path.getcwdu() added to prevent OSError on launch from locations that are not present

Fixed the OSError on launch of ipython to where thw os.getcwdu() function caused the exception to bubble and crash on launch.

It handles the OSError with errno 2 : corresponding to directory not present, and defaults it to the user home directory.

It also warns the user about its actions using the IPython.utils.warn.warn() about the action it takes hence maintaining transparency to the users.

[takluyver]

I think we should avoid importing other parts of IPython in the externals - these are separate packages that we include. If the problem affects this package, it should be fixed separately and sent upstream.

[takluyver]

Although looking at what this does, in this case I don't think it needs a fix. path just provides an OO representation of a file path, so it doesn't guarantee that a given path exists.

[takluyver]

Overall, I think this warrants a closer look at what each case should be doing if the cwd doesn't exist, rather than simply replacing all calls with the new function. E.g. where cwd is used in tests, we might not want to catch the error, because that could mask something that's going wrong. And there may be other cases where it makes more sense to fail (with a helpful message) than to carry on with the user's home directory.

[fperez]

BTW, this PR can't currently be merged due to conflicts.

But I agree with @takluyver, a blanket catch of this error is the wrong approach. Let us know if you think you can work on this one further...

[takluyver]

The conflicts are probably due to a big pull request I merged without enough consideration - let me know if you want a hand rebasing it.

[fperez]

@dhananjaysathe, do you think you'll have a chance to address the feedback here and rebase it? We'd love to have your contributions, but right now they need some fixing up first. If you think you'll have a chance to work on it let us know. Otherwise we'll close the PR for now, as it's problematic to keep open PRs that linger for a long time. You're always welcome to reopen it at any time in the future if you find the time to return to the work, and we'd be happy to help you with the necessary rebase and other feedback.

[dhananjaysathe]

Yep ill look into it and re-base, a bit tight on my schedule at the
moment, ill try my best to fix it asap !

Cheers !!!

Dhananjay Deepak Sathe | +919764871950
dhananjaysathe@gmail.com,dhananjaysathe@acm.org,f2009260@bits-goa.ac.in,f2009260@bits-goa.ac.in
Blog : http://dsathe.blogspot.com
3rd Year Undergraduate,
BE(Hons) Electronics and Instrumentation,
BITS Pilani Goa Campus.

On Sun, Nov 27, 2011 at 2:24 AM, Fernando Perez <
reply@reply.github.com

wrote:

@dhananjaysathe, do you think you'll have a chance to address the feedback
here and rebase it? We'd love to have your contributions, but right now
they need some fixing up first. If you think you'll have a chance to work
on it let us know. Otherwise we'll close the PR for now, as it's
problematic to keep open PRs that linger for a long time. You're always
welcome to reopen it at any time in the future if you find the time to
return to the work, and we'd be happy to help you with the necessary rebase
and other feedback.

---

Reply to this email directly or view it on GitHub:
#811 (comment)

[ivanov]

I know this is an old PR, but I was just wondering how frequently (and when at all) such a situation would occur? i.e. "launch from locations that are not present" - is it when you started IPython and the directory you started from was moved or deleted right after that from under you?

[takluyver]

I've done that a few times - deleted a folder from one program while
it was the working directory of a terminal somewhere. I can't really
blame programs in that terminal for crashing, though - I think
"working directory exists" is normally a reasonable assumption.

[dhananjaysathe]

Hi, to give you an example me and some of my friends collaborate over an
ssh server or these days on an ec2 instance. A lot of our work is on
python and django. In such cases it does happen that you are not aware of
a sudden change, you return to debugging something and the entire session
and work crashes. I do understand that it's our onus. To prevent such an
occurrence but it could slip through in rare cases. Instead of crashing
outright this could warn the user. IMHO It's a minor but nice failsafe
feature to have unless there is a good reason against having it. (Perhaps
some unintended effects I am not aware of ??)
I can also foresee such a case occurring in a lab or a server where
multiple users access the machine at different times and aren't aware of
any inherited changes. ( this is how I came across it initially)
Sorry I haven't been able to make any further contributions/rebase as I
have been immensely busy with some research project. I'll be sure to to
make any changes now as I have some time.

Cheers!!!

• Sent from my Android Device
  On Feb 14, 2012 4:15 PM, "Thomas" <
  reply@reply.github.com>
  wrote:

I've done that a few times - deleted a folder from one program while
it was the working directory of a terminal somewhere. I can't really
blame programs in that terminal for crashing, though - I think
"working directory exists" is normally a reasonable assumption.

---

Reply to this email directly or view it on GitHub:
#811 (comment)

[ivanov]

it seems that if we're going to report home as the cwd on error 2, we should CD to it, so that if the user ends up doing things using relative paths there are no surprises for him/her. And now I'm not even sure I like that solution either, because now something that ought not change state but only report the current working directory, sometimes (depending on whether or not the error is thrown) will change the state. The alternative of leaving this as is is also confusing, because getcwdu will report /home/user, but none of the standard python calls or system calls issued will actually have that as the current working directory.

[bfroehle]

I'm generally against this --- it's not surprising that IPython will crash if there is no current working directory. Most other command line tools will break, often with weird messages. For example, after a quick setup:

$ mkdir tmp
$ cd tmp
$ rm -rf ../tmp

bash cannot write to files:

$ cat > hello
-bash: hello: No such file or directory

ls can't list anything, not even the current directory:

$ ls -al # notice no output at all!
$ 

And ipython does give a proper error:

$ ipython
Traceback (most recent call last):
...
  File "/Users/bfroehle/src/ipython/IPython/core/profiledir.py", line 203, in find_profile_dir_by_name
    paths = [os.getcwdu(), ipython_dir]
OSError: [Errno 2] No such file or directory
...

[takluyver]

@dhananjaysathe : Not crashing is a reasonable aim, but we don't need to protect every call to os.getcwdu() in this way. E.g. some of these are only called when starting up, or are part of the test suite, so they can't be hit in normal operation.

Building on @ivanov's suggestion, I suggest you implement an IPython extension. There's a hook which is called before each code execution (you can call ip.set_hook('pre_run_code_hook', my_function)). In your function, check if the cwd exists, and if it doesn't, cd to home and print out a message like 'WARNING: Working directory deleted. Your working directory is now...'.

I'm going to close this pull request, as it's been sitting around for ages, and it's got various issues. You're welcome to implement a better solution and open a new PR, or talk to us on the mailing lists or on IRC if you want to know more.

[marceloslacerda]

I followed the suggestion of @takluyver and made this little extension:
https://gist.github.com/marceloslacerda/6488503

It should be able to install with this:
%install_ext https://gist.github.com/marceloslacerda/6488503/raw/c6c8c7bb80bb2a0c834ff898764ea125e5590d0a/cd_ipy.py

[takluyver]

Thanks @marceloslacerda , I've left you a few suggestions in a comment on your gist.