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.


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


More information about the freebsd-questions mailing list