rcorder issue

Polytropon freebsd at edvax.de
Fri Nov 1 05:16:44 UTC 2013

On Thu, 31 Oct 2013 12:17:33 +0330, takCoder wrote:
> Thank you for your quick and complete reply :)

I'm happy to be a helpful support drone. :-)

> On Thu, Oct 31, 2013 at 11:59 AM, Polytropon <freebsd at edvax.de> wrote:
> > On Thu, 31 Oct 2013 11:42:41 +0330, takCoder wrote:
> > > Hi all,
> > >
> > > My question is: May it cause a problem, for rcorder or else, to have a
> > > sub-folder in rc.d/ path ?
> >
> > First, the things you are refering to are directories and
> > subdirectories. "Folder" is technically wrong. The correct
> > term is directory. A "folder" is the name of a visual
> > representation (usually an icon) that represents a directory
> > within a GUI concept. The relations that reflect that
> > difference are "is a" vs. "represents a". :-)
> >
> Excuse me for that miss-use of "folder" term, and thanks for your
> clarification. I'll try to keep that in mind ;)

Certain environments encourage non-standard "creations" instead
established terminology. It's important to differentiate here.
I have to admit that I'm very pedantic with the paperwork. :-)

> > It's about _files_, so * will usually be resolved by the
> > shell to any entry found in the specified directory. In
> > case that a subdirectory is found, any future operation
> > will be done on _that subdirectory_ instead of a file
> > (that is maybe contained in that subdirectory). That's
> > why it's suggested to put the rc.d scripts without any
> > "deeper nesting" into /etc/rc.d and /usr/local/etc/rc.d
> > respectively. Similarly, non-OS scripts are processed
> > from the /usr/local/etc/rc.d directory (and other directories
> > the user might have added).
> >
> Yes I guess that's the point! It is then where rc do not expect a directory
> in rc.d and things happen..

If you have a look at /etc/rc.subr's functions find_local_scripts_old()
and find_local_scripts_new() (where "old" and "new" corresponds
to the syntax of the rc.d files), you can see that it works
in a similar manner: the shell resolves <directoryname>/* and
expects * to be resolved to files in order to call them. If
a _directory_ is found, doing things that are supposed to be
done with files (e. g. grep, test for +x and call it in a
subshell) just doesn't work. The idea of supplying an additional
directory where rc can search for rc.d-style files is the most
convenient way to deal with this.

> > > But now I can't  be sure about it as i can't remember it clearly or find
> > > it.. One of my mates created a sub-folder in his system's rc.d folder, so
> > > he can run his preferred scripts there in his required order, using
> > > /etc/rc.
> >
> > It would also be possible to add a custom /opt/rc.d
> > directory and add this to the local_startup vairable
> > in /etc/rc.conf, for example:
> >
> >         local_startup="/usr/local/etc/rc.d /opt/rc.d"
> >
> > This will cause additional directories to be sourced.
> > Note that I'm an optimist and therefore often (ab)use
> > the Solaris-ism (Solarism?) of /opt. :-)
> >
> Just keep being an optimist! That's what's right .. :)

My intention of /opt is that I use it to keep things that
are not managed by the system in any way, e. g. system-wide
user scripts, manually installed programs or local ports.
In this specific case, /opt contains a subtree structure
similar to what the system uses (e. g. /opt/bin which is
also in $PATH, /opt/libexec for handmade printer filters
or /opt/src for local sources). I don't say that this is
the _correct_ way to handle things, but it works so long
that "never touch a running system" might be indicated. :-)

The difference, by the way, of not using /usr/local for
such things is that this subtree is reserved for software
installed from ports or packages (read: system means),
and many other directories are reserved for the OS itself,
so putting random stuff in there simply doesn't sound right.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list