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 ) I doubt the overhead of spinning up a shell instance is noticeable in the common case, however 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? I believe that Mike is already planning a big cleanup to the various tup-related files. On Mar 30 2016, at 3:21 pm, Kalrish Bäakjen <[email protected]> wrote: > Hello, > > > > AFAIK, Tup runs commands through the shell, as if it used [system](http://en.cppreference.com/w/c/program/system) (I haven't found such a call in the source code, though). However, the shell is not very reliable: there are big differences between some of them (especially between Bash and cmd.exe), concerning such basic aspects as string escaping (for example, cmd.exe doesn't use single quotes) or redirection. The problem could in fact arise that one started using features specific to his system's shell (like pipes and redirection in Bash, which are missing or have a different syntax in cmd.exe) without noticing, and then the build failed on other platforms. > > > > Plain Tupfiles need a tokenizer (either the shell's or Tup's own internal one) because their syntax specifies commands as plain strings instead of arrays, which is what OSes internally work with when it comes to execute a program. It is therefore understandable that plain Tupfiles remain dependent on the shell, because, if they were to bypass it, a shell-like parser would need to be implemented in Tup itself and, while this would certainly bring standardization, it wouldn't be an easy task. > > > > However, Lua Tupfiles don't need a tokenizer. Lua supports tables, which could be used to represent command arguments. Consider: > > \-- Relies on the shell (worrisome dependence) tup.definerule{ inputs={ "main.c" }, command='gcc -o main.o main.c', outputs={ "main.o" } } \-- Doesn't need the shell nor any tokenizer. Yay! tup.definerule{ > > inputs={ "main.c" }, command={ 'gcc' , '-o' , 'main.o' , 'main.c' }, outputs={ "main.o" } } > > Additionally, getting rid of the shell could speed up execution. > > > > Such a change wouldn't need to break the existing interface: the implementation of tup.definerule could just check if command is a string or a table and act accordingly, thus preserving compatibility with existing Lua Tupfiles. > > > > What do you think about this? > > \-- \-- 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]](mailto:tup- [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.
