shells/bash-4.0 port horribly broken
andrew clarke
$ uname -a
FreeBSD blizzard.phoenix 6.4-RELEASE-p1 FreeBSD 6.4-RELEASE-p1 #0: Sun
Dec 21 07:56:41 UTC 2008
ro...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
$ sudo portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
Fetching snapshot tag from portsnap1.FreeBSD.org... done.
Latest snapshot on server matches what we already have.
No updates needed.
Ports tree is already up to date.
$ sudo make
===> Vulnerability check disabled, database not found
=> bash-4.tar.gz is not in /usr/ports/shells/bash/distinfo.
=> Either /usr/ports/shells/bash/distinfo is out of date, or
=> bash-4.tar.gz is spelled incorrectly.
*** Error code 1
Stop in /usr/ports/shells/bash.
$ portlint
FATAL: Makefile: extra item "PATCHLEVEL" placed in the PORTNAME section.
FATAL: Package conflicts with itself. You should remove
"bash-[0-24-9].*" from CONFLICTS.
WARN: Makefile: "PKGNAMESUFFIX" has to appear earlier.
WARN: Found IGNOREFILES. It is not recomended.
FATAL: /usr/ports/shells/bash/distinfo: has no SIZE record for
bash/bash-4.tar.gz.
FATAL: -1: [no checksum record for bash/bash-4.tar.gz.]:
WARN: /usr/ports/shells/bash/distinfo: no checksum records for all
supported algorithms (SHA256 MD5) for bash/bash-4.tar.gz.
4 fatal errors and 3 warnings found.
Thanks,
Regards
Andrew
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
andrew clarke
> $ sudo make
> ===> Vulnerability check disabled, database not found
> => bash-4.tar.gz is not in /usr/ports/shells/bash/distinfo.
> => Either /usr/ports/shells/bash/distinfo is out of date, or
> => bash-4.tar.gz is spelled incorrectly.
> *** Error code 1
>
> Stop in /usr/ports/shells/bash.
Update: After a recent ports tree update bash now builds correctly here.
Thanks again :)
Emanuel Haupt
> > ===> Vulnerability check disabled, database not found
> > => bash-4.tar.gz is not in /usr/ports/shells/bash/distinfo.
> > => Either /usr/ports/shells/bash/distinfo is out of date, or
> > => bash-4.tar.gz is spelled incorrectly.
> > *** Error code 1
> >
> > Stop in /usr/ports/shells/bash.
>
> Update: After a recent ports tree update bash now builds correctly
> here.
The update still remains broken:
[fooman@portjail ~]$ pkg_info
bash-static-4.0.10_1 The GNU Project's Bourne Again SHell
[root@portjail ~]$ set -x
[root@portjail ~]$ echo $(uname)
-bash: command substitution: line 25: syntax error near unexpected token `)'
-bash: command substitution: line 25: `uname)'
[root@portjail ~]$ echo $(uptime)
-bash: command substitution: line 26: syntax error near unexpected token `)'
-bash: command substitution: line 26: `uptime)'
[root@portjail ~]$ echo $(ls)
-bash: command substitution: line 27: syntax error near unexpected token `)'
-bash: command substitution: line 27: `ls)'
however, backticks work:
[root@portjail ~]$ echo `uname`
++ uname
+ echo FreeBSD
FreeBSD
Also, shells/bash now conflicts with shells/bash-completion which
it shouldn't.
Emanuel
--
GnuPG key id: 0x90215DB9 Download: http://pgp.mit.edu:11371
Key fingerprint: 741B C70F 100B F360 0B52 E92D 5F01 7A86 9021 5DB9
Stefan Bethke
>>> $ sudo make
>>> ===> Vulnerability check disabled, database not found
>>> => bash-4.tar.gz is not in /usr/ports/shells/bash/distinfo.
>>> => Either /usr/ports/shells/bash/distinfo is out of date, or
>>> => bash-4.tar.gz is spelled incorrectly.
>>> *** Error code 1
>>>
>>> Stop in /usr/ports/shells/bash.
>>
>> Update: After a recent ports tree update bash now builds correctly
>> here.
>
> The update still remains broken:
>
> [fooman@portjail ~]$ pkg_info
> bash-static-4.0.10_1 The GNU Project's Bourne Again SHell
>
> [root@portjail ~]$ set -x
> [root@portjail ~]$ echo $(uname)
> -bash: command substitution: line 25: syntax error near unexpected
> token `)'
> -bash: command substitution: line 25: `uname)'
I also find this rather annoying. I believe that a rather large
percentage of people use bash as their default shell, so moving from
3.2 to 4.0 should have been preceded by a headsup or an entry in
UPDATING.
Stefan
--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811
Andrew W. Nosenko
> Am 12.03.2009 um 11:29 schrieb Emanuel Haupt:
>
>>>> $ sudo make
>>>> ===> Vulnerability check disabled, database not found
>>>> => bash-4.tar.gz is not in /usr/ports/shells/bash/distinfo.
>>>> => Either /usr/ports/shells/bash/distinfo is out of date, or
>>>> => bash-4.tar.gz is spelled incorrectly.
>>>> *** Error code 1
>>>>
>>>> Stop in /usr/ports/shells/bash.
>>>
>>> Update: After a recent ports tree update bash now builds correctly
>>> here.
>>
>> The update still remains broken:
>>
>> [fooman@portjail ~]$ pkg_info
>> bash-static-4.0.10_1 The GNU Project's Bourne Again SHell
>>
>> [root@portjail ~]$ set -x
>> [root@portjail ~]$ echo $(uname)
>> -bash: command substitution: line 25: syntax error near unexpected token
>> `)'
>> -bash: command substitution: line 25: `uname)'
>
> I also find this rather annoying. I believe that a rather large percentage
> of people use bash as their default shell, so moving from 3.2 to 4.0 should
> have been preceded by a headsup or an entry in UPDATING.
Hmm... But record in UPDATING won't cure the bug itself. Or error in
the parsing
$ echo $(ls)
construct is not a bug? If it is not a bug but intended behavior,
then could someone point me to the appropriate part of documentation?
--
Andrew W. Nosenko <andrew.w...@gmail.com>
Jerry
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, 12 Mar 2009 12:48:09 +0100
Stefan Bethke <s...@lassitu.de> wrote:
>Am 12.03.2009 um 11:29 schrieb Emanuel Haupt:
>
>>>> $ sudo make
>>>> =3D=3D=3D> Vulnerability check disabled, database not found
>>>> =3D> bash-4.tar.gz is not in /usr/ports/shells/bash/distinfo.
>>>> =3D> Either /usr/ports/shells/bash/distinfo is out of date, or
>>>> =3D> bash-4.tar.gz is spelled incorrectly.
>>>> *** Error code 1
>>>>
>>>> Stop in /usr/ports/shells/bash.
>>>
>>> Update: After a recent ports tree update bash now builds correctly
>>> here.
>>
>> The update still remains broken:
>>
>> [fooman@portjail ~]$ pkg_info
>> bash-static-4.0.10_1 The GNU Project's Bourne Again SHell
>>
>> [root@portjail ~]$ set -x
>> [root@portjail ~]$ echo $(uname)
>> -bash: command substitution: line 25: syntax error near unexpected =20
>> token `)'
>> -bash: command substitution: line 25: `uname)'
>
>I also find this rather annoying. I believe that a rather large =20
>percentage of people use bash as their default shell, so moving from =20
>3.2 to 4.0 should have been preceded by a headsup or an entry in =20
>UPDATING.
I am having the exact same problem. Several of my scripts are now
failing. I have modified a few with the older "`" tic method to make
them work; however, I feel that the easiest thing would be to simply
revert to Bash-3.
Was this some sort of 'improvement' by the Bash developers, or is it an
un-squashed bug?
--=20
Jerry
ges...@yahoo.com
--Sig_/E2Hd0ijsHgxnUY5CXO.uHcO
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
iEYEARECAAYFAkm5HHgACgkQBvaKIJWWCO1rhACfT6SoYVR2sqw0utHGFLt5TBzx
fqwAn0MDleToPSAPEZtMSnYw+5f2s0wI
=Nx7i
-----END PGP SIGNATURE-----
--Sig_/E2Hd0ijsHgxnUY5CXO.uHcO--
Johan van Selst
--pWyiEgJYm5f9v55/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Jerry wrote:
> Was this some sort of 'improvement' by the Bash developers, or is it
> an un-squashed bug?
It seems that this might actually be a feature.
Quoting the COMPAT document of bash4:
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.
Ciao,
Johan
--pWyiEgJYm5f9v55/
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
iEYEAREIAAYFAkm5HhYACgkQaOElK32lxTuiXwCgvtfxJYl9ufsEO9gY9IGGRJW+
Te4AoMHehyMwYI3F7xgUhnj4+nansJ2m
=fav/
-----END PGP SIGNATURE-----
--pWyiEgJYm5f9v55/--
Alex Goncharov
| I am having the exact same problem. Several of my scripts are now
| failing. I have modified a few with the older "`" tic method to make
| them work; however, I feel that the easiest thing would be to simply
| revert to Bash-3.
|
| an un-squashed bug?
Breaking the $(command) substitution would be catastrophic and Bash
4.0 documentation claims support for it:
http://tiswww.case.edu/php/chet/bash/bashref.html
Bash Reference Manual
This text is a brief description of the features that are present in
the Bash shell (version 4.0, 29 December 2008).
This is Edition 4.0, last updated 29 December 2008, of The GNU Bash
Reference Manual, for Bash, Version 4.0.
3.5.4 Command Substitution
Command substitution allows the output of a command to replace the
command itself. Command substitution occurs when a command is enclosed
as follows: $(command)
or `command`
Bash performs the expansion by executing command and replacing the
command substitution with the standard output of the command, with any
trailing newlines deleted. Embedded newlines are not deleted, but they
may be removed during word splitting. The command substitution $(cat
file) can be replaced by the equivalent but faster $(< file).
-- Alex -- alex-go...@comcast.net --
/*
* Every time I lose weight, it finds me again!
*/
Andrew W. Nosenko
> Jerry wrote:
>> Was this some sort of 'improvement' by the Bash developers, or is it
>> an un-squashed bug?
>
> Quoting the COMPAT document of bash4:
>
> 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.
Sorry, but I didn't see how it can be applied. In another words, how
the 'ls' command in the
$ echo $(ls)
contradicts with POSIX.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03
With the $( command) form, all characters following the open
parenthesis to the matching closing parenthesis constitute the
command. Any valid shell script can be used for command,
except a script consisting solely of redirections which produces
unspecified results.
Sure, 'ls' is not a something that "consisting solely of redirections".
--
Andrew W. Nosenko <andrew.w...@gmail.com>
Emanuel Haupt
> revert to Bash-3.
This is exactly what I did.
Emanuel
Christian Weisgerber
> The update still remains broken:
>
> [fooman@portjail ~]$ pkg_info
> bash-static-4.0.10_1 The GNU Project's Bourne Again SHell
>
> [root@portjail ~]$ set -x
> [root@portjail ~]$ echo $(uname)
> -bash: command substitution: line 25: syntax error near unexpected token `)'
> -bash: command substitution: line 25: `uname)'
This breakage has been introduced somewhere in the first ten patches.
4.0.0 was fine. Which is funny, considering that the patches claim
to fix some problems in that area.
Apparently nobody runs bash's included regression test suite either...
--
Christian "naddy" Weisgerber na...@mips.inka.de
bf
Hang on guys, we're looking into it. The upstream maintainer
confirms that failures in command substitutions are _not_ the
expected behavior of bash 4.x, that they are not being observed on
many other systems, and that in the past similar problems like
this have been connected with problems in bison, so maybe our use
of system yacc has something to do with it.
The point about running the testsuite is well-taken.
b.
Jerry
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, 12 Mar 2009 13:48:47 -0700 (PDT)
bf <bf2...@yahoo.com> wrote:
>Hang on guys, we're looking into it. The upstream maintainer
>confirms that failures in command substitutions are _not_ the
>expected behavior of bash 4.x, that they are not being observed on
>many other systems, and that in the past similar problems like
>this have been connected with problems in bison, so maybe our use
>of system yacc has something to do with it.
>
>The point about running the testsuite is well-taken.
>
>b.=20
I have filed a bug-report with bash about this. So far, I have received
one reply with a request for further information. So, I guess someone is
at least working on it.
--=20
Jerry
ges...@yahoo.com
--Sig_/8ub2tRYc_W3A7ujb3pYzZEW
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
iEYEARECAAYFAkm5egQACgkQBvaKIJWWCO0GjACfUzBe/eKGH7Rb0yHmIADj+Sgs
pqkAoKLIIY+UDC19zOCSR+Kn/OjoHaYE
=PMT4
-----END PGP SIGNATURE-----
--Sig_/8ub2tRYc_W3A7ujb3pYzZEW--
Jerry
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, 12 Mar 2009 14:18:28 -0700 (PDT)
bf <bf2...@yahoo.com> wrote:
>--- On Thu, 3/12/09, bf <bf2...@yahoo.com> wrote:
>> Hang on guys, we're looking into it. The upstream
>> maintainer
>> confirms that failures in command substitutions are _not_
>> the
>> expected behavior of bash 4.x, that they are not being
>> observed on
>> many other systems, and that in the past similar problems
>> like
>> this have been connected with problems in bison, so maybe
>> our use
>> of system yacc has something to do with it.
>>=20
>> The point about running the testsuite is well-taken.
>>=20
>> b.
>
>Yes, I can confirm on my system (8-CURRENT i386), switching
>the port from system yacc to bison 2.x solves the
>command substitution problem. Try the attached patch.
By any chance, did you commit a Send-PR for this patch? I will try the
patch later tonight anyway.
Thanks!
--=20
Jerry
ges...@yahoo.com
George Orwell 1984. Northwestern 0.
Chicago Reader 10/15/82
--Sig_/3KMcD.P=3ob1e3X9XAcF62h
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
iEYEARECAAYFAkm5fnMACgkQBvaKIJWWCO00RACgqB88vnLrHXye47Eo1psS3qRe
VOQAn03lhVf1n15vGiffSUlMzWNcPKMd
=MGYN
-----END PGP SIGNATURE-----
--Sig_/3KMcD.P=3ob1e3X9XAcF62h--
Emanuel Haupt
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> Yes, I can confirm on my system (8-CURRENT i386), switching
> the port from system yacc to bison 2.x solves the
> command substitution problem. Try the attached patch.
I confirm that this patch solves the problem.
Emanuel
--Signature=_Thu__12_Mar_2009_23_50_15_+0100_wl.j9yw8ev14_Cwx
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkm5kaoACgkQXwF6hpAhXbkJ7gCdH5A4O+qhDtyx5TbJX9FPx10f
2KIAn36plKxC5iRK6EW2ywyQ4xfldD4d
=kOiG
-----END PGP SIGNATURE-----
--Signature=_Thu__12_Mar_2009_23_50_15_+0100_wl.j9yw8ev14_Cwx--
bf
> By any chance, did you commit a Send-PR for this patch? I will
> try the patch later tonight anyway.
> Thanks!
I've submitted a slightly revised patch in a follow-up to an old
PR:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/101230
It turns out that some of the parser problems with the new port
were noticed with earlier versions, but the maintainer decided
to be conservative and chose not to address them then.
David O'Brien
>> The update still remains broken:
>> -bash: command substitution: line 25: syntax error near unexpected token
>> `)'
>> -bash: command substitution: line 25: `uname)'
>
> of people use bash as their default shell, so moving from 3.2 to 4.0 should
> have been preceded by a headsup or an entry in UPDATING.
I didn't have issues with my ~/.bashrc when I updated from 3.2 to 4.0 so
I didn't notice this issue. (guess I'm too old school and use "`"'s).
--
-- David (obr...@FreeBSD.org)
matt donovan
I m not sure if the bash-4.0 port has the current patchset but I know it
fixes some issues with $()