mpremote: Behaviour is confusing with multiple mountpoints
Description
Follow on from https://github.com/micropython/micropython/pull/11777#issuecomment-2390338451.
To the naive user of a system with multiple mounted filesystems the behaviour of
$ mpremote cp foo.py :
seems nondeterministic, because the destination of the copy can only be established with knowledge of the state of the target (its current directory). The same applies to
$ mpremote ls :
The following change would provide a deterministic and more discoverable interface.
- Where there is only one mounted filesystem, behaviour remains exactly as currently.
- Where there are multiple filesystems behaviour is as follows:
mpremote ls : produces a list of mountpoints (as per ls : /).
mpremote cp foo.py : throws an exception because you cannot write to '/'.
mpremote cp foo.py :/sd/ works as at present.
While this is a breaking change, an inability to write to '/' will not surprise anyone familiar with the MP directory structure.
Code Size
No response
Implementation
I hope the MicroPython maintainers or community will implement this feature
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.