> > 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.
