Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135294 > unrolled thread

GForth in Docker.

Back to article view | Back to comp.lang.forth

Contents

  GForth in Docker. Nick P <nick.268@gmail.com> - 2026-08-04 22:21 +0100
    Re: GForth in Docker. jkn <jkn+nin@nicorp.co.uk> - 2026-08-04 22:50 +0100
      Re: GForth in Docker. Nick P <nick.268@gmail.com> - 2026-08-04 23:20 +0100
        Re: GForth in Docker. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-05 06:35 +0000
          Re: GForth in Docker. Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 14:26 -0300
    Re: GForth in Docker. albert@spenarnc.xs4all.nl - 2026-08-05 10:19 +0200
      Re: GForth in Docker. Colin Tree <treecolin@gmail.com> - 2026-08-06 08:47 +1000
        Re: GForth in Docker. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-06 05:08 +0000
          Re: GForth in Docker. albert@spenarnc.xs4all.nl - 2026-08-22 16:01 +0200

#135294 — GForth in Docker.

Hi all, Im new here.

Having checked out the GForth.org webpage I have gone with the "use 
docker" option (on Ubuntu 22.04). As a result I'm having difficulty 
getting .fs files I have on one of my hard drives to run in it.

I can get the docker image running, and use the command line without a 
problem, what I cant do is run a file that is in some arbitary directory 
on a disk.

I strongly suspect its a docker issue rather than a Gforth issue as the 
Gforth site and documentation does not cover this so far as I can tell.

Does anyone have a suggestion of a source of information, jargon lite 
hopefully, that will get me started using source files with GForth in a 
docker container?

[toc] | [next] | [standalone]

#135295

On 04/08/2026 22:21, Nick P wrote:
> Hi all, Im new here.
> 
> Having checked out the GForth.org webpage I have gone with the "use 
> docker" option (on Ubuntu 22.04). As a result I'm having difficulty 
> getting .fs files I have on one of my hard drives to run in it.
> 
> I can get the docker image running, and use the command line without a 
> problem, what I cant do is run a file that is in some arbitary directory 
> on a disk.
> 
> I strongly suspect its a docker issue rather than a Gforth issue as the 
> Gforth site and documentation does not cover this so far as I can tell.
> 
> Does anyone have a suggestion of a source of information, jargon lite 
> hopefully, that will get me started using source files with GForth in a 
> docker container?

What do you mean by 'can't run...'? What did you try, and what happened?

I would expect that your 'docker run' command should include parameters
to map directory/ies on your host machine, to those in the running
docker container. Then, the GForth running in the latter will be able to
see your existing Forth files.

Does that help any?

     J^n

[toc] | [prev] | [next] | [standalone]

#135296

On 04/08/2026 22:50, jkn wrote:
> On 04/08/2026 22:21, Nick P wrote:
>> Hi all, Im new here.
>>
>> Having checked out the GForth.org webpage I have gone with the "use 
>> docker" option (on Ubuntu 22.04). As a result I'm having difficulty 
>> getting .fs files I have on one of my hard drives to run in it.
>>
>> I can get the docker image running, and use the command line without a 
>> problem, what I cant do is run a file that is in some arbitary 
>> directory on a disk.
>>
>> I strongly suspect its a docker issue rather than a Gforth issue as 
>> the Gforth site and documentation does not cover this so far as I can 
>> tell.
>>
>> Does anyone have a suggestion of a source of information, jargon lite 
>> hopefully, that will get me started using source files with GForth in 
>> a docker container?
> 
> What do you mean by 'can't run...'? What did you try, and what happened?
> 
> I would expect that your 'docker run' command should include parameters
> to map directory/ies on your host machine, to those in the running
> docker container. Then, the GForth running in the latter will be able to
> see your existing Forth files.
> 
> Does that help any?
> 
>      J^n
> 

Yes it does somewhat.

I initially tried:

$sudo docker run -it --rm forthy42/gforth filename.fs

in a terminal in the forth files folder, this was more in hope than 
expectation to be honest. It didn't work I got a number of directory not 
found errors, I forget exactly which.

