I'm not sure how the redirection works in your environment. But, AFAIK, in some
environments, the shell would be doing the redirection for the taskset command
initially, not the ltplayerlua, because you haven't escaped the redirections.
As far as the shell syntax is concerned, taskset is the command. It doesn't know
that ltplayerlua is a command. To the shell, ltplayerlua is just an argument to
the taskset command.
Then, if your environment was set up not to close file descriptors during execution
of a subtask, ltplayerlua could inherit that redirection once it executes. With
some programs, if they are not connected to a tty, they conclude that they are
running in the background, and behave differently. In your environment, if the
redirections do first apply to taskset, since it's then no longer associated with
a tty, maybe it behaves differently.
In my environment, I know of no documentation that says that taskset will behave
differently if it's running in the background. So I know of no specific reason why
it would. But you're doing two things that are similar, you're expecting similar
results, and you're not getting similar results. I often find that looking at the
differences between two similar things, one that works and one that doesn't, allows
me to get the one that wasn't working, to work, without having to explain exactly
why it didn't work in the first place.
You might want to try to find a way to force the redirections to apply only to
ltplayerlua. Or for now, just hard code the use of /dev/null internal to
ltplayerlua just to see if it works that way.