[arch-general] Start a daemon, show a syntax error
No matter I manual start any a daemon, I always see a error shown on console: /etc/rc.d/functions: line 506: syntax error near unexpected token `(' /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /) But it seem that the daemon can run correctly, so should I need to fix it and how to fix it ?
2012/2/17 大熊 <bearsprite@gmail.com>:
No matter I manual start any a daemon, I always see a error shown on console:
/etc/rc.d/functions: line 506: syntax error near unexpected token `(' /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
But it seem that the daemon can run correctly, so should I need to fix it and how to fix it ?
I don't know why this bug is always occur again and again. The fix is to edit /etc/rc.d/functions, change line 506 to the following: done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /) /etc/bash_completion.d/git has the same issue before.
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 大熊 <bearsprite@gmail.com>:
No matter I manual start any a daemon, I always see a error shown on console:
/etc/rc.d/functions: line 506: syntax error near unexpected token `(' /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
But it seem that the daemon can run correctly, so should I need to fix it and how to fix it ?
I don't know why this bug is always occur again and again.
The fix is to edit /etc/rc.d/functions, change line 506 to the following:
done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which bash` and `pacman -Qo /bin/bash`.
/etc/bash_completion.d/git has the same issue before.
在 2012年2月17日 下午2:57，Lukas Fleischer <archlinux@cryptocrack.de>写道：
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 大熊 <bearsprite@gmail.com>:
No matter I manual start any a daemon, I always see a error shown on console:
/etc/rc.d/functions: line 506: syntax error near unexpected token `(' /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
But it seem that the daemon can run correctly, so should I need to fix it and how to fix it ?
I don't know why this bug is always occur again and again.
The fix is to edit /etc/rc.d/functions, change line 506 to the following:
done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which bash` and `pacman -Qo /bin/bash`.
➜ ~ bash --help|head -1 GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu) ➜ ~ which bash /bin/bash ➜ ~ pacman -Qo /bin/bash /bin/bash is owned by bash 4.2.020-1 ➜ ~
On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
在 2012年2月17日 下午2:57，Lukas Fleischer <archlinux@cryptocrack.de>写道：
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 大熊 <bearsprite@gmail.com>:
No matter I manual start any a daemon, I always see a error shown on console:
/etc/rc.d/functions: line 506: syntax error near unexpected token `(' /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
But it seem that the daemon can run correctly, so should I need to fix it and how to fix it ?
I don't know why this bug is always occur again and again.
The fix is to edit /etc/rc.d/functions, change line 506 to the following:
done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which bash` and `pacman -Qo /bin/bash`.
➜ ~ bash --help|head -1 GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu) ➜ ~ which bash /bin/bash ➜ ~ pacman -Qo /bin/bash /bin/bash is owned by bash 4.2.020-1 ➜ ~
Weird... Did you enforce POSIX-compatibility somewhere? How do you start the daemons? Do you use something broken like `sh rc.d start $foo` or `sh /etc/rc.d/$foo start`? If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1 /etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as well.
2012/2/17 Lukas Fleischer <archlinux@cryptocrack.de>:
On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
在 2012年2月17日 下午2:57，Lukas Fleischer <archlinux@cryptocrack.de>写道：
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 大熊 <bearsprite@gmail.com>:
No matter I manual start any a daemon, I always see a error shown on console:
/etc/rc.d/functions: line 506: syntax error near unexpected token `(' /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
But it seem that the daemon can run correctly, so should I need to fix it and how to fix it ?
I don't know why this bug is always occur again and again.
The fix is to edit /etc/rc.d/functions, change line 506 to the following:
done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which bash` and `pacman -Qo /bin/bash`.
➜ ~ bash --help|head -1 GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu) ➜ ~ which bash /bin/bash ➜ ~ pacman -Qo /bin/bash /bin/bash is owned by bash 4.2.020-1 ➜ ~
Weird... Did you enforce POSIX-compatibility somewhere? How do you start the daemons? Do you use something broken like `sh rc.d start $foo` or `sh /etc/rc.d/$foo start`?
If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1 /etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as well.
I have the same problem.It is all happened at codes like "done < <(some stuff)",but after I changed it to "done < $(some stuff)", all going well.I don't know bash has such a syntax usage?
On Fri, Feb 17, 2012 at 05:58:31PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 Lukas Fleischer <archlinux@cryptocrack.de>:
On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
在 2012年2月17日 下午2:57，Lukas Fleischer <archlinux@cryptocrack.de>写道：
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 大熊 <bearsprite@gmail.com>:
No matter I manual start any a daemon, I always see a error shown on console:
/etc/rc.d/functions: line 506: syntax error near unexpected token `(' /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
But it seem that the daemon can run correctly, so should I need to fix it and how to fix it ?
I don't know why this bug is always occur again and again.
The fix is to edit /etc/rc.d/functions, change line 506 to the following:
done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which bash` and `pacman -Qo /bin/bash`.
➜ ~ bash --help|head -1 GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu) ➜ ~ which bash /bin/bash ➜ ~ pacman -Qo /bin/bash /bin/bash is owned by bash 4.2.020-1 ➜ ~
Weird... Did you enforce POSIX-compatibility somewhere? How do you start the daemons? Do you use something broken like `sh rc.d start $foo` or `sh /etc/rc.d/$foo start`?
If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1 /etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as well.
I have the same problem.It is all happened at codes like "done < <(some stuff)",but after I changed it to "done < $(some stuff)", all going well.I don't know bash has such a syntax usage?
"done < $(foo)" isn't the same thing as "done < <(foo)". You break scripts by changing that (see "Command Substitution" vs. "Process Substitution" in the bash(1) man page). Sounds like process substitution support is broken for you which might have occurred because a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). b) You built bash manually and disabled process substitution support. c) You're running bash in POSIX mode. d) Something else happened.
On Fri, Feb 17, 2012 at 12:03:24PM +0100, Lukas Fleischer wrote:
On Fri, Feb 17, 2012 at 05:58:31PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 Lukas Fleischer <archlinux@cryptocrack.de>:
On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
在 2012年2月17日 下午2:57，Lukas Fleischer <archlinux@cryptocrack.de>写道：
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 大熊 <bearsprite@gmail.com>: > No matter I manual start any a daemon, I always see a error shown on > console: > > /etc/rc.d/functions: line 506: syntax error near unexpected token `(' > /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo > TARGET,FSTYPE,OPTIONS /) > > But it seem that the daemon can run correctly, so should I need to fix it > and how to fix it ?
I don't know why this bug is always occur again and again.
The fix is to edit /etc/rc.d/functions, change line 506 to the following:
done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which bash` and `pacman -Qo /bin/bash`.
➜ ~ bash --help|head -1 GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu) ➜ ~ which bash /bin/bash ➜ ~ pacman -Qo /bin/bash /bin/bash is owned by bash 4.2.020-1 ➜ ~
Weird... Did you enforce POSIX-compatibility somewhere? How do you start the daemons? Do you use something broken like `sh rc.d start $foo` or `sh /etc/rc.d/$foo start`?
If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1 /etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as well.
I have the same problem.It is all happened at codes like "done < <(some stuff)",but after I changed it to "done < $(some stuff)", all going well.I don't know bash has such a syntax usage?
"done < $(foo)" isn't the same thing as "done < <(foo)". You break scripts by changing that (see "Command Substitution" vs. "Process Substitution" in the bash(1) man page). Sounds like process substitution support is broken for you which might have occurred because
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). b) You built bash manually and disabled process substitution support. c) You're running bash in POSIX mode. d) Something else happened.
e) Someone hacked into your system and changed the shebang of all daemon scripts to "#!/bin/sh".
On Fri, Feb 17, 2012 at 12:18 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). b) You built bash manually and disabled process substitution support. c) You're running bash in POSIX mode. d) Something else happened.
e) Someone hacked into your system and changed the shebang of all daemon scripts to "#!/bin/sh".
Maybe f) Your default shell is not bash?
On Fri, Feb 17, 2012 at 3:03 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
On Fri, Feb 17, 2012 at 12:18 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). b) You built bash manually and disabled process substitution support. c) You're running bash in POSIX mode. d) Something else happened.
e) Someone hacked into your system and changed the shebang of all daemon scripts to "#!/bin/sh".
Maybe f) Your default shell is not bash?
The rc scripts should all have a #!/bin/bash, so what shell you call from should not matter. -t
On Fri, Feb 17, 2012 at 03:03:21PM +0100, SanskritFritz wrote:
On Fri, Feb 17, 2012 at 12:18 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). b) You built bash manually and disabled process substitution support. c) You're running bash in POSIX mode. d) Something else happened.
e) Someone hacked into your system and changed the shebang of all daemon scripts to "#!/bin/sh".
Maybe f) Your default shell is not bash?
That doesn't matter unless he invokes the "rc.d" script in a pretty stupid way. The most likely reason is that the script in question has a "#!/bin/sh" shebang (even though the OP claimed that it happens with all daemon scripts)...
I can confirm that all my daemon script begin with "#!/bin/bash" by runing `cd /etc/rc.d;find . -type f | xargs head -1 *`. 2012/2/17 Lukas Fleischer <archlinux@cryptocrack.de>:
On Fri, Feb 17, 2012 at 03:03:21PM +0100, SanskritFritz wrote:
On Fri, Feb 17, 2012 at 12:18 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). b) You built bash manually and disabled process substitution support. c) You're running bash in POSIX mode. d) Something else happened.
e) Someone hacked into your system and changed the shebang of all daemon scripts to "#!/bin/sh".
Maybe f) Your default shell is not bash?
That doesn't matter unless he invokes the "rc.d" script in a pretty stupid way. The most likely reason is that the script in question has a "#!/bin/sh" shebang (even though the OP claimed that it happens with all daemon scripts)...
My default shell is bash.But I am not sure which shell it is using or under which mode of the bash while the system is starting.How to ensure that? 2012/2/17 SanskritFritz <sanskritfritz@gmail.com>:
On Fri, Feb 17, 2012 at 12:18 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). b) You built bash manually and disabled process substitution support. c) You're running bash in POSIX mode. d) Something else happened.
e) Someone hacked into your system and changed the shebang of all daemon scripts to "#!/bin/sh".
Maybe f) Your default shell is not bash?
2012/2/17 Lukas Fleischer <archlinux@cryptocrack.de>:
On Fri, Feb 17, 2012 at 05:58:31PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 Lukas Fleischer <archlinux@cryptocrack.de>:
On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
在 2012年2月17日 下午2:57，Lukas Fleischer <archlinux@cryptocrack.de>写道：
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 大熊 <bearsprite@gmail.com>: > No matter I manual start any a daemon, I always see a error shown on > console: > > /etc/rc.d/functions: line 506: syntax error near unexpected token `(' > /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo > TARGET,FSTYPE,OPTIONS /) > > But it seem that the daemon can run correctly, so should I need to fix it > and how to fix it ?
I don't know why this bug is always occur again and again.
The fix is to edit /etc/rc.d/functions, change line 506 to the following:
done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which bash` and `pacman -Qo /bin/bash`.
➜ ~ bash --help|head -1 GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu) ➜ ~ which bash /bin/bash ➜ ~ pacman -Qo /bin/bash /bin/bash is owned by bash 4.2.020-1 ➜ ~
Weird... Did you enforce POSIX-compatibility somewhere? How do you start the daemons? Do you use something broken like `sh rc.d start $foo` or `sh /etc/rc.d/$foo start`?
If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1 /etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as well.
I have the same problem.It is all happened at codes like "done < <(some stuff)",but after I changed it to "done < $(some stuff)", all going well.I don't know bash has such a syntax usage?
"done < $(foo)" isn't the same thing as "done < <(foo)". You break scripts by changing that (see "Command Substitution" vs. "Process Substitution" in the bash(1) man page). Sounds like process substitution support is broken for you which might have occurred because
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). I am currently using bash, but I am not sure which shell is using while booting process. b) You built bash manually and disabled process substitution support. I am using the bash from the official repo. c) You're running bash in POSIX mode. I am not sure about this,how to check it out? d) Something else happened.
As I mentioned before, same problem in my /etc/bash_completion.d/git happend some tiem ago, now it is gone, because git bash_completion does not contain "done < <(*)" syntax any more. Also, as the first mail submiter and I are both Chinese. Is there any chance that may be the locale caused this? I set locale to "en_US.UTF-8" in the rc.conf while using "zh_CN.UFT-8" under X. 2012/2/17 郑文辉(Techlive Zheng) <techlivezheng@gmail.com>:
2012/2/17 Lukas Fleischer <archlinux@cryptocrack.de>:
On Fri, Feb 17, 2012 at 05:58:31PM +0800, 郑文辉(Techlive Zheng) wrote:
2012/2/17 Lukas Fleischer <archlinux@cryptocrack.de>:
On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
在 2012年2月17日 下午2:57，Lukas Fleischer <archlinux@cryptocrack.de>写道：
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote: > 2012/2/17 大熊 <bearsprite@gmail.com>: > > No matter I manual start any a daemon, I always see a error shown on > > console: > > > > /etc/rc.d/functions: line 506: syntax error near unexpected token `(' > > /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo > > TARGET,FSTYPE,OPTIONS /) > > > > But it seem that the daemon can run correctly, so should I need to fix it > > and how to fix it ? > > I don't know why this bug is always occur again and again. > > The fix is to edit /etc/rc.d/functions, change line 506 to the following: > > done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which bash` and `pacman -Qo /bin/bash`.
➜ ~ bash --help|head -1 GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu) ➜ ~ which bash /bin/bash ➜ ~ pacman -Qo /bin/bash /bin/bash is owned by bash 4.2.020-1 ➜ ~
Weird... Did you enforce POSIX-compatibility somewhere? How do you start the daemons? Do you use something broken like `sh rc.d start $foo` or `sh /etc/rc.d/$foo start`?
If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1 /etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as well.
I have the same problem.It is all happened at codes like "done < <(some stuff)",but after I changed it to "done < $(some stuff)", all going well.I don't know bash has such a syntax usage?
"done < $(foo)" isn't the same thing as "done < <(foo)". You break scripts by changing that (see "Command Substitution" vs. "Process Substitution" in the bash(1) man page). Sounds like process substitution support is broken for you which might have occurred because
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). I am currently using bash, but I am not sure which shell is using while booting process. b) You built bash manually and disabled process substitution support. I am using the bash from the official repo. c) You're running bash in POSIX mode. I am not sure about this,how to check it out? d) Something else happened.
在 2012年2月17日 下午10:32，郑文辉(Techlive Zheng) <techlivezheng@gmail.com>写道：
As I mentioned before, same problem in my /etc/bash_completion.d/git happend some tiem ago, now it is gone, because git bash_completion does not contain "done < <(*)" syntax any more.
Also, as the first mail submiter and I are both Chinese. Is there any chance that may be the locale caused this? I set locale to "en_US.UTF-8" in the rc.conf while using "zh_CN.UFT-8" under X.
I meet this problem on a fresh installed system, no more customization. Also, I set en_US.UTF-8 in rc.conf and set zh_CN.UTF-8 in my login shell(I use zsh). -- 立志在女儿把我搞崩溃前把她养大 看着女儿一天天长大，可惜我还是菜鸟
2012/2/18 大熊 <bearsprite@gmail.com>:
在 2012年2月17日 下午10:32，郑文辉(Techlive Zheng) <techlivezheng@gmail.com>写道：
As I mentioned before, same problem in my /etc/bash_completion.d/git happend some tiem ago, now it is gone, because git bash_completion does not contain "done < <(*)" syntax any more.
Also, as the first mail submiter and I are both Chinese. Is there any chance that may be the locale caused this? I set locale to "en_US.UTF-8" in the rc.conf while using "zh_CN.UFT-8" under X.
I meet this problem on a fresh installed system, no more customization. Also, I set en_US.UTF-8 in rc.conf and set zh_CN.UTF-8 in my login shell(I use zsh).
-- 立志在女儿把我搞崩溃前把她养大 看着女儿一天天长大，可惜我还是菜鸟
Does this has anything todo with the bash_completion, I comment the line "source /etc/bash_completion" in both /etc/profile and /etc/bash.bashrc, and then, everything goes well.
2012/2/18 郑文辉(Techlive Zheng) <techlivezheng@gmail.com>:
2012/2/18 大熊 <bearsprite@gmail.com>:
在 2012年2月17日 下午10:32，郑文辉(Techlive Zheng) <techlivezheng@gmail.com>写道：
As I mentioned before, same problem in my /etc/bash_completion.d/git happend some tiem ago, now it is gone, because git bash_completion does not contain "done < <(*)" syntax any more.
Also, as the first mail submiter and I are both Chinese. Is there any chance that may be the locale caused this? I set locale to "en_US.UTF-8" in the rc.conf while using "zh_CN.UFT-8" under X.
I meet this problem on a fresh installed system, no more customization. Also, I set en_US.UTF-8 in rc.conf and set zh_CN.UTF-8 in my login shell(I use zsh).
-- 立志在女儿把我搞崩溃前把她养大 看着女儿一天天长大，可惜我还是菜鸟
Does this has anything todo with the bash_completion, I comment the line "source /etc/bash_completion" in both /etc/profile and /etc/bash.bashrc, and then, everything goes well.
running `sh /etc/rc.d/functions`, shows /etc/rc.d/functions: line 506: syntax error near unexpected token `<' /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)' running `bash /etc/rc.d/functions` is okay. But 'ls -l /bin/sh', shows that sh is a symlink to bash, but why it behaves so differently? lrwxrwxrwx 1 root root 4 2011-11-23 14:08 /bin/sh -> bash
2012/3/20 郑文辉(Techlive Zheng) <techlivezheng@gmail.com>:
But 'ls -l /bin/sh', shows that sh is a symlink to bash, but why it behaves so differently?
lrwxrwxrwx 1 root root 4 2011-11-23 14:08 /bin/sh -> bash
When called as "/bin/sh", bash works in compatibility mode. Initscripts only support bash being called as "bash". To find out more, Google is your friend :-) -t
2012/3/20 Tom Gundersen <teg@jklm.no>:
2012/3/20 郑文辉(Techlive Zheng) <techlivezheng@gmail.com>:
But 'ls -l /bin/sh', shows that sh is a symlink to bash, but why it behaves so differently?
lrwxrwxrwx 1 root root 4 2011-11-23 14:08 /bin/sh -> bash
When called as "/bin/sh", bash works in compatibility mode. Initscripts only support bash being called as "bash".
To find out more, Google is your friend :-)
-t
Thank you, I thought it is related with this issue, so just ask here, next time, I will do my research first. I think I found the cause of my problem, it turns out I am using an very old /etc/profile. I move the /etc/profile to /etc/profile.bak and reinstall the filesystem package, then I diff the /etc/profile and /etc/profile.bak. I found my previous version of /etc/profile using the some sort of guess mechanism to find the shell that is using and 'sh' is the default value of $SHELL which may cause the last line of 'source /etc/bash-completion' running in compatibility mode. Here is the diff output. diff /etc/profile.bak /etc/profile 2,25d1 < # < # This file is intended to be used for ALL common < # Bourne-compatible shells. Shell specifics should be < # handled in /etc/profile.$SHELL where $SHELL is the name < # of the binary being run (discounting symlinks) < # < # Sections taken from SuSe's /etc/profile < # Note the explicit use of 'test' to cover all bases < # and potentially incompatible shells < < #Determine our shell without using $SHELL, which may lie < shell="sh" < if test -f /proc/mounts; then < case $(/bin/ls -l /proc/$$/exe) in < *bash) shell=bash ;; < *dash) shell=dash ;; < *ash) shell=ash ;; < *ksh) shell=ksh ;; < *zsh) shell=zsh ;; < esac < fi < < # Load shell specific profile settings < test -f "/etc/profile.$shell" && . "/etc/profile.$shell" 31c7 < PATH="/bin:/usr/bin:/sbin:/usr/sbin" --- > PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin" 34,46d9 < # Export default pkg-config path < PKG_CONFIG_PATH="/usr/lib/pkgconfig" < export PKG_CONFIG_PATH < < # Some readline stuff that is fairly common < HISTSIZE=1000 < HISTCONTROL="erasedups" < < INPUTRC="/etc/inputrc" < LESS="-R" < < export HISTSIZE HISTCONTROL INPUTRC LESS < 50c13 < test -x $profile && . $profile --- > test -r "$profile" && . "$profile" 65,66d27 < < source /etc/bash_completion
"郑文辉(Techlive Zheng)" <techlivezheng@gmail.com> writes: [...]
I think I found the cause of my problem, it turns out I am using an very old /etc/profile.
That should be rare. I however, found some of the daemon scripts written with #!/bin/sh but sources /etc/rc.d/functions. That shouldn't make sense, and I think I should report these bugs. I haven't, since I'm lazy... They are /etc/ifplugd/ifplugd.action and /etc/ifplugd/netcfg.action. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
On 2012-02-17 at 12:03 +0100, Lukas Fleischer wrote:
"done < $(foo)" isn't the same thing as "done < <(foo)".
Just out of curiosity: in unmount_all() in /etc/rc.d/functions this is used: while read -r target fstype options; do ... done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /) But why not simply use a pipe in this case: findmnt -mrunRo TARGET,FSTYPE,OPTIONS / \ | while read -r target fstype options; do ... done This should do the same and would be more idiomatic. The commit message[1] when this was introduced did not say anything about that. I wonder what might be the reason for this, understand it and thus improve my shell scripting skills. :) Thanks, Sebastian [1]: http://projects.archlinux.org/initscripts.git/commit/?id=34714bf34e5928479e5...
On 2012-02-17 18:07, Sebastian Schwarz wrote:
On 2012-02-17 at 12:03 +0100, Lukas Fleischer wrote:
"done < $(foo)" isn't the same thing as "done < <(foo)".
Just out of curiosity: in unmount_all() in /etc/rc.d/functions this is used:
while read -r target fstype options; do ... done < <(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
But why not simply use a pipe in this case:
findmnt -mrunRo TARGET,FSTYPE,OPTIONS / \ | while read -r target fstype options; do ... done
This should do the same and would be more idiomatic. The commit message[1] when this was introduced did not say anything about that.
I wonder what might be the reason for this, understand it and thus improve my shell scripting skills. :)
Commands in a pipe would be executed using subshells, so any changes the 'while' loop makes to variables would be lost when the subshell exited. In the current code, 'while' is executed in the main shell process (with `findmnt` being inside a subshell), allowing the $mounts array to be built inside the loop and used outside it. (Play around with `while read; do echo $$ $BASHPID; done` in both forms to see the primary difference.) -- Mantas Mikulėnas <grawity@gmail.com>
On 2012-02-17 at 19:00 +0200, Mantas Mikulėnas wrote:
Commands in a pipe would be executed using subshells, so any changes the 'while' loop makes to variables would be lost when the subshell exited.
I wasn't aware of this. I guess I was lucky I didn't run into a problem with this in all my scripts up to now. Also zsh doesn't seem to use subshells for commands in pipelines. So in zsh both forms would indeed yield the same result. But thank you for the explanation. Regards, Sebastian
participants (8)
-
Lukas Fleischer
-
Mantas Mikulėnas
-
SanskritFritz
-
Sebastian Schwarz
-
Tom Gundersen
-
XeCycle
-
大熊
-
郑文辉(Techlive Zheng)