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