MicroPython Forum (Archive)

On the REPL you can use arrow-up to get the last lines you entered. It's limited to a couple of lines tough.

I agree, but recording the history will do a lot of write cycles on the flash. It is maybe not an issue when using a sd card, as you can change it, but what about the internal flash? How many write cycle can it handle?

This feature should be an option the user has to specifically turn on, knowing the risks.

For other features, like code completion, I guess this would use a lot of memory...

There is already 8 lines of history that you can retrieve using the up-arrow (at least under linux).

If your terminal is sending the ANSI escape sequence for the up arrow (which is ESC [ A) then you should be getting history displayed.

Ohh,
did not know about that. Or my terminal (screen under Linux) is not sending the right ANSI escapes.

Need to test.

History could be cached in (user adjustable) RAM. Only if you want to make it persistent, a write down could be issued for every n new commands. That should lower the write cycles quite a bit.

Yep, completion would be quite resource hungry. And since you normally do not deal with very large and complex modules like pylab on the pyboard, completion might not really be so helpful.

Another idea would be to hack ipython on the PC side to work with the pyboard. Instead of sending the commands to an local python-interpreter it would send them over serial to the pyboard. Does ipython have the ability to e.g. execute the commands on another machine?
There was something like clustering with the ipython webinterface. Would be fun to use the ipython notebook webinterface to test and debug the pyboard.

Here's a little code snippet you can run on your pyboard to see what keys are sent: and this is what I see when I press the up arrow:

I now have working: Also:
cd without args crashed, I made it cd to /

The '>' is implemented within do_cat and do_echo - I guess this should be done in a more generic way by building it into Shell.line_to_arg(line).
'micropython' is implemented using exec() - and seems to be working fine.

I'll send you a pull request once I think it's sane. [edit: done]

Yeah - we should have the various commands send their output to self.stdout and get their input from self.stdin

Then we can put the > and < processing in the line_to_arg and have it set self.stdin and self.stdout and then we just need to reset those after (or just before) each command runs.

cmd calls a function postcmd which is called after the command runs, and we can provide that function in Shell and have it restore self.stdin and self.stdout

Hi Dave-

Thanks for making this shell for micropython available! Fun, convenient, and useful!

This is an old thread, so I wonder if your shell.py and/or cmd.py has been updated since?

I'm wondering if there is a cp command, or maybe there's a different method you use the shell with to copy files?

Thanks,
Keith Ostertag

in microypthon-lib there is a module called upysh with a small set of *ix like commands
https://github.com/micropython/micropyt ... ster/upysh
Installable by direct copy or upip.
It has no cp, but that could easily be added.

The shell I wrote doesn't have a cp command, but it does have a a cat command and supports redirection so you can use: to do a copy. Adding a cp command would be pretty straight forward. You can use the help command to see what commands exist.

PRs welcome