Currently, INCLUDE and REQUIRE parse file names which are delimited by a space or white space character. These words preclude file names with
spaces. There are, of course, INCLUDED and REQUIRED which take a string argument from the stack, and, thus, filenames with spaces can be processed.
However, if a user wants to write a word which can parse file names with spaces, then some type of convention must be used. For example, one can define PARSE"
: parse" [char] " parse ;
and use it like this,
parse" A file name with spaces.txt"
PARSE" seems like a good solution, and is more readable than
char " parse A file name with spaces.txt"
or, equivalently in Forth-2012,
'"' parse A filename with spaces.txt"
What other methods do Forthers use for file names with spaces?
--
Krishna
...
What other methods do Forthers use for file names with spaces?
Currently, INCLUDE and REQUIRE parse file names which are delimited by a space or white space character. These words preclude file names with
spaces. There are, of course, INCLUDED and REQUIRED which take a string argument from the stack, and, thus, filenames with spaces can be processed.
However, if a user wants to write a word which can parse file names with spaces, then some type of convention must be used. For example, one can define PARSE"
: parse" [char] " parse ;
and use it like this,
parse" A file name with spaces.txt"
PARSE" seems like a good solution, and is more readable than
char " parse A file name with spaces.txt"
or, equivalently in Forth-2012,
'"' parse A filename with spaces.txt"
What other methods do Forthers use for file names with spaces?
--
Krishna
However, if a user wants to write a word which can parse file names with >spaces, then some type of convention must be used. For example, one can >define PARSE"
: parse" [char] " parse ;
Krishna Myneni <krishna.myneni@ccreweb.org> writes:...
: parse" [char] " parse ;
The result is very similar to the interpretation semantics of FILE S",
except that with PARSE" the resulting parsed string is only valid
while the current line is being parsed, while S" gives you two
buffers, each with unlimited life time.
For the problem with embedded quotes or other characters that cannot
occur in S" strings, there is S\".
Your suggestion is that a better definition of PARSE" would be
: PARSE" ( "text" -- c-addr u ) ['] s" execute ;
What do
you mean by S" gives you *two* buffers?
What do
you mean by S" gives you *two* buffers?
According to
<https://forth-standard.org/standard/file#subsection.11.3.4>:
|[...] there shall be at least two buffers. The system should be able
|to store two strings defined by sequential use of S" or S\".
Currently, INCLUDE and REQUIRE parse file names which are delimited by a >space or white space character. These words preclude file names with
spaces. There are, of course, INCLUDED and REQUIRED which take a string >argument from the stack, and, thus, filenames with spaces can be processed.
However, if a user wants to write a word which can parse file names with >spaces, then some type of convention must be used. For example, one can >define PARSE"
: parse" [char] " parse ;
and use it like this,
parse" A file name with spaces.txt"
PARSE" seems like a good solution, and is more readable than
char " parse A file name with spaces.txt"
or, equivalently in Forth-2012,
'"' parse A filename with spaces.txt"
What other methods do Forthers use for file names with spaces?
--
Krishna
In article <10pu4t0$12cqm$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
Currently, INCLUDE and REQUIRE parse file names which are delimited by a
space or white space character. These words preclude file names with
spaces. There are, of course, INCLUDED and REQUIRED which take a string
argument from the stack, and, thus, filenames with spaces can be processed. >>
However, if a user wants to write a word which can parse file names with
spaces, then some type of convention must be used. For example, one can
define PARSE"
: parse" [char] " parse ;
and use it like this,
parse" A file name with spaces.txt"
PARSE" seems like a good solution, and is more readable than
char " parse A file name with spaces.txt"
or, equivalently in Forth-2012,
'"' parse A filename with spaces.txt"
What other methods do Forthers use for file names with spaces?
A better solution is to rename files that contains spaces. --------------------------------------------------
for i in *
do
if ( echo "$i" | fgrep ' ' )
then
mv "$i" "`echo $i | sed -e s/\ /_/g`"
fi
done
-----------------------------------------------------
For what it is worth.
"this is a ""silly filename with spaces and quotes" R/W OPEN-FILE
at least shows what the file is.
On 25/03/2026 12:51 am, Krishna Myneni wrote:
...
What other methods do Forthers use for file names with spaces?
Don't recall the origin but I had this stashed away.
: GETFILENAME ( -- c-addr u )
>in @ char dup rot >in !
[char] " - if drop bl then word count
dup 0= abort" filename?" ;
On 25/03/2026 1:28 am, dxf wrote:
On 25/03/2026 12:51 am, Krishna Myneni wrote:
...
What other methods do Forthers use for file names with spaces?
Don't recall the origin but I had this stashed away.
: GETFILENAME ( -- c-addr u )
>in @ char dup rot >in !
[char] " - if drop bl then word count
dup 0= abort" filename?" ;
Fixes some quirks.
: GETFILENAME ( -- c-addr u )
source >in @ /string tuck bl skip negate rot + >in +!
c@ dup [char] " - if drop bl then word count
dup 0= abort" filename?" ;
: t getfilename cr type ;
t foobar
foobar ok
t foobar
foobar ok
t "foobar"
foobar ok
t "foobar"
foobar ok
t "foo bar"
foo bar ok
t "foo bar"
foo bar ok
t filename?
On 24 Mar 2026 at 14:51:28 CET, "Krishna Myneni" <krishna.myneni@ccreweb.org> wrote:
Currently, INCLUDE and REQUIRE parse file names which are delimited by a
space or white space character. These words preclude file names with
spaces. There are, of course, INCLUDED and REQUIRED which take a string
argument from the stack, and, thus, filenames with spaces can be processed. >>
However, if a user wants to write a word which can parse file names with
spaces, then some type of convention must be used. For example, one can
define PARSE"
: parse" [char] " parse ;
and use it like this,
parse" A file name with spaces.txt"
PARSE" seems like a good solution, and is more readable than
char " parse A file name with spaces.txt"
or, equivalently in Forth-2012,
'"' parse A filename with spaces.txt"
What other methods do Forthers use for file names with spaces?
--
Krishna
We see this problem most often when parsing file names. Some operating systems allow you to use " as a name separator. We (Wodni&Pelc, ex MPE) provide this in VFX Forth.
: GetPathSpec \ -- c-addr u | c-addr 0 ; 0 if null string
\ *G Parse the input stream for a file/path name and return
\ ** the address and length. If the name starts with a '"'
\ ** character the returned string contains the characters
\ ** between the first and second '"' characters but does
\ ** not include the '"' characters themselves. If you need
\ ** to include names that include '"' characters, delimit
\ ** the string with '(' and ')'. In all other cases a space
\ ** is used as the delimiting character. *\fo{GetPathSpec} does
\ ** not expand text macro names.
It seems like Forth is overdue for a standard way of being able to parse >modern file paths.
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
It seems like Forth is overdue for a standard way of being able to parse
modern file paths.
FILE S" has been available since Forth-94, with all filename-handling
words accepting c-addr u strings.
For files that include double-quotes and control characters, S\" has
been available since Forth-2012, with most filename-handling words
accepting c-addr u strings, and the remaining ones having c-addr u alternatives.
In article <10pu4t0$12cqm$1@dont-email.me>,--
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
Currently, INCLUDE and REQUIRE parse file names which are delimited by a
space or white space character. These words preclude file names with
spaces. There are, of course, INCLUDED and REQUIRED which take a string
argument from the stack, and, thus, filenames with spaces can be processed. >>
However, if a user wants to write a word which can parse file names with
spaces, then some type of convention must be used. For example, one can
define PARSE"
: parse" [char] " parse ;
and use it like this,
parse" A file name with spaces.txt"
PARSE" seems like a good solution, and is more readable than
char " parse A file name with spaces.txt"
or, equivalently in Forth-2012,
'"' parse A filename with spaces.txt"
What other methods do Forthers use for file names with spaces?
A better solution is to rename files that contains spaces. --------------------------------------------------
for i in *
do
if ( echo "$i" | fgrep ' ' )
then
mv "$i" "`echo $i | sed -e s/\ /_/g`"
fi
done
-----------------------------------------------------
For what it is worth.
"this is a ""silly filename with spaces and quotes" R/W OPEN-FILE
at least shows what the file is.
Groetjes Albert
--
Krishna
Hi,
Should the file name parsing be respectful to the underlying operating system.
In Linux
$ ls Vis*
'VisionFive2 build.sh ' VisionFive2_get.sh
first file name with two spaces, second with none
sorry can't do a Windows example (no windows, no gates)
I think null is a generic delimiter if a buffer was pre-filled with 1'b0
On 3/25/26 11:56 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
It seems like Forth is overdue for a standard way of being able to parse >>> modern file paths.
FILE S" has been available since Forth-94, with all filename-handling
words accepting c-addr u strings.
For files that include double-quotes and control characters, S\" has
been available since Forth-2012, with most filename-handling words
accepting c-addr u strings, and the remaining ones having c-addr u
alternatives.
A concrete example of a word which parses the filename/filepath from the input stream, based on S" or S\" would be helpful to see how it works in practice. For example, a word called TAIL which outputs the last 10 lines of a file, similar to the GNU utility.
\ From Forth, print the last 10 lines of a file specified by filepath
\ The filepath should be able to specify a file name with spaces and/or
\ other allowed special characters.
tail filepath
I will have a go at writing it, but feel free to post your solution.
On 26/03/2026 7:22 am, Krishna Myneni wrote:
On 3/25/26 11:56 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
It seems like Forth is overdue for a standard way of being able to parse >>>> modern file paths.
FILE S" has been available since Forth-94, with all filename-handling
words accepting c-addr u strings.
For files that include double-quotes and control characters, S\" has
been available since Forth-2012, with most filename-handling words
accepting c-addr u strings, and the remaining ones having c-addr u
alternatives.
A concrete example of a word which parses the filename/filepath from the input stream, based on S" or S\" would be helpful to see how it works in practice. For example, a word called TAIL which outputs the last 10 lines of a file, similar to the GNU utility.
\ From Forth, print the last 10 lines of a file specified by filepath
\ The filepath should be able to specify a file name with spaces and/or
\ other allowed special characters.
tail filepath
I will have a go at writing it, but feel free to post your solution.
A filename parser based on S\" is hardly practical. Who outside of forth >would consider that :)
In article <69c728bb$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 26/03/2026 7:22 am, Krishna Myneni wrote:
On 3/25/26 11:56 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
It seems like Forth is overdue for a standard way of being able to parse >>>>> modern file paths.
FILE S" has been available since Forth-94, with all filename-handling
words accepting c-addr u strings.
For files that include double-quotes and control characters, S\" has
been available since Forth-2012, with most filename-handling words
accepting c-addr u strings, and the remaining ones having c-addr u
alternatives.
A concrete example of a word which parses the filename/filepath from the input stream, based on S" or S\" would be helpful to see how it works in practice. For example, a word called TAIL which outputs the last 10 lines of a file, similar to the GNU utility.
\ From Forth, print the last 10 lines of a file specified by filepath
\ The filepath should be able to specify a file name with spaces and/or
\ other allowed special characters.
tail filepath
I will have a go at writing it, but feel free to post your solution.
A filename parser based on S\" is hardly practical. Who outside of forth
would consider that :)
I don't see that your tool can handle a file with leading spaces
/tmp: ls -l *b
-rw-rw-r-- 1 albert albert 27 Mar 28 08:48 ' a b'
-rw-rw-r-- 1 albert albert 36 Mar 28 08:46 'a b'
-rw-rw-r-- 1 albert albert 355328 Nov 29 12:33 forth.lab
-rw-r--r-- 1 albert albert 136583 Jan 28 12:03 fw_dynamic.itb
/tmp: lina
AMDX86 ciforth 5.5.1
" a b" GET-FILE TYPE
jdskljdsldjs
ds
s
s
s
s
s
OK
BYE
My tool is GETFILENAME which handles " or BL delimited.
On 3/25/26 11:56 AM, Anton Ertl wrote:
FILE S" has been available since Forth-94, with all filename-handling
words accepting c-addr u strings.
For files that include double-quotes and control characters, S\" has
been available since Forth-2012, with most filename-handling words
accepting c-addr u strings, and the remaining ones having c-addr u
alternatives.
A concrete example of a word which parses the filename/filepath from the >input stream, based on S" or S\" would be helpful to see how it works
in practice. For example, a word called TAIL which outputs the last 10
lines of a file, similar to the GNU utility.
Hi,
Should the file name parsing be respectful to the underlying operating >system.
...
If you insist on a parsing word, then in order to cover all possible
file names, you should base your parsing word on S\", and the usage
would be
tail\" a filename\twith a special character"
The definition might be:
: tail\" ['] s\" execute tail ;
As discussed, a parsing word that takes the rest of the line as
string-name argument has a certain cuteness:
tail$ a filename with spaces
but has the disadvantages that you cannot put comments on the same
line, that trailing spaces are invisible, and that you cannot use
special characters (tab may be ok, but is still problematic, because
you usually do not see whether it is a tab or a series of spaces).
...
Bigtreeman <treecolin@gmail.com> writes:
Hi,
Should the file name parsing be respectful to the underlying operating
system.
For use in a portable program, no. It would be really nasty if the
parsing behaviour of a given program worked one way on one OS, and differently on another. I also don't see how OS differences would
make a differences in the parsing.
The interpretation of filenames is a different issue, and OS and
(probably OS-based) mentality differences have led to lack of common
practice when dealing with relative filenames (including iForth not
working for relative filenames at all, which has led me to exclude
iForth from my tests in most cases where files are involved).
- anton
I'm happy with the Linux method of using ' as a delimiter for a
filename with spaces, but it's not going to work for everyone ?
Bigtreeman <treecolin@gmail.com> writes:
I'm happy with the Linux method of using ' as a delimiter for a
filename with spaces, but it's not going to work for everyone ?
I'm having trouble understanding what's wrong with S" filename with spaces" for the usual case. S"\ helps with some slightly more difficult ones,
but it's gforth-specific and still might not be that great with control characters and whatnot.
Worst case: HERE DUP 'f' C, 'i' C, ... HERE SWAP - ( a u )
Many forths have INCLUDE and similar that parse filespecs. Why can't
they be based on GETFILENAME or equivalent?
Why wouldn't a filespec delimited by " or BL allow comments?
Who sensibly
puts control characters in a filespec?
Were one forced to deal with
someone who foolishly did, as you say there's S\" to save the day but I >expect it to be exceptional and can be handled if/when the need arises.
I'm happy with the Linux method of using ' as a delimiter for a filename >with spaces, but it's not going to work for everyone ?
I'm having trouble understanding what's wrong with S" filename with spaces" >for the usual case. S"\ helps with some slightly more difficult ones,
but it's gforth-specific
dxf <dxforth@gmail.com> writes:
Many forths have INCLUDE and similar that parse filespecs. Why can't
they be based on GETFILENAME or equivalent?
I don't know and I don't care what GETFILENAME does. The
specification for INCLUDE is clear:
|Skip leading white space and parse name delimited by a white space >|character.
Why wouldn't a filespec delimited by " or BL allow comments?
Who said it wouldn't?
Who sensibly
puts control characters in a filespec?
Who sensibly puts white space in a file name? I think that for words
that parse file names, the usual Forth way (e.g., INCLUDE) of parsing >white-space-delimited file names is fine, and for the senseless cases,
there is INCLUDED and S" or S\".
Were one forced to deal with
someone who foolishly did, as you say there's S\" to save the day but I >>expect it to be exceptional and can be handled if/when the need arises.
Exactly.
- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/
dxf <dxforth@gmail.com> writes:
Many forths have INCLUDE and similar that parse filespecs. Why can't
they be based on GETFILENAME or equivalent?
I don't know and I don't care what GETFILENAME does. The
specification for INCLUDE is clear:
|Skip leading white space and parse name delimited by a white space |character.
Why wouldn't a filespec delimited by " or BL allow comments?
Who said it wouldn't?
Who sensibly
puts control characters in a filespec?
Who sensibly puts white space in a file name?
I think that for words
that parse file names, the usual Forth way (e.g., INCLUDE) of parsing white-space-delimited file names is fine, and for the senseless cases,
there is INCLUDED and S" or S\".
Were one forced to deal with
someone who foolishly did, as you say there's S\" to save the day but I
expect it to be exceptional and can be handled if/when the need arises.
Exactly.
Currently, INCLUDE and REQUIRE parse file names which are delimited by a space or white space character. These words preclude file names with
spaces. There are, of course, INCLUDED and REQUIRED which take a string argument from the stack, and, thus, filenames with spaces can be processed.
However, if a user wants to write a word which can parse file names with spaces, then some type of convention must be used. For example, one can define PARSE"
: parse" [char] " parse ;
and use it like this,
parse" A file name with spaces.txt"
PARSE" seems like a good solution, and is more readable than
char " parse A file name with spaces.txt"
or, equivalently in Forth-2012,
'"' parse A filename with spaces.txt"
What other methods do Forthers use for file names with spaces?
--
Krishna
On 29/03/2026 8:24 pm, Anton Ertl wrote:
I don't know and I don't care what GETFILENAME does. The
specification for INCLUDE is clear:
|Skip leading white space and parse name delimited by a white space
|character.
Are you saying Gforth's INCLUDE is limited to that?
Bernd had a solution
in 2001:
https://groups.google.com/g/comp.lang.forth/c/DIUoVsCq5Os/m/wYSJ_KuioRkJ
Who sensibly
puts control characters in a filespec?
Who sensibly puts white space in a file name?
Like it or not such is the reality on today's major desktop systems.
I wouldn't tolerate an INCLUDE that didn't handle likely cases.
cr include "foo.4th .( bar)^
dxf <dxforth@gmail.com> writes:
On 29/03/2026 8:24 pm, Anton Ertl wrote:
I don't know and I don't care what GETFILENAME does. The
specification for INCLUDE is clear:
|Skip leading white space and parse name delimited by a white space
|character.
Are you saying Gforth's INCLUDE is limited to that?
Gforth implements the standard INCLUDE
sorry ' (as used in Linux) clashes with tick i.e. ' word execute
Bigtreeman <treecolin@gmail.com> writes:If the delimiter is changed to ' it won't recognise the following space
sorry ' (as used in Linux) clashes with tick i.e. ' word execute
' is a word in its own right, i.e. it's only recognized as a word if
followed by a space. Gforth 0.7.3:
'a' . 97 ok
Bigtreeman <treecolin@gmail.com> writes:ok, so forth_sane would be no spaces or using underscores, etc,
I'm happy with the Linux method of using ' as a delimiter for a filename
with spaces, but it's not going to work for everyone ?
I think you mean the Unix shell ways of providing arguments to
programs and shell commands, including arguments that contain spaces
or other characters that usually are treated as meta-characters in the
shell (e.g., the semicolon). These ways all have some drawbacks that
tend to appear in more advanced shell usage.
In Unix, including Linux, file names (in system calls) can contain any character except NUL (because that is used for terminating file names)
and / (because that is used for separating file names in file paths).
The shells only support a subset conveniently (in particular, no
white space), and the rest through extra syntax with various drawbacks.
Forth is similar in that respect:
We can have
include sane-name.4th
or
s" insane name.4th" included
or
s\" totally\nbonkers\nname.4th" included
And when we try to put such things into strings (which happens much
less often in Forth code than in shell scripts), the disadvantages of
the less-than-sane file names become even more visible:
s" include sane-name.4th" evaluate
s\" s\" insane name.4th\" included" evaluate
s\" s\\\" totally\\nbonkers\\nname.4th\"" included
- anton
On 30/03/2026 3:08 am, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
On 29/03/2026 8:24 pm, Anton Ertl wrote:
I don't know and I don't care what GETFILENAME does. The
specification for INCLUDE is clear:
|Skip leading white space and parse name delimited by a white space
|character.
Are you saying Gforth's INCLUDE is limited to that?
Gforth implements the standard INCLUDE
Christians cite Leviticus 20. What's your point?
On 30/03/2026 9:34 am, dxf wrote:
On 30/03/2026 3:08 am, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
On 29/03/2026 8:24 pm, Anton Ertl wrote:
I don't know and I don't care what GETFILENAME does. The
specification for INCLUDE is clear:
|Skip leading white space and parse name delimited by a white space
|character.
Are you saying Gforth's INCLUDE is limited to that?
Gforth implements the standard INCLUDE
Christians cite Leviticus 20. What's your point?
LMAO. Woke up to discover Forth Inc has reverted to the standard's
INCLUDE of 2006. It's worth repeating what they said in late 2006:
SwiftForth 3.0.5 (22-Nov-2006)
Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly
parsing for a space character and checking for file existence (which
causes problems with file/directory name ambiguity), INCLUDE now uses
the more standard technique of allowing optional double-quote delimited
path names. The quotes are only required when the path name contains a
space. In all other cases, this change has no impact.
30 years after the world was introduced to filenames with spaces, forth
does a taliban in favour of one that no longer exists.
...
INCLUDE per the Forth-2012 standard is inadequate for modern desktop systems, which was the starting point of this thread.
While changing the long-standing behavior of INCLUDE is not a good idea, using a consistent method for parsing file names in use currently is needed. It doesn't matter whether or not one thinks such names are insane. Such names are a reality we have to address.
When dealing with command-line OS of times past, it was commonplace to enter >commands in the form:
rename oldfilename newfilename
For convenience I wanted to duplicate this familiar setup in forth - hence the >addition of INCLUDE RENAME DELETE etc.
Critically these words will be parsing
*filenames* which are going to be OS-specific.
I see no point to having INCLUDE et al if I'm told I can use
INCLUDED RENAME-FILE DELETE-FILE etc instead.
While changing the long-standing behavior of INCLUDE is not a good idea, >using a consistent method for parsing file names in use currently is
needed. It doesn't matter whether or not one thinks such names are
insane. Such names are a reality we have to address.
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
While changing the long-standing behavior of INCLUDE is not a good idea,
using a consistent method for parsing file names in use currently is
needed. It doesn't matter whether or not one thinks such names are
insane. Such names are a reality we have to address.
File name with just spaces have been addressed by INCLUDED long before INCLUDE was standardized in Forth-2012. ...
Forth-2012 also added 'S\"',
which makes it easier than before to also include file names that
contain double quotes or special characters.
INCLUDED is not a parsing form, which is needed in some use cases.
Forth-2012 also added 'S\"',
which makes it easier than before to also include file names that
contain double quotes or special characters.
S" and S\" are useful factors for writing a more general file name
parser e.g. for file names with spaces.
It's not clear whether or not S" and S\" will be sufficient for parsing >general UTF-8 encoded Unicode file names
On 3/30/26 5:18 PM, dxf wrote:
On 30/03/2026 9:34 am, dxf wrote:
On 30/03/2026 3:08 am, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
On 29/03/2026 8:24 pm, Anton Ertl wrote:
I don't know and I don't care what GETFILENAME does. The
specification for INCLUDE is clear:
|Skip leading white space and parse name delimited by a white space >>>>>> |character.
Are you saying Gforth's INCLUDE is limited to that?
Gforth implements the standard INCLUDE
Christians cite Leviticus 20. What's your point?
LMAO. Woke up to discover Forth Inc has reverted to the standard's
INCLUDE of 2006. It's worth repeating what they said in late 2006:
SwiftForth 3.0.5 (22-Nov-2006)
Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly
parsing for a space character and checking for file existence (which
causes problems with file/directory name ambiguity), INCLUDE now uses
the more standard technique of allowing optional double-quote delimited >> path names. The quotes are only required when the path name contains a
space. In all other cases, this change has no impact.
30 years after the world was introduced to filenames with spaces, forth
does a taliban in favour of one that no longer exists.
INCLUDE per the Forth-2012 standard is inadequate for modern desktop
systems, which was the starting point of this thread.
Krishna
dxf <dxforth@gmail.com> writes:This is a sound advantage, it makes no sense to learn two disparate
When dealing with command-line OS of times past, it was commonplace to enter >>commands in the form:
rename oldfilename newfilename
For convenience I wanted to duplicate this familiar setup in forth - hence the
addition of INCLUDE RENAME DELETE etc.
Gforth and VFX64 provide SH and SwiftForth includes $; these words
pass the rest of the line to the shell, so you can the use OS
commands, with the filename given in the syntax of the shell, and use
the shell syntax for comments. E.g., with Gforth invoking bash with
Unix commands:
sh echo test >sane-file-name
sh mv sane-file-name insane\ file\ name # mv (as in "move") renames
sh cat "insane file name" # prints "test"
sh rm 'insane file name' # rm (as in "remove") deletes
Critically these words will be parsing
*filenames* which are going to be OS-specific.
And the cool thing is, with SH all the shell-specific syntax for file
names works; three different ways of specifying "insane file name" in
bash were shown in the example above.
anton--
In article <10qf8nr$2vaat$1@dont-email.me>,... there is no reason
to use INCLUDE apart from an interactive convenience.
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
INCLUDED is not a parsing form, which is needed in some use cases.
In which use cases?
Forth-2012 also added 'S\"',
which makes it easier than before to also include file names that
contain double quotes or special characters.
S" and S\" are useful factors for writing a more general file name
parser e.g. for file names with spaces.
They are not particularly well-suited as factors (in git terminology,
they are not "plumbing", but "porcelain"). For uninterpreted strings
that are processed right away, as in an INCLUDE" word,
'"' parse
is a good factor to use instead of S".
...
It's not clear whether or not S" and S\" will be sufficient for parsing
general UTF-8 encoded Unicode file names
According to <https://forth-standard.org/standard/xchar#section.18.1>:
|All words dealing with strings shall handle xchars when the xchar word
|set is present. This includes dictionary definitions. White space
|parsing does not have to treat code points greater than $20 as white
|space.
So if the Forth system implements the standard and the xchar wordset
and uses UTF-8 as xchar, S" and S\" are guarenteed to work for parsing UTF-8-encoded filenames.
...
On 3/31/26 5:32 AM, Anton Ertl wrote:That is not Forth like. If you go this route you have to provide
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
INCLUDED is not a parsing form, which is needed in some use cases.
In which use cases?
In cases such as the TAIL example I gave earlier. For those case where
you want to provide a Forth word to the user in the form
<wordname> <file1> <file2> ...
KM
In article <10qgp41$3ejgv$2@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
On 3/31/26 5:32 AM, Anton Ertl wrote:That is not Forth like. If you go this route you have to provide
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
INCLUDED is not a parsing form, which is needed in some use cases.
In which use cases?
In cases such as the TAIL example I gave earlier. For those case where
you want to provide a Forth word to the user in the form
<wordname> <file1> <file2> ...
two boxes in a gui where you fill in filenames.
In article <10qf8nr$2vaat$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
...
INCLUDE per the Forth-2012 standard is inadequate for modern desktop
systems, which was the starting point of this thread.
No. INCLUDED is the proper way, and once proper string denotation
is introduced by recognizers e.g. "foor bar.c" there is no reason
to use INCLUDE apart from an interactive convenience.
In the time of blocks, nobody had the idea of
LOAD 13
instead of
13 LOAD
dxf <dxforth@gmail.com> writes:
When dealing with command-line OS of times past, it was commonplace to enter >> commands in the form:
rename oldfilename newfilename
For convenience I wanted to duplicate this familiar setup in forth - hence the
addition of INCLUDE RENAME DELETE etc.
Gforth and VFX64 provide SH and SwiftForth includes $; these words
pass the rest of the line to the shell, so you can the use OS
commands, with the filename given in the syntax of the shell, and use
the shell syntax for comments. E.g., with Gforth invoking bash with
Unix commands:
sh echo test >sane-file-name
sh mv sane-file-name insane\ file\ name # mv (as in "move") renames
sh cat "insane file name" # prints "test"
sh rm 'insane file name' # rm (as in "remove") deletes
Critically these words will be parsing
*filenames* which are going to be OS-specific.
And the cool thing is, with SH all the shell-specific syntax for file
names works; three different ways of specifying "insane file name" in
bash were shown in the example above.
I see no point to having INCLUDE et al if I'm told I can use
INCLUDED RENAME-FILE DELETE-FILE etc instead.
No programmer is required to use INCLUDE, and no system is required to implement INCLUDE. INCLUDE is an optional word in the FILE EXT
extension in Forth-2012. If you see no point, just don't use it and
don't implement it.
On 3/31/26 2:54 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
While changing the long-standing behavior of INCLUDE is not a good idea, >>> using a consistent method for parsing file names in use currently is
needed. It doesn't matter whether or not one thinks such names are
insane. Such names are a reality we have to address.
File name with just spaces have been addressed by INCLUDED long before
INCLUDE was standardized in Forth-2012. ...
INCLUDED is not a parsing form, which is needed in some use cases.
...
On 3/31/26 5:32 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
INCLUDED is not a parsing form, which is needed in some use cases.
In which use cases?
In cases such as the TAIL example I gave earlier.
For those case where
you want to provide a Forth word to the user in the form
<wordname> <file1> <file2> ...
What I object to are appeals to authority
On 31/03/2026 6:36 pm, Anton Ertl wrote:
Gforth and VFX64 provide SH and SwiftForth includes $; these words
pass the rest of the line to the shell, so you can the use OS
commands, with the filename given in the syntax of the shell, and use
the shell syntax for comments. E.g., with Gforth invoking bash with
Unix commands:
sh echo test >sane-file-name
sh mv sane-file-name insane\ file\ name # mv (as in "move") renames
sh cat "insane file name" # prints "test"
sh rm 'insane file name' # rm (as in "remove") deletes
It's not a solution under MS-DOS (lots of buffers and code) nor under CP/M >where AFAIK shelling is impossible.
INCLUDE is an optional word in the FILE EXT
extension in Forth-2012. If you see no point, just don't use it and
don't implement it.
What is the point - according to you since the standard never explains?
dxf <dxforth@gmail.com> writes:
What I object to are appeals to authority
Look who's talking.
dxf <dxforth@gmail.com> writes:
On 31/03/2026 6:36 pm, Anton Ertl wrote:
Gforth and VFX64 provide SH and SwiftForth includes $; these words
pass the rest of the line to the shell, so you can the use OS
commands, with the filename given in the syntax of the shell, and use
the shell syntax for comments. E.g., with Gforth invoking bash with
Unix commands:
sh echo test >sane-file-name
sh mv sane-file-name insane\ file\ name # mv (as in "move") renames
sh cat "insane file name" # prints "test"
sh rm 'insane file name' # rm (as in "remove") deletes
It's not a solution under MS-DOS (lots of buffers and code) nor under CP/M >> where AFAIK shelling is impossible.
That's fine, given that you wrote <69cb3c29$1@news.ausics.net>:
|Critically these words will be parsing
|*filenames* which are going to be OS-specific.
So here you have an OS-specific solution.
Concerning MS-DOS and CP/M, how do their commands handle file names
with spaces? Write your RENAME etc. in an OS-specific way that parses
these file names in an OS-specific way. Those who want an
OS-independent way can use RENAME-FILE.
INCLUDE is an optional word in the FILE EXT
extension in Forth-2012. If you see no point, just don't use it and
don't implement it.
What is the point - according to you since the standard never explains?
The proposal <http://www.forth200x.org/required.html> contains:
|INCLUDE is implemented and used widely, so we might just as well |standardize it
On 31/03/2026 10:41 pm, albert@spenarnc.xs4all.nl wrote:
In article <10qf8nr$2vaat$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
...
INCLUDE per the Forth-2012 standard is inadequate for modern desktop
systems, which was the starting point of this thread.
No. INCLUDED is the proper way, and once proper string denotation
is introduced by recognizers e.g. "foor bar.c" there is no reason
to use INCLUDE apart from an interactive convenience.
In the time of blocks, nobody had the idea of
LOAD 13
instead of
13 LOAD
Given CHAR [CHAR] what reason is there for 'c' ? Some swear for it
while others at it. For me it wasn't merely redundant, it required
hacking the forth interpreter to implement.
dxf <dxforth@gmail.com> writes:
On 31/03/2026 6:36 pm, Anton Ertl wrote:
Gforth and VFX64 provide SH and SwiftForth includes $; these words
pass the rest of the line to the shell, so you can the use OS
commands, with the filename given in the syntax of the shell, and use
the shell syntax for comments. E.g., with Gforth invoking bash with
Unix commands:
sh echo test >sane-file-name
sh mv sane-file-name insane\ file\ name # mv (as in "move") renames
sh cat "insane file name" # prints "test"
sh rm 'insane file name' # rm (as in "remove") deletes
It's not a solution under MS-DOS (lots of buffers and code) nor under CP/M >>where AFAIK shelling is impossible.
That's fine, given that you wrote <69cb3c29$1@news.ausics.net>:
|Critically these words will be parsing
|*filenames* which are going to be OS-specific.
So here you have an OS-specific solution.
Concerning MS-DOS and CP/M, how do their commands handle file names
with spaces? Write your RENAME etc. in an OS-specific way that parses
these file names in an OS-specific way. Those who want an
OS-independent way can use RENAME-FILE.
INCLUDE is an optional word in the FILE EXT
extension in Forth-2012. If you see no point, just don't use it and
don't implement it.
What is the point - according to you since the standard never explains?
The proposal <http://www.forth200x.org/required.html> contains:
|INCLUDE is implemented and used widely, so we might just as well >|standardize it
- anton
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
On 3/31/26 5:32 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
INCLUDED is not a parsing form, which is needed in some use cases.
In which use cases?
In cases such as the TAIL example I gave earlier.
I doubt that INCLUDE is a factor of TAIL, so how INCLUDE parses its
file name is independent of how TAIL gets its file name.
For those case where
you want to provide a Forth word to the user in the form
<wordname> <file1> <file2> ...
Ok, you "want", probably because you think it's more convenient for
the user, i.e., no technical reason.
You have the choices:
1) Pass each file names as c-addr u on the stack. Advantages:
a) This word can deal with all kinds of file names.
b) The user can use whatever is appropriate for the file name: S"
for a file name with only blanks; or S\" for a file name that
contain " or control characters. The user can use the
appropriate way for each file name.
c) The word is more flexible for use as factor in other words.
2) Write a parsing word that uses PARSE-NAME. Advantages:
a) Easy to implement.
b) fits with the usual white-space-delimited Forth syntax
Disadvantage: Cannot deal with file names containing white space.
3) Write a parsing word that uses '"' PARSE.
Advantage: Can deal with file names containing white space.
Disadvantage: Cannot deal with file names containing " or control
characters.
4) Write a parsing word that uses ['] S\" EXECUTE.
Advantage: Can deal with all kinds of file names.
Disadvantage: The user needs to escape \ (supported by 2 and 3) and
" (supported by 2), and to use appropriate sequences for control
characters (supported by neither 2 nor 3).
If you want to provide parsing words to the user, for convenience and completeness you might want to provide 2, 3, and 4, and implement 1 as
common factor, and document at least 2-4. But is the result really
more convenient for the user than just providing 1?
In article <2026Apr1.102201@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
dxf <dxforth@gmail.com> writes:
On 31/03/2026 6:36 pm, Anton Ertl wrote:
Gforth and VFX64 provide SH and SwiftForth includes $; these words
pass the rest of the line to the shell, so you can the use OS
commands, with the filename given in the syntax of the shell, and use
the shell syntax for comments. E.g., with Gforth invoking bash with
Unix commands:
sh echo test >sane-file-name
sh mv sane-file-name insane\ file\ name # mv (as in "move") renames
sh cat "insane file name" # prints "test"
sh rm 'insane file name' # rm (as in "remove") deletes
It's not a solution under MS-DOS (lots of buffers and code) nor under CP/M >>> where AFAIK shelling is impossible.
That's fine, given that you wrote <69cb3c29$1@news.ausics.net>:
|Critically these words will be parsing
|*filenames* which are going to be OS-specific.
So here you have an OS-specific solution.
Concerning MS-DOS and CP/M, how do their commands handle file names
with spaces? Write your RENAME etc. in an OS-specific way that parses
these file names in an OS-specific way. Those who want an
OS-independent way can use RENAME-FILE.
INCLUDE is an optional word in the FILE EXT
extension in Forth-2012. If you see no point, just don't use it and
don't implement it.
What is the point - according to you since the standard never explains?
The proposal <http://www.forth200x.org/required.html> contains:
|INCLUDE is implemented and used widely, so we might just as well
|standardize it
And we could add a phrase:
The filename is blank limited and can only contain Forth characters.
Whether the filename is case-insensitive is implementation defined.
The implementation documents what characters (like % $ ' " ( / \ ) are forbidden in the filename.
This is better than opening a Pandora's box on how the filename is interpreted in a general way.
INCLUDE testris.4th
is fine
INCLUDE aap$"skls
is dubious.
On 31/03/2026 10:41 pm, albert@spenarnc.xs4all.nl wrote:
In article <10qf8nr$2vaat$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
...
INCLUDE per the Forth-2012 standard is inadequate for modern desktop
systems, which was the starting point of this thread.
No. INCLUDED is the proper way, and once proper string denotation
is introduced by recognizers e.g. "foor bar.c" there is no reason
to use INCLUDE apart from an interactive convenience.
In the time of blocks, nobody had the idea of
LOAD 13
instead of
13 LOAD
Given CHAR [CHAR] what reason is there for 'c' ? Some swear for it
while others at it. For me it wasn't merely redundant, it required
hacking the forth interpreter to implement.
On 01/04/2026 01:28, dxf wrote:
On 31/03/2026 10:41 pm, albert@spenarnc.xs4all.nl wrote:
In article <10qf8nr$2vaat$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
...
INCLUDE per the Forth-2012 standard is inadequate for modern desktop
systems, which was the starting point of this thread.
No. INCLUDED is the proper way, and once proper string denotation
is introduced by recognizers e.g. "foor bar.c" there is no reason
to use INCLUDE apart from an interactive convenience.
In the time of blocks, nobody had the idea of
LOAD 13
instead of
13 LOAD
Given CHAR [CHAR] what reason is there for 'c' ? Some swear for it
while others at it. For me it wasn't merely redundant, it required
hacking the forth interpreter to implement.
I'm curious - why did you implement it if redundant and you clearly hate it?
...
: number ( c-addr -- n|d|r xt )
dup 2@ swap $FF00 and $27002703. d= if 2+ c@ postpone literal exit then
count ...
FORTH-94 didn't have any words that parsed a filename so it was never an issue.
That changed when 200x introduced REQUIRE and INCLUDE. The culprit in their >stack comment was the continued use of the token <name>. Properly a new token >representing filenames should have been defined and added to 2.2.3 'Parsed-text
notation'. This would have covered what forth systems were using in real life.
Since each OS has its own rules regard filenames there is no 'OS-independent >use of RENAME-FILE' or indeed any forth function that uses filenames.
The proposal <http://www.forth200x.org/required.html> contains:
|INCLUDE is implemented and used widely, so we might just as well
|standardize it
But you didn't standardize the INCLUDE used by Bigforth, Win32Forth and >likely VFX (it had GetPathSpec in 2001). 20 years on, they're still
waiting.
dxf <dxforth@gmail.com> writes:
FORTH-94 didn't have any words that parsed a filename so it was never an issue.
That changed when 200x introduced REQUIRE and INCLUDE. The culprit in their >> stack comment was the continued use of the token <name>. Properly a new token
representing filenames should have been defined and added to 2.2.3 'Parsed-text
notation'. This would have covered what forth systems were using in real life.
What Gforth has been using in real life is parsing
white-space-delimited file names, which goes back to the time that
Gforth first implemented INCLUDE and REQUIRE (they already were
present in Gforth-0.2 in 1996). There have been no complaints about
that behaviour in the last 3 decades, and I have no intention to
change it.
dxf <dxforth@gmail.com> writes:
Since each OS has its own rules regard filenames there is no 'OS-independent >> use of RENAME-FILE' or indeed any forth function that uses filenames.
If that was true, we could not use any of the words portably that deal
with filenames. In particular, we could not use INCLUDED and friends
in portable programs. Fortunately, that is not the case.
...
On 4/1/26 2:54 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
On 3/31/26 5:32 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
INCLUDED is not a parsing form, which is needed in some use cases.
In which use cases?
In cases such as the TAIL example I gave earlier.
I doubt that INCLUDE is a factor of TAIL, so how INCLUDE parses its
file name is independent of how TAIL gets its file name.
??
We are talking about a file name parsing word as a factor for writing
other words, not about using INCLUDE as a factor for doing that.
For those case where
you want to provide a Forth word to the user in the form
<wordname> <file1> <file2> ...
Ok, you "want", probably because you think it's more convenient for
the user, i.e., no technical reason.
You have the choices:
1) Pass each file names as c-addr u on the stack. Advantages:
a) This word can deal with all kinds of file names.
b) The user can use whatever is appropriate for the file name: S"
for a file name with only blanks; or S\" for a file name that
contain " or control characters. The user can use the
appropriate way for each file name.
c) The word is more flexible for use as factor in other words.
2) Write a parsing word that uses PARSE-NAME. Advantages:
a) Easy to implement.
b) fits with the usual white-space-delimited Forth syntax
Disadvantage: Cannot deal with file names containing white space.
3) Write a parsing word that uses '"' PARSE.
Advantage: Can deal with file names containing white space.
Disadvantage: Cannot deal with file names containing " or control
characters.
4) Write a parsing word that uses ['] S\" EXECUTE.
Advantage: Can deal with all kinds of file names.
Disadvantage: The user needs to escape \ (supported by 2 and 3) and
" (supported by 2), and to use appropriate sequences for control
characters (supported by neither 2 nor 3).
If you want to provide parsing words to the user, for convenience and
completeness you might want to provide 2, 3, and 4, and implement 1 as
common factor, and document at least 2-4. But is the result really
more convenient for the user than just providing 1?
INCLUDE (a parsing word) has been standardized after common usage
because system's implementers thought it was useful. Otherwise everyone >would just have stuck with INCLUDED as the default mechanism.
But it
wasn't convenient enough because
1. back then there was no S" in interpretation state.
2. no one wanted to force users to write s" <filename>" included
after common usage INCLUDE was around
Similarly systems implementers provided a general purpose parsing word
for file names which were usable under the OS's they were dealing with.
VFX implemented GetPathSpec for that purpose. dxforth implemented his
own file name parser, GetFileName. Obviously there is a perceived need
by system implementers for such a word.
On 2/04/2026 5:43 am, Gerry Jackson wrote:...
On 01/04/2026 01:28, dxf wrote:
Given CHAR [CHAR] what reason is there for 'c' ?
For me, it was 34 bytes better spent elsewhere.
: number ( c-addr -- n|d|r xt )
dup 2@ swap $FF00 and $27002703. d= if 2+ c@ ['] literal exit then
count ...
Given CHAR [CHAR] what reason is there for 'c' ?
For me it wasn't merely redundant, it required
hacking the forth interpreter to implement.
dxf <dxforth@gmail.com> writes:
On 2/04/2026 5:43 am, Gerry Jackson wrote:...
On 01/04/2026 01:28, dxf wrote:
Given CHAR [CHAR] what reason is there for 'c' ?
For me, it was 34 bytes better spent elsewhere.
How much do CHAR and [CHAR] cost in your system?
On 2/04/2026 5:05 pm, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
Since each OS has its own rules regard filenames there is no 'OS-independent
use of RENAME-FILE' or indeed any forth function that uses filenames.
If that was true, we could not use any of the words portably that deal
with filenames. In particular, we could not use INCLUDED and friends
in portable programs. Fortunately, that is not the case.
Of course they can be used. What is not guaranteed to work is the
filename passed to the function. If the application specifies one,
it's a dependency since the standard declined to say anything more
about filenames than what is contained in section 11.1. To my mind
they made the right call as filenames pertain to an OS - not to a
language.
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
...
Similarly systems implementers provided a general purpose parsing word
for file names which were usable under the OS's they were dealing with.
VFX implemented GetPathSpec for that purpose. dxforth implemented his
own file name parser, GetFileName. Obviously there is a perceived need
by system implementers for such a word.
I have never heard of for such a thing before the present thread, and
I certainly don't perceive any need now. Passing c-addr u on the
stack is good enough.
Not really. Let's say you wanted a word which operates on an arbitrary >number of files (which fit on a single line).
<wordname> <file_1> <file_2> <file_3> ... <file_n>
S" <file_1>" S" <file_2> S" <file_3>" ... S" <file_n>" n wordname
Forth is often advertised as a useful language for writing DSLs. Parsing >words are critical for writing a DSL when it doesn't use stack passing
of parameters.
2stack#
In article <69ce163d$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 2/04/2026 5:05 pm, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
Since each OS has its own rules regard filenames there is no 'OS-independent
use of RENAME-FILE' or indeed any forth function that uses filenames.
If that was true, we could not use any of the words portably that deal
with filenames. In particular, we could not use INCLUDED and friends
in portable programs. Fortunately, that is not the case.
Of course they can be used. What is not guaranteed to work is the
filename passed to the function. If the application specifies one,
it's a dependency since the standard declined to say anything more
about filenames than what is contained in section 11.1. To my mind
they made the right call as filenames pertain to an OS - not to a
language.
An OS requires a filename sitting in a buffer. Unix allows a BELL, quotes,blanks or an ACKnowledge in a filename. Chinese Unix allows
more. All this can be accommodated with a (byte-address count ).
INCLUDE talks about (caddr n) but this is the same in practice.
What is not guaranteed to work? Opening a file certainly succeeds.
Maybe TYPEing the (caddr n) to a VT100 terminal fails, or you
could physically damage a 640x480 color terminal.
All that is outside of the scope of INCLUDED.
You could e.g. program a recursive copy in Forth, without
examining the filenames, just using them.
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
Not really. Let's say you wanted a word which operates on an arbitrary
number of files (which fit on a single line).
Such a requirement has not surfaced for my Forth programs in the last 4 decades.
If you have such a requirement, PARSE-NAME is good enough, because
"modern file paths" (i.e., those that tend to contain spaces) tend to
be too long to fit several comfortably on a single line. E.g., here's
one of the files I have on my file system:
/home/anton/stuko/curricula/Informatik/Masterstudium_Medizinische_Informatik/module/MethodologicalFoundationsOfPublicHealthInformatics.tex
And these are not even using spaces. If this was using spaces instead
of CamelCase, it would be even longer. Here's another one:
/home/anton/stuko/curricula/Informatik/Masterstudium_Software_Engineering/module/AdvancedTopicsInDistributedAndNextGenerationComputing.tex
Even a single component of this path is up to 53 characters.
Let's take a look at file names that actually contain spaces:
/home/cds/tracks/1999 Compilation--Short Music for Short People/99.Caustic Soda; Misfits; Wizo--Welcome To Dumpsville, Population: You; NY Ranger; The Count.ogg
That's a nasty one, because this CD contains more then 99 songs, but
the CD format only supports 99 tracks, so the last track contains
several songs. Let's take a look at another one:
/home/cds/tracks/2007 Marilyn Manson--Eat Me, Drink Me/12.Heart-Shaped Glasses (When The Heart Guides The Hand) (Inhuman Remix By Jade E Puget).ogg
The users and programs that create filenames with spaces, whether it
is scripts, as in the track cases, or whether it is users using GUIs
don't avoid longish file names, unlike human CLI users.
So if you design an interface for human CLI users like
<wordname> <file_1> <file_2> <file_3> ... <file_n>
then I see little point in designing it for filenames coming out of
GUIs etc. Just use PARSE-NAME (appropriate for CLI filenames), and
leave file names containing spaces to a word like
S" <file_1>" S" <file_2> S" <file_3>" ... S" <file_n>" n wordname
Here the user can write
"MethodologicalFoundationsOfPublicHealthInformatics.tex"
"99.Caustic Soda; Misfits; Wizo--Welcome To Dumpsville, Population: You; NY Ranger; The Count.ogg"
"12.Heart-Shaped Glasses (When The Heart Guides The Hand) (Inhuman Remix By Jade E Puget).ogg"
3 wordname
[note that these are only the last components of several of the file
names shown above]
(or do it with S" if you want, and include something like SAVE-MEM if necessary on your system)
This still does not look particularly neat, but better than putting
all the file names in one line (and AFAIK some widely used Forth
systems still have hard limits on line length, and do not even do
proper error reporting when the limits are exceeded).
Plus, you can use comments between file names, which parsing words
usually do not support.
Forth is often advertised as a useful language for writing DSLs. Parsing
words are critical for writing a DSL when it doesn't use stack passing
of parameters.
Use stack-passing of parameters. For a variable number, a pair of
words that does the counting for you may be useful; something like:
As for being useful for DSLs, I have often seen the claim, but not
examples. At least not examples where some syntax that requires
significant parsing is involved. If you go there, you no longer can
mix Forth and DSL code, and Forth loses a lot of its benefits.
Krishna Myneni <krishna.myneni@ccreweb.org> writes:<SNIP>
Not really. Let's say you wanted a word which operates on an arbitrary >>number of files (which fit on a single line).
Such a requirement has not surfaced for my Forth programs in the last 4 >decades.
Let's take a look at file names that actually contain spaces:
/home/cds/tracks/1999 Compilation--Short Music for Short People/99.Caustic Soda; Misfits; Wizo--Welcome To Dumpsville, Population: You; NY Ranger; The Count.ogg
As for being useful for DSLs, I have often seen the claim, but notRight
examples. At least not examples where some syntax that requires
significant parsing is involved. If you go there, you no longer can
mix Forth and DSL code, and Forth loses a lot of its benefits.
- anton--
An OS requires a valid filename. It's not for a Forth standard to
specify or limit what that is - is all I'm saying. The standard
violated that when it specified INCLUDE REQUIRE. I'd like to think
the latter was an oversight but given certain statements made in
this thread, I fear it wasn't.
In article <69cf1078$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
An OS requires a valid filename. It's not for a Forth standard to
specify or limit what that is - is all I'm saying. The standard
violated that when it specified INCLUDE REQUIRE. I'd like to think
the latter was an oversight but given certain statements made in
this thread, I fear it wasn't.
Not an oversight. An optional convenience that works in a great
many cases.
In cases such as the TAIL example I gave earlier. For those case where
you want to provide a Forth word to the user in the form
<wordname> <file1> <file2> ...
pad/txt/rubyatXLIX <==XLIX.
pad/txt/ovid <==Dixit `ut auctoris sortem in contraria mutet,
pad/txt/wlan <==April is the cruellest month, breeding
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
In cases such as the TAIL example I gave earlier. For those case where"proxy" /demo
you want to provide a Forth word to the user in the form
<wordname> <file1> <file2> ...
Demo Forth proxy for Bash command
-- FigForth with Toad extensions
--
-- /SYS ( s -- )
-- Send string to OS as a command.
--
-- APPEND_AT ( s1 s2 a -- s3 )
-- At address 'a' append string 's2' to string 's2'
-- push result as string 's3'.
--
-- "..." ( "<">ccc<">" -- s)
-- Bounded string where double quotes are used as
-- delimiters
--
-- TAIL ( filelist -- )
-- Blank parse each item listed.
-- Add spacing as needed and append
-- to string 'tail '
-- Send string to system
Your parsing word here is WORD with a space delimiter, so standard PARSE-NAME should work here as well since you did not treat the case of
file names with spaces. How would you extend this to the case where file names are allowed to have spaces?
pad/ nasty "name" file.f <==This is a nasty named file. The file name needs to be quoted in
pad/txt/wlan <==April is the cruellest month, breeding
pad/txt/ovid <==Dixit `ut auctoris sortem in contraria mutet,
On 3/04/2026 8:44 pm, albert@spenarnc.xs4all.nl wrote:
In article <69cf1078$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
An OS requires a valid filename. It's not for a Forth standard to
specify or limit what that is - is all I'm saying. The standard
violated that when it specified INCLUDE REQUIRE. I'd like to think
the latter was an oversight but given certain statements made in
this thread, I fear it wasn't.
Not an oversight. An optional convenience that works in a great
many cases.
It would handle many more cases were it defined:
11.6.2.1714 INCLUDE
( i*x “fname”–– j*x )
Skip leading white space and parse fname delimited by a white space
character. Push the address and length of the file name represented
by fname on the stack and perform the function of INCLUDED
2.2.3 Parsed-text notation
Table 2.1: Parsed text abbreviations
...
fname a token equivalent to name representing a file name.
translation from fname to file name is implementation defined.
...
This one is better worded should anyone wish to use it as a basis for a proposal.
11.6.2.1714 INCLUDE
( i*x "fname"-- j*x )
Skip leading white space and parse fname delimited by either a white
space or an implementation defined character. Push the address and
length of the file name represented by fname on the stack and perform
the function of INCLUDED.
11.6.2.2144.10 REQUIRE
( i*x "name"-- i*x )
Skip leading white space and parse name delimited by either a white
space or an implementation defined character. Push the address and
length of the name on the stack and perform the function of REQUIRED.
2.2.3 Parsed-text notation
Table 2.1: Parsed text abbreviations
...
fname a sequence of characters corresponding to the name of a file.
the file name may be blank-delimited or enclosed by delimiter
characters which are implementation defined. the format of
the file name is implementation defined.
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
-- TAIL ( filelist -- )
Your parsing word here is WORD with a space delimiter, so standard
PARSE-NAME should work here as well since you did not treat the case of
file names with spaces. How would you extend this to the case where file
names are allowed to have spaces?
-- Blank parse each item listed.
-- Add spacing as needed.
-- Append to string 'tail ' and send to system
: TAIL
CR
PAD 0 OVER C!
"tail " PAD append_at
BEGIN BL WORD HERE
1+ C@ WHILE HERE PAD append_at
" " PAD append_at
REPEAT /sys ;
-
- You only need to enclose the nasty file name in single quotes.
-
tail pad/' nasty "name" file.f ' pad/txt/wlan pad/txt/ovid
pad/ nasty "name" file.f <==This is a nasty named file. The file name needs to be quoted in
single quotes.
Wouldn't the blank delimited parse loop fail in the case of two or more consecutive spaces? Apparently this was the reason behind Forth Inc's
pad/ nasty "name" file <==OK
pad/ yucky file <==
dxf <dxforth@gmail.com> wrote:
Wouldn't the blank delimited parse loop fail in the case of two or more
consecutive spaces? Apparently this was the reason behind Forth Inc's
Nope.
tail pad/' nasty "name" file ' pad/' yucky file '
pad/ nasty "name" file <==
pad/ yucky file <==OK
Much spaces between the two above filepaths.
The command line above is sent to Bash as one null terminated string,
spaces and all, which Bash can handle.
sjack <sjack@dontemail.me> wrote:
dxf <dxforth@gmail.com> wrote:
Wouldn't the blank delimited parse loop fail in the case of two or more
consecutive spaces? Apparently this was the reason behind Forth Inc's
tail pad/' bad file1 ' pad/' bad file2 '
sjack <sjack@dontemail.me> wrote:
sjack <sjack@dontemail.me> wrote:
dxf <dxforth@gmail.com> wrote:
Wouldn't the blank delimited parse loop fail in the case of two or more >>>> consecutive spaces? Apparently this was the reason behind Forth Inc's
anew job OK
fload job
-echo
-- TAIL ( filelist -- )
-- Blank parse each item listed.
-- Add spacing as needed.
-- Append to string 'tail ' and send to system
--
: TAILTAIL ISN'T UNIQUE
CR
PAD 0 OVER C!
"tail " PAD append_at
BEGIN BL WORD HERE
dup i. cr tell
1+ C@ WHILE HERE PAD append_at
" " PAD append_at
REPEAT cr i. tell ;
tail pad/' bad file1 ' pad/' bad file2 '
pad/' -->
bad -->
file1 -->
' -->
pad/' -->
bad -->
file2 -->
' -->
tail pad/' bad file1 ' pad/' bad file2 '
-fin-
OK
===
You be right; There be problem with multiple spaces within the
filespace; the spaces become collapsed.
SYS parses a whole line; so no problem there.
MON parses bounded string; so no problem there either.
===
AFAICS GetPathSpec etc is useful only for executing forth functions,
and even then use is likely to be limited. OTOH 200x elected to
define parsing words INCLUDE REQUIRE which let the cat out of the bag.
What I object to are appeals
to authority which apparently have caused otherwise sane people to do
insane things.
LMAO. Woke up to discover Forth Inc has reverted to the standard's
INCLUDE of 2006. It's worth repeating what they said in late 2006:
SwiftForth 3.0.5 (22-Nov-2006)
Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly
parsing for a space character and checking for file existence (which
causes problems with file/directory name ambiguity), INCLUDE now uses
the more standard technique of allowing optional double-quote delimited
path names. The quotes are only required when the path name contains a
space. In all other cases, this change has no impact.
30 years after the world was introduced to filenames with spaces, forth
does a taliban in favour of one that no longer exists.
On 31-03-2026 00:18, dxf wrote:
LMAO. Woke up to discover Forth Inc has reverted to the standard's
INCLUDE of 2006. It's worth repeating what they said in late 2006:
SwiftForth 3.0.5 (22-Nov-2006)
Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly
parsing for a space character and checking for file existence (which
causes problems with file/directory name ambiguity), INCLUDE now uses >> the more standard technique of allowing optional double-quote delimited >> path names. The quotes are only required when the path name contains a >> space. In all other cases, this change has no impact.
30 years after the world was introduced to filenames with spaces, forth
does a taliban in favour of one that no longer exists.
Was that the standard? Really? I'm already ashamed I must try to open an include file twice - because the $DIR4TH environment variable may be involved. ;-)
No, the first space is the delimiter of the filename. Ik ben gekke Henkie niet..
On 13/04/2026 3:44 am, Hans Bezemer wrote:
On 31-03-2026 00:18, dxf wrote:
LMAO. Woke up to discover Forth Inc has reverted to the standard's
INCLUDE of 2006. It's worth repeating what they said in late 2006:
SwiftForth 3.0.5 (22-Nov-2006)
Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly >>> parsing for a space character and checking for file existence (which >>> causes problems with file/directory name ambiguity), INCLUDE now uses >>> the more standard technique of allowing optional double-quote delimited
path names. The quotes are only required when the path name contains a
space. In all other cases, this change has no impact.
30 years after the world was introduced to filenames with spaces, forth
does a taliban in favour of one that no longer exists.
Was that the standard? Really? I'm already ashamed I must try to open an include file twice - because the $DIR4TH environment variable may be involved. ;-)
No, the first space is the delimiter of the filename. Ik ben gekke Henkie niet..
I should mention that Forth Inc has back-flipped on their recent decision
and restored what they had. User complaints?
I should mention that Forth Inc has back-flipped on their recent decision
and restored what they had. User complaints?
Probably.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,113 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492335:46:08 |
| Calls: | 14,238 |
| Files: | 186,312 |
| D/L today: |
3,563 files (1,160M bytes) |
| Messages: | 2,514,866 |