File module

I’m looking at the file module from the repository and it’s not making a lot of sense. Am I missing something?

I’m calling “d = io.popen(‘dir’)”

The string parameter is passed into the new popen function which calls ConvertProcessLine with the input string parameter but this function seems to require a table as the parameter. It’s just downhill from there. 🙁

Attachments:

You must be logged in to view attached files.

Yes… I think I changed the calling convention for popen – because my file module was experimental I was trying out this calling form:

local P = io.popen{command=’dir’, args=’…’}

Although I didn’t get around to putting in help support to give intellisense on the arguments or document it :-(.

Guess it bit off changing the calling form of the built in commands although the file module in general is quite invasive since it changes the behavior of all the built in file handling and process commands.

This explains the theory behind it:

http://help.interfaceware.com/kb/the-anatomy-of-an-iguana-app/5

BTW – do you about os.fs.glob? It’s a better alternative to calling ‘dir’ directly from popen.

Right, that makes sense, although I’m not convinced about changing the calling convention for built-in functions. I can understand the rationale and what you are trying to achieve.

Yes, I’d normally use glob(). ‘dir’ was just for a simple example.

Thanks for the info.

Yes – I probably shouldn’t have changed the calling signature for popen… it was little bit of catch22 in that with the file module I was trying to make every API adopt a platform independent way of specifying paths – popen takes a path so I needed to change it but the convention of it having all this kind of stuff where you do:

local P = io.popen(“D: && D:\some\command.exe XX YY ZZ”)

Is not at all an amenable interface to making a platform portable syntax for calling command line programs. Incidentally the thing with having to change the partition with D: is a unique pain that happens with windows.

So io.popen had an interface which really makes it difficult to writing cross platform Lua code which is why I changed it (spur of the moment experiment)

Another way of doing it would have been to completely remove the io.popen line.

Although I think if the new version of popen had some nice descriptive error message, built in help and good documentation explaining the change in the interface then it probably wouldn’t be so jarring…

Alternative syntax for that call would be:

local P = io.popen{command=’command’, args=’XX YY ZZ’, dir=’D:/some/’}

Although maybe the args should go into an array… heh no perfect answer.

All looks good till you hit something like:

local P = io.popen{command=’command’, args=’XX d:\\something\\else.txt ZZ’, dir=’D:/some/’}

Making paths os independent also applies to the arguements. :`-(

A previous comment from you caught my attention – Windows is OK with forward slash. I gave it a try and yes, I can use forward slashes with no problems. Would it be as simple as a gsub on the popen command string?

local POpen = io.popen
function io.popen(cmd, mode)
return POpen(cmd:gsub(‘\\’, ‘/’), mode)
end

(Nothing is ever that simple)

Or encourage everyone to use forward slash in explicit paths.

Yeash… as I was writing that popen wrapper I did get the distinct feeling it was not a complete solution. I dunnoe 🙂 I’m stumped. At least just a module – not part of the core GA release of Iguana…!

popen in general opens you up to a lot of platform specific stuff. We’ve been trying with the Iguana apps where possible to avoid using popen and create apis like we did with with filter.zip.inflate etc. That makes a lot of platform specific headaches go away.