Re: Running an editor from ANSI C

On 12/06/2024 10:00, David Brown wrote:

On 12/06/2024 10:08, Malcolm McLean wrote:

On 10/06/2024 18:14, Richard Harnden wrote:

On 10/06/2024 14:19, Malcolm McLean wrote:

>
Well that's a way of doing it. But it's pretty inconvenient. The shell lets you edit a FileSystem, XML file in place. Then of course I've got to test bbx_filesystem.c very rigorously because it must work, it's the heart of BabyXFS. So by writing the shell, I flush out any problems with it.
>
And of course now the fun part of the project comes in. I add MiniBasic to the shell, so you can run basic programs from it.
>

>
I'd expect to run ksh commands from within ksh, bash commands from within bash, etc.
>
I wouldn't expect a filesystem to be part of the shell at all.
>
>

On 10/06/2024 18:14, Richard Harnden wrote:

On 10/06/2024 14:19, Malcolm McLean wrote:

>
Well that's a way of doing it. But it's pretty inconvenient. The shell
lets you edit a FileSystem, XML file in place. Then of course I've got
to test bbx_filesystem.c very rigorously because it must work, it's
the heart of BabyXFS. So by writing the shell, I flush out any
problems with it.
>
And of course now the fun part of the project comes in. I add
MiniBasic to the shell, so you can run basic programs from it.
>

>
I'd expect to run ksh commands from within ksh, bash commands from
within bash, etc.
>
I wouldn't expect a filesystem to be part of the shell at all.
>
>

>
You'd expect to have a FileSystem file, and to type in at your ksh orz
zsh, cd "myfilesysyem.xml" and for ksh to mount it. But of course ksh
can't do that, because it doesn't recognise that format. So you have to
switch to the Baby X shell. And so your $ ksh promt is replaced by BBX$
prompt, to remind you that you are now in the Baby X shell and have a
limited set of commands, though of course you have cd, ls, cp, mv, rm,
edit invokes the text editor, and, though it doesn't do anything useful
yet, bb runs the MiniBasic interpreter.
>
And of course you also need "import" and "export" to transfer files int
he FileSystem XML file to and from the host.
>
And I've just written an ls which runs on a host computer, and that will
become the ls command. Currently it just prints out a list of files in
the current directory.
>
The when that is done, the next challenge is to add a grep as an
external command, not built into the shell like the other commands.

 Are you really intending to replicate the entire suite of common *nix command line programs with your own versions, just so that they can access the original data within your "filesystem xml" files?
 Do you think that people used to bash, or PowerShell, and all the command-line tools they use now and in the future, will be happy to swap that out for something akin to a weak copy of MS-DOS 2.0, just so that they can pretend your "filesystem xml" is like a directory?  Seriously?
 I have yet to hear any realistic possible use of your "filesystem xml" format, but it seems blindingly obvious that the way it would be used in practice is for people to have their resource files in a normal directory with normal files.  When they want to build an executable image with these files embedded, their build process (makefile, bat file, or whatever they like) will pack that directory into an xml file using your tools, then embed it within their executable image.
 If you /really/ believe that people will want to edit files within the xml file directly, as well as move data and files in and out of them, then there is a vastly better way to deal with that.  Make a fuse filesystem wrapper, so that the /OS/ can treat it as a filesystem.  Then people can use their normal shells, or editors, or gui programs, or whatever they want.  I use fuse filesystems all the time on Linux (sshfs mounts), and I gather they are quite practical to implement on Linux and Windows.  I'm sure there is an equivalent for Macs too.
  If you are doing all this for fun and a personal challenge, that's another matter - I'm fully supportive of that.  But you write as though you think you are writing code that you think will be useful and important to other people, and that boggles the mind.
 (I can imagine that your "Baby X" gui toolkit and your "resource compiler" might have some interest to others - it's your shell and your "filesystem xml" that I am talking about here.)
 

I don't have to worry about whether Baby X makes money or not, because that's something I've been excused. And now I'm full time programming on the things that interest me.
But yes, my view is the Baby X FileSystem is going to enhance Baby X and lift it to a new level. The ability to mount an internal filesystem in a small program is very useful indeed.
--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc