user not informed of inputrc errors

In the man page history-preserve-point needs its default value listed: history-preserve-point (Off) P.S., let's say one just wants to turn it on for a couple of commands. The man page's Readline Initialization section makes it seem that the only chance of setting

Re: ^B should be allowed to climb back up to the previous line

It seems ^B should be allowed to climb back up to the previous line here, instead of only allowing ^P to do it: $ e\ f^B^B Chet Why? To readline, they're two separate lines. Well real emacs can. So we emacs users get the feeling that something is broken and give up hope of getting back

Re: transpose-words on $? $@

This happened in Makefile mode. Well OK, they aren't words. By the way, in bash, one at least gets a beep and the cursor doesn't move. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

set -x makes r=1 echo and r=1; echo look the same

Hurmf, I don't like how the former looks like it was two separate commands according to set -x: $ set -x $ r=1 echo + r=1 + echo $ r=1; echo + r=1 + echo They shouldn't give exactly the same, no? ___ Bug-bash mailing list Bug-bash@gnu.org

help should check 2nd ... args

$ help : ! :: : No effect; the command does nothing. A zero exit code is returned. What about that second argument? $ help ! bash: help: no help topics match `!'. Try `help help' or `man -k !' or `info !'. Regarding RESERVED WORDS $ set ! case do done elif else esac fi for function \

wishlist: an absolute ESC .

How can one make a ESC . command that will get the last word from the last line, even if we have just hit a few ^P's? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

set -x and $''

Interesting, here in big5 land I notice set -x will encode into octal its output unless the item has certian printing non alphanumerics in it I suppose. Anyways, there should be a way to tell set -x that one doesn't want the $'' help, and would just like the raw chars. Also a way to have set -x

$(case x in x)...

The man page berates old-timers: When the old-style backquote form of substitution is used... However, who is it that is too hungry for the next )?: $ k=$(case x in x) :;; esac) bash: syntax error near unexpected token `;;' $ k=$(case x in x) :; esac) bash: syntax error near unexpected

man page doesn't say typeset obsolete

But the man page doesn't say obsolete: $ help typeset typeset: typeset [-afFirtx] [-p] name[=value] ... Obsolete. See `declare'. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

say how to remove functions too

The FUNCTIONS part of the man page should mention that functions can be destroyed with unset, even if it is mentioned elsewhere. E.g., unalias is mentioned right away in the ALIAS section. ___ Bug-bash mailing list Bug-bash@gnu.org

expansion fails upon pipes in big5 chars

$ echo 05017法規修訂座* 05017法規修訂座談會-1.pdf 05017法規修訂座談會.pdf hitting tab gets caught in the hidden | in the last byte: $ echo 05017法規修訂座談愧| Display all 3261 possibilities? (y or n) Therefore bash filename expansion fails upon pipes in big5 chars $ echo 會|qp-encode =B7| It knows it is one char though:

can't expand after colon

Must one use \: to make this work? $ cd /tmp/jidanni.orgTAB jidanni.org/ jidanni.org:2082/ $ cd /tmp/jidanni.org:TAB Display all 456 possibilities? (y or n) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

whole line echoed every char I type