Following your suggestion I did a bit of Duck Duck AI on the issue.

It came up with the suggestion of opening a terminal in the files 
directory and running the multiline:

  sudo docker run -it \
   -v "$PWD":/usr/src/myapp \
   -w /usr/src/myapp \
   forthy42/gforth gforth fac1.fs -e bye

which didn't give me any errors but closed Forth immediately. Losing the 
'-e bye' from the end kept it open, and I was able to use the colon 
definitions in the fac1.fs file at the command line.

So I seem to be able to run an arbitrary file now, but having pre-read 
through "Starting Forth" and "Forth Programmers Handbook" before setting 
out on learning Forth properly, it's clear that may not suffice.

So am I correct in thinking it's a Docker issue and I should try to 
understand that?

N.

[toc] | [prev] | [next] | [standalone]

#135297

Nick P <nick.268@gmail.com> writes:
>It came up with the suggestion of opening a terminal in the files 
>directory and running the multiline:
>
>  sudo docker run -it \
>   -v "$PWD":/usr/src/myapp \
>   -w /usr/src/myapp \
>   forthy42/gforth gforth fac1.fs -e bye
>
>which didn't give me any errors but closed Forth immediately. Losing the 
>'-e bye' from the end kept it open, and I was able to use the colon 
>definitions in the fac1.fs file at the command line.

Container technologies like Docker try to isolate the stuff inside the
container from the outside, in order to protect the outside from
whatever may go wild inside the container.  But these days it is
questionable how well that promise holds up for technologies like
Docker that rely on the OS kernel being secure; VMs make the same
promise, with a higher overhead, and I have read suggestions that
their promise has a better chance of holding up.

You probably do not want this kind of isolation when running Gforth,
but if you use Docker, you get it and have to tell it where to drop
the isolation.

Reading through the man page of docker, the -v option means that your
working directory ($PWD) becomes visible as /usr/src/myapp inside the
container with read and write permissions, and the -w option means
that /usr/src/myapp becomes the working directory inside the
container.  So with this command line, you can let gforth access files
in your working directory, but not elsewhere.  You may need a changed
-v option or additional -v options if you want to make more
directories visible to Gforth, and adjust -w accordingly.

>So I seem to be able to run an arbitrary file now, but having pre-read 
>through "Starting Forth" and "Forth Programmers Handbook" before setting 
>out on learning Forth properly, it's clear that may not suffice.

My guess is that these options may be enough for working through these
books.

>So am I correct in thinking it's a Docker issue and I should try to 
>understand that?

If you want to do more things with Gforth, like letting Gforth scripts
process files in other directories than your working directory, you
probably should look more closely at the docker options.

Alternatives:

1) Use Ubuntu's gforth package.  A disadvantage is that this is gforth
0.7.3, and misses some conveniences of the current development
version.

2) Build Gforth from the tarball; see <https://gforth.org/> for
instructions.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135531

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Nick P <nick.268@gmail.com> writes:
>>    sudo docker run -it \
>>     -v "$PWD":/usr/src/myapp \
>>     -w /usr/src/myapp \
>>     forthy42/gforth gforth fac1.fs -e bye
>
> Container technologies like Docker try to isolate the stuff inside the
> container from the outside, in order to protect the outside from
> whatever may go wild inside the container.  (...) if you use Docker,
> you get it and have to tell it where to drop the isolation.

Yes, this is the right answer in general.  Docker creates a little
isolated universe that can’t see the rest of your system, and you have
to explicitly specify what access it has to the rest of the system.
The `-v` flag is the easiest way to do that for the filesystem; `-p`
does it for network ports.

In Docker’s main use cases, this is more to protect the container from
the system than to protect the system from the container — it ensures
that what’s running inside the container doesn’t depend on your system C
library or your system installation of Python or whatever.  This is a
pretty big problem with things like Python: the “it works on my
machine!” problem.

Docker isn’t really intended or suited for interactive applications like
GForth, not really supporting X-Windows, D-Bus, etc.

