Re: Bug? Bad permissions in $PATH breaks Git aliases

James Pickens [off-list ref] writes:

On Tue, Mar 27, 2012 at 8:14 AM, Junio C Hamano [off-list ref] wrote:

quoted

James Pickens [off-list ref] writes:

quoted

I'm not claiming that it's sane to have a broken PATH, but as I
mentioned in an earlier email, sometimes my PATH gets broken through
no fault of my own, and it would be nice if Git could be more helpful
in that case.

Hrm, so which was more helpful in diagnosing the broken PATH? Git by
letting you be aware that there is some problem, or your shell by keeping
me oblivious of the issue?

In this case the broken parts of my PATH were completely uninteresting
to me - they didn't contain any executables that I would ever use.  So
if it didn't break my Git aliases, I could have continued working with
the broken PATH and never known or cared that it was broken.

But I get your point - sometimes it's more helpful to let the user
know something is amiss than try to guess what was intended.

That was not the "point" of my question.  In fact, there was no point.  I
may be a mean person and may often throw rhetorical questions to embarrass
others, but I am not *that* mean to always ask only rhetorical questions ;-).

Judging from your answer, it would have been better for you if Git didn't
even tell you that there was an error due to an unreadable directory.  And
if that is the case, "Git could be more helpful in that case" will lead us
in one direction (i.e. "we simply ignore EACCESS and treat it as ENOENT"),
which is a quite different direction from what others discussed and
suggested in the thread (i.e. "we give more detailed diagnosis, perhaps
saying "your PATH has /usr/local/bin but it cannot be read, so we cannot
tell git-frotz exists there or not").

I just wanted to see what was the desired behaviour you have in mind.