On Thu, Nov 28, 2013 at 09:09:32AM -0700, LuKreme wrote:
> Also, the Fields are all single words, and almost all the parameters
> have multiple_words_with_underscores, so there might be something
> there.
>
> myhostname mydomain myorigin mydestination and mynetworks seem
> to be the only parameter labels without an _ on my system, for
> example. They all conveniently start with "my".
Counter-examples exist:
$ postconf -d | awk '{print $1}' | egrep -v _ | egrep -v '^my'
biff
relayhost
stress
users are free to create their own parameters. You may, for example,
have seen some of my posts that introduce ${indexed}...
At Morgan Stanley I implemented a separate postmast(1) utility,
that could be used to show all, or just non-default, master.cf
entries, and to insert or delete master.cf entries. It did not
support granular access to the components of an entry.
In postmast(1) there was no ambiguity between "." in a service name
and "." between the service name and the service type, because
these were specified separately "postmast [-s <service>] [-t <type>]
...". While integrating a super-set of postmast(1) functionality into
postconf(1) Wietse has switched from "." to "/", but this may not
solve the problem because some service names have "/" in them
(paths of sockets outside /var/spool/postfix/{private,public}).
To safely eliminate the ambiguity we can either use white-space to
separate the name and type:
# Single type
$ postconf -F "smtp inet"
# Any type
$ postconf -F smtp
or make the type mandatory with the empty string or "any" as a
wildcard:
# Single type
$ postconf -F smtp.inet
# Any type
$ postconf -F smtp.
OR
$ postconf -F smtp.any
I think "." is less visually intrusive than "/", and since "/" does
not eliminate the ambiguity, I would revert the separator to "."
with the next snapshot, with "any" for a wildcard:
# inet type
$ postconf -F smtp.inet
# any type
$ postconf -F smtp.any
With ".<type>" required, the ambiguity goes away.
--
Viktor.
