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
It is a little bit of an inconsistency that the st<XXX>.ctl control files live in /usr2/control, rather than /usr2/st/control. The <XXX> are cmd, err, and pgm. The issue is that if they are really specific to the station (ST) software, they should probably be maintained, and accessed, as part of /usr2/st. Moving them would parallel the use of the /usr2/fs/control for the fs<XXX>.ctl control files. It would also be consistent with the use of /usr2/fs/help and /usr2/st/help for FS and ST help files, respectively.
A problem with simply moving the files is that the local configuration might need to specify additional local command aliases (like fmout-gps) and other startup programs for the client (like monit2). So we would need additional YYcmd.ctl and YYpgm.ctl files, respectively, in /usr2/control/ (the value to use for YY is TBD). We probably don't need YYerr.ctl (additional local error messages) but maybe it should be included for consistency.
Some details of a possible implementation are given below:
Currently, the fscmd.ctl and stpgm.ctl files are processed in that order. The YYpgm.ctl file would be processed after stpgm.ctl. This maintains fscmd.ctl's priority over stpgm.ctl and gives stpgm.ctl priority over YYpgm.clt. The files are additive (no file overrides another).
The other YY<XXX>.ctl files would be processed before the corresponding st<XXX>.ctl files. The current order, which would be preserved, is st<XXX>.ctl then fs<XXX>.ctl to allow st<XXX>.ctl to override fs<XXX>.ctl when something is listed in both. Thus YY<XXX>.ctl would be able to override both.
For backward compatibility, the FS would look for the st<XX>.ctl files in both /usr2/control and /usr2/st/control at startup. To reduce confusion, if a file is in both directories, it would generate an error and the FS would stop. We could go further and if some files appear in one directory and other files in the other directory, that could also generate an error and the FS could stop. That latter option is probably the better one.
Also for backward compatibility, if any YY<XXX>.ctl files don't exist, their absence could be ignored.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
It is a little bit of an inconsistency that the st<XXX>.ctl control files live in /usr2/control, rather than /usr2/st/control. The <XXX> are cmd, err, and pgm. The issue is that if they are really specific to the station (ST) software, they should probably be maintained, and accessed, as part of /usr2/st. Moving them would parallel the use of the /usr2/fs/control for the fs<XXX>.ctl control files. It would also be consistent with the use of /usr2/fs/help and /usr2/st/help for FS and ST help files, respectively.
A problem with simply moving the files is that the local configuration might need to specify additional local command aliases (like
fmout-gps
) and other startup programs for the client (like monit2). So we would need additional YYcmd.ctl and YYpgm.ctl files, respectively, in /usr2/control/ (the value to use for YY is TBD). We probably don't need YYerr.ctl (additional local error messages) but maybe it should be included for consistency.Some details of a possible implementation are given below:
Questions:
Beta Was this translation helpful? Give feedback.
All reactions