Apologies for a late reply. I have looked at the ticket already and I was then testing it against one of my testing devices (Catalyst C3750), but in my case, regardless of how I inserted the commands or whether I used TFTP or SCP/HTTP, I couldn't replicate the issue, so I sent a message to one of our developers and was waiting for a response and if they encountered this type of behavior (I reckoned this might be a known quirk in XE drivers), but I haven't received a response yet.
It seems, however, that you were able to achieve it. The easiest solution in my mind would be to send another enter, but because how MCP works
https://wiki.unimus.net/display/UNPUB/M ... ttodevices
to send an extra enter it would require us to first see the device's prompt (a known data) before we would be able to send another, but in this case I think what happened is that the device cached the extra enter sent after a no-wait
modifier (that one tells Unimus to send the command (including enter) in the line without consequently waiting to see a device's prompt after the command is sent before sending another line of commands) and the device executed it after the copy ended. I will perform some testing on my end as well to double-check it (with my device I reckon I should see then see two prompts after my copy command ends), but yes, it seems this is what this device needed.