Re: io.popen Run command with spaces in argument filename, and get the result

[Andrew Gierth <andrew@...>]

>>>>> "Robin" == Robin Stern <robinstern1290@gmail.com> writes:

 Robin> Hi there,

 Robin> Am new to lua, and coming here from Python land. One thing that
 Robin> I have been not able to get right after browsing internet for 2
 Robin> hours (and trying solutions) is run a simple command from within
 Robin> lua, and get the stdout, stderr for it. Here's the command:

 Robin> otfinfo -p /path/to/file name/ with spaces.otf

The Lua standard library only supports a thin wrapper around the OS's
popen() function, which means you (a) have to deal with shell behavior,
which in turn may be OS-dependent on non-POSIX systems, and (b) you can
only get the stdout (the subprocess stderr will go to wherever stderr is
going in the Lua program, unless you put redirections in the command).

Assuming a POSIX-like system (i.e. that popen() invokes a POSIX shell),
something like this should do, provided that the value of LC_CTYPE (if
set) does not specify an "unsafe" encoding:

function myprog(filename)
  assert(not filename:find("\0", 1, true), "NUL not allowed in filenames")
  local file_esc = filename:gsub([[']], [['\'']])
  return io.popen(("otfinfo -p '%s'"):format(file_esc))
end

The logic here is that '...' in POSIX shell quotes every character
except ' itself, without allowing any form of escape, so we replace ' by
the sequence '\'' which closes the existing quote, adds an escaped '
character, and opens another quote. There are other ways to do shell
quoting but this one is the safest.

If you want the code to work on Windows, the required quoting will be
different, and I don't know what they are.

The other option is to use a module specifically for spawning
subprocesses.

(The only encoding which I know of which is "unsafe" for this purpose is
the Johab encoding of Korean, which allows ' to be the second byte of a
two-byte sequence. Other encodings which are unsafe in other contexts,
such as Shift-JIS, Big5, GB18030, which have the property of allowing
second bytes in the range 0x40 upwards (including the \ character), are
not unsafe in this context.)

-- 
Andrew.