User Commands - where should they go?

Overview

By default Dyalog is looking for User Commands in a sub folder Salt\Spice within the Dyalog installation folder. Therefore the easiest way to get your own User Commands recognized by Dyalog is to put put them into that directory.

Easy may it be but it also has a couple of serious disadvantages: messing up Dyalog user commands with your own user commands is not a good idea because ...

Dyalog might introduce a new user command with a name already used by you.
When a new version of Dyalog arrives you are in trouble
You need admin rights to add, change or delete files in Salt/Spice

It's certainly a much better idea to keep Dyalog's user commands separate from your own ones.

Solution

For all versions of Dyalog and all user accounts

To separate your own user commands from the Dyalog user commands is not too difficult.

For this you need a folder that hosts all your user commands. Of course that folder can have any name you like but in this document we refer to this folder as C:\MyUserCommands.

Create the folder C:\MyUserCommands.
Add that folder to the SALT search path:
1. Call "Configuration" from the "Options" menu.
2. Activate the "User Commands" tab.
3. Press the "Browse" button and browse to C:\MyUserCommands.
4. Press the "Add" button.
5. Press "OK"

Note that the forth step can be easily forgotten.

Now either restart Dyalog or execute the user command ]ureset.

For all versions of Dyalog but a specific user account (Windows)

Since this page was created Dyalog has invented a general mechanism that allows you to save any user command in a certain place because all versions of Dyalog supported at the time of writing (May 2019: 15.0 and better) scan a folder MyUCMDs which is located under %USERPROFILE%\Documents\MyUCMDs in Windows and ~ (home directory) in Linux and Mac OS.

A script file with the name setup.dyalog in this folder will be executed as part of the start-up procedure of any version of Dyalog, but any other script will be considered a user command script.

Complex User Commands

If the code which is the "real thing" is small it can and probably will go into the script which is defining the User Command as such. If it is a big thing (like ADOC) or a complete application (like Fire) than it will reside in a workspace.

That workspace can be saved along with the user command itself. Within your user command you should not use a real path to copy what it needed from that workspace. Instead you can find out what the path is by checking ##.SourceFile: that gives you the fully qualified name of the user command.

This will give you the folder name that hosts the current user command:

{⎕IO←1 ⋄ ⍵↓⍨-⌊/'\/'⍳⍨⌽⍵} ##.SourceFile

Scripts

Sometimes a user command will not contain all the code itself but use one or more scripts to perform a certain task.

Note that you cannot save such files with the extension dyalog within the folder that hosts user commands because Dyalog assumes that everything that is saved in such a file is a user command.

The solution to the problem is to give the script(s) a different extension. For example code would be just fine. You can still load such a script with the SALT commands; you just have to specify the extension explicitly.

Author: -- KaiJaeger 2015-04-04 08:50:51

Last update: 2019-05-30.

-  ⇤ ← Revision 25 as of 2011-08-05 16:00:08 → 
  Size: 3795
  Editor: KaiJaeger
  Comment:
+   ← Revision 31 as of 2019-05-30 09:04:34 → ⇥
  Size: 3598
  Editor: KaiJaeger
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 7:
-By default Dyalog is looking for any User Commands in a sub folder `Salt\Spice` within the Dyalog installation folder.
+By default Dyalog is looking for User Commands in a sub folder `Salt\Spice` within the Dyalog installation folder. Therefore the easiest way to get your own User Commands recognized by Dyalog is to put put them into that directory.
 Line 9:
-Therefore the easiest way to get your own User Commands recognized and dealt with is putting them into that directory. Easy may it be but it also has a couple of serious disadvantages: messing up Dyalog scripts with your own scripts is not a good idea because ...
+Easy may it be but it also has a couple of serious disadvantages: messing up Dyalog user commands with your own user commands is not a good idea because ...
 Line 11:
- * Dyalog might introduce a new User Command with a name already used by you. 
 * When a new version of Dyalog arrives you are in trouble. Which shall go into the new version?
+ * Dyalog might introduce a new user command with a name already used by you.
 * When a new version of Dyalog arrives you are in trouble
 * You need admin rights to add, change or delete files in `Salt/Spice`
-Line 14:
+Line 15:
-It's certainly a much better idea to keep Dyalog's User Commands separate from others.
+It's certainly a much better idea to keep Dyalog's user commands separate from your own ones.
-Line 18:
+Line 19:
-To achieve that is not too difficult:
+=== For all versions of Dyalog and all user accounts ===
-Line 20:
+Line 21:
-. Create a folder somewhere which is going to host all your User Commands.
 1. Add the folder to the SALT search path.
+To separate your own user commands from the Dyalog user commands is not too difficult.
 Line 23:
