missing docs for new ulimit options in bash-3.1
in the bash 3.1 release, new options were added: -i -q -x
however, the doc/bashref.texi and doc/bash.1 files were not updated
to document these fun features
i've attached an updated patch based upon the ulimit.patch from Fedora
which documents these three options and adds two new ones ...
any reason to not include the -e (scheduling priority) and -r (rt
priority) options that Fedora has been using ?
-mike
Ripped from Fedora
Add support for RLIMIT_NICE/RLIMIT_RTPRIO and add missing documentation
for many other options
--- builtins/ulimit.def
+++ builtins/ulimit.def
@@ -34,18 +34,20 @@
-a all current limits are reported
-c the maximum size of core files created
-d the maximum size of a process's data segment
+-e the maximum scheduling priority (`nice')
-f the maximum size of files created by the shell
--i the maximum number of pending signals
+-i the maximum number of pending signals
-l the maximum size a process may lock into memory
-m the maximum resident set size
-n the maximum number of open file descriptors
-p the pipe buffer size
--q the maximum number of bytes in POSIX message queues
+-q the maximum number of bytes in POSIX message queues
+-r the maximum rt priority
-s the maximum stack size
-t the maximum amount of cpu time in seconds
-u the maximum number of user processes
-v the size of virtual memory
--x the maximum number of file locks
+-x the maximum number of file locks
If LIMIT is given, it is the new value of the specified resource;
the special LIMIT values `soft', `hard', and `unlimited' stand for
@@ -202,6 +204,9 @@
#ifdef RLIMIT_DATA
{ 'd', RLIMIT_DATA, 1024, "data seg size","kbytes" },
#endif
+#ifdef RLIMIT_NICE
+ { 'e', RLIMIT_NICE, 1,"max nice", (char *)NULL},
+#endif
{ 'f', RLIMIT_FILESIZE, 1024, "file size","blocks" },
#ifdef RLIMIT_SIGPENDING
{ 'i', RLIMIT_SIGPENDING, 1, "pending signals", (char *)NULL },
@@ -217,6 +222,9 @@
#ifdef RLIMIT_MSGQUEUE
{ 'q', RLIMIT_MSGQUEUE, 1, "POSIX message queues", "bytes" },
#endif
+#ifdef RLIMIT_RTPRIO
+ { 'r', RLIMIT_RTPRIO, 1, "max rt priority", (char *)NULL},
+#endif
#ifdef RLIMIT_STACK
{ 's', RLIMIT_STACK, 1024, "stack size", "kbytes" },
#endif
--- doc/bashref.texi
+++ doc/bashref.texi
@@ -3833,7 +3833,7 @@
@item ulimit
@btindex ulimit
@example
-ulimit [-acdflmnpstuvSH] [EMAIL PROTECTED]
+ulimit [-acdefilmnpqrstuvxSH] [EMAIL PROTECTED]
@end example
@code{ulimit} provides control over the resources available to processes
started by the shell, on systems that allow such control. If an
@@ -3854,9 +3854,15 @@
@item -d
The maximum size of a process's data segment.
[EMAIL PROTECTED] -e
+The maximum scheduling priority.
+
@item -f
The maximum size of files created by the shell.
[EMAIL PROTECTED] -i
+The maximum number of pending signals.
+
@item -l
The maximum size that may be locked into memory.
@@ -3869,6 +3875,12 @@
@item -p
The pipe buffer size.
[EMAIL PROTECTED] -q
+The maximum number of bytes in POSIX message queues.
+
[EMAIL PROTECTED] -r
+The maximum RT priority.
+
@item -s
The maximum stack size.
@@ -3881,6 +3893,9 @@
@item -v
The maximum amount of virtual memory available to the process.
[EMAIL PROTECTED] -x
+The maximum amount of file locks.
+
@end table
If @var{limit} is given, it is the new value of the specified resource;
--- doc/bash.1
+++ doc/bash.1
@@ -8484,7 +8484,7 @@
returns true if any of the arguments are found, false if
none are found.
.TP
-\fBulimit\fP [\fB\-SHacdflmnpstuv\fP [\fIlimit\fP]]
+\fBulimit\fP [\fB\-SHacdefilmnpqrstuvx\fP [\fIlimit\fP]]
Provides control over the resources available to the shell and to
processes started by it, on systems that allow such control.
The \fB\-H\fP and \fB\-S\fP options specify that the hard or soft limit is
@@ -8520,9 +8520,15 @@
.B \-d
The maximum size of a process's data segment
.TP
+.B \-e
+The maximum scheduling priority (`nice')
+.TP
.B \-f
The maximum size of files created by the shell
.TP
+.B \-i
+The maximum number of pending signals
+.TP
.B \-l
The maximum size that may be locked into memory
.TP
@@ -8536,6 +8542,12 @@
.B \-p
The pipe size in 512-byte blocks (this may not be set)
.TP
+.B \-q
+The maximum number of bytes in POSIX message queues
+.TP
+.B \-r
+The maximum rt priority
+.TP
.B \-s
The maximum stack size
.TP
@@ -8547,6 +8559,9 @@
.TP
.B \-v
The maximum amount of virtual memory available to the shell
+.TP
+.B \-x
+The maximum number of file locks
.PD
.PP
If
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Visual completion ellipsis
Here's a proposed patch for Bash (or readline) which implements a
usability feature. This feature reduces the amount of text output
when filename completion shows a list of files after pressing TAB
twice (or once if you configure it so), showing as first letter
what you have to type to disambiguate the completion. Here's an
output example:
[0:[EMAIL PROTECTED]:0] [~/project/bash-3.1-ellipsis]$ ./bash
[EMAIL PROTECTED]:~/project/bash-3.1-ellipsis$ ls ar
___.c ...func.c ...func.h ...func.o ___.h ___.o
[EMAIL PROTECTED]:~/project/bash-3.1-ellipsis$ ls array
As you can see, instead of showing the full name, an ellipsis
replaces the common prefix in the list. This is more helpful the
longer the names get:
[EMAIL PROTECTED]:~/project/bash-3.1-ellipsis$ ls ~/all
...df ...s.gz
[EMAIL PROTECTED]:~/project/bash-3.1-ellipsis$ ls ~/allegro-manual-4.0.3.en.p
The patch is not implemented for multibyte (don't know how to deal
with that) and it would be better if the length of the ellipsis
could be set at runtime rather than with a define. I wonder if you
would like to merge this patch with the main distribution. Please
tell me what modifications would I have to do, if you so desire.
Now, about the long story of this improvement. I started thinking
about it during April of 2003. The 16th of that month I mailed
[EMAIL PROTECTED] asking what would be the procedure to
collaborate a patch implementing this feature. While I waited for
an answer (which never came), I implemented this for bash 2.x and
used it just myself.
Years later I realise I forgot to contribute the patch digging
through an old mailbox. This time, the 29th of October of 2005
I try luck with [EMAIL PROTECTED] Again, no luck. This time I
even included the patch for bash 2.x.
Nearly a month later, despite a lack of instructions, I manage to
subscribe to this mailing thanks to the answers of Bob Proulx and
Chet Ramey. Lurking here, I see no trace of active development,
no information about the process of submitting patches, no real
hint of what somebody would have to do to contribute one...
It just looks very very sad that two presumably valid email
addresses don't have anybody reading their mail (or somebody not
bothering to answer), and even instructions about mailing list
subscription are hidden and have to be asked or discovered. Isn't
the bash/readline community preventing software contributions
through lack of communication?
I yet have to find if there is any source control software in use,
so I could make a diff against some sort of development branch. I
wonder, is there any or you guys control things by hand?
diff -u -r bash-3.1/doc/bashref.info bash-3.1-ellipsis/doc/bashref.info
--- bash-3.1/doc/bashref.info 2005-10-03 21:07:32.0 +0200
+++ bash-3.1-ellipsis/doc/bashref.info 2005-12-10 22:43:09.091010680 +0100
@@ -5986,6 +5986,12 @@
`insert-comment' command is executed. The default value is
`"#"'.
+`completion-ellipsis'
+ If set to `on', Readline will transform the common prefix
+ of matched words in an ellipsis when showing possible
+ options, if the prefix is longer than three characters.
+ The default value is `off'.
+
`completion-ignore-case'
If set to `on', Readline performs filename matching and
completion in a case-insensitive fashion. The default value
diff -u -r bash-3.1/lib/readline/bind.c bash-3.1-ellipsis/lib/readline/bind.c
--- bash-3.1/lib/readline/bind.c2005-10-14 17:04:27.0 +0200
+++ bash-3.1-ellipsis/lib/readline/bind.c 2005-12-10 22:39:20.485763960
+0100
@@ -1383,6 +1383,7 @@
{ "bind-tty-special-chars", &_rl_bind_stty_chars, 0 },
{ "blink-matching-paren",&rl_blink_matching_paren, V_SPECIAL },
{ "byte-oriented", &rl_byte_oriented, 0 },
+ { "completion-ellipsis", &_rl_completion_ellipsis, 0 },
{ "completion-ignore-case", &_rl_completion_case_fold, 0 },
{ "convert-meta",&_rl_convert_meta_chars_to_ascii, 0 },
{ "disable-completion", &rl_inhibit_completion, 0 },
diff -u -r bash-3.1/lib/readline/complete.c
bash-3.1-ellipsis/lib/readline/complete.c
--- bash-3.1/lib/readline/complete.c2005-10-08 04:30:18.0 +0200
+++ bash-3.1-ellipsis/lib/readline/complete.c 2005-12-10 22:36:58.844296736
+0100
@@ -110,8 +110,8 @@
static int _rl_internal_pager PARAMS((int));
static char *printable_part PARAMS((char *));
static int fnwidth PARAMS((const char *));
-static int fnprint PARAMS((const char *));
-static int print_filename PARAMS((char *, char *));
+static int fnprint PARAMS((const char *, const int));
+static int print_filename PARAMS((char *, char *, int));
static char **gen_completion_matches PARAMS((char *, int, int,
rl_compentry_func_t *, int, int));
@@ -160,6 +160,11 @@
int _rl_completion_case_fold;
#endif
+/* If non-zero, the common
Re: Visual completion ellipsis
On Sat, Dec 10, 2005 at 11:36:53PM +0100, Grzegorz Adam Hankiewicz wrote: > Nearly a month later, despite a lack of instructions, I manage to > subscribe to this mailing thanks to the answers of Bob Proulx and > Chet Ramey. Lurking here, I see no trace of active development, > no information about the process of submitting patches, no real > hint of what somebody would have to do to contribute one... Bash and Readline are written by Chet Ramey. So, give the guy a break. He's too busy fixing bugs. :-) -- William Park <[EMAIL PROTECTED]>, Toronto, Canada ThinFlash: Linux thin-client on USB key (flash) drive http://home.eol.ca/~parkw/thinflash.html BashDiff: Super Bash shell http://freshmeat.net/projects/bashdiff/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Visual completion ellipsis
Grzegorz Adam Hankiewicz wrote: > Here's a proposed patch for Bash (or readline) which implements a > usability feature. This feature reduces the amount of text output > when filename completion shows a list of files after pressing TAB > twice (or once if you configure it so), showing as first letter > what you have to type to disambiguate the completion. Here's an > output example: I will look at it for the next release. It arrived too late to be considered for bash-3.1/readline-5.1. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
backgrounded children forgotten
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=nocona -O3 -pipe -fomit-frame-pointer uname output: Linux vino 2.6.15-rc1 #1 SMP PREEMPT Thu Nov 17 10:10:29 EST 2005 x86_64 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: When 2 processes are backgrounded inside $(...), bash forgets the first one was a child of the shell. Repeat-By: Note this needs to be a script, not cmdline, otherwise $! doesn't work. $ cat demo output=$( true & pid=$! true & sleep 1 wait $pid ) $ bash demo demo: line 13: wait: pid 25183 is not a child of this shell ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
