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 was one of my directories. Well if I saw $ pdf pdf/ pdf2ps pdfcrack pdffonts pdfinfo pdfsig pdftocairo pdftoppm Then I would know it was a directory, instead of a command. I see there is a mark-directories (On) If set to On, completed directory names have a slash appended. but... version 5.2.2
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 $ 64;1;2;6;9;15;16;17;18;21;22;28c64;1;2;6;9;15;16;17;18;21;22;28c64;1;2; GNU bash, version 5.2.15(1)
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.
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.
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 somewhere that "if the variable is set more than once within the same statement, the final value is used." $ m=1 m=2; echo $m #(Yes, acts the same as:) $ m=1; m=2; echo $m version 5.2.15(1)-release
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.
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
Warn upon "declare -ax"
Shouldn't "declare -ax" print a warning that it is useless?
Re: set -x vs. n=($@)
OK. That's well and good. But my main problem now is that that fact is not documented anywhere. (Also here it is again, so as to remove any confusion about "compound assignment" (some readers might think it meant two ='s on the same line.) $ bash -c 'set a b c; set -x; 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=($@) CR> It's because the compound assignment forces the expansion to be deferred. CR> You have to figure out what kind of array you're dealing with, for example, CR> and what kind of compound assignment, and bash figures all that out after CR> the `we're performing a variable assignment with xtrace enabled, print the CR> rhs' code runs.
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 jida^Ci.org/geo/house_numbering/grids/us/il/lake/lake_county/ (The ^Cs are where I quit in order to make this "screenshot".) The average Joe, if looking up at his screen, will mostly just notice the line getting longer and longer for each character he types, no matter if it started failing many characters ago. Hmmm, how does emacs handle such situations? Well when the first failed character is entered there is a flash. Then every additional useless character entered gets a red background. Anyway Bash could be more aggressive to wake the user up to the fact that "He is hiking up the wrong trail. Sending money to candidates who already quit the race and shut their accounts." -- typing for no reason. Let's see, it could flash/beep on each useless character. And or refuse to echo them etc. Anyway, after such improvements the average user, instead of typing five or six useless characters before realizing failure has already occurred, would type just one or two! One might say that negative doggy training (beeps, red characters (if color turned on), frozen line), wouldn't be needed if the user would just please be aware of the word "failed" at the start of the line. Well that word isn't even in uppercase.
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 the screen. Just like when the recycle department doesn't just let one pile stuff up at their door when they are closed.
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 Yes, we see bind readline-command-line well maybe say bind 'readline-command-line'
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 clean-up effort workarounds, e.g., $ HISTTIMEFORMAT=' ' history | perl -pwle 's/^\s+\S+\s+//' Better yet, add a history -j: Just print history, with no added timestamps or line numbers, etc. Or OK, there's HISTTIMEFORMAT. How about also a HISTFORMAT (default " %5n %t %h\n" or whatever,) so one could use "%h\n" for "just give me the history item."
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 Snordsworth too $ fc -ln 999 1000|cat -vt ^I echo invite Nerbleson for dinner ^I echo and Snordsworth too (Well I guess that's better than the other way around at least. (Inserting the numbers but forgetting the separators.)) MDK> It might be helpful to have explicit cross-references between the MDK> help displays for «history» and «fc». Yup, else I would have never learned about this feature unless the nice man from .nz stepped forth. Imagine that, me, an innocent reader of the "help history" command, is supposed to magically know about the "fc" command, without a shred of "SEE ALSO" there on the "help history" page. Yes, we are all supposed to read the Bash Man page, but a tiny 'see also "fc"' would go miles in making "help" more helpful.
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
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: 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 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 shell is just a gaping mouth..."
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 SECONDS=0; fi" esac
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 null. bash, version 4.3.0(1)-rc1 (i486-pc-linux-gnu)
Re: Segmentation fault when -x is added and variable contains nulls
What a clod I was, thinking @ was ^@. OK glad you guys are hot on the trail.
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 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-interrupt-subjob) Interrupt the current subjob. This command also kills the pending input between the process mark and point.
two ESC . in a row on a fresh shell kills it
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@jidanni5:/tmp$ :Script done, file is typescript $ cat -v typescript Script started on Thu Feb 20 13:10:28 2014 nobody@jidanni5:/tmp$ :^M nobody@jidanni5:/tmp$ : Script done on Thu Feb 20 13:10:33 2014 nobody@jidanni5:/tmp$ echo $BASH_VERSION 4.3.0(1)-rc2
~ 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 in by hand. BASH_VERSION='4.3.0(1)-rc2'
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 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@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 in >> by hand. BASH_VERSION='4.3.0(1)-rc2' CR> I can't reproduce this on Mac OS X or RHEL 5. Are you sure it's not CR> bash-completion? Indeed, I see that package is installed on my jidanni5 machine where the problem occurred, but not on my jidanni6 machine where I am today where I cannot reproduce it. OK I will remove the bash-completion package on my jidanni5 machine. If anybody is interested, all one needs to do is su - nobody to get the pristine testing environment to reproduce it there on Debian sid.
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 history-preserve-point is by putting it in an inputrc file, and the only time the inputrc is read is at the birth of a new shell. Nothing like set -o available. Hope it isn't true. P.P.S., Here, } Except where noted, readline variables can take the values On } or Off. The variables and their default values are: Mention that lowercase 'on' and 'off' are OK too. PPPS, also mention the command to dump all the current readline settings to the screen. All we see is how to set them, no command for how to see their current values. What's real bad is that the user is not told of any problems encountered in reading inputrc. The user could put set history-preserve-point on #cool! there, and never be informed that that line was considered an error. Yes the man page says comments must be on the beginning of lines. The user could even put z in inputrc, with no error message that something was wrong. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
^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 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 up, unless we experiment with ^P. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 http://lists.gnu.org/mailman/listinfo/bug-bash
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 \
if in select then until while { } time [[ ]]
$ for i do help >&- 2>&- $i||e=$i\ $e; done
$ echo $e
]] } then in fi esac else elif done do !
OK, but ! perhaps should have a blurb.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
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 print in hex rather than octal. BASH_VERSION='3.1.0(1)-release' $ sh -c 'set -x *; : $@' 2>&1|perl -pwe "s/(pdf') /$&\n/g" + : $'01\246\355\246v\244\247\252\305\266\241\260\317\246\354\277\357\276\334pdf' $'02\252\305\266\241\302I\253\254\272A\244\300\252R-\273O\245_\245\253pdf' ... $'19\247Q\245\316\245b\272\312\267\376\246\241\276\367\276\271pdf' $'20\275s\251w\244u\267~\260\317\245\316\246a\272\364\273\332pdf' '21應用數值高程模型於山坡地pdf' $'[EMAIL PROTECTED]' ... $'32SuperTour-\246\346\260\312\246\241\256\310\271C\276\311\304\375pdf' $'33\300\263\245\316\246a\262z\270\352\260T\250t\262\316\273\262\247U\260\352\255xpdf' '34電子地圖操作介面設計.pdf' $'35\272\326\272\270\274\257\250F\275\303\254P\244G\270\271\274v\271\263\300\263\245\316pdf' ... ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
$(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 token `esac' $ k=`case x in x) :; esac` $ The man page even mentions: Command substitutions may be nested. To nest when using the backquoted form, escape the inner backquotes with backslashes. But tripping/conflict over case esac innards hadn't been discovered until today for $() so isn't mentioned. Fix the "bug" or mention it here and in the "case ... esac" sections of all docs. By the way, >> 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? C> You'll have to modify the source, since ^P changes your position in C> the history list. (It is more likely that the source will modify me. Anyway, I end up pasting with the mouse 30 times a day. I have only once in my life used ^R.ESC. or ^P^P^P...ESC. as offered.) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
prompt miscalculations seen more often in 3.1.0?
Prompt miscalculations seems to happen slightly more in 3.1.0? Live
with this below script for a few days and often using ^R, ^A, combined
with inserting characters etc. and you too should see how often bash
miscalculates where things are on the screen. It's hard to describe,
so no precise examples coming forth from me this time, but that's
good, as living with this for a few days and you will discover even
more problems perhaps. If bash had an emacs-like view-lossage command
(very good idea!) I would be more inclined to give a precise example.
Anyway, I often reach for ^L these days. BASH_VERSION='3.1.0(1)-release'
case z-$TERM in
z-rxvt)
my_color_on="\[\e[01;35m\]" my_color_off="\[\e[00m\]"
if test -w /
then my_color_on="\[\e[01;41;30m\]"
fi
esac
#Mr. http://cfaj.freeshell.org:
PROMPT_COMMAND='prompt_tricks_z=" $?"; prompt_tricks_z=${prompt_tricks_z# 0}
case $PWD in $HOME) pwd=\~;; *) pwd=${PWD##*/};; esac'
PS1=$SPECIAL_PS1"$my_color_on\A\$prompt_tricks_z \$pwd\\$""$my_color_off "
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
yank-last-arg after a #
I do $ # x y z $ zzz the ESC. doesn't get the last argument these days if there was a #. I get a bell. OK, I'll use ":" then I suppose now. Wait, $ xx yy zz # qq ESC. still gets the qq. And ^P still recalls lines, no matter where the # is. bash3.1.0(1). ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 http://lists.gnu.org/mailman/listinfo/bug-bash
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: $ echo 05017法規修訂座談?.pdf 05017法規修訂座談會.pdf ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: yank-last-arg after a #
>> $ xx yy zz # qq >> ESC. still gets the qq. C> I get `zz'. Oops, me too. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
can't expand after colon
Must one use \: to make this work? $ cd /tmp/jidanni.org jidanni.org/ jidanni.org:2082/ $ cd /tmp/jidanni.org: 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 done on Tue Jan 24 03:39:50 2006
03:40 ~$ script
Script started, file is typescript
03:40 ~$ exit
Script done, file is typescript
03:40 ~$ cat -v typescript
Script started on M-&M-hM-$M-82006M-&~01M-$M-k24M-$M-i (M-6gM-$G) [EMAIL
PROTECTED],M-m
^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40
~$^[[00m e^M^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40 ~$^[[00m
e^M^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40 ~$^[[00m
ex^M^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40 ~$^[[00m
ex^M^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40 ~$^[[00m
exi^M^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40 ~$^[[00m
exi^M^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40 ~$^[[00m
exit^M^[[01;35m03:40 ~$^[[00m ^M^[[01;35m03:40 ~$^[[00m exit^M
Script done on M-&M-hM-$M-82006M-&~01M-$M-k24M-$M-i (M-6gM-$G) [EMAIL
PROTECTED],M-m
(One doesn't notice the echos. I broke the single long line above to
fit nicer in this message.)
BASH_VERSION='3.1.0(1)-release'
LANG=zh_TW.Big5
LC_COLLATE=C
LC_CTYPE=zh_TW.Big5
LC_MESSAGES=C
PROMPT_COMMAND=$'prompt_tricks_z=" $?"; prompt_tricks_z=${prompt_tricks_z# 0}\n
case $PWD in $HOME) pwd=\\~;; *) pwd=${PWD##*/};; esac'
PS1='\[\e[01;35m\]\A$prompt_tricks_z $pwd\$\[\e[00m\] '
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: whole line echoed every char I type
If I do set +o emacs, the problem goes away. Anyway, you must admit it is a big problem. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 but to continue undoing, continue the destruction. Other approach: gimp has a redo key. We see: revert-line (M-r) Undo all changes made to this line. This is like executing the undo command enough times to return the line to its initial state. Thanks but all I wanted to do was undo one undo... ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
warn on bad $'...' stings?
Maybe there should be a mechanism to output warning or $?=1 for things like $ echo $'\0x11' where the user has fudged the syntax etc. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
document that echo can't be given a NULL
No way to hand echo or /bin/echo a NULL. $ set a $'\x00' b $ echo $# 3 $ echo A$'\x01'B|wc -c 4 $ echo A$'\x00'B|wc -c 3 $ echo -n `echo -ne 000`|wc -c 0 BASH_VERSION='3.1.0(1)-release' At least the echo docs should say so. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
"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 Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 who get to effectively save its history, overwriting that of the earlier exiting shell? Will setting histappend allow one to merge the two? Say if this is the case. Also where the man page mentions truncating the HISTFILE, one thinks of the bottom of the file getting truncated, when it is in fact the top. Mention this. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 my screen for me to copy." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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: Installed: 1:3.2.6-2.2 still looks a mess: Name Num ActionDescription () ()#very long wrapped line 0 0 n/a exit code indicates if a signal may be sent ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 http://lists.gnu.org/mailman/listinfo/bug-bash
set -e vs. !
$ cat t.sh set -ex ! true #should stop here but doesn't!?! ! false true false : already quit $ bash t.sh + true + false + true + false $ pdksh t.sh + true $ dash t.sh + true + false + true + false ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
${//}: say how to non-destructively prefix/suffix
Regarding the
${parameter/pattern/string}
${parameter//pattern/string}
discussion on the man page:
You don't mention what if pattern is null.
Seems that will never match.
Anyway, no way to
$ set aa bb cc
$ echo [EMAIL PROTECTED]
so that one gets all parameters to have a string appended,
e.g. aa.t bb.t cc.t
One must sacrifice at least one character in "pattern". No way to
destroy less than one character.
One must do
$ ls|sed s/$/.t/|xargs make -n
as there is no pure bash single shortcut to eliminate the pipes.
Brace Expansion not employable here either.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
need \:
Not sure if there is much that can be done here. The user needs to know to enter \: instead of : which causes him to just see the files in $PWD. Wait, is needing a \ reasonable? $ man /usr/share/man/man3/XBase XBase.3pm.gz XBase::Index.3pm.gz XBaseFontNameListOfFontSet.3.gz XBase::Base.3pm.gz XBase::Memo.3pm.gz XBase::FAQ.3pm.gzXBase::SDBM.3pm.gz $ man /usr/share/man/man3/XBase: FAQ.gz README.Debian changelog.Debian.gz driver_characteristics.gz README ToDo copyright examples/ $ man /usr/share/man/man3/XBase\: XBase::Base.3pm.gz XBase::FAQ.3pm.gzXBase::Index.3pm.gz XBase::Memo.3pm.gz XBase::SDBM.3pm.gz $ man /usr/share/man/man3/XBase\:\: ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
disown, unlike fg, can't realize current job
How inconvenient, disown, unlike fg, can't realize the current job or whatever: $ sleep 111& [1] 7125 $ sleep 222& [2] 7126 $ disown $ disown bash: disown: current: no such job $ jobs [1]- Running sleep 111 & $ disown %1 $ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 JOBSPEC argument from the table of active jobs. If the -h option is given, the job is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP. The -a option, when JOBSPEC is not supplied, means to remove all jobs from the job table; the -r option means to remove only running jobs. But you don't mention what should happen if given no arguments! I thought it would delete the last job but it instead had different ideas this time. Certainly in the past I only had experience with one job. OK, must always use jobspec to be sure. Also pstree shows job 1 still alive. There should be a command to somehow reattach it. That was a big blow. No way to get back into my su session. Also, on the man page also please add the word JOBSPECS here: JOBSPECS There are a number of ways to refer to a job in the shell. The character % intro- duces a job name. Job number n may be referred to as %n. A job may also be referred to using a prefix of the name used to start it, or using a substring that appears in Else it is very hard to find where the definition of jobspec, so often talked about on the man page, is. Anyway, I was looking for a sure fire way to do $ bla& disown and always disown bla. But it seems I will have to do $ bla& disown %bla or how does one guarantee no mishaps? disown %what not hardwiring bla? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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... $ man kill mentions to see also the shell's builtin, but bash doesn't return the favor. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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 signal the parent to bomb out? echo never got here
cannot execute binary file
Perhaps it's about time to fix this? $ head -1 one_time_job wget --spider -Y off -S http://www.ham.com.tw/ctarl/940524-940604衛生署公文.jpg $ sh -n one_time_job one_time_job: one_time_job: cannot execute binary file $ bash --version GNU bash, version 3.00.16(1)-release (i386-pc-linux-gnu) Workaround: add a blank line at top of the file. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
ESC t not ready for Chinese
If I put the cursor between the last two items,
$ search 鼓山 福州
and type ESC t, I get
$ s 福州 鼓山earch
Whereas in real emacs, I correctly get
$ search 福州 鼓山
P.S., Here are the items again in case this mail gets mangled
$ echo search 鼓山 福州|qp-encode
search =B9=AA=A4s =BA=D6=A6{
$ set
BASH_VERSION='3.00.16(1)-release'
HISTIGNORE='&:bg:fg'
LANG=zh_TW.Big5
LC_COLLATE=C
LC_CTYPE=zh_TW.Big5
LC_MESSAGES=C
SHELLOPTS=braceexpand:emacs:hashall:ignoreeof:interactive-comments:monitor:noclobber:notify
TERM=rxvt
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
wait: mention PID must be a child of this shell
$ help wait doesn't mention that PID must be a child of this shell. Nor does it advise how to wait if PID is not a child of this shell. User wanted to do noffle --f & (wait $!; noffle -f) & for better or worse. User forced to use (noffle -f; noffle -f)& ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
add PS1 to messages?
Not sure if there is any fix for this. When sending messages like "Terminated" to the terminal, maybe also send a PS1, if indeed we are in prompt waiting foreground mode or whatever. Don't just leave the users cursor parked at column 1: # PS1="# " # sleep 33& [1] 3355 # killall sleep # [1]+ Terminated sleep 33 jobs # ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
${p+\"$p\"}
So how am I to get "A" with bash? $ cat z p=A cat <
$ < 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'
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"). 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 .. (comint-insert-previous-argument INDEX) Insert the INDEXth argument from the previous Comint command-line at point. Spaces are added at beginning and/or end of the inserted string if necessary to ensure that it's separated from adjacent arguments. Interactively, if no prefix argument is given, the last argument is inserted. Repeated interactive invocations will cycle through the same argument from progressively earlier commands (using the value of INDEX specified with the first command). This command is like `M-.' in bash.
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- tions, point refers to the current cursor position, and mark refers to a cursor position saved by the set-mark command. The text between the point and mark is referred to as the region. please mention "There is no way to run any of the commands that are not bound to a keyboard sequence without binding them to a keyboard sequence." http://unix.stackexchange.com/questions/52578/execute-a-readline-function-without-keybinding Yes that is right, just to run e.g., dump-variables Print all of the settable readline variables and their values to the readline output stream. If a numeric argument is supplied, the output is formatted in such a way that it can be made part of an inputrc file. once, one has to bind it to a key. Why can't there be some $ run_readline_command dump-variables
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 grep the typescript. Or one must be in X-windows, bind the key, and the copy the output of pushing the bound key into a file, and the grep that. So my proposal would save a rather large amount of work this time. (No, don't really call it exactly run_readline_command.)
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: "\t %s", >>> unless perhaps the spec says that %s always starts with a space. >> The standard doesn't say that, so in native mode bash's `fc' is >> indeed slightly nonconformant, but in POSIX mode it does omit the >> extra space. CR> That character is a `*' if the line has been modified (has an existing CR> set of edits to undo) and ` ' if not. This is what `history' does. Ah ha! Therefore I would recommend changing this part of the Bash man page, history -s arg [arg ...] With no options, display the command history list with line num- bers. Lines listed with a * have been modified. to say history -s arg [arg ...] With no options, display the command history list. Each line consists of a line number, then a * if the line has been modified, else a blank. Then a blank, then a timestamp, then a blank, then the command. Or maybe history -s arg [arg ...] With no options, display the command history list, in the following printf format: "%5d %s %s %s", $number, $modified, $timestamp, $command, where $modified is "*" if modified, " " if not. Well something like that. Helps people who are parsing history.
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 sh -x. By the way, I looked up and down the man page, and wasn't sure if it says one should expect $c to end up as c= or c=b in fact! And I'm not sure the man page says to expect two lines or one of -x output either, when using sh vs. bash.
Poor messages when the '#!' file isn't found
$ 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 worse. Can't make more confusing messages than that one. Yes, $ ls /usr/bin/python* /usr/bin/python3 /usr/bin/python3.11 but that's not the point.
history -f filename
$ 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 history -anrw [filename] or history -ps arg [arg...] So if one wants to use a filename, then one needs to use -anrw (-[anrw]). So maybe a new -f is needed: $ history -f filename to simply read from filename.
Re: history -f filename
$ 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 35312 /home/jidanni/.bash_history_jidanni-emacs We see for simple $ history output, there's no way to change the file it reads, at least with the current (same PID) shell. > "CR" == Chet Ramey writes: CR> Use `history -r'? That would change files (by more than just one line). All I want is a read-only operation. CR> Because those are the options that act on the history file. The rest act CR> on the in-memory history list. >> So maybe a new -f is needed: >> $ history -f filename >> to simply read from filename. CR> What exactly would this do? It would do just like plain $ history but instead of reading from the in memory list, (which is about the same as $HISTFILE + or - one line) it would read from the given file.
Document variable names need to be all ASCII
$ 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 name=value PARAMETERS A parameter is an entity that stores values. It can be a name, a num‐ ber, or one of the special characters listed below under Special Param‐ eters. A variable is a parameter denoted by a name. A variable has ...
Document that set -v inside case statements is special
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 ;; esac : C $ bash A : C I.e., -v and +v in case statements are remembered, but only have effects after leaving all case statements. Unlike +x, -x. Same it turns out for dash(1). Bash 5.1.4.
"command" help page
$ 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 when you say "description" one expects something like: $ man cat | col -b | grep -A 1 -i description DESCRIPTION Concatenate FILE(s) to standard output.
help for needs to mention for ((...))
$ 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
Re: help for needs to mention for ((...))
OK, then "help for" should at least mention that trick to get the rest of the story.
Re: help for needs to mention for ((...))
$ 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.
Re: help for needs to mention for ((...))
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; done
function: function name { COMMANDS ; } or name () { COMMANDS ; }
the function name is 'for (('
not 'for (( ))' etc.
Great.
Document -x and -vx give the same results
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
Re: Document -x and -vx give the same results
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* buffer.
>| expansion assumes | rules instead of > rules
# 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)
'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' format? Well, it would be nice to have it ask instead Display all 132 possibilities? (y, n, or t) But wait, what if there are not so many completions to trigger the question? (Well, in that case one could say that alphabetical order is OK as it isn't that difficult to find what one is looking for among so few items.) Anyway, one might remove "in alphabetical order" from print-completions-horizontally (Off) If set to On, readline will display completions with matches sorted horizontally in alphabetical order, rather than down the screen. as in the future that might not always be the case! Anyway, in addition to t for time, there could be r for reverse. (But no rt or tr as it should act on the first character it reads.)
Re: expand x*y concludes with one
OK I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865875 against bash-completion.
ulimit -c unlimited
$ 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.
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 $ ulimit -c 999 bash: ulimit: 999: limit out of range Hmmm, maybe make the above error message say what the range is, so the user doesn't have to probe it. Or say "do ... to see the valid range". $ ulimit -c 9 bash: ulimit: core file size: cannot modify limit: Operation not permitted $ ulimit -c 99 bash: ulimit: core file size: cannot modify limit: Operation not permitted $ ulimit -c 99 bash: ulimit: core file size: cannot modify limit: Operation not permitted By this time the user has probably given up... thinking that it isn't the value that is the problem, but the basic Operation. (But if he probes further, indeed some values work.) $ ulimit -c 99 $ ulimit -c 999 bash: ulimit: core file size: cannot modify limit: Operation not permitted Odd, a little later I try $ ulimit -c 99 bash: ulimit: core file size: cannot modify limit: Operation not permitted > "R" == Reuti writes: R> Do you get this as root too? I'm just trying to say the messages are confusing for the normal user. I don't want make my report too big, so am not trying it for root. R> If the hard limit is unlimited, then you can raise the soft limit R> again also as normal user to be unlimited. So the statement "Operation R> not permitted" is correct, although it means: "can't raise hard limit R> again" as without -S or -H it sets both limits. The soft limit OTOH R> can be changed between a value and unlimited as often as you like, as R> the long as the hard limit stays to be set to unlimited. Hmmm...Wait... I was using "help ulimit", now I see on the bash man page The -H and -S options specify that the hard or soft limit is set for the given resource. A hard limit cannot be increased by a non-root user once it is set; a soft limit may be increased up to the value of the hard limit. So maybe that explains why the user can only set it once (99 above) then cannot change it... OK I recommend the "help ulimit" now say [-S|-H] -aall current limits are reported [-S|-H] -bthe socket buffer size [-S|-H] -cthe maximum size of core files created [-S|-H] -dthe maximum size of a process's data segment [-S|-H] -ethe maximum scheduling priority (`nice') [-S|-H] -fthe maximum size of files written by the shell and its children and perhaps the same on the bash man page.
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...
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.
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 not asking for help. I am saying $ help complete should mention more things.
Re: variables not TAB expanded except in first position
OK submitted https://github.com/scop/bash-completion/issues/173
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.
