[Done] IncludeFromVar> pulls script lines from a variable

[jpuziano]

Hi Marcus,

Please consider enhancing the Include> statement so that in addition to pulling in script lines from a file like it does today...
Include>scriptfile

...it also could function like this:
Include>Var_Containing_Script_lines

Why? Consider a compiled script installed on multiple machines and the script needs frequent updates. That means constant recompiling and re-installs on all the machines.

Much more efficient to install a simple compiled base script on all the machines that has a dynamic Include> statement in it. When the script runs, an HTTPRequest> line can pull the "latest version" of the script from a file maintained in one place on a company webserver... now the script lines are in a variable. To get them Included into the script run on the PC, now I have to first write them to a file, only then can the Include> statement pull them in.

After they are pulled in, the first line of the included code can delete that file if it would be best not to have it sit around on the hard drive however... it would be an advantage not to have to write that file in the first place.

If Include> could pull in script lines directly from a variable, the steps of writing the file and later deleting the file could be eliminated.

- It would be faster, time saved
- It would be easier, less lines of code
- It would be more efficient, less wear and tear on the hard drives

Taking this concept one step further, we could even imagine...

HTTPInclude>

...which could function like a combination of HTTPRequest> and the Include> statement all-in-one. I am not recommending this however because maybe we are getting the new script lines some other way, FTP for instance... so just having Include> be able to pull in script lines directly from a variable is probably enough.

Thank you for considering this request...

Here's a link to a related post also asking for enhancements to the Include> statement:

Include function and compiling
http://www.mjtnet.com/forum/include-fun ... t5677.html

Take care

[jpuziano]

Hi again Marcus,

While shaving this morning, I thought of another benefit of this enhancement... security. If I have confidential data inside my script, passwords, client info, whatever... if I use Include> to pull in those script lines, that means I have to write that file to disk first and I'd really rather not do that.

When I got to work, I received an off-forum communication from JRL that pointed me to the following post:
http://www.mjtnet.com/forum/enhancement ... t6955.html

And while the original poster schwander of the above post was concerned about the Macro> command and I am talking about the Include> command, the security issue is exactly the same:

Far more dangerous is the situation where the macro is interrupted by the user (or in case of program bug) and the temporary file of decrypted script remains on the hard disk.

Good point schwander... good point... exactly what I was thinking!

To be fair, let's say that you:

• - encrypted your file containing the script lines you want to Include
  - you pull the lines in with HTTPRequest> and they are now in a variable
  - notice this provides protection against packet sniffing as you DO NOT transmit your script lines (containing your confidential data) in plain text
  - great, so you have the data and its still secure because its still encrypted
  - but can you use Include> to pull the lines into your running script?
  - Nope, you will have to decrypt first
  - After decrypting, a variable contains the unprotected script lines... can you point Include> at the variable and get those lines in?
  - Not yet... you STILL have to WRITE the UNPROTECTED script lines to a file first, then use Include> to suck them in
  - Of course, after the Include>, it would be wise to immediately delete that file you had to create and let's say you do that with a DeleteFile> command in the first line of the Included file
  - Sure the unprotected script lines (containing your sensitive data) only existed for a fraction of a second before deleting... however... see a few comments below from JRL taken from schwander's original post referenced above:

If you use the include> function rather than the Macro> function you can delete the script immediately after creation. Make the first line of the script being written to disk a deleteFile> function that deletes its own script. In this way the script exists on the disk for a fraction of a second.

It is true this is not absolutely secure, A very astute user might possibly use a program to wait for the file to exist and grab it during its one hundred thousandth of a second life time. To help prevent this you could also randomize the file name and location.

Still not secure because the file did exist on disk and that same astute user might find it using a deleted file recovery tool. So the second line of the script should be a WriteLn> that writes gibberish to the script file name thus preventing anyone whose resources fall short of a major government from recovering the original file contents. If you do that you would of course add another DeleteFile> after writing the gibberish.

Wow. Thanks JRL for covering all those angles... and if the data I'm protecting is important enough, yes I would go through all that trouble.

On the other hand... the need to do all of that would be ELIMINATED if the Include> statement could simply read in script lines straight from a variable.

Sorry for being so demanding... Yes I want security but I also want it to be easy (or... as easy as possible).

And let me just say... several times in the last 10 years I have almost moved on to another product seeking some command or ability not possible or yet available in Macro Scheduler... and every time Marcus has come through and I find myself happily expanding the capabilities of my existing scripts.

Thank you for considering this Marcus and if anyone else out there appreciates security and this enhancement in particular... then let's hear from you... that's what the forums are for.

[Marcus Tettmar]

We'll definitely consider the ability to execute code from a variable.

I'm not convinced the existing Include statement is the way to do it though as that is a traditional Include statement which works like the Include statement in pretty much any other programming language. I think it should stay that way, but certainly I can see the benefit of being able to execute code from a variable, so it's worth considering.

Maybe all we need is an ExecuteCode> statement. Which could take one or more lines of code.

It's on the wish list anyway.

[jpuziano]

Maybe all we need is an ExecuteCode> statement. Which could take one or more lines of code.

That would certainly do it and if I can help by testing a beta version, just let me know.

Thanks Marcus, much appreciated!

[jpuziano]

Mi Marcus,

Not to be picky... and I'm almost afraid to post this because I need this ability asap at work... however I am thinking that maybe ExecuteCode> is not the best name for the new command... because we already have ExecuteFile>

ExecuteFile

ExecuteFile>file_to_execute[,parameters]

Executes a file using the application associated with the given file's filetype.

file_to_execute can include a full path.

Abbreviation : Exe
See also: RunProgram

Example

ExecuteFile>report.doc

or

Let>filename=c:\my documents\accounts.xls

ExecuteFile>filename

Both ExecuteFile and RunProgram deal with starting up "another" process OUTSIDE of the currently running script.

What I want is much closer to Include> as it will pull in script lines from a variable and carry on using those lines INSIDE the currently running script.

Following the precident set by the well-named LabelToVar> command... I recommend that we call the new command...

IncludeFromVar>

An additional benefit to this name is... when someone is searching the Help File for "Include" or they look at an alphabetical listing of the commands, they are going to see Include> and IncludeFromVar> together and that is as it should be because they BOTH function to include (pull in) script lines into the running script... verses ExecuteFile> and RunProgram> which definately DO NOT pull in lines into the running script.

Marcus, your thoughts? Anyone else?

[Marcus Tettmar]

Whatever. Toss a coin.

[Marcus Tettmar]

I see pros and cons of both names. I don't think the name matters right now. I don't think the help file keyword issue matters either way since less than 1% of users will likely use it. The functionality doesn't even exist yet anyway. I might call it JP1>

[jpuziano]

JP1>

I like the sound of that!

[jpuziano]

Hi Marcus and everyone,

Just updating this post to say IncludeFromVar> was added...

Version 14.0.1 31/01/2012
- IncludeFromVar function

...and to say thanks for adding this one Marcus.

For my purposes, the combination of HTMLRequest> and IncludeFromVar> is fantastic.

This has GREATLY simplified pushing new versions of a compiled script out to my users... in fact... it has eliminated the need for users to MANUALLY install the newest version of the script... because now they automatically get the latest version everytime they fire it up!

If you're curious, read the following post which describes a use scenario:

IncludeFromVar
http://www.mjtnet.com/forum/includefromvar-t7624.html

Thanks again!