[arch-projects] [initscripts] [PATCH] Fix: don't use install where target file can't/shouldn't be removed

[Seblu]

On Mon, Jun 27, 2011 at 12:44 AM, Kurt J. Bosch
<kjb-temp-2009 at alpenjodel.de> wrote:
> Seblu, 2011-06-27 00:28:
>>
>> On Sun, Jun 26, 2011 at 11:51 PM, Kurt J. Bosch
>> <kjb-temp-2009 at alpenjodel.de>  wrote:
>>>
>>> ---
>>>  functions  |    7 +++++++
>>>  rc.sysinit |    4 ++--
>>>  2 files changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/functions b/functions
>>> index 43414c0..9ad75a9 100644
>>> --- a/functions
>>> +++ b/functions
>>> @@ -428,6 +428,13 @@ install_file() {
>>>        install -T "$@"<(printf '%s' "$content") "$file"
>>>  }
>>>
>>> +# install would fail because files can't be removed from /proc
>>> +# moreover we don't want to remove nodes from /dev
>>> +write_file() {
>>> +       local file=$1 content=$2
>>> +       printf '%s' "$content">| "$file"
>>> +}
>>> +
>>>  bootlogd_stop() {
>>>        [[ -f /run/bootlogd.pid ]] || return 0
>>>        touch /var/log/boot
>>> diff --git a/rc.sysinit b/rc.sysinit
>>> index dcc88f5..2c08f02 100755
>>> --- a/rc.sysinit
>>> +++ b/rc.sysinit
>>> @@ -209,7 +209,7 @@ status "Activating Swap" swapon -a
>>>  RANDOM_SEED=/var/lib/misc/random-seed
>>>  [[ -f $RANDOM_SEED ]]&&
>>>        status "Initializing Random Seed" \
>>> -               install_file /dev/urandom "$(<  "$RANDOM_SEED" )"
>>> +               cp "$RANDOM_SEED" /dev/urandom
>>>
>>>  stat_busy "Removing Leftover Files"
>>>        rm -rf /etc/{nologin,shutdownpid} /forcefsck /tmp/*
>>> /tmp/.*&>/dev/null
>>> @@ -225,7 +225,7 @@ stat_done
>>>
>>>  [[ $HOSTNAME ]]&&
>>>        status "Setting Hostname: $HOSTNAME" \
>>> -               install_file /proc/sys/kernel/hostname "$HOSTNAME"
>>> +               write_file /proc/sys/kernel/hostname "$HOSTNAME"
>>>
>>
>> Do you call a function to do the job of a redirection?
>>
> Yep. We need to do it _within_ status.

Reading (or not) your commit message I thought you wanted to do that.
What do you think about doing you eval inside status?

Or better, just rollback from your previous patch where you assert
this write can be done in one line with status instead of a classic
status_start / status_done?
In this case, the use of status is not the best choice I think.

-- 
Sébastien Luttringer
www.seblu.net