Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Running an editor from ANSI C
Date: Wed, 12 Jun 2024 11:00:00 +0200
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <v4bo2g$1iqqi$1@dont-email.me>
References: <v3pge7$uf2i$1@dont-email.me> <v3r2pl$16mtl$1@dont-email.me>
 <v3r7v8$1b57j$1@dont-email.me> <v3rek5$1c4i5$1@dont-email.me>
 <v3rrtm$1e6g8$1@dont-email.me> <v3ru84$1eafb$1@dont-email.me>
 <87o78dzw1a.fsf@nosuchdomain.example.com> <v3tkmb$1o860$3@dont-email.me>
 <v3uk0l$20s0s$2@dont-email.me> <v3uoeo$21g4g$5@dont-email.me>
 <v3v6jt$23q0b$2@dont-email.me> <v3vk3m$265uv$1@dont-email.me>
 <v44itr$3jn4i$1@dont-email.me> <v46o75$dnnu$1@dont-email.me>
 <v46qj9$e4lf$1@dont-email.me> <v46uha$fj5k$1@dont-email.me>
 <v47c92$hv04$1@dont-email.me> <v4bl16$1ieto$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 12 Jun 2024 11:00:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="56b4a0ed48525cf719a93689486bb34c";
	logging-data="1665874"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180de9zJdsV3ZYKk2QgxePPfucIFdP84II="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:UsstTYdXKg3BZu/X0Vgd2Kon+LI=
In-Reply-To: <v4bl16$1ieto$1@dont-email.me>
Content-Language: en-GB
Bytes: 6157

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.)