Re: io.popen: reading both stdout AND stderr

[Lorenzo Donati <lorenzodonatibz@...>]

On 15/08/2013 10.37, Michal Kottman wrote:
> On 15 August 2013 10:08, steve donovan <steve.j.donovan@gmail.com
> <mailto:steve.j.donovan@gmail.com>> wrote:
>> On Thu, Aug 15, 2013 at 9:15 AM, Jakub Piotr Cłapa <jpc-ml@zenburn.net
> <mailto:jpc-ml@zenburn.net>> wrote:
>>>
>>> What would be really nice is a wrapper around luaposix and lua-winapi
> modules which would work like the subprocess module in Python.
>>
>> Nice and very doable, I've been thinking about this. Generally people
> pick a platform and use the appropriate native API, but it _is_ useful
> to have cross-platform scripting that hides some implementation details.
> 
> 
> There is already an implementation of an API allowing you to spawn
> processes and having a better control of the standard streams -
> http://lua-users.org/wiki/ExtensionProposal - available for POSIX and
> Windows. Here is an example of "popen2", which spawns a process and
> creates necessary pipes for standard input and standard output. It

[...]

Thank you all for the answers!

Ok, so my guess that it cannot be done in pure Lua has been confirmed.

@Steve:

In general I've no problem with temp files, but sometimes I have to
process sensitive, privacy-related, data and leaving traces on the
system where I use my scripts is not something I'm very happy to do. Not
that I need NSA-level security, but Italian law is *both very strict and
too vague* about what sensitive information are(ugh!), so I am paranoid
when it comes to handling students' data.

Moreover stderr contents often are produced when something goes wrong,
and this means that my script could well have done something silly and
so stderr could contain something like passsword or login information or
other security-related info that I don't really want to sit on a system
not under my full control (e.g. what guarantees have we that temp files
are automatically deleted from the system after an app has crashed. On
Linux probably we now for sure, but for Windows ... )

BTW. If Lua team doesn't deem it useful enough to enhance popen in this
sense, IMO this should be added at least to lfs

On a related note, although a robust workhorse, I find lfs a bit
lacking. I'd really like it to be a little more feature complete.

Features I miss from lfs (which should be easy to bind to already
existing APIs in the host OS):

* mkdir cannot create directories recursively ( mkdir "a/b/c" gives an
error if "a" doesn't exist, whereas I'd like to have a flag to tell it
"do make all the intermediate dirs")

* File copy operations.

* Pathname existance checking and
canonalization/normalization/resolution (e.g. lfs.exists
"/foo/bar/a/b/../../c" would return "/foo/bar/c" if this file exists, or
nil otherwise)

* lfs.dir iterator should not return ".." and "." as directories.
Especially ".." is dangerous when building recursive functions on top of
lfs.dir: you could by mistake recurse upwards (I'm always wrapping
lfs.dir to remove ".." and ".", but this inconvenient and error prone -
I don't know you, but I never used lfs.dir output directly). At least
this behaviour should be documented.

Other operations that are not strictly file-system operations, but IMO
too much connected to them:

* lfs.setenv (to pair os.getenv)

* lfs.popen (as said above)

* lfs.execute  having a richer API than os.execute (e.g. see wxWidgets
wxExecute) and allowing sync/async execution


I acknowledge that many of the above can be built on top of lfs, but
sometimes it is tricky and anyway not as efficient as wrapping existing
OS APIs.

Cheers.

-- Lorenzo

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments