On 2 March 2010 09:21, Hans Hagen <[email protected]> wrote: > On 2-3-2010 8:01, Taco Hoekwater wrote: >> T T wrote: >>> >>> With the other thread asking to add readlink, I would also like to ask >>> for an addition of Windows specific GetShortPathName. Without this >>> function it is impossible to check if two paths point to the same >>> place. >> >> Is that because of reparse points or so? I though GetShortPathName >> was more or less obsolete now. > > indeed and luatex will not run nicely on windows < xp anyway (or os-9 or > whatever old is around)
Win2000 should be OK too (or generally NT-based systems, although we don't test anything prior to Win2k). Support for Win98 and below have been officially dropped in TL'08 I think. > best is to settle on long names consistently (i noticed some short name > issues a while ago) This is not possible for two reasons: 1) there is still some old software breaking on long paths occasionally (or rather on names with spaces); we struggled recently with dviout but this is resolved now; I'm not aware of any other cases, atm. 2) even if we ignore old programs, short paths are accepted thoughout the Windows API and pop-up in various places from time to time (e.g. %TEMP% var); moreover, paths specified in mixed short/long convention are OK too and the only way to get a cannonical path on Windows is through GetShortPathName (or it's twin GetLongPathName, but this one is not nearly as useful) On 2 March 2010 07:01, Taco Hoekwater <[email protected]> wrote: > T T wrote: >> However, I'm not sure if beefing up LuaTeX with this kind of >> functionality is the best thing to do (there will be undoubtedly other >> things worth adding). > > I am less hesitant than usual about adding stuff when the request is > about scripting for texlive. If GetShortPathName is useful in such > a context, I do not mind adding it. I'm really glad to hear that. And yes, I think that GetShortPathName is one of those essential functions you can't work around when you need it. It's either there or not. >From less essential functionality I would also love to have access to MessageBox for a minimal GUI functionality. I just introduced a few wrappers that run without a console (for gui programs), so there is no place to output error messages. I worked around this with an ugly hack but a proper solution would be nicer. >> Perhaps external modules? What's the status of >> loading binary modules? Will this be available for the coming TL >> release? > > Yes, but I expect there will not be any binary modules actually > included. That might easily change once the machinery is in place ;) Adding/updating a module if definitely less troublesome and easier to experiment with than updating the whole luatex stack (which in practice we can't do in TL in between the releases). >> And another request if I may. With kpsewhich it is possible to specify >> a search path explicitly with the -path switch, but this functionality >> is not exposed through lua kpse lib. Could this be added? > > Sure. If there is anything else from kpathsea people want, please > say so. There are a few other kpsewhich options not covered thus far: 1) -all output all matches, one per line. 2) -engine=STRING set engine name to STRING. 3) [-no]-mktex=FMT disable/enable mktexFMT generation (FMT=pk/mf/tex/tfm). 4) -subdir=STRING only output matches whose directory ends with STRING. (1) and (4) could be occasionally useful (although the latter one can be trivially implemented in terms of the former one in Lua). For the remaining ones I have no opinion, I've never encountered the need for them myself. Perhaps also kpse.version should be added for version checking? Cheers, Tomek _______________________________________________ dev-luatex mailing list [email protected] http://www.ntg.nl/mailman/listinfo/dev-luatex