Kragen

[toc] | [prev] | [next] | [standalone]

#135298

In article <114tl3v$2fsah$1@dont-email.me>, Nick P  <nick.268@gmail.com> wrote:
>Hi all, Im new here.
>
>Having checked out the GForth.org webpage I have gone with the "use
>docker" option (on Ubuntu 22.04). As a result I'm having difficulty
>getting .fs files I have on one of my hard drives to run in it.
>
>I can get the docker image running, and use the command line without a
>problem, what I cant do is run a file that is in some arbitary directory
>on a disk.
>
>I strongly suspect its a docker issue rather than a Gforth issue as the
>Gforth site and documentation does not cover this so far as I can tell.
>
>Does anyone have a suggestion of a source of information, jargon lite
>hopefully, that will get me started using source files with GForth in a
>docker container?

To me it merely proves that docker is creating problems, not solving them.
The first thing I want to know if I run a compiler where the working
directory is so that I can access files without a graphics interface.

So preferred:
unzip a forth archive
cd working
try it
cd ..
delete working recursively

If you like it, you can install the program.
If the forth is any good, you will want it all
over the place.

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [next] | [standalone]

#135301

Hi,
No Debian package... recursive dependency, cute.
Installed package from Sid, plus dependencies,

then compiled from source with many, many dependencies,
purged Sid packages, installed, that was painful.

Hoping the Sid package makes it to stable on the next release.

Colin

On 5/8/26 18:19, albert@spenarnc.xs4all.nl wrote:
> In article <114tl3v$2fsah$1@dont-email.me>, Nick P  <nick.268@gmail.com> wrote:
>> Hi all, Im new here.
>>
>> Having checked out the GForth.org webpage I have gone with the "use
>> docker" option (on Ubuntu 22.04). As a result I'm having difficulty
>> getting .fs files I have on one of my hard drives to run in it.
>>
>> I can get the docker image running, and use the command line without a
>> problem, what I cant do is run a file that is in some arbitary directory
>> on a disk.
>>
>> I strongly suspect its a docker issue rather than a Gforth issue as the
>> Gforth site and documentation does not cover this so far as I can tell.
>>
>> Does anyone have a suggestion of a source of information, jargon lite
>> hopefully, that will get me started using source files with GForth in a
>> docker container?
> 
> To me it merely proves that docker is creating problems, not solving them.
> The first thing I want to know if I run a compiler where the working
> directory is so that I can access files without a graphics interface.
> 
> So preferred:
> unzip a forth archive
> cd working
> try it
> cd ..
> delete working recursively
> 
> If you like it, you can install the program.
> If the forth is any good, you will want it all
> over the place.
> 
> Groetjes Albert

[toc] | [prev] | [next] | [standalone]

#135302

Colin Tree <treecolin@gmail.com> writes:
>No Debian package... recursive dependency, cute.

The tarball contains the stuff that needs gforth to build.

>then compiled from source with many, many dependencies,

Yes.  Gforth relies on a lot of infrastructure during building,
somewhat less at run-time.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html

[toc] | [prev] | [next] | [standalone]

#135381

In article <2026Aug6.070834@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Colin Tree <treecolin@gmail.com> writes:
>>No Debian package... recursive dependency, cute.
>
>The tarball contains the stuff that needs gforth to build.
>
>>then compiled from source with many, many dependencies,
>
>Yes.  Gforth relies on a lot of infrastructure during building,
>somewhat less at run-time.

To compare :

~/PROJECT/ciforths/ciforth: fasm lina64.fas
flat assembler  version 1.70.02  (16384 kilobytes memory)
2 passes, 56376 bytes.
~/PROJECT/ciforths/ciforth: lina64

AMDX86 ciforth beta 2026Aug22

During runtime  you need forth.lab in the current directory
for electives, scripting, compilation, SAVE-SYSTEM ,
obsolete words.

>
>- anton
>--
>M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
>comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>     New standard: https://forth-standard.org/
>EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web