Holy moly, without LC_ALL=C, for every character I type, the whole line is echoed! 03:39 ~$ LC_ALL=C script Script started, file is typescript 03:39 ~$ exit Script done, file is typescript 03:39 ~$ cat -v typescript Script started on Tue Jan 24 03:39:46 2006 ^[[01;35m03:39 ~$^[[00m exit^M Script

one by one undo the undos

We see: (C-_, C-x C-u) Incremental undo, separately remembered for each line. Each line? Fancy. I'd trade it for a way to back out once one has undone too much. Like real emacs, one can do e.g., ^F to break the undo habit and then begin undoing the undos. With bash there is no way

syntax error near unexpected token `done' could be more wordy

$ for i do case $i in *!*) echo $i;done bash: syntax error near unexpected token `done' Well OK, but you could also say ... while looking for esac I bet perl would say that if it had esacs. Would help in big programs. ___ Bug-bash mailing list

HISTFILE vs. two or more bashes

The HISTORY section on the man page should mention the case where one has one bash session in one window, and another in another, etc., both with all the same history related environment variables, including $HISTFILE, inherited from a parent shell. Is it only the shell that exits last the one

current input line lost on ^Z

Perhaps bad? $ cat p bb ccc^Z $ something_else $ fg zzz ^D $ cat pr bb zzz I was not finished composing line ccc when I had to do something_else. Now I have to remember what I was typing to type line ccc all over again, and it might not even be left on

message: ^Z: nothing to suspend

Maybe bash should print a message when one hits ^Z but there is nothing to suspend: $ bla ^Z bash: useless hit of ^Z or bash: ^Z: nothing to suspend ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

mention kill 0

The kill(1) man page doesn't mention kill 0. /bin/kill 0 #scripts proceed no further The bash man page mentions kill 0, but not in its main kill paragraph. The bash man page doesn't mention kill -1. The bash help kill bulrb doesn't mention kill 0 or -1. The kill(1) man page, as of procps:

Re: message: ^Z: nothing to suspend

By the way, printing such a message, one could tell if one's program died and we are back in the shell or is just not responding. (Yes one can also see Terminated messages.) ___ Bug-bash mailing list Bug-bash@gnu.org

one undo too many and bye bye line

Type $ abcde then five DELs or ^H's to erase it, then five undos (^/ or whatever) to restore it, and then one more undo for good luck, and wham, bye bye line. No getting back anything whatever you type. You'll just have to type abcde all over again.

disowned not the job expected

Another disown adventure. # suspend [1]+ Stopped su $ emacs -f gnus fileA [2] 4865 $ disown bash: warning: deleting stopped job 1 with process group 3457 $ jobs [2]- Running emacs -f gnus fileA $ help disown disown: disown [-h] [-ar] [jobspec ...] By default, removes each

bash -x $'' hexadecimal

I notice bash -x prints some messages in octal, $'\345\226\256\350\252\236\345\214\226' I bet there's no way to get it to print them in hexadecimal. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

help kill should also mention man kill

Incompatibility: one verbose, one not. $ kill -1 1812 1818 1825 1826 1857 bash: kill: (1812) - No such process bash: kill: (1818) - No such process... $ /bin/kill -1 1812 1818 1825 1826 1857 $ Or at least also mention /bin/kill here $ help kill ...Kill is a shell builtin for two reasons... $

Bug#442077: su + ssh + false kills $PPID?

Package: openssh-client Version: 1:4.6p1-5 Severity: normal File: /usr/bin/ssh Why does this script not finish, only when using su, and only when using ssh? # cat script su my_username_here \EOEOE set -x echo $- #no -e here, see remote=my.remote.host.here false ssh $remote false #Why does this

Re: let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND

Thanks fellows but now bash has become very slow to the touch that way.

Re: let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND

Can you somehow give the user his prompt first and then wait, instead of the other way around? Also rapid ^P RET ^P RET should somehow be exempt.

Re: let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND

PG == Pierre Gaston pierre.gas...@gmail.com writes: PG Maybe try something like: PROMPT_COMMAND='read -t0 sleep 10' But how will that on its own stop me from dumping tons of lines of junk into bash via one accidental mouse click?

Re: let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND

Ah ha! Thanks for the private tip 4 minutes ago. This works!: saftey_seconds=5 PROMPT_COMMAND='if ((SECONDS==0)); then echo TOO FAST HOLMES, waiting '\ $saftey_seconds' seconds or hit ^C; sleep '$saftey_seconds'; else SECONDS=0; fi' Hope somebody documents it somewhere as otherwise, well, the

Re: let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND

case $- in *i*) saftey_seconds=5 SECONDS=1 PROMPT_COMMAND=if ((SECONDS==0)); then echo TOO FAST HOLMES, waiting \ $saftey_seconds seconds or hit ^C; sleep $saftey_seconds; else SECONDS=0; fi esac

Re: let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND

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

Segmentation fault when -x is added and variable contains nulls

# 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

Hitting C-c C-c in Emacs' *shell* causes segmentation fault

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.

Re: Hitting C-c C-c in Emacs' *shell* causes segmentation fault

CR == Chet Ramey chet.ra...@case.edu 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

two ESC . in a row on a fresh shell kills it

Try su - nobody #(pristine account) then type :RET 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$ :

~ vs. filename expansion

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

Bug#739835: ~ vs. filename expansion

X-debbugs-cc: chet.ra...@case.edu bug-bash@gnu.org Package: bash-completion Version: 1:2.1-2 CR == Chet Ramey chet.ra...@case.edu 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/location/directions/ nobody

TAB expand as much as you can before asking "Display all possibilities"

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").

$ < some_file some_command Tab expansion

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'

why would anybody want ESC . to remember "&" ?

$ 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 ..

Re: run_readline_command to avoid the bother of binding something

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

run_readline_command to avoid the bother of binding something

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-

${p+\"$p\"}

So how am I to get "A" with bash? $ cat z p=A cat <

set -x vs. n=($@)

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

Re: set -x vs. 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=($@) CR> It's because the compound assignm

Warn upon "declare -ax"

Shouldn't "declare -ax" print a warning that it is useless?

Show slash if a directory upon TAB

$ 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

Re: Junk at the end on history

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.

Junk at the end on 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 $

Re: Junk at the end on history

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.

Document m=1 m=2; echo $m result

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

Re: Document m=1 m=2; echo $m result

> "LV" == Lawrence Velázquez writes: LV> This is stated under "Simple Command Expansion". OK good. No more issue.

Add example of bind readline-command-line

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

Make reverse-i-search failure joltingly clear

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

Re: Make reverse-i-search failure joltingly clear

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

Re: Add option to just print history, with no added timestamps or line numbers

>>>>> "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: &

Re: Add option to just print history, with no added timestamps or line numbers

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.

Re: Add option to just print history, with no added timestamps or line numbers

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.

Re: Add option to just print history, with no added timestamps or line numbers

> "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

Add option to just print history, with no added timestamps or line numbers

$ 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

sh vs. bash -xc 'a=b c=$a'

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

'help' command adds unnecessary trailing blanks indenting empty lines

No big deal but, $ help :|cat -e :: :$ Null command.$ $ No effect; the command does nothing.$ $ Exit Status:$ Always succeeds.$

Display all 132 possibilities? (y, n, or t) t=time!

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'

add argument to help history

$ 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

why must bash zap last search string just because we hit ^C?

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?

Re: why must bash zap last search string just because we hit ^C?

> 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.

Re: why must bash zap last search string just because we hit ^C?

> "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.

Re: why must bash zap last search string just because we hit ^C?

> "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

Re: why must bash zap last search string just because we hit ^C?

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

Re: why must bash zap last search string just because we hit ^C?

> "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.

Re: why must bash zap last search string just because we hit ^C?

> "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.

Re: make first different character bold when showing completions ala emacs

> "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

make first different character bold when showing completions ala emacs

# 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:

Re: history vs. poweroff

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

Re: history vs. poweroff

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.

history vs. poweroff

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

undocumented 'prefer-visible-bell' found in /bin/bash

$ 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

Re: run_readline_command to avoid the bother of binding something

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

help vs. partial option lists

$ 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

Re: echo x > a > b > c > d

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

echo x > a > b > c > d

Maybe bash should catch this $ echo x > a > b > c > d and print a warning. Same with $ cat < a < b < c < d

Re: echo x > a > b > c > d

OK sorry. I guess they make a lot of sense.

Re: ulimit -c unlimited

$ 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

Re: ulimit -c unlimited

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...

CTRL-R RET "morning after pill" keystroke

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

Re: expand x*y concludes with one

$ 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.

expand x*y concludes with one

# 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

Re: expand x*y concludes with one

OK I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865875 against bash-completion.

Re: help complete: mention remove all AND restore all

> "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.

variables not TAB expanded except in first position

$ $BRO #makes $BROWSER. Good! $ xargs $BRO #just beeps. Bad. Yes I have bash-completions installed but am not sure what is to blame.

Re: help complete: mention remove all AND restore all

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.

help complete: mention remove all AND restore all

$ 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

Re: help shopt: mention what happens if only optnames are given

OK it mentions "Without any option arguments". Then it also needs to mention "Without any argument at all".

help shopt: mention what happens if only optnames are given

$ 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

Re: help complete: mention remove all AND restore all

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

Re: variables not TAB expanded except in first position

OK submitted https://github.com/scop/bash-completion/issues/173

$PS5, for sh -v!

$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'

Re: ${p+\"$p\"}

OK so bash is right and dash is wrong? So I should file a dash bug?

Maybe implement emacs' previous-history-element

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

Add warning on test -a, -o documentation

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

  1   2   >