You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a more a quality of life thing, but something that I find occurs when using
the orchestrator in it's intended interactive mode (well, and also in batch mode), is that
the printed location of the microlog in the output stream of the orchestrator has an
offset from the directory that the user (or operator) is currently in.
For example, if I am in the orchestrator directory:
dt10@byron:~/Orchestrator$ Tests/ReferenceXML/run_app_standard_outputs.exp /home/dt10/graph_schema/apps/tests/supervisors/test_supervisor_100dev_to_sup_bcast_overload.xml
...
POETS> 03:26:50.02: 20(I) The microlog for the command 'load /engine = "../Config/POETSHardwareOneBox.ocfg"' will be written to '../Output/Microlog/Microlog_2022_07_14T03_26_50p0.plog'.
....
But ../Output from the current directory doesn't exist.
I don't think it matters which current directory the orchestrator is started from, though I could be wrong.
For the above example, if I change to my home directory then the same thing still happens, with the
microlog prefix as '../Output/Microlog`, regardless of user location.
I can see the potential benefit of locating the logs relative to the binary installation, sort of.
However, having the relative path that is not relative to where the "operator" is makes things
more complicated, as the user needs to edit the path before opening it in a view or editor
to find out what the errors were.
It might be more user-friendly to just print the absolute path of the microlog, so that
it can be passed to less or cat, and/or to allow ctrl-click to open in other editors.
Alternatively, if relative paths are preferred as they are shorter, printing out the relative
path compared to the user's cwd would make things better for the operator, as then
they would see paths relative to where they are, rather than relative to where the
orchestrator happens to be installed.
Another approach would be to put the logs relative to the input xml, but this seems
full of unintended consequences.
I realise this can be controlled by the user through (greps documentation) path /ulog:, but it requires the user to work out how to set that and to
know that it exists.
Given the output of the orchestrator is quite verbose, printing absolute paths
would not add much, but would make it much easier to look at micrologs.
The text was updated successfully, but these errors were encountered:
This is a more a quality of life thing, but something that I find occurs when using
the orchestrator in it's intended interactive mode (well, and also in batch mode), is that
the printed location of the microlog in the output stream of the orchestrator has an
offset from the directory that the user (or operator) is currently in.
For example, if I am in the orchestrator directory:
But
../Output
from the current directory doesn't exist.I don't think it matters which current directory the orchestrator is started from, though I could be wrong.
For the above example, if I change to my home directory then the same thing still happens, with the
microlog prefix as '../Output/Microlog`, regardless of user location.
I can see the potential benefit of locating the logs relative to the binary installation, sort of.
However, having the relative path that is not relative to where the "operator" is makes things
more complicated, as the user needs to edit the path before opening it in a view or editor
to find out what the errors were.
It might be more user-friendly to just print the absolute path of the microlog, so that
it can be passed to
less
orcat
, and/or to allow ctrl-click to open in other editors.Alternatively, if relative paths are preferred as they are shorter, printing out the relative
path compared to the user's cwd would make things better for the operator, as then
they would see paths relative to where they are, rather than relative to where the
orchestrator happens to be installed.
Another approach would be to put the logs relative to the input xml, but this seems
full of unintended consequences.
I realise this can be controlled by the user through (greps documentation)
path /ulog:
, but it requires the user to work out how to set that and toknow that it exists.
Given the output of the orchestrator is quite verbose, printing absolute paths
would not add much, but would make it much easier to look at micrologs.
The text was updated successfully, but these errors were encountered: