Building the loadable modules depends on files created during the
main build. However, the Makefile doesn't record any such dependency.
Running for instance "make -j10 all loadables" will fail due to a
lack of enforced sequencing.
A straightforward fix would be to make the "loadables" target depe
loadables/finfo.c uses the %ld format string to print time_t values.
This is wrong on OpenBSD, where time_t is long long on all platforms.
I suggest %lld and a cast to long long.
Alternatively, %jd and intmax_t could be used.
--- examples/loadables/finfo.c.orig Mon Jun 29 16:56:32 2020
+++ ex
Dynamic loading of modules is broken on OpenBSD:
bash-5.2$ enable finfo
bash:/usr/local/lib/bash/finfo: undefined symbol 'sh_optind'
bash:/usr/local/lib/bash/finfo: undefined symbol 'sh_optarg'
bash: enable: finfo: not a shell builtin
This is trivially fixed, configure simply needs to add -rdynam
There is a small omission in bash 5.0's build infrastructure:
The CPPFLAGS variable doesn't propagate to the actual compiler flags
used to build the loadables. In practice, this means that the seq
loadable will fail to build on operating systems that have libintl
outside the default paths (e.g. Op
The bash 5.0 release still ships with very old autoconf macros to
detect gettext. In aclocal.m4, the copy of gettext.m4 and the
supporting lib-link.m4 are from gettext-0.12 dating from 2003.
In particular, the included version of AC_LIB_LINKFLAGS_BODY cannot
detect shared libraries on OpenBSD. (
Chet Ramey:
> > printf("%ld\n", (long) st->st_size);
> >
> > which potentially truncate values.
>
> Pretty much all the systems bash runs on these days have 64-bit longs.
> How big a file do you have? But the fix is the same as above.
32-bit platforms (IA-32, ARMv7) are still ar
I'm not sure what the new tests/test1.sub in bash 5.0alpha is
intended to test, but it fails on OpenBSD because /dev/fd/* are
actual character devices there, so test -p /dev/fd/6 will always
be unsuccessful.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Compiling examples/loadables/finfo.c (bash 4.4.23, 5.0-alpha) on
OpenBSD produces various warnings about ill-matched types:
--->
finfo.c:325:20: warning: format specifies type 'long' but the argument has type
'time_t' (aka 'long long') [-Wformat]
printf("%l
There is an issue in the build framework of bash 4.4.23 (and 5.0-alpha):
"make all" does not build examples/loadables.
"make install" however recurses into examples/loadables and, since
the loadable modules aren't there, proceeds to build them before
installation.
Shouldn't the ".made" target have
Marty E. Plummer:
> Maintainers, I'd really like to hear your thoughts on this matter. If
> the diffs are produced as -p1 unified diffs, then downstreams who do
> convert from -p0 context won't have to, and distros who work around it
> won't either.
Speaking in my capacity as the OpenBSD packager
I'm forwarding this bug report by Robert Nagy ,
which also concerns bash 4.4:
>
Unbreak autoconf checks with clang by not using nested functions
in the checks.
Someone clearly did not read the autoconf documentation because
using the following functions with a function declaration
This came up on comp.unix.shell:
There appears to be a parsing problem in bash where the sequence
$$'...' is treated as $'...', and $$"..." as $"...", when inside
$(...).
$ echo 'x\nx'
x\nx
$ echo $'x\nx'
x
x
$ echo $$'x\nx'
86293x\nx
$ echo $(echo $'x\nx')
x x
$ echo $(echo $$'x\nx')
x x
T
Chet Ramey:
> > Running the bash 4.4 regression test suite on OpenBSD/amd64, I noticed
> > a crash in the redir tests. Specifically, running redir10.sub with
> > bash 4.4 causes it to die with a bus error most of the time.
>
> Thanks for the report. I can't reproduce this,
Here's the backtrace
Running the bash 4.4 regression test suite on OpenBSD/amd64, I noticed
a crash in the redir tests. Specifically, running redir10.sub with
bash 4.4 causes it to die with a bus error most of the time.
Program terminated with signal 10, Bus error.
#0 0x1c9ad0634009 in find_pipeline (pid=97028,
Christian Weisgerber:
> The output of "help " suffers from various indentation problems.
PS:
I ran *.def through expand(1), which is one way to fix the problem,
but this also reveals that some help texts run over the 80-column
limit when indented by four characters: mapfil
The output of "help " suffers from various indentation problems.
E.g., an excerpt from "help history":
...
-aappend history lines from this session to the history file
-nread all history lines not already read from the history file
-rread the history file
Deron Meranda:
> I was wondering if anybody was going to address the problem with 4.2 patch
> 49 ?
>
> It is still corrupted on the FTP server. There are a few lines that appear
> to have been deleted out of the middle of the patch file.
Indeed.
> Not only is there a critical line of code miss
Mark Goldfinch:
> Can someone clarify to me why y.tab.c is included within the bash source
> tree if it is generated from parse.y?
>
> If one looks in the FreeBSD ports tree, they're deliberately taking the
> initiative to touch parse.y to ensure that y.tab.c is always rebuilt.
They also have a
This turned up when I compared the output of groff(1) and mandoc(1)
(http://mdocml.bsd.lv/).
--- doc/bash.1.orig Sat Aug 4 21:34:54 2012
+++ doc/bash.1 Sat Aug 4 21:35:13 2012
@@ -2271,7 +2271,7 @@ The value of \fIp\fP determines whether or not the fra
included.
.IP
If this variable is n
Chet Ramey:
> >> I suppose the only real variable is the revision of bison:
> >
> > 2.4.1 and 2.3 on my FreeBSD and OpenBSD box, respectively.
>
> Try 1.875 and see if the problems go away.
Red herring. I found the problem, it is embarrassingly stupid, and
Andreas was right. The fault lies wi
Chet Ramey:
> I suppose the only real variable is the revision of bison:
2.4.1 and 2.3 on my FreeBSD and OpenBSD box, respectively.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Chet Ramey:
> Christian Weisgerber wrote:
> > Even in the latest bash, 4.0.33, $() parsing is still broken:
> >
> > $ bash -c 'echo $(echo \|)'
> > bash: -c: line 0: unexpected EOF while looking for matching `)'
> > bash: -c: line 1: syntax error:
Andreas Schwab:
> > Even in the latest bash, 4.0.33, $() parsing is still broken:
> >
> > $ bash -c 'echo $(echo \|)'
> > bash: -c: line 0: unexpected EOF while looking for matching `)'
> > bash: -c: line 1: syntax error: unexpected end of file
>
> This has been fixed with patch 1, are you sure y
Even in the latest bash, 4.0.33, $() parsing is still broken:
$ bash -c 'echo $(echo \|)'
bash: -c: line 0: unexpected EOF while looking for matching `)'
bash: -c: line 1: syntax error: unexpected end of file
And yes, this is bash built with GNU bison, not Berkeley yacc.
--
Christian "naddy" We
Bash-4.0 official patch 25 adds a section that looks to the compiler
like a nested C comment. Obviously somebody recognized this and
added #if 0 ... #endif around the whole comment.
Alas, GCC 3.3 still errors out:
cc -c -DHAVE_CONFIG_H -DSHELL -I/usr/local/include -I. -I../.. -I../..
-I../../in
msgfmt will abort with an error about illegal UTF-8 encoding when
processing ru.po. The Russian text in the file is actually encoded
in KOI8-R.
--- po/ru.po.orig Sat Oct 14 19:29:17 2006
+++ po/ru.poSat Oct 14 19:29:29 2006
@@ -12,7 +12,7 @@ msgstr ""
"Last-Translator: Evgeniy Dushisto
26 matches
Mail list logo
