[Oberon] Why are `*` and `^` interpreted by individual Oberon commands?

Wed Sep 9 01:19:34 CEST 2026

I have asked the same question on IRC and got several arguments in favor of leaving wildcard interpretation to the command.

The main points were:

* If the command receives the literal *, it can know that the user actually typed a wildcard. That can matter semantically. For example, a destructive command such as

---
rm -f *
---

could choose to warn specifically because the user used *.

With Unix-style shell expansion, the command only receives the expanded list of filenames and cannot tell whether they came from *, from explicit arguments, or from some other expansion.

* Not every command necessarily wants wildcard expansion. If expansion is done by the shell/system, it is imposed on all commands unless quoting or some other escape mechanism is used. If commands handle it themselves, they can decide whether wildcard syntax is meaningful.

* There is an objection that every command would then need its own wildcard implementation. However the common parsing/expansion functionality can be implemented in a library.

* Unix shell expansion can run into the `ARG_MAX` limit. A sufficiently large wildcard expansion produces an "Argument list too long" error because the complete expanded filename list has to be passed as process arguments.

* There is also an interesting option-parsing problem. Suppose a directory contains a file named

---
-rf
---

Then something like

---
rm *
---

may be expanded by the shell into an argument list containing "-rf". From the point of view of "rm", that argument is indistinguishable from an option unless special precautions are taken.

If the command itself performs wildcard matching, it knows the difference between the user's options and filenames discovered as a result of wildcard expansion.

Someone also pointed out that MS-DOS traditionally followed this model: * was generally passed to the program and wildcard matching was handled by the command/program rather than expanded by the command interpreter.

So after this discussion, I can see that the advantages that Oberon approach has.

Keeping * or ^ visible to the command preserves information about the user's intent, avoids forcing expansion semantics on every command, and avoids some problems caused by flattening an expression into an ordinary argument list too early.

norayr

On Tue, 11 Aug 2026 15:10:47 +0200
Hans Klaver <hklaver at dds.nl> wrote:

> >  նորայր <norayr at arnet.am> wrote:
> > 
> > I did, and it's near me.
> > Would you like to point out which particular page to re-read?
> 
> 
> 
> In Martin Reiser's The Oberon System (1991):
> https://oberoncore.ru/_media/library/mros1991.pdf
> or
> https://bitsavers.trailing-edge.com/pdf/eth/ceres/Reiser_The_Oberon_System_1991.pdf
> Page 18-19 
> EBNF-notation of the syntax of commands
> 
> Page 34 and following
> 2.5 Commands
> 
> Note that in this early book @ is not yet mentioned as a special character in the parameter list of a command.
> 
> But in the following documents the @ is mentioned:
> Project Oberon (original 1992 book) page 40
> 
> Project Oberon (2005 edition) page 33
> https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf
> 
> Project Oberon (2013): page 33
> https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf
> 
> Note that on page 3 of the text Using Oberon (2015, see below) the * as special character in parameter lists (referring to the marked viewer) has disappeared. Which is a pity because it is very handy when compiling modules because you don't have to select the (beginning of) the text you want to (re)compile. Even when the star marker is not visible any more the most recently marked viewer is remembered by the System.
> https://people.inf.ethz.ch/wirth/ProjectOberon/UsingOberon.pdf  (one of the last texts Wirth wrote on the Oberon System).
> 
> Regards,
> 
> 
> Hans Klaver
> 
> 
> > Op 11 aug. 2026, om 01:22 heeft նորայր <norayr at arnet.am> het volgende geschreven:
> > 
> > I did, and it's near me.
> > Would you like to point out which particular page to re-read?
> > 
> > On Tue, 11 Aug 2026 08:22:11 +0930
> > Chris Burrows <cfbsoftware at gmail.com> wrote:
> > 
> >> On Mon, Aug 10, 2026 at 4:15 PM նորայր <norayr at arnet.am> wrote:
> >> 
> >>> 
> >>> I have been thinking about the design of command arguments in the Oberon
> >>> System, and I would be interested to hear the reasoning behind one
> >>> particular choice.
> >>> ...
> >> 
> >> 
> >> I recommend that you read the book The Oberon System
> >> <https://bitsavers.trailing-edge.com/pdf/eth/ceres/Reiser_The_Oberon_System_1991.pdf>
> >> -  User
> >> Guide and Programmer's Manual by Martin Reiser, ACM Press 1991, ISBN
> >> 0-201-54422-9. Chapters 1 and 2 in particular discuss the features of the
> >> user interface design.
> > 
> > 
> > -- 
> > There are two ways of constructing a software design.  One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
> > 
> > -- C.A.R. Hoare
> > 
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

-- 
There are two ways of constructing a software design.  One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

-- C.A.R. Hoare

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 870 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20260909/d8a134fd/attachment.sig>