command line options

[FourthWorld]

Thanks for your work on that, Mark.

If it's convenient to look into this while you're working on other aspects of CLI support, it would be useful to be able to regain some of the command-line options the engine reserves but no longer uses:
http://quality.runrev.com/show_bug.cgi?id=1644

[LCMark]

@FourthWorld: Yes - I decided that cleaning up the command-line arguments should be part of this little endeavour. As should cleaning up the startup code in the engine which is currently spread around about 10 different places (hence it being fiddlier than I first intended!).

[FourthWorld]

Thanks, Mark. Very glad to hear it.

And thanks for apparently taking care of the move to fstat64 for file systems with 64-bit inodes. I just tested a standalone on one of my Dreamhost servers that use a 64-bit inode implementation of XFS, and now I can reliably read files with "put url..." and obtain listings of files with "the files", both of which had failed with earlier version of LS on that system.

Will that change be part of the next release of LC Server as well? I don't mind using a CLI standalone for CGIs, but I have a lot of server code I'd like to share with the community, and LC server would of course be the best way to do that (once I can use it on Dreamhost, that is).

[LCMark]

@FourthWorld: Glad the fix worked - it's a little tricky to test as it only appears (it seems) when the XFS file system has enough files on it to overflow a 32-bit count! In regards to Server, then yes, the fix was applied to that code too.

[FourthWorld]

@mwieder: Whatever became of your RQCC request to eliminate the engine's reservation of CLI flags that are no longer used?

And what is the report number (I couldn't find it this morning)?

[mwieder]

It's now filed as bug 11403 http://quality.runrev.com/show_bug.cgi?id=11403.

These are the current command line options that are eaten by the engine.

Revolution 6.5.0-rc-1 Copyright 2003-2008 Runtime Revolution Ltd
Usage: <path>/livecodecommunity.x86 [-d[isplay] displayname]
[-f[iles] (disable access to files and processes)
[-g[eometry] ={+-}<xoffset>{+-}<yoffset>]
[-i[nput] fd] read commands from fd (0 is stdin) or named pipe
[-m[map]] (don't memory map files)
[-n[opixmaps]] (draw direct to screen)
[-p[ointerfocus]] (use active focus)
[-s[haredoff]] (don't use shared memory server extension)
[+s[haredon]] (use shared memory server extension)
[-u] (don't create graphical user interface)
[-v[isualid] n] (use visual id n as listed from xdpyinfo)
[-w[indowid] n] (watch window id n for commands)
[stackname(s) | argument(s)]

[mwieder]

...and note that the server engine doesn't accept commandline switches at all.

[LCMark]

I realized I probably should have posted my comments here rather than in bugzilla - so just to bring the conversation back here...

(From me on the rqcc)

Looking at this, I wonder if we actually really need any of the command line flags apart from -ui (which we could require to be first). The rest are all legacy things from UNIX, all of which the engine determines for itself, or aren't really relevant anymore.

The only one which does need a bit of thought is '-files' - but the use case for that would be an 'untrusted' LiveCode standalone that you wanted to run in secureMode - i.e. one from an arbitrary source. However, does such a thing ever occur? Given that secureMode can be set by script on startup, perhaps it should be up to the standalone to do so (based on a command-line argument, if it chooses to do so).

(Then from @mwieder)

I don't think any of those command line arguments are really necessary any more. I wouldn't mind if the -i option worked, as far as I can determine it doesn't. Being able to use the engine as a shell script replacement would be great, but I can now use the server engine for that so it's not such a big deal.

(The from @FourthWorld)

For many things the Server is great, but the use case I need to satisfy is for desktop apps that also provide APIs for some of their more critical routines as CLI commands so they can be used as a sort of middleware in workflows tied together with Bash.

Making up longer arg names isn't the end of the world, but it'll be nice when the old ones the engine no longer uses go away so we can make good use of the ourselves.

[LCMark]

I think we can have our cake and eat it here - how about this:

If the standalone (community) engine does not have an embedded stack (i.e. it has not been used to build a standalone), it will accept -ui as the first argument, and then take the next argument as a stackfile to run.

If the standalone engine does have an embedded stack in it then it consumes -ui if it is the first argument otherwise it leaves everything intact. The current '-files' option can be handled in script on startup.

We can look at reinstating the 'read from stdin'/'fd' option again at some point in the case of a standalone with no embedded stack also.

UPDATE: I forgot to mention, I reinstated the ability to load a stack from the cmd line (it takes the first non eaten argument as a filepath to a stackfile) in a branch the other day - feature-cmdlinestack in runrevmark/livecode.git... I've not had a chance to test it out too much yet though.

[mwieder]

Some further thoughts:

The -files commandline option might still be nice to have as a prophylactic for standalones that are loaded from untrusted third-party sources.

If the standalone (community) engine does not have an embedded stack (i.e. it has not been used to build a standalone), it will accept -ui as the first argument, and then take the next argument as a stackfile to run.

That's an interesting idea. So the standalone engine by itself becomes a player for stacks, eliminating the need to build a standalone app.

I reinstated the ability to load a stack from the cmd line

Fetched and building right now.

[mwieder]

Build failed because the develop branch Makefiles still haven't been updated.

[LCMark]

@mwieder: The develop branch has been as far as I'm aware (we did do a full build today after all).

However that isn't relevant in this case since feature-cmdlinestack was taken off of master. It would probably fail to build if you had checked out develop, then this branch and not updated submodules as the thirdparty folder would be out of sync with what the master branch (and derivatives thereof) expect.

EDIT: It's also worth cleaning out _cache / _build (I think make clean in top-level does this) when switching between develop and master (on Linux), as the dependency tracking can get a bit confused due to the significant changes to the file sets being compiled between the two branches.

[mwieder]

@runrevmark - I do a make clean before each make. Yes, it takes longer, but it removes a variable.

But I just pulled the latest develop branch from github and the Makefiles are still wrong.
On the other thing, I'll <sigh> move the cmdline branch to master and build from there.

Update: after removing the cmdline branch from the develop branch the build succeeded.

[LCMark]

Did you definitely pull in changes from the runrev LiveCode repo? Your commit fixing the linux makefiled definitely appears to be in the log for develop, and I'm sure it built fine on Linux earlier for me when I was investigating a bug. What build errors are you getting?

Btw, in my previous post I was assuming you'd checked out the cmdlinestack branch from my repo rather than pulling into develop... The former is generally a better idea as the changes against master won't necessarily work against develop.

[mwieder]

No worries. The commandline branch is off master now, and both it and the develop branches build without errors.