bash should consult .config/bash/...
Maybe on the list of config files bash looks at, there should be also .config/bash/... as that is the trend these days...
let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND
Gentlemen, I have once again come up with a million dollar idea for bash, revolutionizing the shell world. As we all know, nobody in their right mind could type more than one command per second into bash when in interactive mode. So let's establish BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND=1.0 Any faster than that means the user has once again by accident pasted wads and wads of some essay into bash! Bash should simply print error message(s) and _not add those lines to history_. Voila, the damage is limited to just the first line being interpreted, instead of feeding your (even root) shell all 1000 lines of random junk! Sure, the default could be BASH_MINIMUM_TIME_BETWEEN_INTERACTIVE_COMMAND=0 so it still could be available just for users that need it (badly like me.)
Re: can't just hold down ^K to clean up history
On Thu, Oct 17, 2013 at 07:54:47AM -0400, Chet Ramey wrote: It's the difference between a line-oriented command editing tool and a screen editor. Well, it could go that extra mile, as a extra bonus, since it is usually doing nothing better (well most commands are all on one line), to let us automatically start killing the next items lines after we are finished with the current ones. Further proof: do a ^Ra^R^R^R^R . Notice how say three hits are on this line, one on the next, two on the next next etc. So we are allowed horizontal as well as vertical movement...
can't just hold down ^K to clean up history
Let's say one accidentally pastes a many lines of some email into a bash window. Yes bash tries to execute each line. Can't blame it. But now we are faced with cleaning the mess out of history. We use ^P^P^P^P^P^P^P... to finally get to the top of the mess. Then we must use ^K^N^K^N^K^N^K^N^K^N^K^N... to clean it up. However this leaves many blank lines in history! Also why can't we just hold down ^K^K^K^K^K^K^K^K^K ?
Re: can't just hold down ^K to clean up history
Also why can't we just hold down ^K^K^K^K^K^K^K^K^K ? CD Why do you expect to be able to do that? C-k in readline deletes to the end of CD the current line. There's no reason why it should also get the next line. Ah ha, but there is also no reason why it should not! I hereby propose that it should. Let's compare emacs, kill-line is an interactive compiled Lisp function in `simple.el'. It is bound to C-k, deleteline. (kill-line optional ARG) Kill the rest of the current line; if no nonblanks there, kill thru newline... To kill a whole line, when point is not at the beginning, type C-a C-k C-k. If option `kill-whole-line' is non-nil, then this command kills the whole line including its terminating newline, when used at the beginning of a line with no argument. As a consequence, you can always kill a whole line by typing C-a C-k. and kill-whole-line is a variable defined in `simple.el'. Its value is t Original value was nil Documentation: If non-nil, `kill-line' with no arg at start of line kills the whole line. Anyway, this all boils down to holding down the ^K for rapid munching of more than one line, please. Yes, ^P still needed, Greg, but one could fix up the mess totally via the keyboard, with no need for risky file maneuvers.
Re: noclobber vs command not found
GW == Greg Wooledge wool...@eeg.ccf.org writes: GW I find tab completion to be a primary safeguard Yes but in this case I am merely obediently copying the whole line with my mouse and stuffing it into the shell. Thanks anyway though.
noclobber vs command not found
Hello noclobber fans. It was a cheery day, until during an aptitude safe-upgrade, Processing triggers for hicolor-icon-theme ... (gtk-update-icon-cache:13613): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory This likely means that your installation is broken. Try running the command #OH NO they forgot to mention the full path! gdk-pixbuf-query-loaders /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache to make things work again for the time being. So ever obedient, I do # gdk-pixbuf-query-loaders /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache bash: /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache: cannot overwrite existing file # gdk-pixbuf-query-loaders | /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache bash: gdk-pixbuf-query-loaders: command not found Now you can guess the feeling: Why didn't it (bash) tell me in the first place (first line) before I destroyed the file? It (bash) was already talking to me on the first line, goading me along, things were looking good, and then like the O'Jays Backstabbers song, whammo there on the second line. A sucker punch! So, I know it is not in the traditional order of operations, but you might consider telling the user somehow, oh and by the way...'.
don't just seek to the next line if the script has been edited
Let's say you are running a script that is doing a loop while ... echo Enter name; read name; .. During which the script gets edited on the disk by somebody. Well shouldn't bash, when it goes back to the disk to read some next part of the script, first do some sort of check to tell if the script has changed on disk, instead of the current behavior which apparently is to seek() to the former byte number and execute the next line which now very well might be halfway lodged inside some comment or something.
Re: don't just seek to the next line if the script has been edited
Well OK but sometimes a script could be running for years, during which any change to a file will result in bash executing random bytes... Imagine if you press down on the mouse button meanwhile someone moves the screen up or down... you end up pressing on a different person's face. So I don't see any case where allowing this adds any value to bash. In fact I don't recall any other program with such scary behavior. I mean it's fine with me if bash will execute my script version 1, or my script version 2, but not some mishmosh of random bytes. Surely a little itty bitty check can't slow things that much down. So if I were bash I would bail out $0 changed on disk. Bailing out rather than executing random bytes.
Re: don't just seek to the next line if the script has been edited
GW == Greg Wooledge wool...@eeg.ccf.org writes: GW On Fri, Jun 07, 2013 at 09:09:53PM +0800, jida...@jidanni.org wrote: Well OK but sometimes a script could be running for years, during which any change to a file will result in bash executing random bytes... GW This is why you don't edit an installed script in-place. Instead, you GW move it aside, or remove it, or hardlink it, or do some other fancy thing. Well it is going to happen anyway, so maybe bash should check by default, and not check if -o risky is set or something. It can't be that expensive.
Re: don't just seek to the next line if the script has been edited
CR == Chet Ramey chet.ra...@case.edu writes: CR I think the correct solution is to retain this behavior where it is CR required (e.g., when reading a script from the standard input) and to CR discard it when reading a script from a file. This doesn't directly CR address the jidanni's concern, but I think the actual occurrence of this CR problem is infrequent enough to not do anything more elaborate. All I know is there I am in emacs seeing things in the output of a running bash script that I want to tweak and get busy tweaking and saving changes before the script finishes, thinking that all this stuff will be effective on the next run of it, when lo and behold now it begins executing random bytes... Yes one can say that these are not C programs and one needs to revise ones expectations, but still I think some parental safety cap is required to keep it from munching random bytes which will always be wrong... such overly dynamic-ness can never be a feature and always be a wild incident unless one gets the alignment just right etc. etc. Anyway my problem is always for scripts on disk and not for the stdin case so maybe I'm covered by the coming changes.
variables vs. TAB
$ mkdir /tmp/some_dir $ touch /tmp/some_dir/file $ a=/tmp $ cat $a/someTAB /tmp/someTAB Note how the former TAB just gives $a/some_dirSPACEBUG! Which SPACE one must replace with a / by hand to continue expanding like the latter. Whilst the latter gives /tmp/some_dir/ correctly. bash: Installed: 4.2-5 Indeed, $ aaa=/tmp $ $aaaTAB also gives the bad behavior. It's as if it never occurred to the authors these might be directories.
Why does -v not work until after } in scripts?
Why does -v not work until after } in this script?
# su - nobody
No directory, logging in with HOME=/
$ cat /tmp/o
{
set -v
# NO STDERR
}
# YES STDERR
$ sh /tmp/o
# YES STDERR
bash:
Installed: 4.2-4
Re: Why does -v not work until after } in scripts?
Well -x works right away, but -v gets stuck until all depths of nested { } are
over with.
Display all 224 possibilities? (y,n,t,?,...)
Dudes! I've got a brilliant idea. Instead of just saying Display all 224 possibilities? (y or n) Why not also offer more, like (y,n,t,?) Add t where t is by time as in 'ls -t', and ? is to explain them all. While you are at it, why not add even more, all from ls. l = ls -l etc. And what about -rt... how to pack that into one character though? Ah, add - which then can accept more characters until they hit RET. Yes, another brilliant idea, from yours truly, http://www.youtube.com/watch?v=lQ57rtIv7kklist=PL6E40919035151385
error messages should spit back out UTF-8
$ LC_ALL=zh_TW.UTF-8 $ 哼 bash: $'\345\223\274'：命令找不到 It really should spit out what it was given, not octal.
protection against accidental massive pastes into the command line
Maybe there should be a limit, MAX_INTERACTIVE_COMMAND_LENGTH on how much can be fed into one bash command line, any more and bash should beep and reject the whole command. Otherwise an innocent middle click, or SHIFT INSERT slip of the fingers could paste an entire book out of the clipboard, into the command line, which would then cause bash to try to execute every line.
Re: protection against accidental massive pastes into the command line
This would also save on later having to clean the massive blob out of the history list.
let's set the positional parameters with a simple 'read'
One can do $ read p to set $p but no just as easy method to set $@, $1, etc. One must do $ set -- `cat` #which involves ^D, too much trouble Or set -- `read x; echo $x` etc. No, nothing as easy as $ read 1 sds bash: read: `1': not a valid identifier $ read @ sdss bash: read: `@': not a valid identifier Regretful. How about just $ set -- sds you say. Well that won't work as good as $ read x http://www.youtube.com/watch?v=PLTOc2TVAs8list=PL54881C422E6B58FC $ When one is pasting URLs with the mouse, and they contain special characters. Yes one could do $ set 'PASTE' but that is a little more fuss. So I propose we 'wreck the language' to allow me to do $ read @ to set $@, same with 1, 2,.. * (almost the same as @).
Re: let's set the positional parameters with a simple 'read'
GW == Greg Wooledge wool...@eeg.ccf.org writes: GW Why not just use a named array? GW $ read -a myarray But does that let me get a my favorite array, the positional parameters?
Re: let's set the positional parameters with a simple 'read'
Hmmm, as S. CHAZELAS said seems zsh also gives one a chance to reset an
arbitrary positional parameter, e.g., the 42nd, whereas in bash one must
set them all at once:
$ set `seq 55`
$ echo $42
42
$ echo $66
66
:-)
Anyway isn't it rather old fashioned not to be able to somehow reset
${42} without needing to tamper with the rest?
TAB vs. colon
The user pastes this into his shell window and adds uTAB $ ls /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/uTAB Any point in making him painfully go back and put backslashes behind each colon before expansion works (giving .../BAT0/uevent)?
Re: TAB vs. colon
JS == Jon Seymour jon.seym...@gmail.com writes: JS You mean apart from the obvious that perhaps the user's intent was to JS paste unescaped colons into the command line at that point? In any JS case, paste is a function of the terminal, not the shell. I'm saying normally when we build a path, we enter several TABS in the process, and the \: \: stuff gets added for us, so no problem. But sometime we don't type in the path by hand, but instead paste it in from elsewhere via the mouse or something. In this case we have to painfully add the \ \ stuff by hand before any TAB expansion works.
Re: TAB vs. colon
GH == Geir Hauge geir.ha...@gmail.com writes: GH A workaround would be to quote the path. E.g. instead of GH ls pasteutab GH do GH ls 'paste'utab KoOl! It's a deal and I withdraw my case. Let's just hope this tip is documented.
document factors influencing select's number of columns
The 'select' documentation should also document the perhaps complex way $LINES $COLUMNS the number of items the length of the longest item interact to determine if the items will be displayed in rows/columns, etc.
Re: set -m +m -x and the element of chance or is it race conditions?
CR == Chet Ramey chet.ra...@case.edu writes: CR Is it a problem? Bash prints messages about signal-terminated processes -- CR at least those that don't die due to SIGINT or SIGPIPE -- when the CR shell is not interactive. Most people want to know when their jobs die CR and their scripts fail. But some don't, but also don't want to do exec 2/dev/null and take other messages to the grave with it. Plus it isn't documented, depends on having e.g., sleep 0 after it, and in general looks like one big hack. And violates the set +mb promise! CR (And, by the way, historical versions of sh did the same thing.) But not the oldest. OK, never mind, I'll just do sleep 11 kill -INT $! sleep 0 However you might want to document it there on the bash man page. There is a lot about SIGINT, but not this.
Re: set -m +m -x and the element of chance or is it race conditions?
Don't forget to mention that there better be e.g., at least a sleep 0 after it, if they want to be sure to see the message.
Re: set -m +m -x and the element of chance or is it race conditions?
CR == Chet Ramey chet.ra...@case.edu writes: CR Is everything you don't like that's not explicitly documented a bug? In CR any case, a little thought should tell you why having the shell stick CR around long enough to catch the child's death makes a difference. With me you can exclude the concept of thought. Never had, never will. Therefore we need hard details on the man page. E.g., make sure there is at least a /bin/echo, or better yet sleep 0 after your command, not just a ':' or echo, or else the shell might finish too quick to see the message. To always not see the message, kill(1) with -SIG... CR And what is the `set +mb promise'? OK, I thought those messages had to do with job control.
Re: set -m +m -x and the element of chance or is it race conditions?
I isolated the problem and submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611417 which I forget to X-Debbugs-cc to bash-...@gnu.org, which I should have, as it probably is a upstream problem that only the bash authors can fix.
Re: set -m +m -x and the element of chance or is it race conditions?
Thanks Greg, but aren't I acting by the rules? $ cat l set +m sleep 44 kill $! $ for i in `seq 33`; do bash -xm l; done Which gives + kill 5256 + set +m + kill 5258 + set +m + kill 5260 l: line 4: 5260 Terminated sleep 44 + set +m + kill 5262 + set +m + kill 5264 + set +m I.e., one out of the 33 cases produced the Terminated message on my one test run. Why must set -m; set +m cause a race condition? P.S., $ wc -l l 3 So line 4 is wrong too.
Re: set -m +m -x and the element of chance or is it race conditions?
GW == Greg Wooledge wool...@eeg.ccf.org writes:
GW You used seq, so you're clearly doing it on Linux. Maybe it's an
GW OS-specific thing?
Package: bash
Version: 4.1-3
Debian Release: 6.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages bash depends on:
ii base-files6.0Debian base system miscellaneous f
ii dash 0.5.6.1-1~exp0 POSIX-compliant shell
ii debianutils 3.4.3 Miscellaneous utilities specific t
ii libc6 2.11.2-9 Embedded GNU C Library: Shared lib
ii libncurses5 5.7+20100313-5 shared libraries for terminal hand
I note it doesn't happen when su'ed to user nobody. Nor when using 'do
sh', nor is it easy to find if one sends it to a pipe. Also it takes
several tries to get. Now adding -p, to exclude any $ENV.
$ cat u
echo $-
set +mbi
sleep 44
kill $!
$ for i in {1..10}; do bash -xpm u; done
Around run #5 gave
+ set +mbi
+ kill 10471
u: line 5: 10471 Terminated sleep 44
I.e., one out of ten gave the message. Then several more runs of the
above line didn't.
set -m +m -x and the element of chance or is it race conditions?
Gentlemen, I am disturbed by these seemingly irregular results,
# perl -pwle 's/\d{4}//' mm|sort|uniq -c
88 ++ kill
44 ++ set +m
44 ++ set -m
1 ++ sleep 33
2 ++ sleep 66
1 ./rt: line 12: Terminated sleep 33
1 ./rt: line 12: Terminated sleep 44
1 ./rt: line 13: Terminated sleep 33
1 ./rt: line 13: Terminated sleep 44
1 ./rt: line 13: Terminated sleep 55
3 ./rt: line 14: Terminated sleep 33
3 ./rt: line 14: Terminated sleep 44
3 ./rt: line 14: Terminated sleep 55
from running my program
# cat rt
set -x
set -m
sleep 33
kill $!
set +m
sleep 44
kill $!
sleep 55
set -m
kill $!
sleep 66
set +m
kill $!
# for i in `seq 22`; do ./rt; done 2 mm
We see some of the sleeps are reported some of the time, and on what
line something was terminated differs too. Also didn't I run it 22
times? Why do some things show up only a couple times instead of all or
none?
P.S., on the man page
-m Monitor mode. Job control is enabled. This option is on
by default for interactive shells on systems that
support it (see JOB CONTROL above). Background
processes run in a separate process group and a
line containing their exit status is printed upon
their completion.
Perhaps mention if what happens if this is turned on or off after
starting the job but before its completion.
reveal matched chars before asking Display all possibilities, not after
Here only after I say 'n' is it revealed to me that I have already completed /func, not just /fu: $ w3m /usr/share/doc/php-doc/html/fuTAB Display all 5361 possibilities? (y or n) n $ w3m /usr/share/doc/php-doc/html/func Therefore, please make bash, upon receiving a TAB, first add all the additional matching characters it knows about, before asking us the question. Here's the whole sequence: 1 $ w3m /usr/share/doc/php-doc/html/fTAB 2 Display all 5486 possibilities? (y or n) n 3 $ w3m /usr/share/doc/php-doc/html/fuTAB ---this u added by me 4 Display all 5361 possibilities? (y or n) 5 $ w3m /usr/share/doc/php-doc/html/func---this nc added by bash I want bash to add the nc at line 3 after I hit TAB, instead of waiting till line 5. This is clearly no skin off bash's back and a bug in that bash is not coughing up all the info it knows at the right time. Version 4.1-3 0
backslash required for [\/]
I have discovered yet another bug in your bash program.
First we see how a normal program, trusty sed, deals with [ ]:
$ r=abaab; echo $r|sed 's/[:?/ba]/u/g'
u
Now we try bash:
$ r=abaab; echo ${r//[:?/ba]/u}
abaab
$ r=abaab; echo ${r//[:?\/ba]/u}
u
Observe how a backslash is required, else the program doesn't fire.
It's as if it is totally unaware that it is already inside the [ ].
And if the backslash was really required, then why doesn't it blow up
if we remove it?
While we are here, here's another interesting phenomena,
$ touch aa
$ echo a[ab]
aa
$ echo a[ab/]
a[ab/]
$ echo a[ab\/]
a[ab/]
$ mkdir ab #doesn't help...
Re: quotes invade positional parameters
Indeed, it is more compact to report ' a' than \ \ \ \ \ \ \ \ \ \ a OK OK... see you next bug.
quotes invade positional parameters
WITNESS for yourselves as the quotes invade the parameters, absconding with the ones at the edges, when close enough. $ cat 201012contract #!/bin/sh -eux set a b c d e f : ''$@'' : ' '$@' ' : ''$*'' : '' $* '' : $* $ ./201012contract + set a b c d e f + : a b c d e f + : ' a' b c d e 'f ' + : 'a' b c d e 'f' + : '' a b c d e f '' + : ' a' b c d e f ' ' $ apt-show-versions bash bash/unstable uptodate 4.1-3 OK, the problem may only be -x deep, affecting the -x reporting output, but not the actual functionality, thank G.O.D.
Re: quotes invade positional parameters
JS == Jan Schampera jan.schamp...@web.de writes: JS I'd say this is expected (and by the way it's not only on set -x). I see. The spaces indeed get glued to the sides. OK, see ya next time.
Re: quotes invade positional parameters
Well anyway, it would be 'no skin off of bash's back' if it just reported what it was given. If it was given ' 'a b c it should report ' 'a b c and not just 'assume' we prefer ' a' b c or ' a' 'b' 'c' etc. Just as legitimate and doesn't cause calls in the middle of the night from the old folks home. Wait, that stage of the program doesn't know it was given that, and to make it know would just increase complexity. As would reporting \ \ a b c or would it... OK, never mind.
document $MAIL for Maildir users
man page says MAIL If this parameter is set to a file name and the MAILPATH variable is not set, bash informs the user of the arrival of mail in the specified file. OK, but also mention one can set it to a directory. And say that MAIL=$HOME/Maildir/ is what Maildir users should use.
[Qq] vs TAB
BASH_VERSION='4.1.5(1)-release' $ ls /cf/20100428xindianS* /cf/20100428xindianSQUARE.jpg /cf/20100428xindianSquare2.jpg $ xli /cf/20100428xindianS[Qq]TAB #shows nothing. Wrong. $ xli /cf/20100428xindianS[Qq]*TAB #shows the files, but then eats the [Qq]* 20100428xindianSQUARE.jpg 20100428xindianSquare2.jpg $ xli /cf/20100428xindianS #leaving just this. I reported something similar recently.
^K should go to next history item
^P^P^P^P^K^K^K^K or at least ^P^P^P^P^A^K^A^K^A^K^A^K should kill each line out of the history. Instead we need to do more steps: ^P^P^P^P^A^K^N^A^K^N^A^K^N^A^K .
Re: completion gobbles partial match string
CR Should readline do this only if there are multiple matches? Getting over my head... I'll trust your judgment.
completion gobbles partial match string
Put the cursor after the word list and hit TAB: # find /etc/apt/sources.list.d/*list #|cpio -o|ssh 192.168.44.4 cpio -ivdm Emacssources.list eeepc.list tw.list # find /etc/apt/sources.list.d/ #|cpio -o|ssh 192.168.44.4 cpio -ivdm Notice how we are shown the completions, but then the *list has been gobbled up! BASH_VERSION='4.1.5(1)-release'
Re: completion gobbles partial match string
CR == Chet Ramey chet.ra...@case.edu writes: CR I have to assume that you're using programmable completion, CR and the compspec for `find' doesn't impose the same restriction. Same happens with cat or :, not only find. It doesn't happen for # su - nobody And I've isolated the problem to somewhere in this chunk of $INPUTRC: set history-preserve-point on set visible-stats on set show-all-if-ambiguous on set meta-flag on set convert-meta off set input-meta on set output-meta on
allow printing completions vertically
We read print-completions-horizontally (Off) If set to On, readline will display completions with matches sorted horizontally in alphabetical order, rather than down the screen. Maybe the above variable is mainly talking about sorting order, in which case it is unfortunately named... because what I want is upon me typing: $ ls /var/cache/apt/archives/xdm_1%3a1.1.TAB instead of the current: xdm_1%3a1.1.8-6_i386.deb xdm_1%3a1.1.9-1_i386.deb xdm_1%3a1.1.9-2_i386.deb I want to see: xdm_1%3a1.1.8-6_i386.deb xdm_1%3a1.1.9-1_i386.deb xdm_1%3a1.1.9-2_i386.deb Which you will have to admit is 10 times easier on the eyes and brain to sort out. Yes, there are just three matches in this case. We see COLUMNS Used by the select builtin command to determine the terminal width when printing selection lists. Automatically set upon receipt of a SIGWINCH. says it only is used by select, not what we're interested in. And even if it was, we don't want to affect other programs too with COLUMNS (which we export COLUMNS=80 mostly.)
mention bind commands too
On man bash _kindly_ mention there is indeed a way to use the following, with no further ado, by adding the stuff in parentheses: dump-functions (bind -P) Print all... dump-variables (bind -V) Print all... dump-macros (bind -S) Print all... Otherwise we almost thought we had to make a binding just to run them once. (Yes, a lawyer could figure out the answers from reading the whole man page twice.)
match-hidden-files docstring
We read match-hidden-files (On) This variable, when set to On, causes readline to match files whose names begin with a `.' (hidden files) when performing filename completion, unless the leading `.' is supplied by the user in the filename to be completed. Don't you mean match-hidden-files (On) This variable, when set to On, causes readline to match files whose names begin with a `.' (hidden files) when performing filename completion. **Otherwise the leading `.' must be supplied by the user**.
~/.inputrc syntax errors not reported to the user
In ~/.inputrc I put the following syntax error sdsddd sdsds and save the file and run re-read-init-file (C-x C-r). No error is reported to me.
are you sure you want to add all the ! stuff to the history?
Are you sure you want to add all the ! stuff to the history? $ mail root ! (then I pasted a big blob here) ! $ To my surprise ^P showed the big blob too. (I didn't just use $ mail root because then it would ask me Cc:, Subject:)
have bg, fg, but lack stop
Notice how I need two steps to stop this running job: $ jobs [1]+ Running firefox $ fg firefox ^Z [1]+ Stopped firefox As there is no $ stop %1 like command. OK, I suppose I can use $ kill -s SIGSTOP %1 $ [1]+ Stopped firefox OK, never mind. Market demand too low to add...
want a M-. that ignores C-r
Same question for years: Want some way for M-. to get the last item, regardless of if we are here via a C-r or not. I want some dumber-downed version of M-., however at the same time I don't want to use that cshell ! stuff. I want something I can bind to M-.. Thanks.
Re: ESC SPC please
PG maybe try the following macro: PG bind '\M- :\M-\\ ' Sorry, that doesn't work on the command line or .inputrc. No effect.
cd $x; rmdir $x; mkdir $x; ...
Yes, this all is probably expected, but I'll post it here anyway, just in case. $ mkdir /tmp/n $ cd /tmp/n $ rmdir /tmp/n $ mkdir /tmp/n $ pwd /tmp/n $ touch k touch: cannot touch `k': No such file or directory $ touch /tmp/n/k $ dash sh: getcwd() failed: No such file or directory $ pwd $ exit $ bash shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory $ pwd pwd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory $ exit $ ls . $ ls -l total 0 $ ls -la total 0 $ ls -la . total 0 $ ls -la $PWD total 0 drwxr-xr-x 2 jidanni jidanni 60 2009-09-12 01:55 . drwxrwxrwt 9 rootroot440 2009-09-12 01:55 .. -rw-r--r-- 1 jidanni jidanni 0 2009-09-12 01:55 k
Re: history --no-numbers-please
CR == Chet Ramey chet.ra...@case.edu writes: $ history needs a --no-numbers-please option (-u maybe?), as I can't recall when I didn't run the output through sed to get rid of them. CR Why not just use fc -ln? Because help history didn't tip me off that I could try that. However $ history|wc -l $ fc -ln|wc -l 16 reveals that fc has absconded with -16 lines, and there is no mention on help fc where they went. OK, one sees on the bash man page that there are ways to get more lines. But the onus is on the bash author to add a --no-numbers-please one letter option just like he has to fc, as any other solution is more work than just using sed... (and now that everything else is fixed and we can quibble about minor issues :-) ). By the way, type $ history|false|less or history|true|less then type q [1]+ Stopped history | false | less Weird. Doesn't happen with $ date|false|less
history --no-numbers-please
$ history needs a --no-numbers-please option (-u maybe?), as I can't recall when I didn't run the output through sed to get rid of them.
line up completions vertically
You know how it shows us the choices when we hit TAB, # rm /var/tmp/dan_home_bkp2009-07-26-02-TAB dan_home_bkp2009-07-26-02-18-36.bz2 dan_home_bkp2009-07-26-02-27-07.bz2 Well given that we are not going to bother to make the differing endings bold, like in emacs, well, at least we can line them up vertically, dan_home_bkp2009-07-26-02-18-36.bz2 dan_home_bkp2009-07-26-02-27-07.bz2 so the eye can get a better comparison of just where they differ.
showing expansion bifurcation point better
When showing choices, $ ls /cf/124451TAB 1244516986.31615_0.ps11007 1244517019.1029_0.ps11007 maybe indicate the bifurcation point with termcap bold, like emacs, or with a pipe: 124451|6986.31615_0.ps11007 124451|7019.1029_0.ps11007 or just show the remaining part, like ...6986.31615_0.ps11007 ...7019.1029_0.ps11007
M-. rings bell if empty
Type # RET ESC . Bash replies with a ^G Wouldn't it be more polite to just do nothing, instead of waking up the neighbors? $ expr 2 + 2 4 $ #e=mcHammer -here I typed ESC # $ e=mc-here I type ESC . ESC . in order to get the 2, but after the first ESC . I must endure the ^G slap in the face, before being allowed to climb back up to get the 2. There I was playing secret agent man with the formula and you had to ring/flash, alerting the N. Korean border guards.
Re: mention what characters need to be escaped inside [...]
Greg Wooledge wool...@eeg.ccf.org writes: quotes inside -- [^ ] -- works. But the backslash approach you used is probably the clearest way to write it. Anyways, it should be mentioned in the man page's [...] discussion, even though legally one could say it is probably already mentioned, though scattered around the man page.
mention what characters need to be escaped inside [...]
Maybe mention in the man page at [...] Matches any one of the enclosed characters... that one will need to backslash at least any spaces used inside it: $ ls [^ ] ls: cannot access [^: No such file or directory ls: cannot access ]: No such file or directory $ ls [^\ ] a
Re: set -x prejudiced; won't smell UTF-8 coffee
Instead of having bash make judgements about what people want from their personal mix of: $ locale|sed 's/.*=//;s///g;/^$/d'|sort|uniq -c 2 C 11 zh_TW.UTF-8 instead just have a passthru option they could enable, that says I hereby agree that I want to be sent raw -x output back, and if it looks weird, it's my own fault, 'garbage in, garbage out'. In fact I forgot at the moment why they would see garbage.
Re: set -x prejudiced; won't smell UTF-8 coffee
locale variables have pretty clear definitions. obviously LC_COLLATE wouldnt be relevant here, but LC_MESSAGES certainly would. Assumptions, assumptions, those happen to be the two C's for me. So let me override without having to tamper with them please.
Re: set -x prejudiced; won't smell UTF-8 coffee
Mike Frysinger vap...@gentoo.org writes: i never said you couldnt override them. i said the *default behavior* would OK, it's a deal. Now all that's left is for that Chet guy to implement it :-)
set -x prejudiced; won't smell UTF-8 coffee
Gentlemen, -x's reporting should just pass the Chinese right back. $ set -x; export LC_ALL=$LANG; echo 中文 + export LC_ALL=zh_TW.UTF-8 + LC_ALL=zh_TW.UTF-8 + echo $'\344\270\255\346\226\207' 中文 Or OK, to be fair, even the ASCII should come back as octal escapes.
Re: set -x prejudiced; won't smell UTF-8 coffee
Mike Frysinger vap...@gentoo.org writes: exactly do you suggest differentiating... I don't know. It's all truly over my head. All I know is how are you going to 'market' this stuff in Asia?. I mean the US kids get to see all their -x feedback pretty, but Asians must see it garbled. I don't know. Some kind of set -o passthru mode, on by default?
arithmetic + + subshell might not be documented
Might not be documented: $ cat q for i in : :; do :|: x$((++a)); echo =$a=; done; ls x?; rm x? for i in : :; do :x$((++b)); echo =$b=; done; ls x?; rm x? $ bash q == == x1 =1= =2= x1 x2
I really mean to go to EOF
You know those pesky error messages, nurdsome: line 17: warning: here-document at line 1 delimited by end-of-file (wanted `EOF') Well there should be a new 'trick': $EOF, \$EOF, or something, the meaning of which is 'I really mean to go all the way to the end of the file'. This is in addition to the usual ways to disable seeing such warnings. Ah, missing since the birth of /bin/sh. OK, never mind.
Re: NULL patch
j + If \fIdelimiter\fP is not found or \fIword\fP is null, reading proceeds to the end of file. Make that just If \fIdelimiter\fP is not found, reading proceeds to the end of file. I can't reproduce the other today without getting an error.
NULL patch
*** bash.1.orig 2008-12-17 07:41:13.193756000 +0800 --- bash.1 2008-12-17 07:39:39.845759000 +0800 *** *** 3157,3159 current source until a line containing only ! .I word (with no trailing blanks) --- 3157,3159 current source until a line containing only ! .I delimiter (with no trailing blanks) *** *** 3195,3196 --- 3195,3197 .BR ` . + If \fIdelimiter\fP is not found or \fIword\fP is null, reading proceeds to the end of file. .PP
echo $s{2,3}
What happened to 2,3? Poof, gone.
$ s=a; echo $s{ $s{} $s} $s{1} $s{2,3} ${s}{4,5}
a{ a{} a} a{1} a4 a5
document -u $@ $* special case
Gentlemen, I have discovered a documentation oversight. In the manual,
we see:
-u Treat unset variables as an error when performing param-
eter expansion. If expansion is attempted on an unset
variable, the shell prints an error message, and, if not
interactive, exits with a non-zero status.
and
${parameter:?word}
Display Error if Null or Unset. If parameter is null or unset,
the expansion of word (or a message to that effect if word is
not present) is written to the standard error and the shell, if
it is not interactive, exits. Otherwise, the value of parameter
is substituted.
However, different behavior is observed between
set -u --
: $@ $*
: $1
and
set --
: ${*?} [EMAIL PROTECTED]
: ${1?}
Therefore the -u paragraph needs to add that $@ and $* unset are not
caught by -u, but $1, $2... are.
C-z bg without the lurch
There are many times one has not planned ahead, and forgets the : $ emacs -nw important.txt #then after a half an hour of editing: ^Z [1]+ Stopped emacs -nw important.txt $ compact_disk_burner_GUI_application #forgot to add OK, we want to get back to emacs, but we dare not stop the compact_disk_burner lest we ruin the burn. No not even for the split second a ^Z bg would take. http://groups.google.com/group/comp.unix.shell/browse_thread/thread/e69b7bf5eddd68ca Sure, next time don't use -nw, killall -1 emacs, your file will be in #important.txt#. Anyway, I wish there was a way to communicate a disown command or something to that shell. stty -a shows a lot of weird keys. Anyway, it would be neat if there was a key e.g., C-y, that would have the effect of C-z bg, but without ever letting the job in question feel the brief sting of being stopped. Anyway, how could it be that the mighty bash can't let me get back to my emacs without lurching my CD burning job, even for a split second?
script vs. terminal vs. same line vs. ^C
Here we see with the same $-, if you put it on the same line, you'll run it despite ^C... $ cat file echo $-; sleep 7; echo BOOM $ bash -i file bhimBC ^C $ echo $-; sleep 7; echo BOOM bhimBC ^C BOOM OK, same $-, and same test -t whatever, so what does one have to do to make bash think it is a script and not go BOOM, unset PS1 or something?
test -t
On (info (coreutils)File type tests, and test(1) man page, we see `-t FD' True if FD is a file descriptor that is associated with a terminal. Well please mention what happens if FD is omitted: $ test -t The answer is it always returns true, no matter what. Test with $ echo 'set -x; for i in 0 1 2 3 ; do /usr/bin/test -t $i; : $?; done; tty'|at now; sleep 4; mail Same problem with the bash and dash builtin tests and documents. bash is even more freaky: $ t=test #bash builtin $ $t -t; echo $? 0 $ $t -t ''; echo $? 1 $ $t -t ' '; echo $? 0 $ t=/usr/bin/test $ $t -t; echo $? 0 $ $t -t ''; echo $? /usr/bin/test: invalid integer `' 2 $ dash $ t=test $ $t -t; echo $? 0 $ $t -t ''; echo $? test: 3: Illegal number: 2
Re: test -t
Is this a bug? $ t=test #bash builtin $ $t -t ' '; echo $? 0 PJ That looks like a bug. bash tries to parse a number from the PJ string and ends up with zero, which is a tty.
Re: Dr. Evil typed sleep 666; rm -rf /
The following message is a courtesy copy of an article that has been posted to comp.unix.shell as well. Regarding how to defuse $ sleep 666; echo BOOM given only one terminal, m Here, running bash in a xterm, this works for me: m ^S ^C ^C ^Q For me in xterm, or even on the Debian sid tty1 console with no dotfiles to be read at login, just ^S ^C already gives $ sleep 666; echo BOOM ^C BOOM BM In most shells you can press C-z. Won't help with bash, which is what I'm talking about here, $ sleep 666; echo BOOM ^Z [1]+ Stopped sleep 666 BOOM No, the only way to defuse it I find is to: hit ^S, then wait for more than 666 seconds, then hit ^C. And even supposing one could just open another window to kill the shell (just to diffuse this one line!), in a pinch everybody would probably only just remember ^C. Boom. bash --posix didn't help.
Re: what matched in a case statement
Poor Yorick wrote: Is there any way to get a handle on what matched in a case statement? Something like this: case lawlesspoets in *poets) echo $CASEMATCH one Well, nobody would do case lawlesspoets in in reality you would always have some variable. So just do CASEMATCH=lawlesspoets; case $CASEMATCH in ... so there.
Re: [Pkg-shadow-devel] Bug#476519: shell-mode garbles input
All I have installed else is dash: 4 successes 0 failures.
SC perl -e '$=$=$(=$)=65534; exec sh'
That gets a shell without triggering the error.
SC perl -e '$=$=$(=$)=65534; system sh'
That filled emacs with \377's with luckily a little CPU left over that
I could kill emacs... *
SC Not sure how what bash_completion does could have an impact on su.
I observed the bug with and without the bash-completion package installed.
# lsof -p $$|wc -l
18
pstree shows no processes running left behind.
I observe the bug with both mesg y and n
SC running out of ideas here...
Me too so I hereby wait for Sven to chime in with what else he sees.
*This side issue only happened in emacs's shell, (and not with
LC_ALL=C, but yes with my zh locale) and is one of the reasons I now
use a different HISTORY file there... piped thru cat -v.
# sleep 22 kill -1 $$ #Safety first, also makes the \377s go away.
[1] 16017
# perl -we '$=$=$(=$)=65534;system q(sh)'
05:40 ~$ Use exit to leave the shell.
05:40 ~$ sh: syntax error near unexpected token `('
05:40 258 ~$ sh:[EMAIL PROTECTED]: command not found
05:40 127 ~$ sh: syntax error near unexpected token `('
Anyway, no I don't believe in UFOs. Never mind this side issue. Bye.
Re: [Pkg-shadow-devel] Bug#476519: shell-mode garbles input
SC Could you try ulimit -a? # su - nobody -c ulimit\ -a|grep -v unlimited core file size (blocks, -c) 0 scheduling priority (-e) 0 pending signals (-i) 1791 max locked memory (kbytes, -l) 32 open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 max user processes (-u) 1791 No directory, logging in with HOME=/ # ps -fjlLunobody; lsof -u nobody both show nothing. No lots of processes for me. SC Do you get it from the Linux console (emacs -nw)? Yes, just tired it in emacs -nw -f shell and after 10 good logins I got a bad one. SC Have you tried changing nobody's shell? I don't want to. CR Does su do anything with process groups? That is an advanced question not for little me. Anyway, the only other human to have reproduced any of this mess is http://bugs.debian.org/476519#52 Nobody :-) has responded to the points of that message #52.
Re: [Pkg-shadow-devel] Bug#476519: shell-mode garbles input
SC Try SC sudo env -i SHELLOPTS=xtrace su -p - nobody (I don't use sudo) uid=0(root) gid=0(root) groups=0(root) # env -i SHELLOPTS=xtrace su -p - nobody + PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games + '[' /bin/sh ']' + PS1='[EMAIL PROTECTED]:\w\$ ' + export PATH + umask 022 [EMAIL PROTECTED]:/root$ kill -1 $$ + kill -1 6215 # env -i SHELLOPTS=xtrace su -p - nobody + PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games + '[' /bin/sh ']' + PS1='[EMAIL PROTECTED]:\w\$ ' + export PATH + umask 022 [EMAIL PROTECTED]:/root$ logout # Above on my first attempt the shell stayed alive, so I typed kill -1 $$ (instead of exit, so it would be clear that I typed it, as that is something the magic hand never uses.) On the second and later attempts, some magic hand typed logout for me. The magic hand also sometimes types exit... SC nobody's shell is sh (being bash) or bash, right? SC $ getent passwd nobody SC nobody:x:65534:65534:nobody:/nonexistent:/bin/sh Same here. SC $ dpkg -S $(command -v su) SC login: /bin/su Same here. $ ls -og /bin/sh lrwxrwxrwx 1 4 2008-04-29 07:04 /bin/sh - bash SC Which su is your su? Is it using PAM? SC $ ldd /bin/su same here except for the hex numbers. SC $ grep '^[^#]' /etc/pam.d/su Same here. SC (also check the included files). Never touched them. $ cd /etc/pam.dfind * -atime -1 -type f|xargs ls -og -rw-r--r-- 1 392 2005-07-26 16:48 common-account -rw-r--r-- 1 436 2005-07-26 16:48 common-auth -rw-r--r-- 1 1097 2005-07-26 16:48 common-password -rw-r--r-- 1 372 2005-07-26 16:48 common-session -rw-r--r-- 1 289 2005-07-05 22:45 cron -rw-r--r-- 1 2843 2006-09-17 15:22 login -rw-r--r-- 1 520 2003-09-01 06:21 other -rw-r--r-- 1 2305 2006-07-14 19:05 su -rw-r--r-- 1 289 2007-08-13 23:54 xdm The only thing I tampered with is probably just making a $ ls -og /etc/environment -rw-r--r-- 1 0 2008-05-02 03:37 /etc/environment to stop the warning in /var/log/auth.log if it is absent. The pam stuff came with my Debian sid installation and apt-get says removing it should NOT be done unless you know exactly what you are doing! i.e., not me, so I dare not touch it.
Re: [Pkg-shadow-devel] Bug#476519: shell-mode garbles input
Here we see the typical deal. You asked me about ulimit. I tried to get a shell oh, six times this time before the magic hand stopped logging me out. Whereupon it bites off the first character of what I type and logs me out, saving the message for after the next prompt. Then I get a shell again to give you the answer. # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ logout # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ logout # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ logout # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ logout # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ logout # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ ulimit logout # su - nobody bash: limit: command not found # No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ ulimit unlimited [EMAIL PROTECTED]:/$ stty speed 38400 baud; line = 0; erase = undef; kill = undef; -brkint -imaxbel -onlcr -echo Happens also in xterm, where # stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 SC Does that happen straight away or after a delay? The logout happens instantaneously, no waiting for me to type my first command as nobody. SC The logout thing looks a bit like eof from the terminal. Very much so. SC strace would probably help then: No. Every time I use strace I get a shell that sticks around. The bug is not triggered. I'll send you one anyway. SC And look at the last read(0 in /tmp/strace.out SC Could be a tty setting as well. SC stty min 0 time 10 -icanon Ho ho ho, that even eats through all the shells stacked up in my emacs shell buffer exiting each one. SC With readline Has readline. I'll send you shopt output.
Re: [Pkg-shadow-devel] Bug#476519: shell-mode garbles input
CR Does this happen only in an emacs shell-mode window? No. It happens also in xterm. Today it at least allowed me to do -c date. I did not type exit or logout. The magic hand did. # su - nobody -c date No directory, logging in with HOME=/ Sat May 3 01:03:10 CST 2008 # su - nobody -c 'sh -i' No directory, logging in with HOME=/ sh-3.2$ exit # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ logout #
distinguish shell generated exits
There are several situations where $ exit and $ logout were typed by the shell and not the user, who must specifically say I did not type that, some magic hand did when sharing shell transcripts with other people. So perhaps those messages should have a bash: prepended or something to distinguish them.
Re: [Pkg-shadow-devel] Bug#476519: shell-mode garbles input
As http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476519 says, maybe it is a bash bug: with Debian sid's BASH_VERSION=3.2.33(1)-release about half the time the below works normally, the other half some magic hand sends exit to it, logging me out right away. The first letter of which gets bitten off or something, here in an emacs shell window: 03:44 ~# env - su - nobody bash: xit: command not found (I do not have the bash-completion package installed, as per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468858 )
Re: TZ=... date affected PROMPT_COMMAND
OK, now using Archimerged's cleaner version, I bet Matthew can
reproduce this.
[EMAIL PROTECTED]:/root# su - nobody
No directory, logging in with HOME=/
[EMAIL PROTECTED]:/$ PROMPT_COMMAND='prompt_status=\ $?'
[EMAIL PROTECTED]:/$ PS1=$SPECIAL_PS1\A\${prompt_status# 0} \W$
17:26 /$ TZ=America/Los_Angeles date
Thu Apr 17 02:26:11 PDT 2008
02:26 /$ echo $BASH_VERSION
3.1.17(1)-release
02:26 /$ false
02:26 1 /$ true
02:26 /$ /bin/true
17:26 /$
Note how the prompt timezone becomes contaminated until we finally
shake it back off with a non-built-in command.
You know, this reminds me of some injection attacks!
TZ=... date affected PROMPT_COMMAND
Never thought that putting TZ here would infect my prompt,
21:07 ~$ date
Wed Apr 16 21:07:54 CST 2008
21:07 ~$ TZ=America/Chicago date
Wed Apr 16 08:08:07 CDT 2008
08:08 ~$ set a b c
08:08 ~$ date
Wed Apr 16 21:08:22 CST 2008
21:08 ~$
all the way until the next non built-in command.
Need to do sh -c 'TZ=America/Chicago date'
if one doesn't want their prompt affected.
(On the other hand, what I do in .bashrc is black magic to me too:)
PROMPT_COMMAND='prompt_tricks_z= $?; prompt_tricks_z=${prompt_tricks_z# 0}
case $PWD in $HOME) pwd=\~;; *) pwd=${PWD##*/};; esac' #cfaj.freeshell.org
PS1=$SPECIAL_PS1$my_color_on\A\$prompt_tricks_z \$pwd\\$$my_color_off
document export x=1 y=$x
On the man page at section export, mention that the latter below will not do what one expects, as here revealed: $ set -x $ a=1 b=$a + a=1 + b=1 $ export x=1 y=$x + export x=1 y= + x=1 + y= Yes I'm sure it is mentioned elsewhere on the page but you might want to drum it home again here. Maybe also at $ help export.
set +o history hard to keep turned off
Put set +o history at the bottom of .bashrc and confirm that it is indeed the last thing run via $ bash -x But then do $ set -o|grep history which will show that it is turned back on.
Re: Dr. Evil typed sleep 666; rm -rf /
Your attention is drawn to the current thread, a small sample of which is: Newsgroups: comp.unix.shell Subject: Re: Dr. Evil typed sleep 666; rm -rf / Date: 11 Feb 2008 bash is the only shell that will run rm if you interrupt sleep with C-c. All the other shells including the Bourne shell, ksh88, ksh93, pdksh, zsh, csh, tcsh, rc, es and their derivatives will not unless Dr. Evil has installed a trap on SIGINT. With bash, you'll have to kill bash from another shell. Bug or feature?
Re: ESC . vs. ^R, ^P again
C \M-.:\M-\M-_ Thanks but that doesn't work. $ : 1 $ : 2 $ : 3 $ : 4 $ I want now typing ^R 2 ^E M-. to put a 4 at the end of the line but the above macro does not.
Re: ESC . vs. ^R, ^P again
$ bind '\e.:\e\e_' $ : 1 $ : 2 $ : 3 $ : 4 $ I want now typing ^R 2 ^E M-. to put a 4 at the end of the line... ...and not wipe out the 2, which is what the above bind did. BASH_VERSION='3.1.17(1)-release'
ESC . on # items
$ echo abc abc $ #echo xyz $ Now do ESC . and experience the pain of the buzzer or visual bell that means one has done something bad. Yes, I know you are against thinking that one would ever want the last item of something one commented out, but at least you don't have to chastise them :-( I personally would give them xyz. What ever you do please don't give them the bell. Odd that one can ^R them but not ESC . them.
case/esac: mention backslash to match a leading (
On the man page: case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac perhaps mention one needs a backslash to match a leading (: case '(1' in (1) echo 2;; \(1)echo 3;; esac
TAB strips wildcards
Here is a true case of what happens when you hit TAB with a wildcard: $ shar /tmp/logs/*/*/*TAB access.log access.log $ shar /tmp/logs/ Yes, it strips the wildcards!
Re: TAB strips wildcards
EB Have you installed a completion function? # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ #WHATEVER /tmp/logs/*/*/*TAB access.log access.log [EMAIL PROTECTED]:/$ bind 'set show-all-if-ambiguous on' [EMAIL PROTECTED]:/$ #WHATEVER /tmp/logs/*/*/*TAB access.log access.log [EMAIL PROTECTED]:/$ #WHATEVER /tmp/logs/ So it is a bug in show-all-if-ambiguous (which one chooses to avoid the bell.) By the way, access.log access.log --P.S. there are two blank spaces here seen upon screen scrape. Wasteful.
prevent more regretful suspend
Regarding suspend: suspend [-f] Suspend the execution of this shell until it receives a SIGCONT signal. The `-f' if specified says not to complain about this being a login shell if it is; just suspend anyway. My problem is often in an e.g., xterm window I suspend by accident, forgetting that this is the lowest layer I have made for myself today, with the only cure being to find the PID number of that shell and send it a kill -18 from an other window. Therefore perhaps extend protection to those kind of windows too, not just login shells. screen(1) detects this if one trys to do it in a screen window. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
