On Mon, Dec 7, 2015 at 4:47 PM, Erik <[email protected]> wrote:
I generally want my tup :-rules to be run in bash with `set -o pipefail` > enabled. I could add this to every single rule but that's verbose and error > prone. Someone on stackoverflow recommended I try doing this with shared > library interposition, which seemed like it might work. My hypothesis at > the time was that the commands were executed using glibc's `system` call. > That seems to be false, but spending some time perusing the codebase, I > couldn't actually find where the commands were executed. It doesn't help > that I'm not very familiar with fuse or pthread. This leaves me with a few > questions: > > - Is shared library interposition a viable root to accomplish this? If > the commands are executed almost directly by a call to some shared library > this seems like it could work, wouldn't be too hard, and wouldn't be > mandatory, or require me (or anyone else) to patch and recompile tup > source. > - If it is viable can someone point me to the appropriate place to > look for where to do the intercept? In addition to reading relevant pieces > of the code (or so I thought), I also tried tracing command execution with > ltrace, but it seemed to interfere with fuse, and I couldn't manage to get > fuse running with ltrace active. > - If it's not viable, is there a better method to accomplish this that > is relatively trivial (on the order of writing a simple interposer)? > - If none of these, is there a potentially better way to improve tup > to allow this? I'm open to contributing a pull request if there's a > relevant piece to write. It seems like maybe with the lua api you could > have a function that arbitrarily modifies every command before it's > executed, but then you'd have to fetch back to the lua api from main tup > which seems like a pain and potentially slow. There could be a specific > flag to do specifically this (e.g. wrap every command in "bash -c '<command > with escaped apostrophes>'") but that seems a little hard coded and less > portable. I'm open to other suggestions. > > That sounds like it may be a good thing for tup to support. What kinds of commands are you running that you'd want this set universally? The code is a little wonky to follow because you can't fork a process from a process running fuse without race conditions. The sub-processes are executed in master_fork.c using execle() - https://github.com/gittup/tup/blob/master/src/tup/server/master_fork.c#L654 Note that tup currently just runs '/bin/sh -e -c [cmd]', and it doesn't look like the stock bourne shell supports pipefail as far as I can tell. So I guess we'd need some way to set a flag or something in the rules, and then run bash if using pipefail? Also, I'm not sure of the best way to communicate to tup that a certain rule should use pipefail. Currently all of the information about a rule is in the :-rule line itself, so we'd probably want to use a ^-flag or something: : |> ^p^ cmd1 | cmd2 |> So it would run 'cmd1 | cmd2' with pipefail enabled. However, since you'd have to add the ^p flag for each rule that uses it, I guess all that really buys you is fewer keystrokes vs specifying bash directly. Would others find this useful? -Mike -- -- 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.
