cylc message and : inconsistencies

[ColemanTom]

Description

In Cylc7 at least, I had a task which did something like cylc message -p CUSTOM "abc::efg::hij::sdf". In Cylc8, that produces an error - cannot contain: unless it occurs at the end of the first word. Changing the above to cylc message "CUSTOM:abc::efg::hij::sdf" does what was expected. However, doing this goes against the error message as there are still multiple : in there, so I'm a bit confused if it should work?

Doing similar different from CLI, outside of a workflow and you get different results.

$ cylc message -p CUSTOM -- workflow_name //20240212T0600Z/task 'hel::foo::gh::a::g'
2024-03-01T04:46:24Z hel - :foo::gh::a::g

In this case, there is no error message, it just strips out the first colon and makes hel the severity, ignoring the -p CUSTOM which was defined.

Reproducible Example

Do above commands in a task.

Expected Behaviour

Several potential things

1. If the -p or equivalent flag is passed, then the : check should not be performed as the severity is defined by the CLI already?
2. Documentation to state that error information and to avoid the use of : perhaps?
3. Consistency between within and outside a task?
4. Update the error message or disallow what I did to work past it (CUSTOM:a::b::c shouldn't work according to the error message)

[MetRonnie]

I can't reproduce the error in your first example cylc message -p CUSTOM "abc::efg::hij::sdf"

Note because there is a colon after the first word abc, Cylc treats abc as a (custom) severity level.

The rule is you can use any number of colons after the first SEVERITY:. If the first word does not end with a colon, you cannot use any colons. This is consistent with the error message "cannot contain : unless it occurs at the end of the first word".

The reason for supporting SEVERITY:msg in addition to -p SEVERITY is to allow multiple messages to be sent at different severities in the same cylc message.

The validation step that enforces only allowing colons if there is one at the end of the first word was an attempt to prevent a message like The month is: March resulting in a severity level of The month is. Admittedly it is a bit clunky but it is not really a priority to improve I'm afraid.

[ColemanTom]

Perhaps the instructions weren't quite right.

[runtime]
    [[start]]
        script = cylc message -p CUSTOM "$MSG"
        [[[environment]]]
            MSG = $(echo /usr/* | sed 's/ /::/g')

If I do MSG=abc::efg::hij::sdf, as you said, there is no error. But, do the double colon directory list and it fails.

+ cylc__job__inst__script
+ cylc message -p CUSTOM /usr/bin::/usr/etc::/usr/games::/usr/include::/usr/lib::/usr/lib64::/usr/libexec::/usr/local::/usr/sbin::/usr/share::/usr/src::/usr/tmp
InputError: Invalid task message "/usr/bin::/usr/etc::/usr/games::/usr/include::/usr/lib::/usr/lib64::/usr/libexec::/usr/local::/usr/sbin::/usr/share::/usr/src::/usr/tmp" - cannot contain `:` unless it occurs at the end of the first word

versus

+ cylc__job__inst__script
+ cylc message -p CUSTOM abc::efg::hij::sdf
+ for func_name in 'env_script' 'user_env' 'pre_script' 'script' 'post_script'

flow.cylc for the above outputs

[scheduling]
    initial cycle point = 20200101T0000Z
    final cycle point = 20200101T0000Z
    [[graph]]
        PT6H = """
                start & end
        """
[runtime]
    [[root]]
        init-script = set -x
        platform = localhost
    [[start]]
        script = cylc message -p CUSTOM "$MSG"
        [[[environment]]]
                MSG = abc::efg::hij::sdf
    [[end]]
        script = cylc message -p CUSTOM "$MSG"
        [[[environment]]]
                MSG = $(echo /usr/* | sed 's/ /::/g')

That is using cylc-flow=8.2.4.

[ColemanTom]

Admittedly it is a bit clunky but it is not really a priority to improve I'm afraid.

That's fine, it's easy to work around in our case, I just raise things when I see them. Based on my example above, I do think this should be classified as a bug (and could be better) - just a low priority bug.

[MetRonnie]

Ah, your real example fails validation because /usr/bin is not a word (in regex terms, a word is composed of alphanumeric chars)