softdevteam/krun

run_shell_cmd() is stringly typed

vext01 opened this issue · 2 comments

I find it annoying that run_shell_cmd wants a string. Because, well, it shouldn't. We pass the argument straight to the Popen constructor.

class subprocess.Popen(args, bufsize=0, executable=None, ...
...
args should be a sequence of program arguments or else a single string. By default, the program to execute is the first item in args if args is a sequence. If args is a string, the interpretation is platform-dependent and described below. See the shell and executable arguments for additional differences from the default behavior. Unless otherwise stated, it is recommended to pass args as a sequence.

Yes, indeed, I'd like to pass them as a sequence too! This saves keystrokes (no join needed) and ensures (god forbid) filenames with spaces work.

So why does run_shell_cmd with ['taskset', '-c', '0', '/home/edd/research/krun/krun/../utils/query_turbo'] give:

Traceback (most recent call last):
  File "../krun.py", line 395, in <module>
    main(parser)
  File "../krun.py", line 240, in main
    raise exn
krun.util.FatalKrunError: Command failed: '['taskset', '-c', '0', '/home/edd/research/krun/krun/../utils/query_turbo']'
stdout:

stderr:
Usage: taskset [options] [mask | cpu-list] [pid|cmd [args...]]


Show or change the CPU affinity of a process.

Options:
 -a, --all-tasks         operate on all the tasks (threads) for a given pid
 -p, --pid               operate on existing given pid
 -c, --cpu-list          display and specify cpus in list format
 -h, --help              display this help
 -V, --version           output version information

The default behavior is to run a new command:
    taskset 03 sshd -b 1024
You can retrieve the mask of an existing task:
    taskset -p 700
Or set it:
    taskset -p 03 700
List format uses a comma-separated list instead of a mask:
    taskset -pc 0,3,7-11 700
Ranges in list format can take a stride argument:
    e.g. 0-31:2 is equivalent to mask 0x55555555

For more details see taskset(1).

You can see it's invoked taskset ok, but something has gone wrong...

If you join the args into a string and use that, this works as expected. Weird.

Pretty sure I'm being daft here...

I wonder if the ../ expansion needs to be done by the shell somewhere?

Maybe that's it, I think I'll experiment when I get a moment.