Danny Backx escreveu:
> On Sat, 2006-11-18 at 21:52 +0000, Pedro Alves wrote:
>
>>> It happens to do that because . is in my path before system directories;
>>> this may be why you don't see it :
>>> sh-3.00$ findpath as
>>> as :./as /usr/bin/as
>>> sh-3.00$ pwd
>>>
>>> (findpath is a script of my own that does something similar to
>>> "whereis".)
>>>
>>>
>>>
>> Huh!? I've asked about your PATH settings before, precisely because I
>> thought you had something like this.
>>
>
> I must not have understood your question.
>
>
>> If you have '.' on the PATH, you are supposed to have it *last*'. All
>> hell breaks lose if you don't, you get what you deserve. :)
>>
>> http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html
>>
>> Why do you need it? Can you consider changing it and reverting the hack?
>>
>
> That FAQ text is questionable as a "universal truth", the comment about
> "all hell" feels slightly exaggerated. This is the first time in >20
> years of using UNIX daily that I'm running into this.
>
>
Putting a :) there allows me to exaggerate :)
> I am a strong believer in software that works; I'd use the term plug and
> play but someone else has already ruined that :-)
>
>
You can't always predict every possible input. But if there are de facto
standards, we might as well
assume they are used, else you would spend all your time coping with
preventing every possible bad
combination from happening. I've shown you the reasons why you shouldn't
put '.' before the system dirs.
If a lot of people where doing this, I am sure gcc would have been fixed
to support it. But,
most (none?) distro does it by default, and that is for the reasons I
pointed you.
> If the GCC build can't cope with . being in $PATH in a specific place
> then it should do something sensible with the situation, not produce an
> error message that shows no relation to the cause of the problem.
>
> My current hack is one workaround; you don't seem to like it. Another
> possibility I see would be to fiddle with PATH at the beginning of the
> build-ARCH.sh scripts, e.g. in this way :
>
> --- build-cegcc.sh (revision 819)
> +++ build-cegcc.sh (working copy)
> @@ -21,7 +21,7 @@
> fi
>
> export TARGET="arm-wince-cegcc"
> -export PATH=${PREFIX}/bin:${PATH}
> +export PATH=${PREFIX}/bin:/usr/bin:/bin:${PATH}
> #export CFLAGS="-g3 -O0"
>
> echo "Building cegcc:"
>
> Would that be more acceptable ?
>
>
Still feels like a hack.
If you are building with a native gcc installed in eg
/opt/gcc_trunk/bin, then this hack wouldn't work for you,
you would need to make sure /opt/gcc_trunk/bin is on the PATH *before* '.'.
At that point you might as well put /usr/bin and /bin on the PATH before
'.' always, and never see this problem.
Do you really see a problem in putting '.' *last* in the PATH? Would it
change your work flow?
If it would, you can easily use a script like:
$cat my_build-cegcc.sh
#!/bin/bash
export PATH=/usr/bin:/bin:$PATH
$path_to_script/build-cegcc.sh $*
There, no hacks involved in the standard script, and since you have a
non standard setup, you cope with
it, not everybody else :)
Cheers,
Pedro Alves
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
