Run a batch from within a plugin

[thomasl]

Let's say I have a C array of strings with TCC commands which I've
constructed dynamically within a plugin. I now want to run that code.

I could repeatedly call Command() but some TCC commands are only valid
in batch files (do ... enddo etc). So, is there a way to run a "batch
file" from a plugin if the batch is already in memory?

(I can easily save the stuff into a temp batch file, then call Command()
with that and delete the temp file afterwards. However, that seems not
very efficient; more importantly, it's not foolproof.)

--
cheers thomasl

web: http://thomaslauer.com/start

 

[rconn]

thomasl wrote:

>
> Let's say I have a C array of strings with TCC commands which I've
> constructed dynamically within a plugin. I now want to run that code.
>
> I could repeatedly call Command() but some TCC commands are only valid
> in batch files (do ... enddo etc). So, is there a way to run a "batch
> file" from a plugin if the batch is already in memory?

Not at this time (though it's on the suggestion list).

Rex Conn
JP Software

 

[vefatica]

On Sat, 05 Jul 2008 15:37:55 -0500, you wrote:

>> I could repeatedly call Command() but some TCC commands are only valid
>> in batch files (do ... enddo etc). So, is there a way to run a "batch
>> file" from a plugin if the batch is already in memory?
>---End Quote---
>Not at this time (though it's on the suggestion list).

As you may be well aware, this seems closely related my request to be able to
"LOADBTM" (into memory) at the command line and later, perhaps repeatedly, run
the memory-resident copy.

 

[thomasl]

rconn <> wrote:

>
> thomasl wrote:
> > Let's say I have a C array of strings with TCC commands which I've
> > constructed dynamically within a plugin. I now want to run that code.
> >
> > I could repeatedly call Command() but some TCC commands are only valid
> > in batch files (do ... enddo etc). So, is there a way to run a "batch
> > file" from a plugin if the batch is already in memory?
> ---End Quote---
> Not at this time (though it's on the suggestion list).

So, for the time being, the only feasible route is indeed writing the
stuff to a temp file and executing that?

If so, I add my vote for a function to execute in-memory batch files.

--
cheers thomasl

web: http://thomaslauer.com/start

 

[thomasl]

Sorry to resurrect/recycle such an old thread... but the question I posted in 2008 is essentially the same I am posting today.

I am preparing a new version of a TCC plugin and there's still this batch thing I'd like to include. (Perhaps I've missed something and in the meantime this has been added to the SDK...?)

Rex, you wrote back then that "it's on the suggestion list". Is it still there? If so, any chances it might get implemented anytime soon?

cheers thomasl

 

[mathewsdw]

In some ways this is almost stupid, but then again maybe not so I'm going to take a chance here. Put simply, I run all of the batch files I develop entirely in memory; they only get committed to a physical hard disk when finished, and this is pretty much true for anything else I am working on a any given time, MS Word documents, spreadsheets, text file(s) I have for whatever reason(s), whatever. How is this? Simple, I have an approximately 400MB RAM disk "mounted". And the primary reason is quite simple: It's much faster than the physical hard disk in this machine (I no longer remember the exact number anymore, but it seems to me it was the low thousands of times). It also saves itself to a physical hard disk on system shutdown and reloads itself on system start up (in always the same, single, physical file so fragmentation is a non-issue), and it can also be set to save itself to that file at whatever time interval you select so that if the system crashes you only use, at most, stuff that's newer then the time interval you've selected. And it's entirely free for "disks" that are less than 4GB big. I'm not in a position at the moment to tell you where to get it, but if anyone is interested and asks I will post that information in this thread at a later time. - Dan

 

[thomasl]

In some ways this is almost stupid, but then again maybe not so I'm going to take a chance here. Put simply, I run all of the batch files I develop entirely in memory; they only get committed to a physical hard disk when finished, and this is pretty much true for anything else I am working on a any given time, MS Word documents, spreadsheets, text file(s) I have for whatever reason(s), whatever. How is this? Simple, I have an approximately 400MB RAM disk "mounted". And the primary reason is quite simple: It's much faster than the physical hard disk in this machine (I no longer remember the exact number anymore, but it seems to me it was the low thousands of times). It also saves itself to a physical hard disk on system shutdown and reloads itself on system start up (in always the same, single, physical file so fragmentation is a non-issue), and it can also be set to save itself to that file at whatever time interval you select so that if the system crashes you only use, at most, stuff that's newer then the time interval you've selected. And it's entirely free for "disks" that are less than 4GB big. I'm not in a position at the moment to tell you where to get it, but if anyone is interested and asks I will post that information in this thread at a later time. - Dan

The efficiency of file-based batches is not my main gripe.

Anyway, this approach has two problems. First, less importantly, is the brittleness of the process to put the batch file lines into a temp file somewhere in the filesystem and then to execute it. It'll work most of the time, sure, but still it feels like an unnecessary complicated way of doing things.
Second, much more importantly, I have absolutely no control over the users of my plugin and the environment they're working with so this approach is simply not going to be viable.

cheers thomasl

 

[mathewsdw]

Thomas, I suspected that that might be the case but I try not to make assumptions. However, it is possible (quite easily!) to verify whether the "Temp" variable/directory exists, and just write the stuff to the root directory of the C: drive (which, I would venture, is pretty much guaranteed to exist) if not and if you delete it when you are done (apparently, the way TCC is coded batch files are loaded into and run directly from memory so there are no open "file handles" on the batch file while it is running; since this is the case batch files are free to delete themselves) you will not, obviously, be leaving "garbage" scattered all over the system. (BTW, it truly amazes me how many processes create files (and even whole directories) in the "Temp" directory that they do not then delete; I actually take the time (I actually wrote a (very!) simple batch file) to "clean it out" periodically; and I did this because the first time I noticed this there was almost a full Gig of stuff in there!) And if the name of the batch file you are creating contains a date/time stamp and even PID, there's essentially no possibility of a "name" conflict. Not an "ideal" solution, I would acknowledge, but certainly a completely workable one given that what you would like does not exist at the moment... - Dan

 

[Charles Dye]

... and just write the stuff to the root directory of the C: drive (which, I would venture, is pretty much guaranteed to exist)

I've seen Windows installations where C:\ did not always exist. (I don't think we're buying from that vendor anymore....) The %_BOOT variable might be a better clue, but I think that UAC might object to normal users dumping stuff in the the root directory of the boot drive under some versions of Windows.

 

[samintz]

Dan, in Win7, you have to have administrative rights to write to the root directory. Since thomasl wrote his initial request four years ago, presumably he's been creating physical script files, running them through the Command() SDK API, and deleting them when he's done. His request wasn't a "how do I do this?" but rather, "is this feature available yet?"

 

[mathewsdw]

Guys, you are both correct. Since I just (pretty much automatically) run this stuff from an "elevated" command prompt, I didn't think about it. (And there is a way, previously documented on this bulletin board, to start a process "elevated" using the task scheduler without invoking the UAC prompt.) However, I think you are both somewhat missing the real point: what he wants does not exist at the moment (and only Rex can fix that) so some kind of "workaround" pretty much using a physical hard disk is necessary. - Dan

 

[thomasl]

Scott has hit the nail... I already have the scaffolding to execute memory batches via a temp file in a temp directory.

I revisited this bit of code recently, saw how ugly it is and just wondered whether anything might have happened on the Execute Memory Batches front. Alas, it seems it hasn't. I guess I'll come back in another four years;-)

cheers thomasl

 

[Charles Dye]

I have to wonder why you would want to execute batches from within a plugin. You realize that a plugin can call TCC commands directly, right? And you can access internal variables and functions via ExpandVariables().

 

[Steve Fabian]

I have to wonder why you would want to execute batches from within a plugin. You realize that a plugin can call TCC commands directly, right? And you can access internal variables and functions via ExpandVariables().

Wouldn't you have to implement all the logic of loops, conditionals, command parsing, etc. in the plugin to do that?

 

[Charles Dye]

Wouldn't you have to implement all the logic of loops, conditionals, command parsing, etc. in the plugin to do that?

Other languages do support loops, conditionals, and so on. My question is whether this whole approach of dynamically generating and executing batch files is necessary in the first place.

 

[thomasl]

Yes, I do realise that I can directly call TCC commands (see my very first post in this thread, from 2008). I also realise that other languages support loops, conditionals, and so on. (In fact the plugin I am talking about here is a fully-fledged script language in its own right and does have all that's required.)

However, sometimes it's easier and/or more flexible to simply produce a self-contained batch file. What's more, the users of my plugin do have their own ideas about how they'd like to go WRT this matter.

cheers thomasl