Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSHRemoteIO endmarker logic flawed #87

Closed
mih opened this issue Sep 21, 2023 · 0 comments · Fixed by #90
Closed

SSHRemoteIO endmarker logic flawed #87

mih opened this issue Sep 21, 2023 · 0 comments · Fixed by #90

Comments

@mih
Copy link
Member

mih commented Sep 21, 2023

        return cmd + " && printf '%s\\n' {} || printf '%s\\n' {}\n".format(
            sh_quote(self.REMOTE_CMD_OK),
            sh_quote(self.REMOTE_CMD_FAIL))

This is the implementation. It appends one or the other to the output of a command. They are defines as

    REMOTE_CMD_FAIL = "ora-remote: end - fail"
    REMOTE_CMD_OK = "ora-remote: end - ok"

Now the IO implementation is based on a loop over readline(). This means that if the preceding output has no final newline, the end marker will not be on its own line. However, this is the code for catching end marker

            if line == self.REMOTE_CMD_OK + '\n':
                ...
            elif line == self.REMOTE_CMD_FAIL + '\n':

It only ever considers markers that are on their own line.

One possibility would be to have markers that start with a newline. The while loop in _run() could then expect a marker on its own line. However, it would need to withhold that additional newline from the output, and also make sure that it does not mistake a regular newline for the start of an end marker that was not actually a complete one.

mih added a commit that referenced this issue Sep 21, 2023
Closes #86
Closes #87
mih added a commit that referenced this issue Sep 21, 2023
The previous implementation did not make sure that an endmarker (that is
expected to occur on a dedicated line) could be dedicated. This was
because a command whose output did not end with a newline would leave
residual content that prevented this detection.

This changeset modifies the nature of the endmarker such that a newline
is unconditionally present.

Closes #86
Closes #87
mih added a commit that referenced this issue Sep 21, 2023
The previous implementation did not make sure that an endmarker (that is
expected to occur on a dedicated line) could be dedicated. This was
because a command whose output did not end with a newline would leave
residual content that prevented this detection.

This changeset modifies the nature of the endmarker such that a newline
is unconditionally present.

Closes #86
Closes #87
@mih mih closed this as completed in #90 Sep 21, 2023
mih added a commit that referenced this issue Sep 21, 2023
The previous implementation did not make sure that an endmarker (that is
expected to occur on a dedicated line) could be dedicated. This was
because a command whose output did not end with a newline would leave
residual content that prevented this detection.

This changeset modifies the nature of the endmarker such that a newline
is unconditionally present.

Closes #86
Closes #87
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant