$ 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
>>>>> "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
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
$ 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
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 <
$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.
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.
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
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
OK then please add
dump-functions
Print all of the functions and their key bindings to the read-
line output stream. If a numeric argument is supplied, the out-
put is formatted in such a way that it can be made part of an
inputr
$ strings /bin/bash | grep -c prefer-visible-bell
1
$ man bash | grep -c prefer-visible-bell
0
$ find /usr/share/doc/bash* -type f | xargs zgrep prefer-visible-bell | wc -l
0
Furthermore, one could finally do
$ run_readline_command dump-variables | grep bell
prefer-visible-bell is set to `on'
bell-style is set to `audible'
which is rather impossible, even if one does bind unbound commands.
Currently one must probably use script(1), bind the key, and then exit
and grep
On the bash page at the end of
Readline Command Names
The following is a list of the names of the commands and the default
key sequences to which they are bound. Command names without an accom-
panying key sequence are unbound by default. In the following descrip-
$ bla1 bla2 bla3 &
$
$ &
Why not
$ bla3
What value is remembering "&".
Emacs' doesn't, and doesn't bother even mentioning it:
C-c . runs the command comint-insert-previous-argument, which is an
interactive compiled Lisp function in `comint.el'.
It is bound to C-c ..
(comint-insert-previous-a
Here we observe that bash _could_ first expand as much as it could,
before asking us y or n,
$ find .backups/\!h
Display all 277 possibilities? (y or n) n
$ find .backups/\!home\!jidanni\!
Instead it waits until we say "n".
(All I typed was the first line, and the "n").
BASH_VERSION='4.4.0(1)-rc
Tab expansion works for both parts of
$ some_command < some_file
but not the some_command of
$ < some_file some_command
BASH_VERSION='4.4.0(1)-rc1'
> Press Ctrl-u
OK I see this also works for
$ ^Rabcdefg^U
$ some command the boss told me to do
$ ^R^R
and voila! I am back to searching "abcdefg" again.
OK, I'll remember ^U. Case closed. Thanks everybody.
> "DR" == Dave Rutherford writes:
DR> Can you run gnu screen? ^A-c will get you a new shell session in the
DR> existing terminal emulator (it will use a new terminal device, though,
DR> if that's what you care about.)
Let's pretend that I am on a gunk device on a gunk OS and all I have to
wo
> "CFAJ" == Chris F A Johnson writes:
CFAJ> ^Z then fg
^Rsearch_string^Z^Z^Z^Z
the ^Z's are ignored. I can't get back to a prompt with ^Z.
> "DW" == Dennis Williamson writes:
DW> Or just open a new terminal rather than interrupting an in-progress search.
I am on a device where opening a new terminal is a lot of trouble.
> "CFAJ" == Chris F A Johnson writes:
CFAJ> Or just press UP (as many times as necessary) and RET.
That won't get me to a $ prompt.
I want to suspend my search and resume it later.
DW> On Fri, Oct 16, 2015 at 1:50 PM, Chet Ramey wrote:
DW> ^C rudely aborts the entire operation. Why assume you want to save any
DW> of the context?
Because I got a phone call: the boss asked me to execute a shell
command. I used ^C to get myself back to a prompt so I could type in the
Type ^Racb^C^R^R
(Search backwards for abc, then hit ^C, then try searching backwards
some more using the last search string.)
My problem is why must bash zap the memory of abc just because we hit ^C?
> "CR" == Chet Ramey writes:
CR> There is an option in readline-7.0 that will cause completion to display
CR> the common prefix of a set of possible completions in a distinctive
CR> color. This has essentially the same visual effect.
OK. I see http://packages.debian.org/readline-common is o
# dpkg -i /var/cache/apt/archives/phpmyadmin_4%3a4. shows
phpmyadmin_4%3a4.4.15-1_all.deb phpmyadmin_4%3a4.5.0.2-2_all.deb
# dpkg -i /var/cache/apt/archives/phpmyadmin_4%3a4.
Can you please make the first different character bold, like emacs does,
Possible completions are:
phpmyadmin_4%3a4.4.15
$ help history
-d offset delete the history entry at offset OFFSET.
-aappend history lines from this session to the history file
-nread all history lines not already read from the history file
-rread the history file and append the contents to the his
Super duper idea: you know when we hit TAB and it says
Display all 132 possibilities? (y or n)
Well, that happens to be the 'ls -a' format it is asking about.
Well, who says that is the most natural format or the format we want at
that time?
What if occasionally we want the 'ls -t' or 'ls -ta' f
No big deal but,
$ help :|cat -e
:: :$
Null command.$
$
No effect; the command does nothing.$
$
Exit Status:$
Always succeeds.$
# su - nobody #create pristine bug testing environment
$ : >| /tmp/
shows much less choices than
$ : > /tmp/
It is probably wrongly assuming we want to see the
$ : | /tmp/
choices!
BASH_VERSION='4.3.0(1)-release'
$ apt-cache policy bash-completion
bash-completion:
Installed: (none)
X-debbugs-cc: chet.ra...@case.edu bug-bash@gnu.org
Package: bash-completion
Version: 1:2.1-2
>>>>> "CR" == Chet Ramey writes:
CR> On 2/21/14, 9:33 PM, Dan Jacobson wrote:
>> Hitting TAB twice at the end of
>> nobody@jidanni5:/$ : /home/jidanni/jidanni.org
Hitting TAB twice at the end of
nobody@jidanni5:/$ : /home/jidanni/jidanni.org/location/directions/
nobody@jidanni5:/$ : ~jidanni/jidanni.org/location/directions/
shows a list of list of the filenames for the former, but not the
latter. Indeed the for the latter one will have to type the filenames
Try
su - nobody #(pristine account)
then type :
then type ESC . ESC .
Whammo! The shell dies!
The second ESC . acts like ^D.
# su - nobody
No directory, logging in with HOME=/
nobody@jidanni5:/$ cd /tmp
nobody@jidanni5:/tmp$ script
Script started, file is typescript
nobody@jidanni5:/tmp$ :
nobody
> "CR" == Chet Ramey writes:
CR> OK, I'll bite. What is C-c C-c supposed to do? It looks like it just
CR> spews a bunch of garbage to your screen. Is that the intent?
C-c C-c runs the command comint-interrupt-subjob, which is an
interactive compiled Lisp function in `comint.el'.
(comint-
Dear Bug-Bash gentlemen,
http://debbugs.gnu.org/16665 says it seems like a bash bug.
Please have a look if you are also an emacs person.
What a clod I was, thinking @ was ^@.
OK glad you guys are hot on the trail.
# su - nobody
No directory, logging in with HOME=/
$ cat /tmp/r
LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
$ sh /tmp/r
/tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(echo
統一|iconv -t big5 -f utf-8) sh -xc ': $N'
Something about that embedded nul
OK fixed spelling.
Put in .bashrc to prevent accidental execution of many line clipboard paste
dumps:
case $- in *i*)
safety_seconds=5 SECONDS=1
PROMPT_COMMAND="if ((SECONDS==0)); then echo TOO FAST HOLMES, waiting \
$safety_seconds seconds or hit ^C; sleep $saftey_seconds; else SEC
1 - 100 of 145 matches
Mail list logo
