classification
Title: please avoid 'which' in Modules/ld_so_aix
Type: behavior Stage: resolved
Components: None Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, haubi, skrah, srid
Priority: normal Keywords: needs review, patch

Created on 2010-01-19 22:15 by haubi, last changed 2010-08-23 10:04 by skrah. This issue is now closed.

Files
File name Uploaded Description Edit
ld_so_aix-which.patch haubi, 2010-01-19 22:15 patch to search for compiler without external program
Messages (8)
msg98070 - (view) Author: Michael Haubenwallner (haubi) * Date: 2010-01-19 22:15
In Modules/ld_so_aix there is `which $CC` to search for the full compiler's path.

Unfortunately, /usr/bin/which on AIX is a csh-script and thus ~/.cshrc gets sourced before doing the path search.

Now, when the user does set some PATH in ~/.cshrc, `which` might print a wrong path for the compiler, causing the build to fail (at best).

It would be better to do the path search without launching an external program.
msg98071 - (view) Author: Michael Haubenwallner (haubi) * Date: 2010-01-19 22:18
Uhm, as I read the patch again, there's room for improvement of pywhich():
it likely fails with CC=/full/path/to/cc
msg111192 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-22 17:08
@Michael: do you intend putting in a new patch for review as hinted at in msg98071?
msg111209 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-07-22 18:56
I'm not sure this should be changed:

  1) Why is .cshrc sourced? It should only get sourced for a login
     shell.

  2) If the user sets a PATH that excludes the compiler, then `which`
     will also not find the compiler on other systems (like Linux).
     Why would anyone set a PATH that excludes the compiler?


Sridhar, has this ever been a problem for you on AIX?
msg111640 - (view) Author: Sridhar Ratnakumar (srid) Date: 2010-07-26 16:36
On 2010-07-22, at 11:56 AM, Stefan Krah wrote:

> 
> Stefan Krah <stefan-usenet@bytereef.org> added the comment:
> 
> I'm not sure this should be changed:
> 
>  1) Why is .cshrc sourced? It should only get sourced for a login
>     shell.

/usr/bin/which is a csh script on our AIX machine too:

bash-2.04$ head -n 5 /usr/bin/which
#!/usr/bin/csh -f
set prompt = "% "
if ( -f ~/.cshrc) then
        source ~/.cshrc
endif

>  2) If the user sets a PATH that excludes the compiler, then `which`
>     will also not find the compiler on other systems (like Linux).
>     Why would anyone set a PATH that excludes the compiler?
> 
> 
> Sridhar, has this ever been a problem for you on AIX?

Not at all, we use bash as the default shell.
msg114441 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-08-20 18:39
Sridhar, thanks for the information. /usr/bin/which is a shell script
on Linux, too, but it does not source any config files.

I think the behavior is odd, but as you say, it can be worked around.
In the worst case, one can set the PATH in ~/.cshrc to a sane PATH.
msg114731 - (view) Author: Michael Haubenwallner (haubi) * Date: 2010-08-23 09:14
@Stefan: Nope, setting some PATH in ~/.cshrc is the wrong thing to do, and it actually is the reason for this issue at all:
'which' is intended to tell the location of some command that would be used when started on current commandline or within current running shell-script using _current_ PATH. When ~/.cshrc modifies PATH, the found command-path would be wrong (or not found at all).
msg114732 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-08-23 10:04
Michael Haubenwallner <report@bugs.python.org> wrote:
> @Stefan: Nope, setting some PATH in ~/.cshrc is the wrong thing to do, and it actually is the reason for this issue at all:
> 'which' is intended to tell the location of some command that would be used when started on current commandline or within current running shell-script using _current_ PATH. When ~/.cshrc modifies PATH, the found command-path would be wrong (or not found at all).

Yes, that's why I wrote "in the worst case". Of course AIX 'which' is broken,
but this could be easily fixed by IBM.
History
Date User Action Args
2010-08-23 10:04:37skrahsetmessages: + msg114732
2010-08-23 09:14:26haubisetmessages: + msg114731
2010-08-20 18:39:58skrahsetstatus: open -> closed
resolution: wont fix
messages: + msg114441

stage: patch review -> resolved
2010-07-26 16:36:28sridsetmessages: + msg111640
2010-07-22 18:56:08skrahsetnosy: + skrah, srid
messages: + msg111209
2010-07-22 17:08:13BreamoreBoysetnosy: + BreamoreBoy
messages: + msg111192
2010-01-19 23:16:45brian.curtinsetversions: + Python 2.7
priority: normal
components: + None
keywords: + needs review
type: behavior
stage: patch review
2010-01-19 22:18:43haubisetmessages: + msg98071
2010-01-19 22:15:50haubicreate