On Friday 04 November 2016 at 08:26:28 -0700, bch wrote: > On Nov 4, 2016 8:18 AM, "Mike Crowe" <m...@mcrowe.com> wrote: > > > > On Friday 04 November 2016 at 08:04:34 -0700, bch wrote: > > > On Nov 4, 2016 8:01 AM, "Mike Crowe" <m...@mcrowe.com> wrote: > > > > The fix for this in 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 appears > to > > > > have changed the existing behaviour of file:// URLs for me: > > > > > > > > On current master (9ea3a6e150dfc822ba1565f649b634848597d2d9): > > > > $ src/curl file://config.log > > > > curl: (37) Couldn't open file /config.log > > > > > > > > On master with 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 reverted: > > > > $ src/curl file://config.log > > > > [contents of config.log] > > > > > > > > Rightly or wrongly, we've used URLs like "file://test.txt" in many of > our > > > > unit tests which are now failing. :( > > > > > > What does file:///test.txt (3 slashes) yield? > > > > On both: > > $ src/curl file:///config.log > > curl: (37) Couldn't open file /config.log > > Is that the correct path, or is the fully qualified path something like > /var/log/config.log (file:///var/log/config.log) ?
/config.log is not the correct path. ./config.log is the correct path. The change in behaviour is that file://config.log used to refer to ./config.log whereas after 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 that URL now refers to /config.log. Mike. ------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html