On Wed, Feb 21, 2024 at 12:17 PM Andreas Schwab wrote:
...
> Or ulimit -v $((8*1024*1024))
>
Good point. If a user remembers that "-v" implicitly works in 1024-byte
units, that's a good shortcut.
When setting memory-size limits via "ulimits", users have to manually
convert from their intuitive units.
E.g., for limiting virtual memory to 8 gigabytes, the invocation is "ulimit
-v 8388608", rather than something like "ulimit -v 8gb".
If I were to submit a patch for this, is there any chance
ty
checks on the data passed to the shared code.
BR, Christian
Am 29.08.23 um 20:19 schrieb Chet Ramey:
On 8/29/23 11:56 AM, Kerin Millar wrote:
One hopes that the shell programmer knows what variable types he's
using, and uses the appropriate constructs.
Some elect to source shell co
you take a look?
If it is intended, can you please explain, why this was changed, and if
there is an alternative for associative arrays?
BR, Christian
--
-
RADIODATA GmbH
Newtonstr. 18
12489 Berlin
Germany
Homepage:
) $(MFLAGS) all
#newversion: mkversion
--
Christian "naddy" Weisgerber na...@mips.inka.de
printf("%ld\n", st->st_ctime);
+ printf("%lld\n", (long long)st->st_ctime);
} else if (flags & OPT_DEV)
printf("%lu\n", (unsigned long)st->st_dev);
else if (flags & OPT_INO)
--
Christian "naddy" Weisgerber na...@mips.inka.de
loading
esac
case "$host_cpu" in
*cray*)LOCAL_CFLAGS="-DCRAY" ;; # shell var so config.h can
use it
esac
case "$host_cpu-$host_os" in
--
Christian "naddy" Weisgerber na...@mips.inka.de
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/ba
$(CPPFLAGS) $(CFLAGS)
#
# These values are generated for configure by ${topdir}/support/shobj-conf.
--
Christian "naddy" Weisgerber na...@mips.inka.de
. (It checks for *.so; OpenBSD
only has fully numbered libraries: *.so.0.0, etc.)
These macros should be updated to newer versions from a recent
release of gettext.
--
Christian "naddy" Weisgerber na...@mips.inka.de
2-bit platforms (IA-32, ARMv7) are still around. And BSD has had
64-bit off_t on 32-bit architectures for about a quarter century.
--
Christian "naddy" Weisgerber na...@mips.inka.de
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
ts in the code, e.g.,
printf("%ld\n", (long) st->st_size);
which potentially truncate values.
I don't know if the example loadables are considered to be more
than, well, rough examples, so I'm uncertain if this should even
be considered a problem.
--
Christian "naddy" Weisgerber na...@mips.inka.de
uldn't the ".made" target have "loadables" as a prerequisite?
--
Christian "naddy" Weisgerber na...@mips.inka.de
my capacity as the OpenBSD packager for bash, either
way is fine. We use the upstream patches as provided ("distribution
patches"). These are applied with -p0 by default, but it's utterly
trivial to specify -p1 if necessary. The choice of context vs.
unified diffs is immaterial; pat
On Tue, Oct 10, 2017 at 5:44 PM, Chet Ramey wrote:
> On 10/9/17 10:37 AM, Christian Brauner wrote:
>
>> A common scenario where this happens is with /dev/console in containers.
>> Usually container runtimes/managers will call openpty() on a ptmx device in
>> the
>
that makes sense to you it'd be greatly
appreciated.
Fwiw, zsh does not seem to run into a problem here.
Thanks
Christian
[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=22145
ash_cv_strtold_broken=no, bash_cv_strtold_broken=yes,
[AC_MSG_WARN(cannot check for broken strtold if cross-compiling,
defaulting to no)])
]
--
Christian "naddy" Weisgerber na...@mips.inka.de
#x27;
86293x\nx
$ echo $(echo $'x\nx')
x x
$ echo $(echo $$'x\nx')
x x
This is with bash 4.4.12... but a quick check shows the same behavior
with 4.2.37.
--
Christian "naddy" Weisgerber na...@mips.inka.de
* In process_substitute(), discard_pipeline(last_procsub_child)
is called.
* discard_pipeline() frees last_procsub_child.
* free() is interrupted by a signal.
* The signal handler eventually calls find_pipeline(), which accesses
the just-freed memory last_procsub_child points to.
--
Christian &q
-538976289, status = -538976289,
running = -538976289,
command = 0xdfdfdfdfdfdfdfdf }
(gdb) p /x last_procsub_child->pid
$3 = 0xdfdfdfdf
This looks like a use after free() since OpenBSD's malloc fills
some of the freed memory with 0xdf.
--
Christian "naddy" Weisgerber na...@mips.inka.de
mance degradation if
arrays are accessed not sequentially.
Thanks,
Christian
2016-09-19 3:41 GMT+02:00 Chet Ramey :
> Yes, you've triggered an infinite loop with the key binding. One of the
> strengths of macros is that the expansion is not simply a string -- it can
> be used as shorthand for a complex key sequence, so simply disallowing
> the general case is not really an
n infinite loop but in that case accumulation of memory is
insignificant.
Since I am not known with the internals of Bash/Readline and I am not
a C programmer I've refrained myself from digging further.
Regards,
Christian Klomp
# Bash 4.3.46:
--- ../bash-4.3/lib/readline/bind.c2013-04-
Hello,
I have been playing around with tilde expansion lately and I think i
have discovered a case where the tilde is expanded where it, according
to the documentation, should not.
When running:
$ x=~
x is set to the current users home directory as expected.
$ echo $x
/home/christian
But
ected end of file
bug.sh: line 7: syntax error near unexpected token `esac'
bug.sh: line 7: ` esac'
$ dash bug.sh
1
2
Workarounds:
- append semicolon behind first 'esac', or
- insert any command line between the case statements, or
- use `...` instead of $(...)
--
Christian Franke
r the former patch for
inclusion?
On Thu, Oct 1, 2015 at 8:29 PM, Chet Ramey wrote:
> On 9/30/15 10:07 AM, Christian Ehrhardt wrote:
> > Hi,
> > I read and worked on a fix reported to ubuntu regarding this issue.
> > https://bugs.launchpad.net/hundredpapercuts/+bug/1488939
>
nd Regards,
Christian
From: Christian Ehrhardt
Fixing some confusion of the bash builtin kill not behaving as the procps
kill which one can see in the manpages by adding a -L option mapping to
the already existing code behind -l.
Signed-off-by: Christian Ehrhardt
---
[diffstat]
builtins/kill.
icular, this also happens when the expansion error occurs in a
line consisting of an "exec"-statement, where evaluation usually *never*
continues (e.g. bash correctly exits when the command is not found).
I think to avoid further damage due to badly set variables, bash
should exit in
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
istory list
-sappend the ARGs to the history list as a single entry
...
The problem is that the documentation in builtins/*.def is written
starting in column 1 and includes tab characters, but the help
output is then indented by BASE_INDENT (4) characters.
Affects at least 4.2.x, 4.3.x.
tical line of code missing, but the the 'patch'
> command will also fail when used with the --fuzz=0 option -- which is
> something that rpmbuild (Fedora, etc) uses.
That's GNU patch. OpenBSD's patch just fails with it.
--
Christian "naddy" Weisgerber na...@mips.inka.de
stamp ends up being newer than parse.y,
Why would this happen?
> a patch which (correctly) only patches parse.y,
... will cause parse.y to have a newer timestamp.
--
Christian "naddy" Weisgerber na...@mips.inka.de
ur
test. But
bash-4.1.13(1), bash-3.1.19(1), and 2.05b.0(1) with all officials
patches fails
the same test. Hope that patches will soon be available for all bash
versions.
Jean-Christian
sticky version string for that old setup.
Jean-Christian
Le 26. 09. 14 16:47, Chet Ramey a écrit :
On 9/26/14, 4:53 AM, Jean-Christian de Rivaz wrote:
Hello,
While this can seem completely obsolete, I still have machines running bash
2.05b (Debian etch). I worry about upgrading to bash 3.x because of some
backward compatibility issue.
It there any
affect this version:
j$ bash --version
GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
j$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
Best Regards,
Jean-Christian
0
--
Christian "naddy" Weisgerber na...@mips.inka.de
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: freebsd8.1
Compiler: cc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='freebsd8.1' -DCONF_MACHTYPE='i386-portbld-freebsd8.1'
-DCONF_VENDOR='portbld' -DLOCALEDIR='/usr/local/share/loc
c rather than y.tab.c, so y.tab.c is never regenerated,
and the parser fix from patch 001 is effectively not applied.
We just need to use YACC="bison -y".
--
Christian "naddy" Weisgerber na...@mips.inka.de
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:
> This has been fixed with patch 1, are you sure you are running the
> patched version?
Yes, I am.
--
Christian "naddy" Weisgerber na...@mips.inka.de
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.
--
C
../../include -I../../lib -O2 -pipe glob.c
glob.c:1023:69: missing terminating ' character
Apparently GCC 3.4 and later versions handle this as intended.
[I'm not subscribed to bug-bash.]
--
Christian "naddy" Weisgerber na...@mips.inka.de
#x27;t be compiled properly with bash 4.x) resolved.
Thank you very much in advance!
Best regards,
Christian
r is correct
or not. Please see my comments below:
Chet Ramey wrote:
> Mike Frysinger wrote:
>> On Thursday 25 June 2009 19:17:38 Chet Ramey wrote:
>>> Christian Krause wrote:
>>>> Bash Version: 4.0
>>>> Patch Level: 16
>>>> Release Status: re
of
environment variables accessible via "set"
* the variable is still in the process's environment
* the variable will be filtered out when the bash executes a subsequent
process
This change may also affect other make-based build systems which rely on
the fact that a make variable which is exported via the keyword "export"
in the Makefile is accessible in nested calls of make.
Best regards,
Christian
that point on I turned off the light that said I should
check for duplicates.
I don't have the energy for checking the
http://www.opengroup.org/onlinepubs/009695399/utilities/set.html link
posted in response to one of the earlier reports right now. Maybe later.
Thanks anyway-
Christian.
(This is a resend because the gnu.org ml server didn't accept the
sender email address that was given by my mailing setup; the first
attempt has also been sent to [EMAIL PROTECTED])
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Comp
Sorry for not reading the documentation ... it just used to work and I didn't
expect it to break :)
Thanks for clarifying things.
Regards,
Christian
On Monday 29 October 2007 18:26:06 Bob Proulx wrote:
> Christian Schubert wrote:
> > PS1='\e[32m$\e[m'
>
> N
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: i686-pc-linux-gnu-gcc
Compilation
CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu'
-DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc'
-DLOCALEDIR='/usr/share/lo
Hi,
i updated bash-3.2 to patch level 25 and i get the following error:
INIT: Entering runlevel: 1
INIT: Id "s0" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel
my inittab entry is:
s0:123:respawn:/sbin/getty -L -n -l /bin/bash ttyS0 115200 linux
gett
Chet Ramey wrote:
Christian Boon wrote:
This is from aclocal.m4:
AC_DEFUN(BASH_SYS_JOB_CONTROL_MISSING,
[AC_REQUIRE([BASH_SYS_SIGNAL_VINTAGE])
AC_MSG_CHECKING(for presence of necessary job control definitions)
AC_CACHE_VAL(bash_cv_job_control_missing,
[AC_TRY_RUN([
#include
#ifdef
Christian Boon wrote:
Chet Ramey wrote:
Christian Boon wrote:
Hello,
i want to cross compile bash-3.2 for my pxa255 arm processor and its
working although i can't get job control working.
It tells you it won't be able to:
checking for presence of necessary job control d
Chet Ramey wrote:
Christian Boon wrote:
Hello,
i want to cross compile bash-3.2 for my pxa255 arm processor and its
working although i can't get job control working.
It tells you it won't be able to:
checking for presence of necessary job control definitions...
Chet Ramey wrote:
cross-compiling bash is known to be broken as it'll mix your host signal defs
into the target binary
This is no longer true; bash-3.2 builds the signal list at invocation time
rather than compile time when cross-compiling.
Chet
so what do i need to have job control
Mike Frysinger wrote:
On Monday 27 August 2007, Christian Boon wrote:
i want to cross compile bash-3.2 for my pxa255 arm processor and its
working although i can't get job control working.
cross-compiling bash is known to be broken as it'll mix your host signal defs
into
Hello,
i want to cross compile bash-3.2 for my pxa255 arm processor and its
working although i can't get job control working.
i configure bash with:
bash-3.2]$ ./configure --host=arm-xscale-linux-gnueabi
--without-bash-malloc --enable-job-control
in the output i see:
checking if opendir(
On Wed, 2007-08-08 at 10:39 +0200, Hans-Christian Egtvedt wrote:
> I am using uClibc 0.9.29 and GCC 4.1.2 to compile bash 3.2 (with the 17
> patches released on web). And I have a problem that configure does not
> detect bzero properly, and thus resulting in a crash later when
> compil
to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined __stub_bzero || defined __stub___bzero
| choke me
| #endif
|
| int
| main ()
| {
| return bzero ();
| ;
| return 0;
| }
configure:12901: result: no
bit\n"
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 &&
n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
t;-- manually removed the backslash,
dir1/ dir2/ --foo= # now it works :-)
It would be nice if you could fix that problem ;-)
Regards,
Christian Boltz
--
2.-5.9.2005: Weinfest in Insheim
Bei der Landjugend: Liquid, AH-Band und Deafen Goblins
Mehr Infos: www.Landjugend-Insheim.de
__
63 matches
Mail list logo
