On Feb 3, 2016, at 8:57 AM, m.r...@5-cent.us wrote:
>
> Notice the *deeply* weird syntax of "=-<cmd>”.
That syntax comes from make(1), where it means the same thing. make(1) has
been with us since 1977, so I’d think “old and familiar” is a better
description than “deeply weird.”
> And, I read in the manpage for systemd.service that if you precede it with
> an @, it will pass arguments. Why it does not use the used-everywhere-else
> of *post*fixing those parms, I have no data.
You’ve misread the page.
All this option does is lets you run one command but tell the command itself
that it was called by a different name. I’m not sure why the systemd creators
added this, since you normally get this behavior with links:
$ sudo yum install unzip
$ ls -li /bin/unzip /bin/infozip
135096149 -rwxr-xr-x. 2 root root 181248 Mar 18 2015 unzip
135096149 -rwxr-xr-x. 2 root root 181248 Mar 18 2015 zipinfo
That is, we have a single program binary with two different names. Invoking
the program as “zipinfo” makes it behave differently than if you invoke it as
“unzip”.
All this systemd feature does is lets you say something like:
ExecStart=@/bin/unzip zipinfo ...
That is, you can run the unzip binary but *call it* zipinfo.
Again, I don’t know why they couldn’t just do it with links. However, I will
point out that the C programming interfaces on your system (execv() and
friends) also support this feature, and have since back before 1977, so that
this, too, is not some fresh new weirdness.
> I also don't
> understand why you'd set as an out-of-the-box default that it should fail
> to come up if it can't resolve any export host, rather than default to
> coming up.
You do it for the same reason you’d fail when mounting any other filesystem.
It may be critical to operation, as with shared /usr.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
