FW: sed: 33: conftest.s1: unescaped newline inside substitute pattern

[Robert Collins]

w/ Automake 1.5, we have the following bug report. In summary, the
following shell code:

  am_aux_dir=`CDPATH=:; cd $ac_aux_dir && pwd`

is not portable to MacOS X, and is causing a headache for folk building
in the same dir tree. Can we change it to

am_aux_dir=`unset CDPATH; cd $ac_aux_dir && pwd` ?

or has this been already been reported and fixed in 1.6?

Rob

> -----Original Message-----
> From: Henrik Nordstrom [mailto:address@hidden 
> Sent: Thursday, April 18, 2002 6:12 PM
> To: Duane Wessels
> Cc: address@hidden
> Subject: Re: sed: 33: conftest.s1: unescaped newline inside 
> substitute pattern
> 
> 
> Duane Wessels wrote:
> 
> > Here's the line from configure that sets $am_aux_dir:
> > 
> >         am_aux_dir=`CDPATH=:; cd $ac_aux_dir && pwd`
> > 
> > The problem appears to be that 'cd' is printing the long version of 
> > the directory because it found it in the CDPATH list (":" being 
> > interpreted as the current directory).
> > 
> > I found two ways to fix this:
> > 
> >         am_aux_dir=`unset CDPATH; cd $ac_aux_dir && pwd`
> > 
> >         am_aux_dir=`CDPATH=:; cd ./$ac_aux_dir && pwd`
> 
> 
> Ah, now I know why I cannot reproduce the problem. I always 
> build in an object tree separate from the source.
> 
> The second approach cannot be used. $ac_aux_dir is outside 
> the current directory when building in a separate object tree.
> 
> Robert: Can you verify with the Automake people if changing 
> from "CDPATH=:" to "unset CDPATH" is OK?
> 
> And perphaps this should be reported as a bug to Apple and to 
> the zsh maintainers.. the manpage clearly states that the 
> shell only echos the new path found via cdpath in interactive 
> shells, and the above is not an interactive shell invocation...
> 
>        cd [ directory ]
>             [...]
>               mat of CDPATH is the same as that of PATH. In an
>               interactive shell, the cd command will print out
>               the name of the directory that it actually switched
>               to if this is different from the name that the user
>               gave.  These may be different either because the
>               CDPATH mechanism was used or because a symbolic
>               link was crossed.
> 
> The bug is confirmed in zsh version 3.0.7 (RedHat 6.2), 3.0.8 
> (MAC OS/X), 4.0.2 (RedHat 7.2), but is only a problem for us 
> if /bin/sh is a zsh (OS/X)
> 
> Regards
> Henrik
>