[arch-general] [PATCH 1/2] kill_everything: Reduce number of -f tests
Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily. --- functions | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/functions b/functions index b9ba718..7a0c4f8 100644 --- a/functions +++ b/functions @@ -206,11 +206,13 @@ kill_everything() { # $1 = where we are being called from. # This is used to determine which hooks to run. # Find daemons NOT in the DAEMONS array. Shut these down first + ( + shopt -s nullglob for daemon in /var/run/daemons/*; do - [[ -f $daemon ]] || continue daemon=${daemon##*/} in_array "$daemon" "${DAEMONS[@]}" || stop_daemon "$daemon" done + ) # Shutdown daemons in reverse order for ((i=${#DAEMONS[@]}-1; i>=0; i--)); do -- 1.7.2.3
Take full advantage of /bin/rm accepting multiple arguments. We still use two calls to separate the recursive from the non-recursive call. --- rc.sysinit | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index b25f7ac..0af84de 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -270,11 +270,8 @@ if [[ -f $RANDOM_SEED ]]; then fi stat_busy "Removing Leftover Files" -/bin/rm -f /etc/nologin &>/dev/null -/bin/rm -f /etc/shutdownpid &>/dev/null -/bin/rm -f /var/lock/* &>/dev/null +/bin/rm -f /etc/{nologin,shutdownpid} /var/lock/* /forcefsck &>/dev/null /bin/rm -rf /tmp/* /tmp/.* &>/dev/null -/bin/rm -f /forcefsck &>/dev/null [[ -d /var/run ]] && /usr/bin/find /var/run/ \! -type d -delete ) : >| /var/run/utmp /bin/chmod 0664 /var/run/utmp -- 1.7.2.3
On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner <d@falconindy.com> wrote:
Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily.
I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :)
--- functions | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/functions b/functions index b9ba718..7a0c4f8 100644 --- a/functions +++ b/functions @@ -206,11 +206,13 @@ kill_everything() { # $1 = where we are being called from. # This is used to determine which hooks to run. # Find daemons NOT in the DAEMONS array. Shut these down first + ( + shopt -s nullglob for daemon in /var/run/daemons/*; do - [[ -f $daemon ]] || continue daemon=${daemon##*/} in_array "$daemon" "${DAEMONS[@]}" || stop_daemon "$daemon" done + )
# Shutdown daemons in reverse order for ((i=${#DAEMONS[@]}-1; i>=0; i--)); do -- 1.7.2.3
Am 08.09.2010 06:16, schrieb Victor Lowther:
On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner <d@falconindy.com> wrote:
Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily.
I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :)
As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell. Do we need extglob anywhere? I don't think so.
"Thomas Bächler" <thomas@archlinux.org> wrote:
Am 08.09.2010 06:16, schrieb Victor Lowther:
On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner <d@falconindy.com> wrote:
Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily.
I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :)
As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell.
Sounds good to me - nullglob is useful in general, and enabling it should not break anything else in the initscripts package.
Do we need extglob anywhere? I don't think so.
I will take a look. -- Sent from my Nexus One with K-9 Mail. Please excuse my brevity.
On 09/09/10 16:19, Victor Lowther wrote:
"Thomas Bächler"<thomas@archlinux.org> wrote:
Am 08.09.2010 06:16, schrieb Victor Lowther:
On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner<d@falconindy.com> wrote:
Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily.
I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :)
As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell.
Sounds good to me - nullglob is useful in general, and enabling it should not break anything else in the initscripts package.
Do we need extglob anywhere? I don't think so.
I will take a look.
I don't see anywhere in the initscripts that has this issue but you might want to take a look at dotglob for the future, because with nullglob you break the behaviour of commands that work like ls. i.e `ls *.ext` etc. would result in ls being passed an argument '*.ext' in the event that *.ext doesn't match anything. With nullglob set, no argument gets passed and you end up with just `ls` which is likely to cause subtle bugs.
"Nathan Wayde" <kumyco@konnichi.com> wrote:
On 09/09/10 16:19, Victor Lowther wrote:
"Thomas Bächler"<thomas@archlinux.org> wrote:
Am 08.09.2010 06:16, schrieb Victor Lowther:
On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner<d@falconindy.com> wrote:
Instead of checking for the existance of a file in
/var/run/daemons
on
every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily.
I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :)
As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell.
Sounds good to me - nullglob is useful in general, and enabling it should not break anything else in the initscripts package.
Do we need extglob anywhere? I don't think so.
I will take a look.
I don't see anywhere in the initscripts that has this issue but you might want to take a look at dotglob for the future, because with nullglob you break the behaviour of commands that work like ls. i.e `ls
*.ext` etc. would result in ls being passed an argument '*.ext' in the event that *.ext doesn't match anything. With nullglob set, no argument
gets passed and you end up with just `ls` which is likely to cause subtle bugs.
Sounds like another reason to never parse the output of ls in a shell script ( not that I needed more). -- Sent from my Nexus One with K-9 Mail. Please excuse my brevity.
Am 09.09.2010 18:48, schrieb Victor Lowther:
*.ext` etc. would result in ls being passed an argument '*.ext' in the event that *.ext doesn't match anything. With nullglob set, no argument
gets passed and you end up with just `ls` which is likely to cause subtle bugs.
Sounds like another reason to never parse the output of ls in a shell script ( not that I needed more).
Agreed! If such a thing is still in the scripts, it should be replaced (I think Victor did that in a few places).
participants (4)
-
Dave Reisner
-
Nathan Wayde
-
Thomas Bächler
-
Victor Lowther