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

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:hno@squid-cache.org]
> Sent: Thursday, April 18, 2002 6:12 PM
> To: Duane Wessels
> Cc: squid-dev@squid-cache.org
> 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
>
Received on Thu Apr 18 2002 - 02:33:09 MDT