-Of course the folder can have any name you like but in this document we refer to this folder as `MyUserCommands\`.
+For this you need a folder that hosts all your user commands. Of course that folder can have any name you like but in this document we refer to this folder as `C:\MyUserCommands`.

 1. Create the folder `C:\MyUserCommands`.
 1. Add that folder to the SALT search path:
    1. Call "Configuration" from the "Options" menu.
    2. Activate the "User Commands" tab.
    3. Press the "Browse" button and browse to `C:\MyUserCommands`.
    4. Press the "Add" button.
    5. Press "OK"

Note that the forth step can be easily forgotten.

Now either restart Dyalog or execute the user command `]ureset`.

=== For all versions of Dyalog but a specific user account (Windows) ===

Since this page was created Dyalog has invented a general mechanism that allows you to save any user command in a certain place because all versions of Dyalog supported at the time of writing (May 2019: 15.0 and better) scan a folder `MyUCMDs` which is located under `%USERPROFILE%\Documents\MyUCMDs` in Windows and `~` (home directory) in Linux and Mac OS.

A script file with the name `setup.dyalog` in this folder will be executed as part of the start-up procedure of any version of Dyalog, but any other script will be considered a user command script.
-Line 27:
+Line 45:
-If the code which is the "real thing" is small it can and probably will go into the script which is defining the User Command as such. If it is a big thing (like [[ADOC]]) or a complete application (like ScriptManager) than it will reside somewhere else.
+If the code which is the "real thing" is small it can and probably will go into the script which is defining the User Command as such. If it is a big thing (like ADOC) or a complete application (like [[Fire]]) than it will reside in a workspace.
-Line 29:
+Line 47:
-Again it's not a good idea to put it into `MyUserCommands\`: name clashes and difficulties to tell User Command scripts from work horses are looming.
+That workspace can be saved along with the user command itself. Within your user command you should not use a real path to copy what it needed from that workspace. Instead you can find out what the path is by checking `##.SourceFile`: that gives you the fully qualified name of the user command.
-Line 31:
+Line 49:
-For that reason I am  proposing to have another folder for hosting the "real thing" - let's call it `MyUserCommandCode\`. This name should go into the Windows Registry with the key name:

`HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder`

Of course you need to change the Dyalog version number to the version you are actually using.

||<tablestyle="background:magenta; both; font-size:large;"> /!\ Watch out: `MyUserCommandCode\` '''must not''' be a sub-folder of `MyUserCommands\`. The reason is that Dyalog searches the folder '''''recursively''''' for User Commands! ||

Now your script need to honor this. There are two possibilities:

=== A Script ===

Your User Command script needs to find out where to find the workhorse. For this it needs a function which can read the Registry key. It then needs to read the script file and fix it.

For this you can use the [[UserCommands/ADOC | ADOC User Command]] as a role model: it has two private methods, `ReadRegKey` and `ReadUtf8File` solving these two problems.

The `Run` method makes use of these two private methods:
+This will give you the folder name that hosts the current user command:
-Line 50:
+Line 51:
-∇ r←Run(Cmd Args);browser;cmdparser;cs;ref;⎕IO;⎕ML;path;regKey
      :Access Shared Public
      ⎕IO←⎕ML←1
      regKey←'HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
      path←ReadRegKey regKey
      path,←'\adoc.dyalog'
      ⎕FIX ReadUtf8File path
      ....
+{⎕IO←1 ⋄ ⍵↓⍨-⌊/'\/'⍳⍨⌽⍵} ##.SourceFile
-Line 60:
+Line 54:
-=== A workspace ===
+== Scripts ==
-Line 62:
+Line 56:
-Your User Command script needs to find out where to find the workspace hosting the application. For this it needs a function which can read the Registry key. It then needs to read the script file and fix it.
+Sometimes a user command will not contain all the code itself but use one or more scripts to perform a certain task.
-Line 64:
+Line 58:
-For this you can use the [[UserCommands/ScriptManager | ScriptManager User Command]] as a role model: it has a private method `ReadRegKey` which is solving this problem.
+Note that you cannot save such files with the extension `dyalog` within the folder that hosts user commands because Dyalog assumes that everything that is saved in such a file is a user command.
-Line 66:
+Line 60:
-The `Run` method makes use of this method:

{{{
∇ r←Run(Cmd Args);browser;cmdparser;cs;ref;⎕IO;⎕ML;path;regKey
      :Access Shared Public
      ⎕IO←⎕ML←1
      r←''
      regKey←'HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
      path←ReadRegKey regKey
      path,←'\ScriptManager.DWS'
     
      ref←⎕NS''
      ref.⎕CY path
      ref.ScriptManager.Run'' 
∇
}}}
+The solution to the problem is to give the script(s) a different extension. For example `code` would be just fine. You can still load such a script with the SALT commands; you just have to specify the extension explicitly.
-Line 84:
+Line 63:
+Author: -- KaiJaeger <<DateTime(2015-04-04T08:50:51Z)>>
-Line 85:
+Line 65:
-Author: KaiJaeger
+Last update: 2019-05-30.