On Wed, 9 Apr 2025 at 15:40, Chet Ramey wrote:
>
> On 4/9/25 9:31 AM, Dan Shelton wrote:
> > On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote:
> >>
> >> On 4/9/25 2:09 AM, Cedric Blancher wrote:
> >>> Good morning!
> >>>
> >>> C
On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote:
>
> On 4/9/25 2:09 AM, Cedric Blancher wrote:
> > Good morning!
> >
> > Could bash please support x=${cmd;} alongside x=$(cmd)?
>
> I implemented it back in 2023 and it will be in bash-5.3.
Thank you.
I like the x=${
.
Docs should clarify that this is NOT the HP/UX madness
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
$ history |wc - $HISTFILE|sed \$d
7622 75741 532254 -
14973 29625 320996 /home/jidanni/.bash_history_jidanni
Works as expected.
$ (a=~/.bash_history_jidanni-emacs; HISTFILE=$a history |wc - $a|sed \$d)
7625 75780 532531 - ### I expected to see about 1399/2 here.
13993535
$ history
is nice, but what if you want to have it read from a different file?
$ help history
says
If FILENAME is given, it is used as the history file. Otherwise,
if HISTFILE has a value, that is used, else ~/.bash_history.
Alas, it also says
history: history [-c] [-d offset] [n] or
$ echo \#!/usr/bin/python > k
$ chmod +x k
$ ./k
bash: ./k: cannot execute: required file not found
Bash should really mention what file it is talking about.
$ echo 'x:k; ./$<' > Makefile
$ make
./k
make: ./k: No such file or directory
make: *** [Makefile:1: x] Error 127
$ ls ./k
./k
Make is wor
It seems these should both make one line "+ a=b c=b" output,
for s in sh bash
do $s -xc 'a=b c=$a'
done
I mean they give the same results, but bash splits it into
two lines, so the user reading the bash -x output cannot tell
if one (correct) or two (incorrect) lines were used.
They can tell with
On Fri, 26 Apr 2024 at 15:10, Chet Ramey wrote:
>
> On 4/25/24 9:56 PM, Dan Shelton wrote:
>
> >> Everyone seems to support MAKEFLAGS by now, and it's part of POSIX, so
> >> maybe we delete $(MFLAGS) and rely on make to pass MAKEFLAGS to submakes
> >> in t
AGS) and rely on make to pass MAKEFLAGS to submakes
> in the environment.
Could you do this for the next alpha release, please?
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
GS}, and the parent and child
> make instances cooperate to limit the number of parallel make processes.
Passing -j to submakes ist just wrong. All submakes and the parent
should be part of ONE GNU make jobserver.
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
>>>>> "CR" == Chet Ramey writes:
CR> On 3/24/24 11:39 PM, Lawrence Velázquez wrote:
>> On Sun, Mar 24, 2024, at 11:01 PM, Dan Jacobson wrote:
>>> P.S., "\t%s" seems to have an extra space squeezed between them with
>>> bash: "\t
Hmm, so no matter POSIX mode or not, both will be dragging around that
little piece of toilet paper stuck to their shoes (\t)... unless some
new option is invented.
How unfortunate.
P.S., "\t%s" seems to have an extra space squeezed between them with bash: "\t
%s",
unless perhaps the spec says that %s always starts with a space.
> "MDK" == Martin D Kealey writes:
MDK> How about « fc -ln » ?
I like it!
P.S.,
$ help fc
-nomit line numbers when listing
Yes, it omits the line numbers. But leaves the "^I " separators!
$ fc -l 999 1000|cat -vt
999^I echo invite Nerbleson for dinner
1000^I echo and Snordsw
$ help history
should mention how in the world one is supposed to just print the plain history,
without any line numbers or time stamps.
You might say, "Just strip it off with perl or sed." Well, fine. Then mention
that in help history.
Currently one needs massive superfund environmental clean-u
bash man page says
-v Display readline variable names and values in such a way
that they can be re-read.
Perhaps add an example of rereading via the bind command:
$ bind 'set bell-style visible'
else the user might try:
$ echo set bell-style visible|bind
Yes,
Well these days the chances of bells, visual or audible, getting
through are less and less, e.g.,
https://github.com/alacritty/alacritty/issues/1528
and on chromebook one must turn the bell on, etc.
So I still think something different should happen than each forlorn
character just mounting up on
Type ^R and some string,
At the point while we are typing that the search fails, all that
happens is the word "failed" gets added at front,
(reverse-i-search)`nni': set
jida^Ci.org/geo/house_numbering/grids/us/il/lake/lake_county/
(failed reverse-i-search)`nnii': set
jida^Ci.org/geo/house_number
depends more on the regex library that Bash got linked with than
anything that Bash inherently does.
Thanks again, and sorry for the noise.
-dan
On Thu, Oct 26, 2023, at 10:50 AM, Dan Bornstein wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: aarch64
Configuration Information [Automatically generated, do not change]:
Machine: aarch64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -ftree-vectorize -flto=auto -ffat-lto-objects -fexcepti\
ons -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY\
_SOURCE=2 -Wp,-D_GLIBCXX
m=$@; n=($@)'
+ m='a b c'
+ n=($@)
)
>>>>> "CR" == Chet Ramey writes:
CR> On 9/3/23 6:08 AM, Dan Jacobson wrote:
>> It's not fair:
>> set -x a b c
>> m=$@ n=($@)
>> == gives ==
>> + m='a b c'
>> + n=($@)
Shouldn't "declare -ax" print a warning that it is useless?
It's not fair:
set -x a b c
m=$@ n=($@)
== gives ==
+ m='a b c'
+ n=($@)
please either say
+ m=$@
+ n=($@)
or better:
+ m='a b c'
+ n=('a' 'b' 'c')
or metion on
https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html the
special exception.
GNU bash, version 5.2.15
> "LV" == Lawrence Velázquez writes:
LV> This is stated under "Simple Command Expansion".
OK good. No more issue.
man page says:
A variable may be assigned to by a statement of the form
name=[value]
If value is not given, the variable is assigned the null string. All
values undergo tilde expansion, parameter and variable
expansion...
OK, but do please mention s
Sorry everybody. I cannot reproduce it. Nor is anything wrong with the
HISTFILEs...
It must of had something to do with me exploring many "i3" windows
configurations that day.
There probably was.
Say, there should be a way to protect the user against something like
that. I wish I could just tell it to only allow utf-8 in my history.
$ history
works fine if I pipe it into tail.
But if I just let it pour out on the screen, I get this junk after it
sitting at the prompt:
9997 Tue, 04 Apr 2023 17:31:36 +0800 history
9998 Tue, 04 Apr 2023 17:31:59 +0800 history |tail
Tue, 04 Apr 2023 17:32:06 +0800 history
$ 64;1;2;6;9;1
. "$sub1"
Turns out the best time to find bugs in your code is when demoing it for
someone else. :-)
On 12/22/22 11:18 AM, Chet Ramey wrote:
On 12/21/22 11:44 PM, Oğuz wrote:
22 Aralık 2022 Perşembe tarihinde Dan Church yazdı:
Repro:
sub1=$(mktemp)
sub2=$(mktemp)
su
'
>"$sub1"
echo 'echo "2nd script starting" && ${THIS_SH} '"$sub3" >"$sub2"
echo 'echo "3rd script starting"' >"$sub3"
. "$sub1"
"1st script still executing" will nev
$ pdf
pdf pdf2ps pdfcrack pdffonts pdfinfo pdfsig pdftocairo pdftoppm
pdftotext pdf2dsc pdfattach pdfdetach pdfimages pdfseparate pdftexi2dvi
pdftohtml pdftops pdfunite
What's this, a new command called "pdf". I must try it!
$ pdf
bash: pdf: command not found
$ ls -d pdf
pdf
Oh, all along it was
I was testing -xeu vs. -vxeu on
set -xeu
set /var/lib/exim4/config.autogenerated
cp $@ /tmp
update-exim4.conf --verbose
diff /tmp $@||:
set update-exim4.conf.conf
echo . $PWD/$@-jidanni > /tmp/$@
diff $@ /tmp
and no matter STDOUT or STDERR they gave the same results, there in
emacs' *compilation*
Man page says:
-vPrint shell input lines as they are read.
-xPrint commands and their arguments as they are executed.
Perhaps mention that -x and -vx give the same results, often or always.
GNU bash, version 5.1.8
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 COMMANDS
$ 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.
$ 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
$ 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!
Also
Please document on the man page somewhere that set -v, +v inside case
statements is special:
$ cat A
case x in x)
set -v
: B
case y in y)
set -v
: Z
;;
esac
$ e哈=1
bash: e哈=1: command not found
OK, but on man bash is it ever mentioned that a variable name must be all ASCII?
ENVIRONMENT
When a program is invoked it is given an array of strings called the
environment. This is a list of name-value pairs, of the form
nam
$ man bash #and
$ help test #say
-a FILETrue if file exists.
-e FILETrue if file exists.
OK, but add a note that it would be better to use -e,
as it is more portable.
Compare
$ test -a .
$ /usr/bin/test -a .
My experiments,
https://github.com/scop/bash-completion/issues/489
"prove" that
set skip-completed-text on
should be the default, not off.
Man bash says
Readline Variables
Readline has variables that can be used to further customize its behav‐
ior. A variable may be set in the inputrc file with a statement of the
form
set variable-name value
or using the bind builtin command (see SHELL B
$ man bash
page-completions (On)
If set to On, readline uses an internal more-like pager to dis‐
play a screenful of possible completions at a time.
OK, and it looks like:
final.target
first-boot-complete.target
fstrim.service
fstrim.timer
--More--
But if I c
Instead of
$ zz /jidanni_backups/da
Display all 113 possibilities? (y or n) n
and then finally showing
$ zz /jidanni_backups/dan_home_bkp
how about doing the expansion first, so entering
$ zz /jidanni_backups/da would then change into
$ zz /jidanni_backups/dan_home_bkp with below it the questio
on't include this section.]
--
Dan Shearer
d...@shearer.org
OK, filed https://github.com/scop/bash-completion/issues/417 .
$ ls $HOME/xx/yy/z
becomes
$ ls \$HOME/xx/yy/zz
It should become
$ ls $HOME/xx/yy/zz
else it will fail when the user finally hits RET.
(Assume a zz file already exists. "ls" here is just an example. same for
"cat" etc.) Bash 5.0.16
> "AKK" == Andreas Kusalananda Kähäri writes:
AKK> Does setting a DEBUG trap not do what you want? Such a trap would be
AKK> executed before each simple command...
OK! I guess it does! Thanks.
PROMPT_COMMAND=sleep\ 1 is great, it lets us slow down scripts...
but alas only if they are interactive.
One might say: "Sure, instead of
$ bash script
just use
$ sed 's/^/sleep 1; /' script | bash"
But that assumes one command per line, and could easily mangle things.
Instead bash simply needs
Man bash: "unset"
if there is no variable by that name, any function with that name is unset.
Add:
If there is no function by that name, nothing happens for that name.
$ mapping/taipower/pole2tm
bash: mapping/taipower/pole2tm: No such file or directory
Must be a bash bug! Proof:
$ ls -l mapping/taipower/pole2tm
-rwxr-xr-x 1 jidanni jidanni 11290 2012-06-19 mapping/taipower/pole2tm
But wait,
$ strace mapping/taipower/pole2tm
execve("mapping/taipower/pole2tm", [
CR> I'm saying that's what the default bash completion code does. The default
CR> bash completion code leaves the word unchanged.
Yes. That's why I'm saying wouldn't it be neat if it made
*.p into *.pdf? What harm could possibly happen?
The idea being if the user has handed it an asterisk,
then he
>>>>> "CR" == Chet Ramey writes:
CR> On 9/1/19 11:10 AM, 積丹尼 Dan Jacobson wrote:
>> $ ls *.pdf
>> a.pdf b.pdf
>> $ diff *.p
>>
>> At this point should complete "*.pdf".
CR> It does (well, the default completion does, may
$ ls *.pdf
a.pdf b.pdf
$ diff *.p
At this point should complete "*.pdf".
Or maybe as a bonus it could complete "a.pdf b.pdf" via a different key.
On the man page:
Readline Variables
Readline has variables that can be used to further customize its
behavior. A variable may be set in the inputrc file with a
ADD: ^or inspected with the bind command, or
set
statement of the for
All I know is in emacs,
let's say we did
^Rgrandma this morning,
and in the afternoon we did
^Rgrandpa.
Well we could do ^R^R to search for grandpa again, and for grandma we
could employ ^R then
> M-p (translated from p) runs the command
> previous-history-element (found in minibuffer-local-isear
On the bash man page at
expr1 -a expr2
True if both expr1 and expr2 are true.
expr1 -o expr2
True if either expr1 or expr2 is true.
and on "help test" perhaps add the same warning as one sees on
(info "(coreutils) Connectives for
OK so bash is right and dash is wrong? So I should file a dash bug?
So how am I to get
"A"
with bash?
$ cat z
p=A
cat <
On Wed, Oct 17, 2018 at 9:05 AM Chet Ramey wrote:
> You know this has already been done, right?
I do now! Still trying to get caught up with the changelog.
On Mon, Aug 27, 2018 at 8:12 PM Chet Ramey wrote:
>
> On 8/27/18 12:25 PM, Grisha Levit wrote:
> > This used to work:
> >
> > bash-4.4$ a=0
> > bash-4.4$ echo $(( a[a[0]] ))
> > 0
> > bash-4.4$ echo ${a[a[a[0]]]}
> > 0
Just curious, did you decide what to do with this?
> This is part of changes
$PS4 is for sh -x. Well, $PS5 or $PSv should be for sh -v!
Imagine, with just a simple PS5='$ ', one could produce
perfect dialogues,
$ set -eu /tmp/x
$ mkdir $@
$ cd $@
$ seq 3|xargs touch
$ ls -U $@
3 2 1
$ mv -v $@ /var$@
created directory '/var/tmp/x'
copied '/tmp/x/1' -> '/var/tmp/x/1'
cop
> "EB" == Eduardo Bustamante writes:
EB> I googled "disable programmable completion bash" and the first result
I was just googling for disable bash completion.
That's how confusing it is for most users.
OK it mentions "Without any option arguments". Then it also needs to
mention "Without any argument at all".
$ help shopt
shopt: shopt [-pqsu] [-o] [optname ...]
Set and unset shell options.
Change the setting of each shell option OPTNAME. Without any option
arguments, list all shell options with an indication of whether or not each
is set.
Add:
If just optnames are given, list
OK, please on
$ help complete
at "-r" please mention
"To instead toggle on and off PROGRAMMABLE completion, use shopt -[su]
progcomp."
Reason: there is very little chance the user could Google the right
answer out of the forest of answers out there.
(P.S., I am not sure if PROGRAMMABLE should be
PG> There is no magic way to restore them
Actually it also says
-pprint existing completion specifications in a reusable format
So maybe it should say do
I=$(completion -p); completion -r; : your tests; $I
but I didn't test it.
OK submitted https://github.com/scop/bash-completion/issues/173
$ help complete
-rremove a completion specification for each NAME, or, if no
NAMEs are supplied, all completion specifications
Add
To later restore them do ...
as one often wants to remove them all, try something, and then put them
all back.
I am no
$ $BRO #makes $BROWSER. Good!
$ xargs $BRO #just beeps. Bad.
Yes I have bash-completions installed but am not sure what is to blame.
On 10/10/2017 07:00 AM, shawn wilson wrote:
> I guess that's the right way to describe what I'm seeing:
>
> [swilson@localhost ~]$ unset f; f=(aaa bbb ccc) declare -p f
> declare -x f="(aaa bbb ccc)"
> [swilson@localhost ~]$ unset f; f=("aaa" "bbb" "ccc") declare -p f
> declare -x f="(aaa bbb ccc)
On 10/08/2017 03:11 PM, Eduardo A. Bustamante López wrote:
> I guess that instead of changing the semantics of
> command_not_found_handle, a new special trap could be added that
> executes in the context of the shell performing the command lookup.
Possible, but magic traps can be ugly. I often end
On 10/08/2017 10:41 AM, Dan Douglas wrote:
> On 10/08/2017 09:47 AM, Chet Ramey wrote:
>> It was originally intended to take the place of the error message that
>> bash prints when it can't find a program to execute. That message was
>> printed by the subshell forked to e
On 10/08/2017 09:47 AM, Chet Ramey wrote:
> It was originally intended to take the place of the error message that
> bash prints when it can't find a program to execute. That message was
> printed by the subshell forked to execute the command, so the message could
> be redirected (nearly ll shells
On 10/07/2017 02:53 PM, Martijn Dekker wrote:
> The bash manual and info pages state:
>
> | If the search is unsuccessful, the shell searches for a
> | defined shell function named 'command_not_found_handle'. If that
> | function exists, it is invoked with the original command and the
> | origina
On 10/05/2017 02:29 PM, Dan Douglas wrote:
> ...
Another band-aid might be to build bash with -fsplit-stack. Hardly
worth mentioning as it doesn't fix anything - you just run out of memory
instead of overflowing a fixed-size stack, should someone actually want
that for som
On 09/25/2017 01:38 PM, Eric Blake wrote:
> On 09/24/2017 12:53 PM, Shlomi Fish wrote:
>
>>
>> I see. Well, the general wisdom is that a program should not ever segfault,
>> but
>> instead gracefully handle the error and exit.
>
> This is possible by installing a SIGSEGV handler that is able to
CR> The third command attempts to increase the limit beyond the current hard
CR> limit. If you're not root, this is not permitted.
I find it odd that a normal user can raise it only once...
$ ulimit -c
0
$ ulimit -c 99
$ ulimit -c
99
$ ulimit -c 99
bash: ulimit: 99: limit out of range
$ ulimit -c 999
bash: ulimit: 999: limit out of range
$ ulimit -c 99
$ ulimit -c 99
$ ulimit -c unlimited
bash: ulimit: core file size: cannot modify limit: Operation not permitted
Maybe say: try again with numbers, not letters.
On 07/14/2017 03:13 PM, Greg Wooledge wrote:
> On Sat, Jul 15, 2017 at 02:59:41AM +0700, Robert Elz wrote:
>> IMO, if SHELL gets unset (it is usually initialised by login, or its
>> equivalent), it should simply stay unset, and not be set to anything,
>> until some user (or script) decides to set i
OK I submitted
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865875
against bash-completion.
$ apt-cache policy bash bash-completion
bash:
Installed: 4.4-5 ...
bash-completion:
Installed: 1:2.1-4.3 ...
OK
$ INPUTRC=/dev/null bash
$ : k*m
kam kaam kam
OK I suppose I should report a bug against the bash-completion package.
# su - nobody
$ touch kam kaam kam
$ : k*m #becomes:
$ : kam
$ sh
sh-4.4$ : k*m #does a better job it seems:
kam kaam kam
sh-4.4$ : k*m
New idea: you've searched way back in history (^R), found what you want,
and hit RET, only to realize that you really wanted to hit ^O.
Well now you have to search all over again (^R) and then hit ^N to get
the same effect.
Well perhaps there could be a "morning after pill" keystroke added. Bash
OK. (But shellcheck doesn't catch it either.)
$ { echo '#!/bin/sh'; echo 'echo x > c > c > c';}|shellcheck /dev/stdin
$ { echo '#!/bin/sh'; echo 'echo x < c < c < c';}|shellcheck /dev/stdin
OK sorry. I guess they make a lot of sense.
Maybe bash should catch this
$ echo x > a > b > c > d
and print a warning.
Same with
$ cat < a < b < c < d
On 03/18/2017 12:19 PM, Chet Ramey wrote:
> On 3/17/17 6:35 PM, Dan Douglas wrote:
>
>> The problem is the non-obvious nature of unset's interaction with scope,
>> (and the lack of documentation). Not much can be done about the former,
>> as it is with so many thing
On 03/17/2017 09:16 PM, Dan Douglas wrote:
> Why
> would a subshell just make the call stack go away?
I guess slight correction, it's unset itself, because:
> In fact, mksh prints "global" even without the subshell, despite it
> using dynamic scope for either
On 03/17/2017 07:21 PM, Stephane Chazelas wrote:
> I don't expect the need to have to add "local var" in
>
> (
>unset -v var
>echo "${var-OK}"
> )
True. I would pretty much never use a subshell command group when I know
that locals are available though. And if I know locals are available
The need to localize IFS is pretty obvious to me - of course that's
given prior knowledge of how it works.
The problem is the non-obvious nature of unset's interaction with scope,
(and the lack of documentation). Not much can be done about the former,
as it is with so many things.
GW> Log out, log back in as root, issue the command, and accept that root's
GW> (very short) shell history will be lost.
Well mention that on the man page.
I.e., the man page should address the paradox of saving a complete
history vs. being able to turn off one's computer.
GW> I'm confused. You don't logout before shutting down your computer?
GW> I would strongly recommend doing so, unless it's an emergency.
All I know is I want to issue one command to turn off the computer.
If I logged off first, how could I issue that (poweroff(8)) command?
OK you people turn of
Man page says:
When a shell with history enabled exits...
and
The shell exits by default upon receipt of a SIGHUP...
However on slower systems, at the end of the day when the user issues
the poweroff(8) command, all this might not complete, resulting in the
entire day's of history getting thr
$ help complete
...
Options:
-pprint existing completion specifications in a reusable format
-rremove a completion specification for each NAME, or, if no
NAMEs are supplied, all completion specifications
-Dapply the completions and actio
On Mon, Dec 26, 2016 at 12:42 PM, Dominique Ramaekers
wrote:
> As I understand it, the command_not_found_handle is not triggered on an
> unknown command in a shell script, run normally.
Where'd you here that? That's easy to test.
$ bash <<<'command_not_found_handle () { echo "$FUNCNAME"; }; bla
A simpler one this time. Bash 4.4 only.
$ bash -c $'alias @="eval {\n}"; eval @'
bash: xrealloc: cannot allocate 18446744071562068464 bytes
I would guess this is part of the way keywords are supposed to be
re-interpolated after alias expansion since 4.4. Maybe not even be a
bug depending on how
On Wed, Nov 23, 2016 at 1:25 PM, Chet Ramey wrote:
> On 11/22/16 5:46 PM, Dan Douglas wrote:
>> Hi. Here's a change between bash 4.1 and 4.2 that persists in 4.4.
>> (Added the counter to make it stop).
>
> Thanks for the incredibly obscure report. This will be fixed
1 - 100 of 471 matches
Mail list logo
