Just spit-balling, but you make the behaviour caller defined and transient:

The "shell" calls:

   RUN "app.bas" [, args$] [ ON END RUN n | filename$ ]

And when "app.bas" ends it will then RUN flash slot 'n' or 'filename$'.

You could get additionally tricksy by:

1. Having a variable Mm.EndCmdLine$ or suchlike, the value of which would then be passed as the command line args when processing the ON END RUN.

2. Also having an optional ON ERROR RUN which would automatically receive the error number and message as its command line args.

HOWEVER ... I'm not convinced we are addressing @javavi's use-case. @javavi could you provide an explicit example of something you want to do rather than describing it in generalities ?

Best wishes,

Tom
Edited 2024-11-23 04:50 by thwill

  matherp said  

Set a string in the program and it is available at the command line when it exits. If you use my MM.END mechanism then you can run it

Maybe I didn't quite understand your solution. It seems redundant to me to run another program from flash to execute the string. Why not just enter the string (if it is defined) upon program termination into the command line environment?
Edited 2024-11-23 04:59 by javavi

  matherp said  

Sorry but I'm not going to implement anything that will inevitably cause users to make simple mistakes with bad outcomes when there are safer alternatives available.

Peter: If the program knows that it is already saved (flag) there is no risk. But I don't want to insist ...

If the concept is to run an application at the command line on instruction from File Manager then it's flawed.

There can only be a single instance of MMBasic, which is running continuously. It's just that it has two forms: command line and runtime. The runtime can accept an argument when it is started from the command line but there is no point in it trying to return an argument as there is nothing to return to - at best it can END and drop out to the command line or FLASH CHAIN to another program that is also stored in flash. The runtime isn't being called at all, operation is being handed over to it.

  Mixtel90 said  

... at best it can END and drop out to the command line or FLASH CHAIN to another program that is also stored in flash.

It can also just RUN another program (with or without command line args), note you don't need to EXECUTE "RUN ..." you can just RUN ...

Tom

javavi

As Tom says, please state the requirement rather than a solution. Then we can understand what, if anything, is an appropriate safe way of meeting it.

  matherp said  

As Tom says, please state the requirement rather than a solution.

I need the program from the runtime environment to be able to pass a string of characters directly to the command line after completing its work.
For example, like this:

And after the program completed, the content of this MM.End$ was entered into the command line.

> FILES
....

Edited 2024-11-23 05:35 by javavi

Ok, so FILES is a corner case because it can't be executed from within a program, but you could write a BASIC program that duplicates its behaviour and call that from your FM using RUN.

Any other examples?

Tom
Edited 2024-11-23 05:39 by thwill

  thwill said  

Any other examples?

I also want to accept any user-entered string in the program for execution.
But don't offer the EXECUTE command, since it has limitations.
Edited 2024-11-23 05:45 by javavi

  javavi said  

I also want to accept any user-entered string in the program for execution. But don't offer the EXECUTE command, since it has limitations.

Write the commands that the user wants to execute into a temporary file, then RUN that file, you can even have that file then RUN the file manager again.

Off the top of my head the things you can't do from a program are FILES, EDIT (did that change recently?) and setting some of the OPTIONs ... most of which require the PicoMite to reboot anyway.

Best wishes,

Tom
Edited 2024-11-23 05:50 by thwill

  javavi said  

Why not just enter the string (if it is defined) upon program termination into the command line environment?

Because in MMBasic there isn't such a command line environment to return to.

Peter's current suggestions may well be as much as you actually need.

John

  JohnS said  

Because in MMBasic there isn't such a command line environment to return to.

Sure there is, the part of the firmware that handles the prompt. I'm fairly sure what is being asked for *could* be implemented (hacked in) ... it's just *strange* and if every bit of *strange* was implemented then MMBasic would be bloated and probably unusable.

Best wishes,

Tom
Edited 2024-11-23 06:43 by thwill

OK, I guess I meant there isn't one at the moment of the kind being requested.

John

The command line is for a user to enter commands. It isn't designed to auto-run things unless it's a program that's been designated as auto run. It certainly isn't designed to run any other commands automatically as it should be impossible. You don't want to get locked out of the system because it keeps running FILES/n continuously.

If you set OPTION AUTORUN ON and OPTION BREAK 0 you are (more or less) in the wet and smelly over your wellies. :)  It's a similar thing if you can auto run command line commands. It's commonly regarded to be a "bad thing". :)

There is no OS environment.
The command interpreter, editor and BASIC interpreter are all one and the same no matter how they appear. Get one stuck and the whole system crashes, it's completely irretrievable.

Giving BASIC control of the command interpreter is giving it control of the routine that passed control to it. You can't "call" it as you got into BASIC via a Jump command - there is no return mechanism. Peter's MM.END is probably the best you can do to keep the system stable.

My keyboard is only connected via Teraterm. Unfortunately, switching with the ALT key does not work.
I have therefore temporarily replaced the ALT key with the backspace key (chr$(8)). This means I can also use the ALT-F keys.
FM v1.12, Line #69:


BTW. I can't find a table of "Special Keyboard Keys" in the manual. Am I just blind?

From the Maximite Manual:


Edited 2024-11-25 02:19 by twofingers

Hi javavi,

Today I did a lot of testing of programs with the new V6.00.01RC1 firmware. Used your FM to navigate through the folders on B:/ a lot, and it works great. A very handy tool.

If you have time to investigate the issue with copying files from B:/ to B:/ that would be great. The issue is that when in the left pane you open a folder on B:/, and try to do the same in the right pane (open a different folder on B:/), you get an error. This is on 1.12

Volhout
Edited 2024-11-26 06:28 by Volhout

Thanks Harm for the Freepins() idea!
https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=17466&LastEntry=Y#230142#230129

I included the sub in the File Manager.


and replaced this:

Regards
Michael

EDIT:
Seems to be obsolete already!?
Edited 2024-11-27 05:29 by twofingers

FM v1.13    PicoMiteVGA/HDMI 6.00.01RC2
- handling the error of no SD card
- additional BS button for Alternative functions
- loading F9 Menu from DATA
- minor fixes...
FMv1.13.zip

Hello Javavi,
Thanks a lot! This is exactly what I was looking for my picomite vga, even started my own implementation, but yours is much more complete.

Have you considered putting the code onto GitHub? Or git is not the way to go for picomite programs?

Thanks!

Hi javavi,

Have you fixed the copy of files from b:/folder/ to b:/other_folder/ ?

Volhout