Updated Assignments overview (markdown)

Assignments-overview.md

@@ -37,6 +37,7 @@ The task results (exit code, time, and memory consumption, etc.) are saved into
 
 ### Directories and Files
 For each job execution unique directory structure is created. Job is not restricted to specified directories (tasks can do whatever is allowed on system), but it is advised to use them inside job. In recodex-worker configuration one can specify worker default directory, this is base of every file which is produced by recodex-worker.
+
 Inside this directory temporary files for job execution are created:
 - **${DEFAULT}/downloads/${WORKER_ID}/${JOB_ID}** - where the downloaded archive is saved
 - **${DEFAULT}/submission/${WORKER_ID}/${JOB_ID}** - decompressed submission is stored here
@@ -47,7 +48,7 @@ Inside this directory temporary files for job execution are created:
 ### Configuration
 Configuration of the job which is passed to worker is generated from two parts:
 - **template** - Common template for similar kinds of tasks. Contains allmost all instructions - when fetch, move, rename files, run commands, judges, ..., task dependencies and priorities. This template can be shared by more problem assignments or every problem (probably in compiller class) can have different one.
-- **isoeval config** - includes data for instancioning the template, e.q. input file names, ...
+- **recodex-worker config** - includes data for instancioning the template, e.q. input file names, ...
 Final configuration for worker is computer generated from those two configs.
 Job configuration consist of some general information and then from list of tasks (one or more)
 
@@ -161,8 +162,10 @@ tasks:
 ```
 
 ### Job variables
-Because frontend does not know which worker gets the job, its necessary to be a little general in configuration file. This means that some worker specific things has to be transparent. Good example of this is directories, which can be placed whenever worker wants. In case of this variables were established.
-Of course there are some restrictions where variables can be used. Basically whenever filesystem paths can be used, variables can be used.
+Because frontend does not know which worker gets the job, its necessary to be a little general in configuration file. This means that some worker specific things has to be transparent. Good example of this is directories, which can be placed whenever worker wants. In case of this variables were established. There are of course some restrictions where variables can be used. Basically whenever filesystem paths can be used, variables can be used.
+
+Usage of variables in configuration is then simple and kind of shell-like. Name of variable is put inside braces which are preceded with dollar sign. Real usage is than something like this: ${VAR}. There should be no quotes or apostrophies around variable name, just simple text in braces. Parsing is simple and whenever there is dollar sign with braces job execution unit automatically assumes that this is a variable, so there is no chance to have this kind of substring.
+
 List of usable variables in job configuration:
 - **WORKER_ID** - integral identification of worker, unique on server
 - **JOB_ID** - identification of this job
@@ -222,6 +225,7 @@ results:
 
 ### Logs
 During execution tasks can use only one shared log. There is no use for multiple logs which will be used in all tasks, because of pretty small amount of information which is loged. Log is in default disabled and can be enabled in job configuration, then all logged actions in tasks will be visible here.
+
 After execution is log packed and sent back to fileserver where can be further processed.