On Wed, Jun 11, 2025 at 10:38:17AM -0400, Chet Ramey wrote:
> The business of installing the loadables and
> headers on `make install' came later as the result of feature requests.
>
And Duncan, correctly, replied:
>Fine for `make install' to *install* them. But it flies in the face of
>convention
On Fri, Jun 13, 2025 at 7:02 AM Duncan Roe wrote:
> Fine for `make install' to *install* them. But it flies in the face of
> convention for `make install' to *build* them - `make' should do that.
`make' should only build bash; documentation, loadables, etc. should
have dedicated targets. If build
On Wed, Jun 11, 2025 at 10:38:17AM -0400, Chet Ramey wrote:
> The business of installing the loadables and
> headers on `make install' came later as the result of feature requests.
>
Fine for `make install' to *install* them. But it flies in the face of
convention for `make install' to *build* them
On 6/6/25 11:43 PM, Duncan Roe wrote:
On Fri, Jun 06, 2025 at 10:27:56AM -0400, Chet Ramey wrote:
They're always built and installed when you use `make install'. The
problem, of course, is users (some) or distros (all) who don't use a
^^^ Slac
On Fri, Jun 06, 2025 at 10:27:56AM -0400, Chet Ramey wrote:
>
> They're always built and installed when you use `make install'. The
> problem, of course, is users (some) or distros (all) who don't use a
^^^ Slackware does
> simple `make install', bu
On Fri, Jun 6, 2025, at 9:29 AM, Stan Marsh wrote:
> I.e., yes, I get the theoretical reasons, but it generates confusion
> for the user
>
> [...]
>
> Of course,
> you still have to "enable" them in your script or shell in order to
> actually use them.
Exactly, you have to explicitly opt into us
On 6/6/25 12:21 AM, Martin D Kealey wrote:
On Thu, 5 Jun 2025 at 20:22, Duncan Roe wrote:
On Wed, Jun 04, 2025 at 09:43:00AM -0400, Chet Ramey wrote:
Is it useful to combine multiple selected fields (-f) into one space-
separated field so `cut' can put the selected portions of each line into
On 6/6/25 9:29 AM, Stan Marsh wrote:
It seems to me they should all be compiled and installed - all the time. Of
course,
you still have to "enable" them in your script or shell in order to actually
use them.
They're always built and installed when you use `make install'. The
problem, of cou
>On Thu, Jun 5, 2025, at 8:37 AM, Stan Marsh wrote:
>> Actually, I am not too fond of the habit of having builtins (particularly
>> those supplied as part of the distribution) with the same name as well-known
>> Unix commands.
>
>It allows for potential drop-in replacement if the external commands
++
On Fri, Jun 6, 2025, 1:10 PM Greg Wooledge wrote:
> On Fri, Jun 06, 2025 at 14:19:33 +1000, Duncan Roe wrote:
> > If one is building bash from source, then (most of) the loadable builtins
> > are built and installed (at least since bash 4.4).
>
> That hasn't been my experience. "./configure"
On Fri, Jun 06, 2025 at 14:19:33 +1000, Duncan Roe wrote:
> If one is building bash from source, then (most of) the loadable builtins
> are built and installed (at least since bash 4.4).
That hasn't been my experience. "./configure" followed by "make"
puts a "bash" executable file in the top-leve
On Thu, 5 Jun 2025 at 20:22, Duncan Roe wrote:
> On Wed, Jun 04, 2025 at 09:43:00AM -0400, Chet Ramey wrote:
> > Is it useful to combine multiple selected fields (-f) into one space-
> > separated field so `cut' can put the selected portions of each line into
> > a corresponding array element?
>
talled bash dev , but there is no `help cut`
> > >
> > > It's a "loadable builtin". You have to build those, install them,
> > > and then load the "cut" builtin explicitly.
> > >
> > `make install` does put the binaries in /usr/lib
On Fri, Jun 06, 2025 at 12:55:34 +1000, Duncan Roe wrote:
> On Thu, Jun 05, 2025 at 06:55:55AM -0400, Greg Wooledge wrote:
> > On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote:
> > > i installed bash dev , but there is no `help cut`
> >
> > It's a &qu
On Thu, Jun 5, 2025, at 8:37 AM, Stan Marsh wrote:
> Actually, I am not too fond of the habit of having builtins (particularly
> those supplied as part of the distribution) with the same name as well-known
> Unix commands.
It allows for potential drop-in replacement if the external commands
are un
On Thu, Jun 05, 2025 at 06:55:55AM -0400, Greg Wooledge wrote:
> On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote:
> > i installed bash dev , but there is no `help cut`
>
> It's a "loadable builtin". You have to build those, install them,
> and then
On Thu, Jun 5, 2025, 12:56â¯PM Greg Wooledge wrote:
> On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote:
> > i installed bash dev , but there is no `help cut`
>
> It's a "loadable builtin". You have to build those, install them,
> and then load the &quo
thxx , ++
On Thu, Jun 5, 2025, 12:56 PM Greg Wooledge wrote:
> On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote:
> > i installed bash dev , but there is no `help cut`
>
> It's a "loadable builtin". You have to build those, install them,
> and then load the "cut" builtin explicitly.
>
>
On Thu, Jun 05, 2025 at 12:34:44 +0200, microsuxx wrote:
> i installed bash dev , but there is no `help cut`
It's a "loadable builtin". You have to build those, install them,
and then load the "cut" builtin explicitly.
i installed bash dev , but there is no `help cut`
On Wed, Jun 4, 2025, 3:43 PM Chet Ramey wrote:
> On 6/2/25 5:58 AM, Duncan Roe wrote:
> > Hi,
> >
> > `cut -a ARRAY ...` puts its last line of output in ARRAY[0] and discards
> any
> > other elements ARRAY used t
> selected field is put into a separate element of the array. When you
> select bytes or characters, the selected bytes get put into array[0] as
> a single field. There's no current way to assign multiple array elements
> when you don't supply -f.
I totally missed that cut -a di
On 6/2/25 5:58 AM, Duncan Roe wrote:
Hi,
`cut -a ARRAY ...` puts its last line of output in ARRAY[0] and discards any
other elements ARRAY used to have. I tried 3 alternatives:
Thanks for the report. Yes, sometimes marrying the multiple-line-oriented
output of a tool like `cut' to one-dimensio
successive array
elements.
Alternative C: apply patch A and then patch B so lines are put in successive
elements but if there are less lines than there were elements originally then
preserve those that weren't overwritten.
I have no feeling for which is the most useful, but in any case help shoul
On 4/8/25 3:55 PM, Rafael Fontenelle via Bug reports for the GNU Bourne
Again SHell wrote:
Translating bash 5.3-pre1, I faced a string change in trap's help message
that I didn't quite understand. The phrase in 5.3-pre1:
---
If a SIGNAL_SPEC is DEBUG, ACTION is executed before ev
Translating bash 5.3-pre1, I faced a string change in trap's help message
that I didn't quite understand. The phrase in 5.3-pre1:
---
If a SIGNAL_SPEC is DEBUG, ACTION is executed before every simple command
and selected other commands.
---
The "and selected other commands&quo
On Sun, Apr 06, 2025 at 05:16:18PM +1000, Duncan Roe wrote:
> ---
> builtins/history.def | 3 ++-
> builtins/setattr.def | 2 +-
> examples/loadables/Makefile.in | 4 ++--
> 3 files changed, 5 insertions(+), 4 deletions(-)
BTW if you like the above patches, save the email to a
---
builtins/history.def | 3 ++-
builtins/setattr.def | 2 +-
examples/loadables/Makefile.in | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtins/history.def b/builtins/history.def
index fa79c0b9..6ce8c8b6 100644
--- a/builtins/history.def
+++ b/bu
On 12/20/24 7:30 PM, Lawrence Velázquez wrote:
On Fri, Dec 20, 2024, at 8:09 AM, Greg Wooledge wrote:
help -d cdoes not exactly match anything, so it's treated like c\*
Is this documented somewhere? I'm not seeing anything about it in
the man page or texinfo manual.
If th
On Fri, Dec 20, 2024 at 19:30:49 -0500, Lawrence Velázquez wrote:
> On Fri, Dec 20, 2024, at 8:09 AM, Greg Wooledge wrote:
> > help -d cdoes not exactly match anything, so it's treated like c\*
>
> Is this documented somewhere? I'm not seeing anything about it in
On Fri, Dec 20, 2024, at 8:09 AM, Greg Wooledge wrote:
> help -d cdoes not exactly match anything, so it's treated like c\*
Is this documented somewhere? I'm not seeing anything about it in
the man page or texinfo manual.
--
vq
On Fri, Dec 20, 2024 at 04:50:17 -0800, Wiley Young wrote:
> For some reason, while `help -d 'c'` prints the same thing as `help -c
> 'c*'` (note the asterisk), the same is not true when the character is
> left-bracket: `help -c '[*'.
Why did you expect them
Testing how bash's help builtin responds to each character.
For some reason, while `help -d 'c'` prints the same thing as `help -c
'c*'` (note the asterisk), the same is not true when the character is
left-bracket: `help -c '[*'. This issue persists on bash 5
their definition.
I changed it to emphasize the single-word display. The help output is
intended to be a brief reminder, not a manual or standard.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ram
To be clear, I have no problem with the behaviour of 'command' itself. My
report was only meant to file a bug against the doc-strings output by 'help
command'. Maybe I could suggest a starting point for a fix, using the
language from the standard linked earlier, and the output
Date:Tue, 26 Nov 2024 16:23:56 +1000
From:Martin D Kealey
Message-ID:
| I'm not convinced that ‘command’ should mention aliases at all, since
| ‘command -v "$var"’ should tell you what ‘"$var"’ will do.
| What it *won't* do is be expanded as an alias.
Absolut
On Tue, 26 Nov 2024 at 12:43, Lawrence Velázquez wrote:
> On Mon, Nov 25, 2024, at 9:03 PM, Martin D Kealey wrote:
> > I keep "similar" there because ‘type -a COMMAND’ shows all possible
> matches
> > for COMMAND, whereas ‘command -V’ only does that when COMMAND is NOT an
> > alias.
>
> I'm not s
On Tuesday, November 26, 2024, Martin D Kealey
wrote:
>
> Would anyone object to adjusting the output of ‘command -V’ to be identical
> to ‘type -a’?
>
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/command.html
--
Oğuz
~ $ command -v bash
/data/data/com.termux/files/usr/bin/bash
~ $ command -V bash
bash is /data/data/com.termux/files/usr/bin/bash
V adds english text
On Tue, Nov 26, 2024, 3:44 AM Lawrence Velázquez wrote:
> On Mon, Nov 25, 2024, at 9:03 PM, Martin D Kealey wrote:
> > I keep "similar" there bec
On Mon, Nov 25, 2024, at 9:47 PM, #!microsuxx wrote:
> V adds english text
That's not what I'm talking about.
--
vq
On Mon, Nov 25, 2024, at 9:03 PM, Martin D Kealey wrote:
> I keep "similar" there because ‘type -a COMMAND’ shows all possible matches
> for COMMAND, whereas ‘command -V’ only does that when COMMAND is NOT an
> alias.
I'm not seeing that "command -V" behavior.
$ type -a bash
bash
On Tue, 26 Nov 2024 at 05:35, Andrew Davis wrote:
> When running 'help command' in the shell, the output contains:
>
> > -vprint a description of COMMAND similar to the `type' builtin
> > -Vprint a more verbose description of each COMMAND
>
On 11/25/24 2:35 PM, Andrew Davis wrote:
When running 'help command' in the shell, the output contains:
-vprint a description of COMMAND similar to the `type' builtin
-Vprint a more verbose description of each COMMAND
This seems to be opposite to the actu
When running 'help command' in the shell, the output contains:
> -vprint a description of COMMAND similar to the `type' builtin
> -Vprint a more verbose description of each COMMAND
This seems to be opposite to the actual behaviour of 'command&
help -d output assumes that long_doc[0] includes a newline, which is
not the case for loadable builtins:
$ enable ln rm
$ help -d ln rm
ln - Link files.rm - Remove files
---
builtins/help.def | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/builtins
On Mon, Sep 9, 2024 at 9:04 AM secretuser56 wrote:
>
> There are errors in the German 'help echo' command in po/de.po and po/de.gmo.
> The descriptions for the following escape sequences are missing: \u
> \U
> Besides that there are two backslashs missing.
There are errors in the German 'help echo' command in po/de.po and po/de.gmo.
The descriptions for the following escape sequences are missing: \u
\U
Besides that there are two backslashs missing. One in front of \a\tAlarm and
one in front of tumgekehrter.
Here are tr
On 7/14/24 9:59 AM, Carlo Teubner wrote:
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
"help ulimit" includes this paragraph:
Thanks for the report. This was changed in the devel branch some time ago.
--
``The lyf so short, the craft so lon
#x27;
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux lapdev 6.9.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 12 Jul
2024 00:06:53 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 26
Release Status: release
Des
On 4/22/24 2:13 AM, felix wrote:
I could explain that '$?' is result of bash's if...then...fi group command
executed correctly and PIPESTATUS hold result of "most-recently-executed
foreground pipeline", but man page say:
PIPESTATUS
An array variable (see Arrays below) containin
On Mon, 22 Apr 2024, at 8:56 AM, Oğuz wrote:
> On Mon, Apr 22, 2024 at 10:24 AM Kerin Millar wrote:
>> I cannot find anything in the manual that concretely explains why bash
>> behaves as it does in this instance.
>
> Me neither, but the current behavior is useful. Take `while false |
Very much
" [2]="1" [3]="4") 7
>
> Where $PIPESTATUS[0]=>2 and $?=>0 !!
>
> I could explain that '$?' is result of bash's if...then...fi group command
> executed correctly [...]
That is indeed the issue here. $? contains the exit status of the &q
On Mon, 22 Apr 2024, 18:13 felix, wrote:
> Hi,
>
> Coming on this very old thread:
>
> [the] man page say[s]:
>
> PIPESTATUS
> An array variable (see Arrays below) containing a list of exit
> status values from the processes in the most-recently-executed
> foreg
Le Mon, Apr 22, 2024 at 10:56:03AM +0300, Oğuz a écrit :
>
> Me neither, but the current behavior is useful.
I agree!
Anyway, reading man page, `$?` have to be equivalent to `${PIPESTATUS[-1]}`!
which is not always the case.
> I've never seen anything like that in a real shell script.
I have to
On Mon, Apr 22, 2024 at 10:24 AM Kerin Millar wrote:
> I cannot find anything in the manual that concretely explains why bash
> behaves as it does in this instance.
Me neither, but the current behavior is useful. Take `while false |
false; do :; done' for example, if bash reported the status of
On Mon, Apr 22, 2024 at 09:15:52AM +0200, felix wrote:
> Le Mon, Apr 22, 2024 at 07:44:48AM +0100, Kerin Millar a écrit :
> > On Mon, 22 Apr 2024, at 7:13 AM, felix wrote:
> > > ...
> > > if ls /wrong/path | wc | cat - /wrong/path | sed 'w/wrong/path'
> > > >/dev/null ; then
> > > echo Don
On Mon, 22 Apr 2024, at 7:44 AM, Kerin Millar wrote:
> On Mon, 22 Apr 2024, at 7:13 AM, felix wrote:
>> Hi,
>>
>> Comming on this very old thread:
>>
>> On Wed, 4 Dec 2013 14:40:11 -0500, Greg Wooledge wrote:
>>>
>>> The most obvious difference is that $? is shorter.
>>>
>>> $? is also POSIX stan
Le Mon, Apr 22, 2024 at 07:44:48AM +0100, Kerin Millar a écrit :
> On Mon, 22 Apr 2024, at 7:13 AM, felix wrote:
> > ...
> > if ls /wrong/path | wc | cat - /wrong/path | sed 'w/wrong/path'
> > >/dev/null ; then
> > echo Don't print this'
> > fi ; echo ${?@Q} ${PIPESTATUS[@]@A} $(( $? ${
On Mon, 22 Apr 2024, at 7:13 AM, felix wrote:
> Hi,
>
> Comming on this very old thread:
>
> On Wed, 4 Dec 2013 14:40:11 -0500, Greg Wooledge wrote:
>>
>> The most obvious difference is that $? is shorter.
>>
>> $? is also POSIX standard (older than POSIX in fact), so it works in sh
>> scripts as
Hi,
Comming on this very old thread:
On Wed, 4 Dec 2013 14:40:11 -0500, Greg Wooledge wrote:
>
> The most obvious difference is that $? is shorter.
>
> $? is also POSIX standard (older than POSIX in fact), so it works in sh
> scripts as well. PIPESTATUS is a Bash extension.
>
> Finally, note
On Thu, Apr 18, 2024 at 03:20:21PM +0700, Robert Elz wrote:
> ps: bash could probably lose the "be a login shell" '-' from argv[0][0]
> for error messages. It isn't helpful.
It's a tiny bit helpful for someone who knows what it means, and harmless
for people who don't know. I'd prefer it to be
On Thu, Apr 18, 2024 at 03:03:32AM -0400, anonymous wrote:
> they gave me reply:
>
> 'There isn't command `-h` on my Limux'
>
> Therefore, after calling -h/--help, I suggest displaying a message like:
Adding a /usr/bin/-h command or whatever sounds like overki
Date:Thu, 18 Apr 2024 03:03:32 -0400 (EDT)
From:anonymous
Message-ID: <20240418-070332.sv0.619...@savannah.gnu.org>
| Arguments are given after the program name and are used to modify the
| program's operation. E.g.: usage:
|
| somecommand --help
URL:
<https://savannah.gnu.org/support/?111051>
Summary: New commands: `-h`, `--help`
Group: The GNU Bourne-Again SHell
Submitter: None
Submitted: Thu 18 Apr 2024 07:03:31 AM UTC
Category
> It is politics. All human activity is political in nature.
Writing for portability is about building a widget that will appeal to a
larger group of customers.
Thanks for your thoughts.
Wiley
On 6/29/22 2:50 PM, Dennis Williamson wrote:
In help declare it says:
Using `+' instead of `-' turns off the given attribute.
In the Bash man page it says:
Using `+' instead of `-' turns off the attribute instead, with the
exceptions that +a and +A may not
In help declare it says:
Using `+' instead of `-' turns off the given attribute.
In the Bash man page it says:
Using `+' instead of `-' turns off the attribute instead, with the
exceptions that +a and +A may not be used to destroy array variables and
+r will not
On 6/7/22 10:17 AM, Gergely wrote:
On 6/7/22 15:49, Chet Ramey wrote:
On 6/7/22 7:57 AM, Gergely wrote:
Because you haven't forced bash to write outside its own address space or
corrupt another area on the stack. This is a resource exhaustion issue,
no more.
I did force it to write out of bou
On 6/7/22 15:49, Chet Ramey wrote:
> On 6/7/22 7:57 AM, Gergely wrote:
>
>>> Because you haven't forced bash to write outside its own address space or
>>> corrupt another area on the stack. This is a resource exhaustion issue,
>>> no more.
>>
>> I did force it to write out of bounds, hence the seg
On 6/7/22 7:57 AM, Gergely wrote:
>> Because you haven't forced bash to write outside its own address space or
>> corrupt another area on the stack. This is a resource exhaustion issue,
>> no more.
>
>
> I did force it to write out of bounds, hence the segfault.
That's backwards. You got a SIGS
t; there if you (or a distro) want to build it in.
Recompiling works perfectly fine, however there is not configure switch, so I
had to edit the code. This might be why the distributions are not setting this?
I'm not sure. At least it's there.
This will not help programmers though
On 6/2/22 4:00 PM, Gergely wrote:
I could not produce a scenario in 15 minutes that would indicate that
this corrupts other sections, as there is a considerable gap between the
stack and everything else. This is OS-dependent though and bash has no
control over what happens should this occur.
B
On 6/1/22 4:49 PM, Gergely wrote:
Hi,
I stumbled upon a recursion overflow crash in BASH. It affects both my
Debian machine (this report), as well as the latest stable built from
source.
Yes, you created an infinitely recursive script. It's a race to see whether
you exceed your stack or VM re
recursion.
I don't think it would be hard to add a SOURCENEST limit, but I find it
would mostly help to catch programming errors, not as a normal
exceptional case for a valid program that the programmer should be
expecting.
Can you provide an example where a sensible program would need to
sour
e code with its
> performance impacts needed behind it) might help, but what exactly is the
> advantage of a "maximum source nesting level exceeded" error over a
> segmentation fault?
>
> Next we will need MAXARRUSAGE, MAXBRACEEXPAN, ...
Well, the issue is not the fact that
Hi Gergely!
> I stumbled upon a recursion overflow crash in BASH.
There are many ways to exhaust memory (and other) recources, recursion is one
them. In your case a variable like SRCNEST (and all the code with its
performance impacts needed behind it) might help, but what exactly is
that there's a very slim chance
of exploitability, but really I saw no point in investigating as at this
point the attacker can pretty much already run code...
As suggested in the previous report like this
(https://lists.gnu.org/archive/html/bug-bash/2022-05/msg00016.html),
FUNCNEST do
OK, so it first looks for exact hits,
then does a grep style match.
And we see that
$ help f|grep :.
false: false
fc: fc [-e ename] [-lnr] [first] [last] or fc -s [pat=rep] [command]
fg: fg [job_spec]
for: for NAME [in WORDS ... ] ; do COMMANDS; done
for ((: for (( exp1; exp2; exp3 )); do
$ help f|wc -l
72
$ help fo |wc -l
24
$ help for |wc -l
10
$ help for\ |wc -l
14
$ help for\ \( |wc -l
14
$ help for\ \(\(|wc -l
14
So help help's 'If PATTERN is specified, gives detailed help on all
commands matching PATTERN." is not telling the whole story about
matching.
OK, then "help for" should at least mention that trick to get the rest of
the story.
On Sun, Sep 19, 2021, 4:07 PM Lawrence Velázquez wrote:
> On Sun, Sep 19, 2021, at 3:25 PM, 積丹尼 Dan Jacobson wrote:
> > $ help for
> > only mentions
> >for name [ [ in [ word ... ] ] ; ] do list ; done
> > and needs to be updated to mention
> >for
On Sun, Sep 19, 2021, at 3:25 PM, 積丹尼 Dan Jacobson wrote:
> $ help for
> only mentions
>for name [ [ in [ word ... ] ] ; ] do list ; done
> and needs to be updated to mention
>for (( expr1 ; expr2 ; expr3 )) ; do list ; done
Not particularly intuitive, but:
bash
$ help for
only mentions
for name [ [ in [ word ... ] ] ; ] do list ; done
and needs to be updated to mention
for (( expr1 ; expr2 ; expr3 )) ; do list ; done
$ echo $BASH_VERSION
5.1.8(1)-release
Just for me :) I know my productivity will be higher. Eventually I'll do a
YouTube video on it. If we see enough adoption, we can consider rolling
them in.
!$ picking up & from the previous command really is a no no :)
On Wed, Sep 1, 2021 at 6:36 PM Lawrence Velázquez wrote:
> On Wed, Sep 1, 20
On Wed, Sep 1, 2021, at 8:20 PM, Ananth Chellappa wrote:
> I hope I can make a genuine contribution at some point.
If you're hoping/planning on getting these changes accepted into
bash, it might be worth hashing out details with Chet before expending
your time and energy. (I am not a contributor,
Thanks Sincerely Chet.
I hope I can make a genuine contribution at some point.
On Wed, Sep 1, 2021 at 12:27 PM Chet Ramey wrote:
> On 8/31/21 6:38 PM, Ananth Chellappa wrote:
> > Hi Team,
> >Could I get some help locating portions of the code that would
> need
> &
On 8/31/21 6:38 PM, Ananth Chellappa wrote:
> Hi Team,
> Could I get some help locating portions of the code that would need
> to be tweaked to add these features?
>
> If I had the time, I would love to get to know the code, but I have too
> much going on in my
Hi Team,
Could I get some help locating portions of the code that would need
to be tweaked to add these features?
If I had the time, I would love to get to know the code, but I have too
much going on in my real job.
1. Intelligent support for !$ (and related - like !2$, !-N, etc) : This
$ help command | grep -i -- -v
-vprint a description of COMMAND similar to the `type' builtin
-Vprint a more verbose description of each COMMAND
$ command -v cat
/bin/cat
$ type cat
cat is /bin/cat
$ command -V cat
cat is /bin/cat
So it turns out -V is like type, not -v!
hort usage synopsis from `help' isn't like that. It's declared at
compile time as a constant string so it can be part of the struct
describing the available builtins. It can't be built at runtime, so it
describes every possible option (and, yes, omitting `R' was an oversight
According to the source, -R should be setting RLIMIT_RTTIME,
but it does not work:
bash-5.0$ ulimit -R
bash: ulimit: -R: invalid option
ulimit: usage: ulimit [-SHabcdefiklmnpqrstuvxPT] [limit]
..and looking at the above help, I notice letters I never saw.
Lets try them?
bash-5.0$ ulimit -b
tributes and values of each name.
> > When -p is used with name arguments, additional options, other than -f
> > and -F, are ignored.
> >
> >
> > But I can't find the same notes from the local version of the document
> > for this command given by `help
ons, other than -f
> and -F, are ignored.
>
>
> But I can't find the same notes from the local version of the document
> for this command given by `help declare', any hints for this problem?
The help text built into bash is a much shorter version of the manual
text. It
f the document
for this command given by `help declare', any hints for this problem?
Regards
--
Hongyi Zhao
On 9/15/19 4:07 PM, Roland Illig wrote:
> The help for "(( ))" says:
>
>> evaluation. Equivalent to "let EXPRESSION".
>
> All other help topics use `these' quotes.
Thanks, it should be let "EXPRESSION", with or without the `' quot
The help for "(( ))" says:
> evaluation. Equivalent to "let EXPRESSION".
All other help topics use `these' quotes.
On 9/9/19 10:45 PM, 2477441814 wrote:
> Dear team,
>
>
> when I invoke 'help printf' in terminal to view help manual, It shown me '%b
> %q %(fmt)T' is an addition to printf(1) and printf(3), The online version of
> bash manual from (http://www.gnu.or
Dear team,
when I invoke 'help printf' in terminal to view help manual, It shown me '%b %q
%(fmt)T' is an addition to printf(1) and printf(3), The online version of bash
manual from (http://www.gnu.org/software/bash/manual/bash.html) does samely
describe. but from GNU
Hi,
I've been searching the BASH manual (
https://www.gnu.org/software/bash/manual/bash.html) to find out about the
precedence/sequence that the shell parses commands. The particular question
I've had which I was helped with:
https://unix.stackexchange.com/questions/526646/precedence-of-subshells-
On 2/10/19 3:28 PM, Koichi Murase wrote:
> Bash Version: 5.0
> Patch Level: 0
> Release Status: release
>
> Description:
> When `builtin bind --help' is executed in Bash 4.4 and 5.0,
> `begin_unwind_frame ("bind_builtin")' is called, but `run_unwin
/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 5.0
Patch Level: 0
Release Status: release
Description:
When `builtin bind --help' is executed in Bash 4.4 and 5.0,
`begin_unwind_frame ("bind_builtin")' is called, but `run_unwind_frame
("bind_builtin")` is not call
1 - 100 of 375 matches
Mail list logo
