Re: Problem with Bash-4 and $(command) syntax
On Thu, Mar 12, 2009 at 11:35 PM, bf bf20...@yahoo.com wrote:
{Problem with Bash-4 and $(command) ...}:
[...]
I found the same problem, and have reverted to
bash3.2 until it's sorted out.
See if the following helps.
http://tiswww.case.edu/php/chet/bash/COMPAT
Especially:
38. Since bash-4.0 now follows Posix rules for finding the
closing
delimiter of a $() command substitution, it will not behave as previous
versions did, but will catch more syntax and parsing errors
before
spawning a subshell to evaluate the command substitution.
--
Eray
Yes, the above is true. But many of the examples cited
by people noticing this problem are perfectly valid and
_should_ work. The problem is that the port's parser is
broken, owing in part to incompatibilities between the
system yacc currently used to build the parser and GNU
bison, which is used by the people who write bash. This
is true of both shells/bash and shells/bash3, but is more
noticeable in shells/bash. A fix has been proposed, and patches
are available, in the follow-up to:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/101230
The port's maintainer has been reluctant to switch to bison,
so this may not be the solution that is ultimately used to
fix the port, but you can use these in the meantime.
Regards,
b.
I'm wondering if a fix can be accomplished due to a semicolon within the ()s
to complete a command line. Similar to how find(1) expression works, you
have to end the expression with a semicolon in order for find to
successfully (and willingly) work.
Can the OP try
if $( which gpg2; ); then
And let us know.
My $.02
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problem with Bash-4 and $(command) syntax
On Fri, 13 Mar 2009 13:16:07 -0600 Tim Judd taj...@gmail.com wrote: On Thu, Mar 12, 2009 at 11:35 PM, bf bf20...@yahoo.com wrote: I'm wondering if a fix can be accomplished due to a semicolon within the ()s to complete a command line. Similar to how find(1) expression works, you have to end the expression with a semicolon in order for find to successfully (and willingly) work. Can the OP try if $( which gpg2; ); then No, that doesn't work either. The problem is with 'yacc'. The port maintainer has updated the bash port to use 'bison' instead. The new port is in the ports tree now. I will be installing it later today; however, it should work fine. -- Jerry ges...@yahoo.com The higher you climb, the more you show your ass. Alexander Pope, The Dunciad signature.asc Description: PGP signature
Problem with Bash-4 and $(command) syntax
I just updated from Bash-3.x to Bash-4.0. There appears to be a problem with the way Bash-4 interprits the following. This works fine on Bash-3.x: snippet #!/usr/bin/env bash GET_PATH=1 if $( which gpg2 ); then printf gpg2 located fi /snippet However, under Bash-4, it fail with this error message: ./t.sh: command substitution: line 6: syntax error near unexpected token `)' ./t.sh: command substitution: line 6: ` which gpg2 )' I have several scripts that use the $(command) syntax and they are all failing now. I have replaced that syntax with the older ` tics method. Is this a known problem with Bash-4? I have not been able to find anything about it on the Bash site. -- Jerry ges...@yahoo.com signature.asc Description: PGP signature
Re: Problem with Bash-4 and $(command) syntax
On 12 Mar 2009 at 10:25, Jerry wrote:
{Problem with Bash-4 and $(command) ...}:
Is this a known problem with Bash-4? I have not been
able to find anything about it on the Bash site.
Jerry
ges...@yahoo.com
I found the same problem, and have reverted to
bash3.2 until it's sorted out.
Like you, I wasn't able to find discussion of this on
the lists I subscribe to - although I'm sure it's going
on. Looking through the diffs in
/usr/ports/distfiles/bash, the bracketed form of
command substitution appears to be a long-
standing problem in bash40-xxx.
The back-tick `command` form works as it should,
but not the Posix-style $(command) form, as of
GNU bash, version 4.0.10(1)-release
Mark
--
--
Mark McConnell
mar...@dataabstractsolutions.com
Data Abstract Solutions - Support
12209 N.E. Fourth Plain Suite DD,
Vancouver WA 98682
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problem with Bash-4 and $(command) syntax
On 13.03.2009 02:04, Mark McConnell wrote:
On 12 Mar 2009 at 10:25, Jerry wrote:
{Problem with Bash-4 and $(command) ...}:
[...]
I found the same problem, and have reverted to
bash3.2 until it's sorted out.
See if the following helps.
http://tiswww.case.edu/php/chet/bash/COMPAT
Especially:
38. Since bash-4.0 now follows Posix rules for finding the closing
delimiter of a $() command substitution, it will not behave as previous
versions did, but will catch more syntax and parsing errors before
spawning a subshell to evaluate the command substitution.
--
Eray
Like you, I wasn't able to find discussion of this on
the lists I subscribe to - although I'm sure it's going
on. Looking through the diffs in
/usr/ports/distfiles/bash, the bracketed form of
command substitution appears to be a long-
standing problem in bash40-xxx.
The back-tick `command` form works as it should,
but not the Posix-style $(command) form, as of
GNU bash, version 4.0.10(1)-release
Mark
--
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problem with Bash-4 and $(command) syntax
{Problem with Bash-4 and $(command) ...}:
[...]
I found the same problem, and have reverted to
bash3.2 until it's sorted out.
See if the following helps.
http://tiswww.case.edu/php/chet/bash/COMPAT
Especially:
38. Since bash-4.0 now follows Posix rules for finding the
closing
delimiter of a $() command substitution, it will not behave as previous
versions did, but will catch more syntax and parsing errors
before
spawning a subshell to evaluate the command substitution.
--
Eray
Yes, the above is true. But many of the examples cited
by people noticing this problem are perfectly valid and
_should_ work. The problem is that the port's parser is
broken, owing in part to incompatibilities between the
system yacc currently used to build the parser and GNU
bison, which is used by the people who write bash. This
is true of both shells/bash and shells/bash3, but is more
noticeable in shells/bash. A fix has been proposed, and patches
are available, in the follow-up to:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/101230
The port's maintainer has been reluctant to switch to bison,
so this may not be the solution that is ultimately used to
fix the port, but you can use these in the meantime.
Regards,
b.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
