On 02/10/2007, Eli Zaretskii <[EMAIL PROTECTED]> wrote: > > Or, what now is a practical case where a gmake with that > > hack works better than one without? > > I don't know how to come up with an example that shows this problem. > But we don't need a specific example to know that this is a problem > that needs to be taken care of. Good engineering does not need an > example for each potential problem in order to prevent them. As long > as we cannot prove that the argument will _never_ have a trailing > slash, we need to protect against that.
Can we make sure all arguments passed to find_directory on Windows do not contain a "/" or "\" at the end? I cannot find any example either. And I have tested that neither DIR\\ or DIR/ can match an existing directory DIR currently---removing the trailing slash is OK. The code was added by Paul in 1999 (very long ago). What was the exact case then? Is the reason still valid? [snipped] > That's because `mkdir' that got invoked is the built-in command of the > Windows shell, and that built-in command thinks a forward slash begins > an option. Try quoting the directory name, like this: > > mkdir "dir/" > > then I think it will work, because the slashes inside quotes aren't > interpreted by the Windows shell. Yes, this is true. > > So, there is still the question: when is the backslash trick in > > find_directory supposed to help, actually? > > Whenever the argument has a trailing slash. As I said above, we have no real case here. -- Wu Yongwei URL: http://wyw.dcweb.cn/ _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
