Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.os.vms
Subject: Local Versus Global Command Options
Date: Thu, 13 Feb 2025 22:52:44 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <volt3s$33lo1$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 13 Feb 2025 23:52:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="722820ba2188b0a993baba3d81c0819d";
	logging-data="3266305"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19vPWjPZmk/Tji4zuxOzZtV"
User-Agent: Pan/0.161 (Chasiv Yar; )
Cancel-Lock: sha1:YcfS9gACunbqoN+UffAcg/u5fc0=
Bytes: 4001

One thing about DCL syntax is its ability to specify options (what it
calls “qualifiers”) either globally for the command, or locally to a
particular command argument:

    «cmd»/«global-options» «arg1» «arg2» ...

where each «arg» can take the form

    «subarg1»/«local-options-1»,«subarg2»/«local-options-2», ...

and then I think you can have plus signs as well as commas, to denote
another level of concatenation. And then you can put spaces
before/after commas and plus signs, and those are ignored and not
considered separators between arguments. So the presence or absence of
a comma or plus sign can become quite significant.

The traditional *nix command syntax never had provision for this. Most
commands take the fairly simple form

    «cmd» «options» «args»

where each of «options» and «args», if nonempty consists of one or
more space-separated items, and all «options» are assumed to have
global effect, though some can add quite a lot of elaboration on this
where necessary.

(Did somebody say “dd”? Passing arguments by keyword, anybody?)

What’s the most complex *nix command you’ve come across? I think it
has to be ffmpeg. This looks broadly like

    ffmpeg «local-input-options-1» -i «infile-1» \
        «local-input-options-2» -i «infile-2» ... \
        «local-output-options-1» «outfile-1» \
        «local-output-options-2» «outfile-2» ...

The convention is that options apply to the immediately following file
specification: this is prefixed with “-i” for an input file, and is a
plain argument for an output file. Note the lack of “global” options:
all settings apply to a particular file.

But that’s not where it ends. Certain of the options can specify
“filtergraphs”, which are entire chains of effects operations to be
applied to a particular video or audio stream. The man page talks
about “simple” versus “complex” filtergraphs, but even the “simple”
ones can be pretty complex.

Filtergraphs can also be used during real-time playback, with the
“ffplay” command. For example:

    ffplay -autoexit -vf scale=1152:864,setsar=0.9 \
        'Sun Is Shining (Official Video).mp4'

That “-vf” option specifies a sequence of video filters, first to
scale up the video to make more use of my screen, and “setsar” (“Set
Source Aspect Ratio”) to fix distortion in the shape of the image
(everybody looking squashed) from the original digitization of the
video.

What would DCL-style syntax for ffmpeg look like? I suppose one
obvious equivalence would be

    ffmpeg -
        «infile-1»/«local-input-options-1»,«infile-2»/«local-input-options-2»,... -
        «outfile-1»/«local-output-options-1»,«outfile-2»/«local-output-options-2»,... -

(being very careful about where the commas go), but what about the
syntax for filtergraphs? Would it be something like

    /vf=(«filter-name-1»=«filter-params-1»,«filter-name-2»=«filter-params-2»...)

Does DCL have provision for this sort of complexity?