Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #134774 > unrolled thread
| Started by | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| First post | 2026-03-24 08:51 -0500 |
| Last post | 2026-03-29 13:22 +0200 |
| Articles | 20 on this page of 98 — 11 participants |
Back to article view | Back to comp.lang.forth
Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-24 08:51 -0500
Re: Parsing a file name with spaces peter <peter.noreply@tin.it> - 2026-03-24 15:24 +0100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-25 01:28 +1100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-25 21:24 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-25 14:57 +0100
Re: Parsing a file name with spaces Stephen Pelc <stephen@vfxforth.com> - 2026-03-24 15:55 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-25 10:05 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-25 16:56 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-25 15:22 -0500
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-28 12:02 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-28 08:54 +0100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-28 19:37 +1100
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-03-28 15:10 +0000
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-28 18:59 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-29 11:11 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-29 09:24 +0000
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-29 13:03 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-29 22:07 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-29 16:08 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-30 09:34 +1100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-31 09:18 +1100
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-30 20:41 -0500
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-31 14:14 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-31 07:36 +0000
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-31 14:03 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 12:22 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-01 08:22 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 20:06 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 06:05 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 18:09 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-02 13:54 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-03 11:57 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-03 11:44 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-04 00:23 +1100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-05 10:55 +1000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-05 11:50 +1000
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-01 12:25 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 00:07 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-31 07:54 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-31 05:03 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-31 10:32 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-31 10:26 -0500
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-01 00:19 +0200
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-31 18:04 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-01 07:54 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-01 06:23 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 08:34 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-02 07:18 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 14:43 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-02 20:52 -0500
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-03 11:40 +0200
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-04 06:21 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-04 08:00 -0500
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-04 22:01 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-07 10:23 +1000
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-07 14:26 +0000
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-07 15:05 +0000
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-07 17:09 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-08 12:25 +1000
Re: Parsing a file name with spaces Stephen Pelc <stephen@vfxforth.com> - 2026-04-09 10:22 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 19:13 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 05:55 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 17:44 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-31 13:41 +0200
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-31 10:18 -0500
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 11:28 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-01 08:17 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 19:42 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-01 12:13 +0200
Re: Parsing a file name with spaces Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-01 19:43 +0100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 12:18 +1100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 12:43 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 09:07 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 21:50 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 09:11 +0000
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-12 19:37 +0200
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-12 19:44 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-13 11:05 +1000
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-14 14:45 +0200
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-15 15:51 +0200
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-24 17:58 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-24 13:41 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-24 20:40 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-24 20:26 -0500
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-25 10:37 +0100
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-25 05:13 -0500
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-26 09:16 +1000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-25 20:57 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-28 19:14 +0000
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-29 12:22 +1000
Re: Parsing a file name with spaces Paul Rubin <no.email@nospam.invalid> - 2026-03-28 20:55 -0700
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-29 17:00 +1000
Re: Parsing a file name with spaces Paul Rubin <no.email@nospam.invalid> - 2026-03-29 19:05 -0700
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-30 21:58 +1000
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-29 09:52 +0000
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-29 09:32 +0000
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-30 22:10 +1000
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-29 13:22 +0200
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-03-31 09:18 +1100 |
| Message-ID | <69caf6c3@news.ausics.net> |
| In reply to | #134812 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-03-30 20:41 -0500 |
| Message-ID | <10qf8nr$2vaat$1@dont-email.me> |
| In reply to | #134816 |
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. 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
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-03-31 14:14 +1100 |
| Message-ID | <69cb3c29$1@news.ausics.net> |
| In reply to | #134817 |
On 31/03/2026 12:41 pm, Krishna Myneni wrote: > ... > 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. Some behaviours were never properly formulated. AFAIK no explicit rationale was ever given for INCLUDE vs. INCLUDED other than the former already existed in several forths. So I'll present mine. 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. To limit the scope to filenames that conform to forth's notion of a 'word' completely misses the intent behind these functions. I see no point to having INCLUDE et al if I'm told I can use INCLUDED RENAME-FILE DELETE-FILE etc instead.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-03-31 07:36 +0000 |
| Message-ID | <2026Mar31.093620@mips.complang.tuwien.ac.at> |
| In reply to | #134818 |
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.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-03-31 14:03 +0200 |
| Message-ID | <nnd$479e551a$4475eba1@acb53aec5ea41930> |
| In reply to | #134819 |
In article <2026Mar31.093620@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>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.
This is a sound advantage, it makes no sense to learn two disparate
ways to escape weird filenames.
I have used `` !! '' for this functionality, compare similar escapes
with ! in ftp etc. I admit that `` sh '' is a better name.
Maybe I'll change it:
"grep" OS-IMPORT grep
"" OS-IMPORT sh \ was: "" OS-IMPORT !!
CREATE cmdbuf 1000 ALLOT
: OS-IMPORT ( sc "name-forth" -- )
CREATE , ,
DOES>
2@ cmdbuf $! BL cmdbuf $C+ \ Command
^J PARSE cmdbuf $+! \ Append
cmdbuf $@ SYSTEM \ Execute
;
>anton
--
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]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-01 12:22 +1100 |
| Message-ID | <69cc7360@news.ausics.net> |
| In reply to | #134819 |
On 31/03/2026 6:36 pm, Anton Ertl wrote: > 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 It's not a solution under MS-DOS (lots of buffers and code) nor under CP/M where AFAIK shelling is impossible. >> 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. What is the point - according to you since the standard never explains?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-04-01 08:22 +0000 |
| Message-ID | <2026Apr1.102201@mips.complang.tuwien.ac.at> |
| In reply to | #134830 |
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
--
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/
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-01 20:06 +1100 |
| Message-ID | <69cce031$1@news.ausics.net> |
| In reply to | #134834 |
On 1/04/2026 7:22 pm, Anton Ertl 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. 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. >>> 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 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.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-04-02 06:05 +0000 |
| Message-ID | <2026Apr2.080500@mips.complang.tuwien.ac.at> |
| In reply to | #134836 |
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.
There actually are OS-independent file names, and POSIX has
standardized the "Portable filename character set" in POSIX 2004 3.276
<https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276>
(possibly earlier). In POSIX 2024 this section is 3.265
<https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_265>.
I proposed adopting that specification to the Forth standard
<http://www.forth200x.org/directories1.html>, but there was zero
interest in that proposal, so I withdrew it.
>> 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.
In the first 20 years none of their implementors or users have ever
mentioned that these systems do not implement the standardized INCLUDE
and REQUIRE, much less made a proposal that would make the behaviour
of these systems standard-compliant. And the best time to bring that
up would have been when the proposal was in the RfD stage, but nobody
mentioned it at the time.
Apparently this particular aspect has not been on anybody's mind
during the proposal stage or in the two decades since then, only
surfacing recently with bombastic claims about the importance of using
file names with blanks in INCLUDE.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-02 18:09 +1100 |
| Message-ID | <69ce163d$1@news.ausics.net> |
| In reply to | #134845 |
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. > ...
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-04-02 13:54 +0200 |
| Message-ID | <nnd$395db44c$3b7cdb4f@1251c8b912d8ce18> |
| In reply to | #134847 |
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. 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]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-03 11:57 +1100 |
| Message-ID | <69cf1078$1@news.ausics.net> |
| In reply to | #134852 |
On 2/04/2026 10:54 pm, albert@spenarnc.xs4all.nl wrote: > 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-04-03 11:44 +0200 |
| Message-ID | <nnd$6c84be0a$1429e4e1@07d75e66d227b9b4> |
| In reply to | #134857 |
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. 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]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-04 00:23 +1100 |
| Message-ID | <69cfbf5d$1@news.ausics.net> |
| In reply to | #134860 |
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.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-05 10:55 +1000 |
| Message-ID | <69d1b2fe$1@news.ausics.net> |
| In reply to | #134861 |
On 4/04/2026 12:23 am, dxf wrote:
> 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.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-05 11:50 +1000 |
| Message-ID | <69d1bfef$1@news.ausics.net> |
| In reply to | #134865 |
On 5/04/2026 10:55 am, dxf wrote: > ... > 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. REQUIRE definition has copy/paste errors. Use INCLUDE as the model.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-04-01 12:25 +0200 |
| Message-ID | <nnd$6b114eb0$0f866d3d@557a5c582a4790ad> |
| In reply to | #134834 |
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.
>- anton
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]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-02 00:07 +1100 |
| Message-ID | <69cd1887@news.ausics.net> |
| In reply to | #134838 |
On 1/04/2026 9:25 pm, albert@spenarnc.xs4all.nl wrote: > 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. The standard itself makes few restrictions on filenames: 11.1 Introduction These words provide access to mass storage in the form of "files" under the following assumptions: - file names are represented as character strings; - the format of file names is determined by the host operating system;
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-03-31 07:54 +0000 |
| Message-ID | <2026Mar31.095456@mips.complang.tuwien.ac.at> |
| In reply to | #134817 |
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.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-03-31 05:03 -0500 |
| Message-ID | <10qg65r$380qk$1@dont-email.me> |
| In reply to | #134820 |
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. > 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. Their use implies that the text being parsed will be delimited by a double quote. It's not clear whether or not S" and S\" will be sufficient for parsing general UTF-8 encoded Unicode file names supporting other languages. I use a number of such files on my Linux computer. The present discussion, however, was only about file names with spaces. --Krishna
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web