June 12, 2017 Re: std.path.buildPath | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| On Sun, 2017-06-04 at 21:32 +0200, Jacob Carlborg via Digitalmars-d- learn wrote: > On 2017-06-04 19:05, Patrick Schluter wrote: > > > buildPath("/usr/bin", "/usr/bin/gcc") > > > > /usr/bin/usr/bin/gcc is obviously wrong. > > Says who? It might be exactly what I want. The case that came up is > inside DStep. The user provides a set of files C header to be > translated > to D modules. The user also provides a flag to indicate where to > place > the resulting files. I wanted to be able to keep the existing > directory > structure of the header files in the new target location. Example: Says Guido et al. it seems, Python has in os.path and pathlib exactly this behaviour. > dstep -o result /usr/include/libxml2/libxml/*.h > > The internals of DStep will do something like: > > buildPath("result", "/usr/include/libxml2/libxml"); > > Which currently results in "/usr/include/libxml2/libxml". The end > result > is that DStep will try to write a file to > "/usr/include/libxml2/libxml", > which the user most likely will not have access to (without using > sudo). > I expected the result of buildPath to be > "result/usr/include/libxml2/libxml". Sadly Python tells us otherwise just as D does. It is perhaps worth noting in passing that D path support seems very like os.path and Python folk are giving that up in favour of pathlib. Java/Kotlin/Groovy have also gone the same way. The implication is that D needs better path support than it currently has to keep up with the evolutions in other languages. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
Copyright © 1999-2021 by the D Language Foundation