Some of my limited knowledge: tup executes :-rules with execle (see pat's reference). The obvious thing to me would be to wrap "string" commands in '"/bin/sh", "-e", "-c", "cmd"' (what's executed now) and store the array structure in the tup db instead. I'm not sure how easy that would be, e.g. storing arrays in sqlite3, but it would allow an arbitrary array of strings to be called instead. This would give up the benefit of all sh functionality (io redirection was mentioned; path lookup also comes to mind [upon further look it looks like execle doesn't do path lookup, execlp does, but there's no execlpe except on nonstandard linux implementations]), but it would allow an api for lua with an array of arguments. It would also allow for a future backwards incompatible change that would have tup parse and tokenize tupfile commands instead of just passing the strings to sh, which could provide extra platform independence.
I was unaware of the different windows call, but it's unsurprising. I'm not sure how this potential change would affect the windows call. I generally side with Pat that it seems like you should be able to write the lua platform independently if you need to, and that should probably be enough. On Wed, Mar 30, 2016 at 3:59 PM Pat Pannuto <[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 > ) > > 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]. >> 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. > -- -- 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.
