So I just call system with nano.
The concept is an ANSI C only shell.
I can write my own text editor on top of Posix easily enough.
But I want to implent an "edit" command so that users can edit files.
And you just can't edit files without non-ASCII keys.
So at the moment I call system with nano, and it wotks. But it's a
clunky solution.
On 06/06/2024 02:18, Lawrence D'Oliveiro wrote:
The concept is an ANSI C only shell.
On Wed, 5 Jun 2024 11:59:19 +0100, Malcolm McLean wrote:
So I just call system with nano.
The trouble with system(3) is it requires a shell as an intermediary,
with consequent pitfalls involving command-line parsing.
More robust to use posix_spawn(3).
It's IMO generally a good approach to not force folks to use some
specific (or even proprietary) editor in context of an application.
It does work. But my compiler warns about rmpnam() being deprecated.
David Brown <david.brown@hesbynett.no> writes:
On 06/06/2024 10:27, Malcolm McLean wrote:
It does work. But my compiler warns about rmpnam() being deprecated.
I presume you mean "tmpnam()" here. No, it has not been deprecated -
True, but at least one form of it is not thread-safe.
On 06/06/2024 10:27, Malcolm McLean wrote:
It does work. But my compiler warns about rmpnam() being deprecated.
I presume you mean "tmpnam()" here. No, it has not been deprecated -
On 06/06/2024 02:18, Lawrence D'Oliveiro wrote:
On Wed, 5 Jun 2024 11:59:19 +0100, Malcolm McLean wrote:
So I just call system with nano.
The trouble with system(3) is it requires a shell as an intermediary, with >> consequent pitfalls involving command-line parsing.
More robust to use posix_spawn(3).
The concept is an ANSI C only shell.
I can write my own text editor on top of Posix easily enough.
But I want to implent an "edit" command so that users can edit files.
And you just can't edit files without non-ASCII keys.
So at the moment I call system with nano, and it wotks. But it's a
clunky solution.
On 06/06/2024 16:42, Mikko wrote:
On 2024-06-06 02:47:04 +0000, Malcolm McLean said:When I was learning C I was given a text editor to write as a starter >exercise. So it's not exactly a challenging program to write. If you can >intercept arrow keys so that the user can move the cursor about the
On 06/06/2024 02:18, Lawrence D'Oliveiro wrote:
On Wed, 5 Jun 2024 11:59:19 +0100, Malcolm McLean wrote:The concept is an ANSI C only shell.
So I just call system with nano.
The trouble with system(3) is it requires a shell as an intermediary,
with
consequent pitfalls involving command-line parsing.
More robust to use posix_spawn(3).
;
I can write my own text editor on top of Posix easily enough.
But I want to implent an "edit" command so that users can edit files.
Just make the editor a part of the shell.
A text editor should be able to work on a teletype, for example ed(1).
The only way I can get the Baby X shell to run nano is to use tmpnam().
I've tried mkstemp insteaad, and I just can't find a way.
(mkstemp() is more flexible, but is not defined by ISO C.)
I want to run nano (or vi, or ed), in a shell running a pure ansi C
program. So the way to do it is to create a file, write the text you
want edit to it, them call system("nano readme.txt"). Nano then grabs
the cobsole, which is what you want. You then read the file to get the edited data.
On Thu, 06 Jun 2024 12:54:57 -0700, Keith Thompson wrote:
(mkstemp() is more flexible, but is not defined by ISO C.)
I’ve said this before: C is essentially crippled without a POSIX layer underneath.
But many people have lots of use of programming in C without any kind of POSIX functionality ...
As for portability, I'm not aware of the $EDITOR convention being used
on non-POSIX systems.
On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote:
As for portability, I'm not aware of the $EDITOR convention being
used on non-POSIX systems.
Can non-POSIX systems offer anything better? Any worthwhile
alternative?
No.
On Fri, 7 Jun 2024 11:31:01 +0200, David Brown wrote:
But many people have lots of use of programming in C without any kind of
POSIX functionality ...
And all those same programs work in the presence of POSIX functionality,
On 06/06/2024 23:55, Keith Thompson wrote:
One suggestion: rather than always using nano (which not everyone is
familiar with), try reading the $EDITOR environment variable to
determine what editor to use. Concatenating the value of
getenv("EDITOR"), followed by a space, followed by the file name, is
likely to give you a valid command you can pass to system(). Fall back
to nano if getenv("EDITOR") returns a null pointer.
(For historical reasons, the convention is to use $VISUAL if it's set,
otherwise $EDITOR if it's set, otherwise some default. Originally
$VISUAL typically referred to a full-screen editor like vi and $EDITOR
to a line editor like ed, to be used when full-screen editing is not
available. That's unlikely to be relevant nowadays, and users typically
either don't set $VISUAL or set it to the same thing as $EDITOR.)
Don't do this for me; I'm not likely to use this. But others are likely
to find it more user-friendly if they can use a chosen editor.
Ah thank you. But then main has to take an extra parameter. Now will
the shell still be absolutely robust, and completely portable, and run
just anywhere?
On Fri, 7 Jun 2024 11:31:01 +0200, David Brown wrote:
But many people have lots of use of programming in C without any kind of
POSIX functionality ...
And all those same programs work in the presence of POSIX functionality,
plus you get access to a whole lot more besides.
The fact that cases keep arising where POSIX functionality would solve problems that are discussed in this group belies your point.
On 07/06/2024 10:37, Keith Thompson wrote:[...]
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:Hre's the main function for the shell.
Ah thank you. But then main has to take an extra parameter. Now will
the shell still be absolutely robust, and completely portable, and run
just anywhere?
What? Why would main need an extra parameter?
int main(int argc, char **argv)
{
}
Now to get the $EDITOR variable I will have to modify this function.
int main(int argc, char **argv, char **envp)
Now what are the implications of doing that? [...]
On 07.06.2024 14:57, Malcolm McLean wrote:
On 07/06/2024 10:37, Keith Thompson wrote:[...]
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:Hre's the main function for the shell.
Ah thank you. But then main has to take an extra parameter. Now will
the shell still be absolutely robust, and completely portable, and run >>>> just anywhere?
What? Why would main need an extra parameter?
int main(int argc, char **argv)
{
}
Now to get the $EDITOR variable I will have to modify this function.
int main(int argc, char **argv, char **envp)
Now what are the implications of doing that? [...]
I'm certainly not the most qualified person to answer that, so
just two comments...
Declaring the extra parameter doesn't spoil the code, does it?
(If you don't use it you don't need to specify it. If you have
declared it you can use it or not.)
Personally my first reflex would be to use a dedicated function
to obtain a specific environment variable, specifically getenv();
I thought it wouldn't require the 'envp' to work?
For me it works
#include <stdlib.h>
#include <stdio.h>
void main (int argc, char * argv[])
{
printf ("%s\t%s\n", argv[1], getenv(argv[1]));
}
On 07/06/2024 18:56, Janis Papanagnou wrote:
On 07.06.2024 14:57, Malcolm McLean wrote:Is getenv() standard now? When did it come in?
On 07/06/2024 10:37, Keith Thompson wrote:[...]
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:Hre's the main function for the shell.
Ah thank you. But then main has to take an extra parameter. Now will >>>>> the shell still be absolutely robust, and completely portable, and run >>>>> just anywhere?
What? Why would main need an extra parameter?
int main(int argc, char **argv)
{
}
Now to get the $EDITOR variable I will have to modify this function.
int main(int argc, char **argv, char **envp)
Now what are the implications of doing that? [...]
I'm certainly not the most qualified person to answer that, so
just two comments...
Declaring the extra parameter doesn't spoil the code, does it?
(If you don't use it you don't need to specify it. If you have
declared it you can use it or not.)
Personally my first reflex would be to use a dedicated function
to obtain a specific environment variable, specifically getenv();
I thought it wouldn't require the 'envp' to work?
For me it works
#include <stdlib.h>
#include <stdio.h>
void main (int argc, char * argv[])
{
printf ("%s\t%s\n", argv[1], getenv(argv[1]));
}
Janis
On 07/06/2024 18:56, Janis Papanagnou wrote:
On 07.06.2024 14:57, Malcolm McLean wrote:Is getenv() standard now? When did it come in?
On 07/06/2024 10:37, Keith Thompson wrote:[...]
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:Hre's the main function for the shell.
Ah thank you. But then main has to take an extra parameter. Now will >>>>> the shell still be absolutely robust, and completely portable, and run >>>>> just anywhere?
What? Why would main need an extra parameter?
int main(int argc, char **argv)
{
}I'm certainly not the most qualified person to answer that, so
Now to get the $EDITOR variable I will have to modify this function.
int main(int argc, char **argv, char **envp)
Now what are the implications of doing that? [...]
just two comments...
Declaring the extra parameter doesn't spoil the code, does it?
(If you don't use it you don't need to specify it. If you have
declared it you can use it or not.)
Personally my first reflex would be to use a dedicated function
to obtain a specific environment variable, specifically getenv();
I thought it wouldn't require the 'envp' to work?
For me it works
#include <stdlib.h>
#include <stdio.h>
void main (int argc, char * argv[])
{
printf ("%s\t%s\n", argv[1], getenv(argv[1]));
}
Janis
On 07/06/2024 15:48, David Brown wrote:
On 07/06/2024 12:46, Lawrence D'Oliveiro wrote:Any idiot can write a shell using Posix.
On Fri, 7 Jun 2024 11:31:01 +0200, David Brown wrote:
But many people have lots of use of programming in C without any kind of >>>> POSIX functionality ...
And all those same programs work in the presence of POSIX functionality, >>> plus you get access to a whole lot more besides.
No, they do not.
And even if POSIX functionality were "present", whatever you mean by
that, it would be of no help to many C programs.
The fact that cases keep arising where POSIX functionality would solve
problems that are discussed in this group belies your point.
There's no doubt that for some C programming, there are POSIX functions
that could help. And no doubt that this is the case for Malcolm's project. >>
That does not in any way demonstrate that POSIX is required for all C
programming, or that C is "essentially crippled" if POSIX is not available. >>
The whole point is to it in pure C.
On 06/06/2024 23:55, Keith Thompson wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:Just Tried it out. On my Mac, which is the whizzy machine I used for >professional development, and now repurposed, because I was allowed to
On 06/06/2024 20:54, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:I want to run nano (or vi, or ed), in a shell running a pure ansi C
On 06/06/2024 10:27, Malcolm McLean wrote:[...]
It does work. But my compiler warns about rmpnam() being deprecated. >>>>>I presume you mean "tmpnam()" here. No, it has not been deprecated - >>>>> not even in C23. I could be wrong, but this sounds like one of MSVC's >>>>> arbitrary self-declared deprecations, using scare tactics to encourage >>>>> people to use MSVC's own functions rather than standard C functions, >>>>> thus locking you into their tools and platform.
You're right, tmpnam() is not deprecated either by ISO C or by
POSIX.
But tmpfile() is likely to be better for most purposes. It creates
a
file and returns a FILE*. tmpnam() returns a string pointer, and it's >>>> possible that some other process could create a file with the same name >>>> before the caller has a chance to create it.
(mkstemp() is more flexible, but is not defined by ISO C.)
program. So the way to do it is to create a file, write the text you
want edit to it, them call system("nano readme.txt"). Nano then grabs
the cobsole, which is what you want. You then read the file to get
the edited data.
The shell isn't just a proof og concept. It has a practical purpose,
because it is FileSystem XML file editor. Whilst I'm playing about
putting Basic into it for fun, the real purpose is serious. And the
user must have an easy way of editing text files in the FileSystem
file.
But it becomes effectively a virtual computer in its own right.
OK -- but that has nothing at all to do with my post, which was about
how to generate the temporary file name.
One suggestion: rather than always using nano (which not everyone is
familiar with), try reading the $EDITOR environment variable to
determine what editor to use. Concatenating the value of
getenv("EDITOR"), followed by a space, followed by the file name, is
likely to give you a valid command you can pass to system(). Fall back
to nano if getenv("EDITOR") returns a null pointer.
(For historical reasons, the convention is to use $VISUAL if it's set,
otherwise $EDITOR if it's set, otherwise some default. Originally
$VISUAL typically referred to a full-screen editor like vi and $EDITOR
to a line editor like ed, to be used when full-screen editing is not
available. That's unlikely to be relevant nowadays, and users typically
either don't set $VISUAL or set it to the same thing as $EDITOR.)
keep it, getenv(EDITOR) returns null, and VISUAL also returns null. So
this system has been broken by some wicked person.
Is getenv() standard now? When did it come in?
On Fri, 7 Jun 2024 10:47:57 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote:
As for portability, I'm not aware of the $EDITOR convention being
used on non-POSIX systems.
Can non-POSIX systems offer anything better? Any worthwhile
alternative?
No.
Yes. The one below is better.
ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL);
On 6/7/24 06:46, Lawrence D'Oliveiro wrote:
On Fri, 7 Jun 2024 11:31:01 +0200, David Brown wrote:
But many people have lots of use of programming in C without any kind
of POSIX functionality ...
And all those same programs work in the presence of POSIX
functionality,
Even those that rely upon some other operating system's corresponding functionality instead?
... POSIX is not the be-all and end-all of operating systems.
Now to get the $EDITOR variable I will have to modify this function.
int main(int argc, char **argv, char **envp)
On 07/06/2024 21:04, Scott Lurndal wrote:
How does your pure "C" shell
spawn a new process without using posix or other OS-specific
APIs?
It can call "system".
On 07/06/2024 15:48, David Brown wrote:
On 07/06/2024 12:46, Lawrence D'Oliveiro wrote:Any idiot can write a shell using Posix.
On Fri, 7 Jun 2024 11:31:01 +0200, David Brown wrote:
But many people have lots of use of programming in C without any kind of >>>> POSIX functionality ...
And all those same programs work in the presence of POSIX functionality, >>> plus you get access to a whole lot more besides.
No, they do not.
And even if POSIX functionality were "present", whatever you mean by
that, it would be of no help to many C programs.
The fact that cases keep arising where POSIX functionality would solve
problems that are discussed in this group belies your point.
There's no doubt that for some C programming, there are POSIX functions
that could help. And no doubt that this is the case for Malcolm's project. >>
That does not in any way demonstrate that POSIX is required for all C
programming, or that C is "essentially crippled" if POSIX is not available. >>
The whole point is to it in pure C. Without a single call to a function
that isn't in the C standard library.
And make it fully functional. A real shell, that people will want to
really use. That's my hobby project. I'm a free man now. I've got the
time. I don't have to write code that makes money any more.
On Fri, 7 Jun 2024 09:32:26 -0400, James Kuyper wrote:
On 6/7/24 06:46, Lawrence D'Oliveiro wrote:
On Fri, 7 Jun 2024 11:31:01 +0200, David Brown wrote:
But many people have lots of use of programming in C without any kind
of POSIX functionality ...
And all those same programs work in the presence of POSIX
functionality,
Even those that rely upon some other operating system's corresponding
functionality instead?
If it really was “corresponding”, then it would already be available via some POSIX-compatible wrapper for that OS.
... POSIX is not the be-all and end-all of operating systems.
You’re right. It’s not. Linux is.
On 07/06/2024 21:04, Scott Lurndal wrote:
How does your pure "C" shell
spawn a new process without using posix or other OS-specific
APIs?
It can call "system".
On 6/7/24 19:59, Lawrence D'Oliveiro wrote:
On Fri, 7 Jun 2024 09:32:26 -0400, James Kuyper wrote:
... POSIX is not the be-all and end-all of operating systems.
You’re right. It’s not. Linux is.
... even I'm not foolish enough to make such a claim for Linux.
nano might run a text editor... Or it might run something else... Fair enough?
On 08/06/2024 01:32, Kaz Kylheku wrote:
Bug I take it that by shell you mean something which is primarily aIt calls system so that real users can use it for real.
command interpreter for driving an operating system, not an adventure
game engine, or sophsticated programming language run-time.
On Fri, 7 Jun 2024 14:24:29 +0300, Michael S wrote:
On Fri, 7 Jun 2024 10:47:57 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote:
As for portability, I'm not aware of the $EDITOR convention being
used on non-POSIX systems.
Can non-POSIX systems offer anything better? Any worthwhile
alternative?
No.
Yes. The one below is better.
ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL);
On Windows, that combines the command-line arguments into a single
string. Which then has to be teased apart by the receiving program.
Assuming the two ends can agree on consistent rules for doing so.
Michael S <already5chosen@yahoo.com> writes:
On Fri, 7 Jun 2024 10:47:57 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote:
As for portability, I'm not aware of the $EDITOR convention being
used on non-POSIX systems.
Can non-POSIX systems offer anything better? Any worthwhile
alternative?
No.
Yes. The one below is better.
ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL);
For those not familiar with Windows, "edit" is not a command name, it's
an "object verb". The above call invokes the user's configured command
to edit the specified file. It might invoke a text editor for foo.txt,
an image editor for foo.png. It's similar to right-clicking a file in
the file explorer and selecting "Edit". Other verbs include "open",
"print", and "properties".
But it's just no good for consumer software. Ganes are no fun without
sound. But it took about an afternoon to add fantastic audio to Baby X Windows, which inclues an MPEG codec, I just couldn't work out gow to do
it on Linux in any way that wouln't break.
ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL);
On Unix-like systems, xdg-open does something similar.
On Fri, 7 Jun 2024 23:57:58 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 7 Jun 2024 14:24:29 +0300, Michael S wrote:
On Fri, 7 Jun 2024 10:47:57 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote:
As for portability, I'm not aware of the $EDITOR convention being
used on non-POSIX systems.
Can non-POSIX systems offer anything better? Any worthwhile
alternative?
No.
Yes. The one below is better.
ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL);
On Windows, that combines the command-line arguments into a single
string. Which then has to be teased apart by the receiving program.
Assuming the two ends can agree on consistent rules for doing so.
You asked for something that is better *for user* than $EDITOR.
The one above is very clearly better for user than $EDITOR.
It is smarter - different editors are selected for different file types.
And it achieves that with zero effort on part of app developer.
On Sat, 8 Jun 2024 22:13:49 +0300, Michael S wrote:
On Fri, 7 Jun 2024 23:57:58 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 7 Jun 2024 14:24:29 +0300, Michael S wrote:
On Fri, 7 Jun 2024 10:47:57 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote:
As for portability, I'm not aware of the $EDITOR convention
being used on non-POSIX systems.
Can non-POSIX systems offer anything better? Any worthwhile
alternative?
No.
Yes. The one below is better.
ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL);
On Windows, that combines the command-line arguments into a single
string. Which then has to be teased apart by the receiving program.
Assuming the two ends can agree on consistent rules for doing so.
You asked for something that is better *for user* than $EDITOR.
The one above is very clearly better for user than $EDITOR.
Neglecting the various potential pitfalls in how the invocation
works, fine.
It is smarter - different editors are selected for different file
types. And it achieves that with zero effort on part of app
developer.
If that’s what you want, then we have xdg-open for that <https://askubuntu.com/questions/1279623/what-is-xdg-open>.
VISUAL and EDITOR are about editing text files, that’s all.
On 08/06/2024 20:13, Michael S wrote:
On Fri, 7 Jun 2024 23:57:58 -0000 (UTC)Yes. What you do is you call the shell with a option "-editor" which
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 7 Jun 2024 14:24:29 +0300, Michael S wrote:
On Fri, 7 Jun 2024 10:47:57 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 07 Jun 2024 02:37:42 -0700, Keith Thompson wrote:
As for portability, I'm not aware of the $EDITOR convention being
used on non-POSIX systems.
Can non-POSIX systems offer anything better? Any worthwhile
alternative?
No.
Yes. The one below is better.
ShellExecute(NULL, "edit", filename, NULL, NULL, SW_NORMAL);
On Windows, that combines the command-line arguments into a single
string. Which then has to be teased apart by the receiving program.
Assuming the two ends can agree on consistent rules for doing so.
You asked for something that is better *for user* than $EDITOR.
The one above is very clearly better for user than $EDITOR.
It is smarter - different editors are selected for different file types.
And it achieves that with zero effort on part of app developer.
I would be surprised if good Unices don't have something similar. But
those better ways of lounching editor are not in POSIX.
tells it which editor to use. That' beter than messing about with
environment variables.
On 07/06/2024 15:48, David Brown wrote:
On 07/06/2024 12:46, Lawrence D'Oliveiro wrote:Any idiot can write a shell using Posix.
On Fri, 7 Jun 2024 11:31:01 +0200, David Brown wrote:
But many people have lots of use of programming in C without any
kind of
POSIX functionality ...
And all those same programs work in the presence of POSIX functionality, >>> plus you get access to a whole lot more besides.
No, they do not.
And even if POSIX functionality were "present", whatever you mean by
that, it would be of no help to many C programs.
The fact that cases keep arising where POSIX functionality would solve
problems that are discussed in this group belies your point.
There's no doubt that for some C programming, there are POSIX
functions that could help. And no doubt that this is the case for
Malcolm's project.
That does not in any way demonstrate that POSIX is required for all C
programming, or that C is "essentially crippled" if POSIX is not
available.
The whole point is to it in pure C. Without a single call to a function
that isn't in the C standard library.
And make it fully functional. A real shell, that people will want to
really use. That's my hobby project. I'm a free man now. I've got the
time. I don't have to write code that makes money any more.
On Sun, 9 Jun 2024 07:24:14 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
If that’s what you want, then we have xdg-open for thatWhich is non-POSIX.
<https://askubuntu.com/questions/1279623/what-is-xdg-open>.
My shell can mount a FileSystem.xml file as a filing system and use that
as backing store. No other shell can do that. That's why I need a shell. Because a shell is effectively an editor for a filing system.
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.
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 embed the XML in the program as a string, and then mount an internal filesystem over it. So you can use stdio functions on internal data.
On 10/06/2024 18:14, Richard Harnden wrote:
On 10/06/2024 14:19, Malcolm McLean wrote:On 10/06/2024 18:14, Richard Harnden 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 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.
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.
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.
On 12/06/2024 10:57, Malcolm McLean wrote:
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.
Why?
You have an xml file, which is just a text file, and you want to slurp
that into your babyx - fine, so now you have a large char*.
Now you want to 'mount' that.
So you can opendir, readdir, ..., fopen something.
All just so that you can fgets?
Just so you can get a string out of a 'file'.
A string you basically had a pointer to already.
I'm sorry, but I just cannot see the point. Seems like you're making it
way more complicated than it needs to be. I'm not sure why you think it needs to exist at all. Or why you think it's a good idea.
On 12/06/2024 11:37, tTh wrote:
On 6/12/24 10:08, Malcolm McLean wrote:I'd be interested in doing that. And may thnaks to David Brown for
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.
Unless someone writes a module for fuse that allows this kind
of manipulation.
I've already come across this kind of thing, which made it
possible to read images from floppy disks of old systems.
mentining that this isnpossible. However it wouldn't be part of Baby X.
I had a quick look at the fuse webite, and I couldn't for the life of me
work out how to write a short fuse script to mount such a simple
directory structure as a FileSystem XML file.
I'm sure it's possible and not too hard to do. But it's the sort of
thing people do for money.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 152:21:01 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,816 |