Eric Blake wrote: > According to Jim Meyering on 10/26/2009 3:04 AM: >> # Use -- to end arguments. >> -cat <<EOF >./-i || framework_failure >> -#!/bin/sh >> -echo pass >> -EOF >> -chmod +x ./-i || framework_failure >> -case `env -i PATH="$PATH" echo good` in >> +ln -s "$abs_top_builddir/src/echo" ./-i || framework_failure >> +case `PATH="$PATH:" env -i echo good` in >> good) ;; >> *) fail=1 ;; >> esac > > This is still failing for me on cygwin: > >> + ln -s /home/eblake/coreutils/src/echo ./-i >> + case `PATH="$PATH:" env -i echo good` in >> ++ >> PATH='/home/eblake/coreutils/src:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:' >> ++ env -i echo good >> env: echo: No such file or directory >> + fail=1 > > In other words, cygwin's execvp can't find /bin/echo once -i cleaned the > environment.
Ok, then go ahead and add PATH="$PATH" to accommodate it. >> +case `env -i -- PATH=. -i no-echo` in >> + no-echo) ;; >> *) fail=1 ;; >> esac > > In a similar vein, cygwin REQUIRES that path include /bin, in order to > find cygwin1.dll; restricting to just dot is too tight: Ugly. But no problem accommodating that, too. >> + case `env -i -- PATH=. -i no-echo` in >> ++ env -i -- PATH=. -i no-echo >> + fail=1 > > Also, did you really mean to include -i twice in that line? yes. The first is to clear the environment. The second is to be interpreted as a program name. Wasn't that the intent of your original test? To ensure that the "-i" after "--" was interpreted as a program name and not as an option? > I'll play with this some more and propose a patch later. Thanks!
