Scripting:"Write" cmd seems somewhat misnamed, IMO

[j_c_hallgren]

Maybe this should be in another sub-forum, but I'll put it here...cause it's sort of a wish..in that, I think, the new "write" cmd is somewhat misnamed as when I see that, based on other language, I presume that the command will cause output to some file, device or screen, and not present a screen allowing bulk on-the-fly input of commands...maybe it's just me, but...it's my $.02!

So what would be a better name for this function/command?
The first that comes to mind is "Run"...
Or maybe "Execute"...
Something along those lines...

[jacky]

Yeah, I would agree. But I'd go with something more like "inputscript" (to keep with the other input... commands)
"run" or "execute" can be misleading as well, I think, as it sounds like it would execute a script (kindof like command load...)

[j_c_hallgren]

Yes..."inputscript" could possibly work for me...but that's also not quite perfect either, as the other input cmds simply capture a value and assign it to a variable, right? And this is not related to variable value setting!

Hummmm..."promptscript"? Since it asks for one via a prompt...
..."cmdscript"? Since it's somewhat like a command entry...
..."scriptrun"? As it takes a script and then runs it immediately...

Just trying to find the best name...

[admin]

push

[j_c_hallgren]

push

As in a command name "push"? That is what I know only as saving an existing value on a stack, such as a register, variable or set of fields, for later use via a "pop" cmd to restore them, so it wouldn't appear to apply in this context...

[admin]

push

As in a command name "push"? That is what I know only as saving an existing value on a stack, such as a register, variable or set of fields, for later use via a "pop" cmd to restore them, so it wouldn't appear to apply in this context...

Yes, that's exactly what is happening here. A script is written, then pushed on the stack, then processed, then it pops down.

You don't like "write", so I suggest the next step: "push"!

Now you suggest "process"...

[j_c_hallgren]

We all know that sometimes what code on the inside is called and what users know it as are totally unlike for ease of use, so in this case, I think the same concept would apply...I was trying to find a two-word combo that best explains in a bit less techy way what will occur...such as entry+exec as another choice...or direct+exec, etc...yes, scripts are not for the novice, but having a name that makes one think it's doing another function isn't clear even for us tech'rs.

[admin]

We all know that sometimes what code on the inside is called and what users know it as are totally unlike for ease of use, so in this case, I think the same concept would apply...I was trying to find a two-word combo that best explains in a bit less techy way what will occur...such as entry+exec as another choice...or direct+exec, etc...yes, scripts are not for the novice, but having a name that makes one think it's doing another function isn't clear even for us tech'rs.

So "push" is too techie for you, and you are too techie for "write" (because write is an extremely novice-friendly label for a textbox where you can write, right? - but said it makes you think of output to devices! YOU are techie! ).

Tell you what: now (0083) we have both!

[j_c_hallgren]

and you are too techie for "write" (because write is an extremely novice-friendly label for a textbox where you can write, right? - but said it makes you think of output to devices! ).

My issue with "write" was more because I think of it as what the system will do once my request is done, and not what I do...so although I could write in the entry box, I can do the same thing in numerous other places as well, and they aren't known as write, ok?

That's how I arrived at the combo idea, such as entryexec, as it more fully describes what occurs (we enter, it executes)...maybe a term such as compose would have also worked...anyway, glad that you're willing to listen to us peons!

[admin]

and you are too techie for "write" (because write is an extremely novice-friendly label for a textbox where you can write, right? - but said it makes you think of output to devices! ).

My issue with "write" was more because I think of it as what the system will do once my request is done, and not what I do...so although I could write in the entry box, I can do the same thing in numerous other places as well, and they aren't known as write, ok?

That's how I arrived at the combo idea, such as entryexec, as it more fully describes what occurs (we enter, it executes)...maybe a term such as compose would have also worked...anyway, glad that you're willing to listen to us peons!

Well, but you must admit that the idea that the "system writes" is a metaphor more techie than the idea that the user writes. Also with "input" it's the user who inputs stuff, not the system.

I had another idea in the meantime: "test" or "try", since this is the main use of this command as I see it.

[j_c_hallgren]

I had another idea in the meantime: "test" or "try", since this is the main use of this command as I see it.

Well...this is SECOND time I'm having to write this! The forum vanished when I hit submit the first time.. But these are more what I was thinking...

Anyway, the other term I thought of was "prototype" which is quite descriptive of what is being done, as "test" implies (to me) more of a debug mode, so "try" is the better one of the two quoted...

The "write" command seems better suited to being saved for later use with custom reports or similar, or some future ability to create output.

[TheQwerty]

I think the real problem is as it stands Write is more complicated than it should be. (Even though the simplified version seems more complicated).

I think we should really have:
::InputScript(VariableName, [Default]);
-Prompts the user to enter in a script to be stored in VariableName.
-Arguments:
VariableName (Req.) - Variable to store script in.
Default (Opt.) - Default contents of text area.

::DoScript([ScriptVar], [Execute]);
-Executes a script.
-Arguments:
ScriptVar (Opt.) - Variable that contains the script to execute. If omitted, the user is prompted. (If omitted call InputScript).
Execute (Opt.) - |#[#]|[Label], same as Load()'s second parameter.


Really DoScript could be rolled into Load if you wanted and could come up with a good way to signify that the argument is a variable instead of file path.


This also has the advantage of allowing the script to prompt the user for a script and then be able to execute it multiple times. (Not that I can think of a use for this now..)

/me shrugs.
That's my two cents.

[admin]

... [large idea called "That's my two cents."]...

Yes, I will do something very similar to your suggestion. But I will keep write (or whatever I'll call it) nevertheless.

[jacky]

Well, but you must admit that the idea that the "system writes" is a metaphor more techie than the idea that the user writes. Also with "input" it's the user who inputs stuff, not the system.

Adding my 2cts in here, for fun : I don't think jc's reasoning is any techie, it's also one simple way to look at things, from a user POV:

What will the command do ?
- seltab, will probably select a tab
- inputfolder, will probably input/ask for a folder
- filter, will probably filter someting
- write, will probably write something... or ask me to enter a script to execute, of course

[admin]

Well, but you must admit that the idea that the "system writes" is a metaphor more techie than the idea that the user writes. Also with "input" it's the user who inputs stuff, not the system.

Adding my 2cts in here, for fun : I don't think jc's reasoning is any techie, it's also one simple way to look at things, from a user POV:

What will the command do ?
- seltab, will probably select a tab
- inputfolder, will probably input/ask for a folder
- filter, will probably filter someting
- write, will probably write something... or ask me to enter a script to execute, of course

You are cheating! inputfolder clearly asks the user to input a folder!