bash using incorrect block size with limits
Maybe already reported bug, but
bash is using 1024 bytes block size, but should be using 512 bytes.
I'm including my easy patch.
diff -up bash-3.2/builtins/ulimit.def.blocksize bash-3.2/builtins/ulimit.def
--- bash-3.2/builtins/ulimit.def.blocksize 2008-06-02 14:59:38.0 +0200
+++ bash-3.2/builtins/ulimit.def 2008-06-02 15:02:38.0 +0200
@@ -199,7 +199,7 @@ typedef struct {
static RESOURCE_LIMITS limits[] = {
#ifdef RLIMIT_CORE
- { 'c', RLIMIT_CORE, 1024, "core file size", "blocks" },
+ { 'c', RLIMIT_CORE, 512, "core file size", "blocks" },
#endif
#ifdef RLIMIT_DATA
{ 'd', RLIMIT_DATA, 1024, "data seg size", "kbytes" },
@@ -207,7 +207,7 @@ static RESOURCE_LIMITS limits[] = {
#ifdef RLIMIT_NICE
{ 'e', RLIMIT_NICE, 1, "scheduling priority", (char *)NULL },
#endif
- { 'f', RLIMIT_FILESIZE, 1024, "file size", "blocks" },
+ { 'f', RLIMIT_FILESIZE, 512, "file size", "blocks" },
#ifdef RLIMIT_SIGPENDING
{ 'i', RLIMIT_SIGPENDING, 1, "pending signals", (char *)NULL },
#endif
begin:vcard
fn:Roman Rakus
n:Rakus;Roman
org:Red Hat;BaseOS
adr:;;;Brno;;;Czech Republic
email;internet:[EMAIL PROTECTED]
title:Associate software engineer
tel;cell:+420 774 891 861
x-mozilla-html:FALSE
version:2.1
end:vcard
Re: Bug with long color prompt + long command line?
Just wondering about the lack of response... - Maybe nobody had time to look into this? (likely) - nobody cares since it's really only a problem with the combination of \w and color prompts? (With \W it only happens with an artificially long directory name as in my example.) - Maybe this is a repeat of old thread(s)? Well, I did find one similar thread http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/68274b1c434bd541/d2760d11300ff621?lnk=gst&q=color+%5Cw#d2760d11300ff621 ...which roughly went like: - someone reports a problem with line wraps and color prompts - everybody says "read the FAQ section E3/E5 (depending on version)" - the original poster says "okay I've properly escaped my prompt according to the FAQ, but there are still problems" - no further replies. I also found this, from 1999(!) which looks closer to my problem, with no replies at all: http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/ba19c607d66bc79e/19ca0e35378d7c2d?lnk=gst&q=color+%5Cw#19ca0e35378d7c2d What I have not found anywhere is either a pointer to documentation that actually fixes the problem (sorry for being redundant but the instructions in the FAQ do *not* fix this problem), or an acknowledgment that there is a problem in bash. Thanks, - PW (rather than quote my entire previous post here's a link: http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/9da7e81b060d77d4 )
Re: bash using incorrect block size with limits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Roman Rakus on 6/2/2008 7:06 AM: | Maybe already reported bug, but | bash is using 1024 bytes block size, but should be using 512 bytes. I would much rather see sizes as 1k if POSIXLY_CORRECT is not set; in other words, if you patch this, I think this is an appropriate place to make the code conditional on whether bash is emulating posix rather than hard-coded. People just don't think conveniently in terms of the older 512b block sizes. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhERcUACgkQ84KuGfSFAYAtSgCfWAoGRXR8G/E9RUeYOF3EQ5qf VBEAn2Bjz+VXcHp/fT7YUhPyZuXFQ/dD =27L4 -END PGP SIGNATURE-
Re: Bug with long color prompt + long command line?
> - Maybe nobody had time to look into this? (likely) It took a while, but I did look at it and fix the problem. The fix will be in bash-4.0, and maybe in a patch to 3.2, depending on timing. > according to the FAQ, but there are still problems" > - no further replies. Because I released a patch that fixed it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: Bug with long color prompt + long command line?
Great to hear it! Thanks very much Chet. On Jun 2, 3:14 pm, Chet Ramey <[EMAIL PROTECTED]> wrote: > It took a while, but I did look at it and fix the problem. The fix will > be in bash-4.0, and maybe in a patch to 3.2, depending on timing.
top level configure from autoconf 2.59 looses --quiet
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i686-pc-cygwin' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I/home/eblake/bash-3.2.39-19/src/bash-3.2 -I/home/eblake/bash-3.2.39-19/src/bash-3.2/include -I/home/eblake/bash-3.2.39-19/src/bash-3.2/lib -O2 -pipe uname output: CYGWIN_NT-5.1 SteveHP 1.5.25(0.156/4/2) 2008-05-26 20:37 i686 Cygwin Machine Type: i686-pc-cygwin Bash Version: 3.2 Patch Level: 39 Release Status: release Description: The top level configure produce by autoconf 2.59 fails to pass --quiet to itself recursivly if ac_recheck requires reconfiguration. The cygwin patch changes some .in/.ac files which will cause configure to rerun on first make invocation. Repeat-By: Untar bash-3.2.tar.gz source, apply cygwin bash-3.2.39-19.src.patch, configure with --quiet, type make clean and watch all the configure checking messages Fix: Running autconf 2.61 on the top level configure.in to produce an updated configure seems to take care of it
Re: top level configure from autoconf 2.59 looses --quiet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Steve Kenton on 6/1/2008 7:46 PM: | | Description: |The top level configure produce by autoconf 2.59 fails to |pass --quiet to itself recursivly if ac_recheck requires |reconfiguration. The cygwin patch changes some .in/.ac files |which will cause configure to rerun on first make invocation. Thanks for the report. However, the cygwin patches to bash are more properly discussed on the cygwin list, until such time as they are ported and posted to this list. | | Repeat-By: |Untar bash-3.2.tar.gz source, apply cygwin | bash-3.2.39-19.src.patch, configure with --quiet, |type make clean and watch all the configure checking messages This behavior is expected. If you apply the cygwin patch, you have to rerun autoconf, or make will do it on your behalf. configure --quiet is not a persistent operation, so there is no way to tell make that you originally configured quietly, and want any rerun of autoconf to also run quietly if timestamps are out of date. I suppose that I could have prepared the cygwin patch to also include the (properly timestamped) changes to configure, so that you wouldn't have to rerun autoconf; but as configure is a generated file, the cygwin patch is much smaller by excluding it from the diff. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] volunteer maintainer of cygwin port of bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhEkocACgkQ84KuGfSFAYDx9QCgxgh7YlQe5syoEQLvtf7n29rs zQYAoIl38uxEnN5yjFdcEOo0rfgenuWo =Se4J -END PGP SIGNATURE-
