From owner-freebsd-questions@FreeBSD.ORG Fri Nov 1 05:16:44 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 219DF8CF for ; Fri, 1 Nov 2013 05:16:44 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B26E72D25 for ; Fri, 1 Nov 2013 05:16:43 +0000 (UTC) Received: from r56.edvax.de (port-92-195-117-74.dynamic.qsc.de [92.195.117.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id 4F9E83CA64; Fri, 1 Nov 2013 06:16:41 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id rA15GVIl003688; Fri, 1 Nov 2013 06:16:31 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Fri, 1 Nov 2013 06:16:31 +0100 From: Polytropon To: tak.official@gmail.com Subject: Re: rcorder issue Message-Id: <20131101061631.2a9adb81.freebsd@edvax.de> In-Reply-To: References: <20131031092922.bd60f4bd.freebsd@edvax.de> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 05:16:44 -0000 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 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 /* 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, ...