The main difference that you seem to be pointing out is tokenization. For the vast majority of file names you could just make your lua code use double quotes, and insert the arguments programmatically. You could also make a shim around define rule that uses double quotes on windows and single quotes on Linux/Darwin, similar to the way that path joining utilities have to use different slashes if you're referencing anything outside of your directory.
Your main issue appears to be between cmd.exe and sh. while on non windows tup uses excele, which could be in principle be changed to do what you want, windows uses CreateProcessW (see Pat's link). That call does not allow a pretokenized string. Doing a little investigation reveals that the problem is not even with cmd.exe but with with windows itself. So, at best the windows side of tup would have to guess as to how to turn your table into a windows command string. This could be done with the best intentions, but actually seems to elide some of the important underpinnings of what's happening. I like the idea of being able to pass a table instead of a string, but it seems like the work required would be negligible, the platform independence would be false and could create unintended side effects, and the performance benefits on *nix would be minimal. On Wed, Mar 30, 2016 at 5:05 PM Kalrish Bäakjen <[email protected]> wrote: > commands do spawn through the shell, but not an arbitrary one, always >> "/bin/sh": >> https://github.com/gittup/tup/blob/master/src/tup/server/master_fork.c#L667 >> >> (Spawning in windows is obviously different: >> https://github.com/gittup/tup/blob/master/src/tup/server/windepfile.c#L214 >> ) >> > > Well, my point was that one can't rely on a particular shell nor even on > commands being run under one. By mentioning tokenization-quotation > differences between shells, I wanted to point out that this uncertainty > affects basic things (e.g. one could use single quotes trying to prevent > any expansion, and then discover that cmd.exe doesn't support them). > > >> […] explicit tokenization could be useful, though it seems that for the >> people who need it Lua is already an effective solution unless there's a >> compelling need to include it in regular tupfiles as well? >> > > Lua isn't a solution currently (the above example with a table doesn't > work), unless there's a way I don't know of. Tup's Lua side uses plain > strings to specify commands (just as regular Tupfiles). What I have > proposed is that Tup's Lua API be extended so that commands may also be > specified with tables, pre-tokenized by the user (as shown in the example). > > As for regular Tupfiles, I don't see how could explicit tokenization be > added to them without big syntactical changes, but I don't think it's > necessary anyway; as you say, those who need this kind of things should > turn to the Lua side. > > -- > -- > tup-users mailing list > email: [email protected] > unsubscribe: [email protected] > options: http://groups.google.com/group/tup-users?hl=en > --- > You received this message because you are subscribed to the Google Groups > "tup-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
