Re: BASH bug CDPATH plus redirection

[chris . bitmead]

>I suggest you set your CDPATH variable in your .profile or .bash_profile,
>and not export it.  That way you have it for interactive use, but it
>won't get in the way of scripts, etc.

Yes well umm, the issue is not whether I can get around it, the issue
is that cd should never echo anything when it successfully executes
in a script. Perhaps I am wrong in this case to export CDPATH, but if
I wrote a script which purposely uses CDPATH, it will still fail and
that is wrong. The unix way is not to give verbosity on success.

>> (cd dir1 ; tar cf - foo ) >foo.tar ; <foo.tar (cd dir2 ; tar xf - )
>> BTW, ash does this correctly, bash does not.
>
>;-) If there's an area where "ash" is more "correct" than bash, I've not
>seen it.

I think you may have seen it now.

>Instead of doing the redirection you're trying, you might be able to get
>away with using a fifo as the intermediate filesystem object to hold the
>data.  That way you shouldn't need to fool around with redirection at all.
>Of course, redirecting the output from cd might be just as easy.

Again, the issue is not whether there is a workaround or another way. Of course
there is. The issue is that the shell
is supposed to accept the redirection at the start of the command. Here is
another case that bash is getting wrong...
</etc/passwd for i in 1 2 3
do
     read A ; echo $A
done

Yep that should work too. Tried it with a ksh implementation I have here.  bash
croaks on that one too.

As far as I know, it's always been the case that bourne shell doesn't care if
the redirection is at the beginning or
end of any sort of command, and it looks to me that bash is broken, and ash and
ksh have got it right. Personally
all my scripts have the input redirection at the beginning because it makes a
lot more sense to me, and they
won't run under bash, but they will under all the other bourne shell
implementations. I've been writing scripts
that way for at least 10 years.