From owner-freebsd-rc@FreeBSD.ORG Sat Dec 24 23:20:06 2005 Return-Path: X-Original-To: freebsd-rc@hub.freebsd.org Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5240D16A41F for ; Sat, 24 Dec 2005 23:20:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B570843D53 for ; Sat, 24 Dec 2005 23:20:05 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBONK5nZ087251 for ; Sat, 24 Dec 2005 23:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBONK5W2087250; Sat, 24 Dec 2005 23:20:05 GMT (envelope-from gnats) Date: Sat, 24 Dec 2005 23:20:05 GMT Message-Id: <200512242320.jBONK5W2087250@freefall.freebsd.org> To: freebsd-rc@FreeBSD.org From: Peter Much Cc: Subject: Re: conf/85363: syntax error in /etc/rc.d/devfs X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Much List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2005 23:20:06 -0000 The following reply was made to PR conf/85363; it has been noted by GNATS. From: Peter Much To: bug-followup@FreeBSD.org Cc: Subject: Re: conf/85363: syntax error in /etc/rc.d/devfs Date: Sat, 24 Dec 2005 23:58:10 +0100 Now I found time to analyze this thoroughly. I found that I have made a mistake. It just does not work to name a ruleset by its NUMBER in rc.conf, instead one must always name it by its NAME. (And, btw, that name must not begin with a number!) Now, ideally, if one mentions the number instead of the name in rc.conf, the code should behave as if a nonexistent ruleset was mentioned - i.e. do nothing or raise an error. Practically it does behave undefined, that is, wrong rulesets will silently be applied. But, overall, this is one of the implicit weaknesses of shell scripting, when strings that are to be freely defined by the installer are used as variable names. And as the thing is designed as it is, there is no easy solution to make it better. An improvement will be the usage of {} delimiters. A construct like "eval rs=\$$1" will behave less undefined if it is written as "eval rs=\${$1}". There is a couple of places in rc.subr where this would be argueable. PMc