docs: mpremote run command
Documentation URL
https://docs.micropython.org/en/latest/reference/mpremote.html#mpremote-command-run
Description
If you have a main.py on the device and invoke mpremote run /home/davef/main.py then the main.py on the device runs. To work on /home/davef/main.py and run that you can not have a main.py on the device.
Code of Conduct
Yes, I agree
mpremote: UI improvements
I think the inconsistencies in the mpremote command set make it error prone. Commands 'mount' and 'run' default to the local FS, whereas the 'fs' commands default to the remote FS, except for 'fs cp' which uses ':' to denote remote. This is confusing:
$ mpremote cp :app . ; edit app # make changes to app
$ mpremote cp app :trial # upload the changed version
$ mpremote exec "import trial" # the changes disappoint
$ mpremote rm app :trial # discard the changed versions: *actually deletes the original*
Using ':' consistently would fix this and would also be welcome if interactive sessions are added to mpremote or if the other fs commands are brought into line with cp / scp.
Command concatenation supports an on-device command session within each 'mpremote' command. But device selection isn't performed by the device, and as part of the session environment it would be better as an option like "--dev device_name". Similarly I'd suggest 'mpremote --list' for candidate devices rather than 'connect list', and 'disconnect' seems redundant.
Commands separators are needed to resolve the ambiguity caused by 'fs' commands taking a variable number of arguments:
$ mpremote mkdir pybdir cp f :pybdir
mkdir :pybdir
mkdir :cp
mkdir :f
mkdir :pybdir
OSError: [Errno 17] EEXIST
'mount' is nice but would be clearer as 'chroot', and 'cp' clearer as 'tf' standing for transfer (or better still fix 'cp :remote1 :remote2'). These changes would improve ease of use even if users can live with some of the oddities for as long as there are only a few commands.