Re: starstar ** symbol
On Wed, Dec 28, 2011 at 04:31, aleksandergajewski
aleksandergajew...@gmail.com wrote:
Hi, i've just come across vim startstar symbol - here's note from vim
help:
CUT HERE
The usage of '*' is quite simple: It matches 0 or more characters.
In a
search pattern this would be .*. Note that the . is not used
for file
searching.
'**' is more sophisticated:
- It ONLY matches directories.
- It matches up to 30 directories deep by default, so you can
use it to
search an entire directory tree
- The maximum number of levels matched can be given by appending
a number
to '**'.
Thus '/usr/**2' can match:
/usr
/usr/include
/usr/include/sys
/usr/include/g++
/usr/lib
/usr/lib/X11
It does NOT match '/usr/include/g++/std' as this would be
three
levels.
The allowed number range is 0 ('**0' is removed) to 100
If the given number is smaller than 0 it defaults to 30, if
it's
bigger than 100 th CUT HERE en 100 is used. The system
also has a limit on the
path length, usually 256 or 1024 bytes.
- '**' can only be at the end of the path or be followed by a
path
separator or by a number and a path separator.
CUT HERE
Every time I wanted to use recursive search in bash, i wrote simple
script, or did manually (eg. ls */*.txt; ls */*/*.txt etc.), then I
found 'find + xargs', but in fact '**' would be sufficient for my
needs (and it seems to be more useful in most cases)
Here is my question: why there is no such thing in bash? Is there any
compatibility issue, which makes it difficult/impossible to introduce
in bash?
Bash 4.0 added a new shopt option `globstar'. ... When enabled, the
globbing code treats `**' specially -- it matches all directories (and
files within them, when appropriate) recursively.
Is that what you want?
Re: [bug] Home dir in PS1 not abbreviated to tilde
On Mon, Mar 12, 2012 at 12:22, Yongzhi Pan panyong...@gmail.com wrote: Tested in GNU bash, version 3.00.16(1)-release and 4.1.2(1)-release. Upon login, home dir is displayed as tilde in PS1: pan@BJ-APN-2 ~$ echo $PS1 \[\033[35m\]\u@\h \w$ \[\033[0m\] pan@BJ-APN-2 ~$ pwd /export/home/pan/ After a cd command, which change directory to $HOME (not changed at all), it is displayed as the complete path: pan@BJ-APN-2 ~$ cd pan@BJ-APN-2 /export/home/pan$ The reason is that my home in passwd has a trailing slash: pan@BJ-APN-2 /export/home/pan$ grep ^$USER: /etc/passwd pan:x:896:1::/export/home/pan/:/bin/bash You can also reproduce this by directly setting HOME to `/export/home/pan/'. This is tricky to find. I hope it will display tilde even if home dir entry in passwd has one or more trailing slash. I personally don't think this needs to be fixed. :) PS: I read the source code and do not know where this is done, maybe in y.tab.c?
Re: RFE: allow bash to have libraries
On Fri, Mar 2, 2012 at 08:20, John Kearney dethrop...@web.de wrote: :) :)) Personal best wrote about 1 lines of code which finally became about 200ish to implement a readkey function. Actually ended up with 2 solutions 1 basted on a full bash script vt100 parser weighing in a about 500 lines including state tables and a s00 line hack. Check out http://mywiki.wooledge.org/ReadingFunctionKeysInBash Personally I'd have to say using path to source a moduel is a massive securtiy risk but thats just me. I actually have a pretty complex bash modules hierarchy solution. If anybodys interested I guess I could upload it somewhere if anybodys interested, I just found https://gist.github.com/ a few days ago :) Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository. its just a play thing for me really but its couple 1000 lines of code proabely more like 1+. Its kinda why I started updating Gregs wiwi I noticed I'd found different/better ways of dealing with a lot of problems. Thiing like secured copy/move funtions. Task Servers. Generic approach to user interface interactions. i.e. supports both gui and console input in my scripts. Or I even started a bash based ncurses type system :), like I say some fune still got some performance issues with that one. Or improves select function that supports arrow keys and mouse selection, written in bash. Anybody interested in this sort of thing? I'm interested.
Re: equivalent of Linux readlink -f in pure bash?
On Wed, Aug 10, 2011 at 18:47, Stephane CHAZELAS stephane_chaze...@yahoo.fr
wrote:
2011-08-10, 12:00(+02), Bernd Eggink:
[...]
function f
{
local OPTIND=1
echo \$1=$1
}
while getopts abcdefg opt
do
echo opt=$opt
f $opt
done
Calling the sript like this works fine:
script -a -b -c
But calling it like this leads to an endless loop:
script -abc
[...]
However, this also loops endlessly. The reason is most likely that bash
maintains an additional internal variable holding the index of the
current character, relative to the current word. While this variable is
not directly accessible by the user, it is set to 0 whenever OPTIND is
assigned a value.
[...]
That would be a bug in bash in my opinion. If OPTIND is marked
local to the function, it shouldn't affect the behavior of
parent contexts.
Note that that bug is also in ksh93, pdksh, mksh and posh
(though slightly different in that one), but not in ash nor zsh.
Seems like ksh93 (tested with version 93u 2011-02-08) implicitly declares
OPTIND and OPTARG in functions defined in the `function NAME {}' syntax and
everything works fine. But if OPTIND or OPTARG are explicitly declared as
local it may not work as expected.
Wish Chet would consider fixing this problem in future bash releases. :)
Note that if you set OPTIND local, you probably want to do the
same for OPTARG (and maybe OPTERR).
--
Stephane
Re: Specify completion without name
On Fri, Jan 6, 2012 at 00:33, Peng Yu pengyu...@gmail.com wrote: I would envision that such a completion function would assemble its list of possible completions by using your read-from-a-file mechanism and augment the list using compgen -a/compgen -b/compgen -A function. It would probably also want to handle glob patterns and expand them to potentially multiple completions, but that gets tricky. I did not know that it is so simple to get the alias (compgen -a), buildins (compgen -b) and functions (compgen -A function) as you mentioned. Once I know these, I agree with you that bash need not handle these internally, rather user can call these three functions directly. But beware to clearly document these by giving working EXAMPLE code which include these three commands (not just text explanation without working code, by working code I mean code snippet is discouraged, a complete completion function should be provided). The bash man page already has ~70 pages manual. I don't like it to grow to ~700 pages (like the ABS Guide) with all the working examples you expected. :) BTW, as I mentioned several times the bash man favors document maintainer rather readers. For example, the following help doesn't help me much when I want to learn how to use compgen. ~$ help compgen compgen: compgen [-abcdefgjksuv] [-o option] [-A action] [-G globpat] [-W wordlist] [-P prefix] [-S suffix] [-X filterpat] [-F function] [-C command] [word] Display the possible completions depending on the options. Intended to be used from within a shell function generating possible completions. If the optional WORD argument is supplied, matches against WORD are generated. The manpage also use a reference rather than list all the options directly. Readers have to jump to complete to understand how to use compgen. This is also inconvenient to users. Generate possible completion matches for word according to the options, which may be any option accepted by the complete builtin If you consider it repetitive to discuss the same option twice in both compgen and complete, at least, you can expand help compgen to describe all the options (merge the current description of compgen and complete in man). Other help messages are so concise that they are not very helpful for learning how to use them. I'd suggest change all of them as well. -- Regards, Peng
extglob pattern: @(/root) vs. @(root)
See following: # shopt extglob extglob on # echo $BASH_VERSION 4.2.20(1)-release # ls -d /root /root # pwd / # echo @(root) root # echo @(/root) @(/root) -- ??? # echo @(/root*) @(/root*) -- ??? # I'm confused why @(/root) and @(/root*) do not work here. -- -Clark
Re: extglob pattern: @(/root) vs. @(root)
On Fri, Dec 9, 2011 at 16:16, Clark J. Wang dearv...@gmail.com wrote: See following: # shopt extglob extglob on # echo $BASH_VERSION 4.2.20(1)-release # ls -d /root /root # pwd / # echo @(root) root # echo @(/root) @(/root) -- ??? # echo @(/root*) @(/root*) -- ??? But /@(root) and /@(root*) work: # echo /@(root) /root # echo /@(root*) /root # # I'm confused why @(/root) and @(/root*) do not work here. -- -Clark
Re: extglob pattern: @(/root) vs. @(root)
On Fri, Dec 9, 2011 at 20:12, Stephane CHAZELAS stephane_chaze...@yahoo.frwrote: 2011-12-9, 16:16(+08), Clark J. Wang: See following: # shopt extglob extglob on # echo $BASH_VERSION 4.2.20(1)-release # ls -d /root /root # pwd / # echo @(root) root # echo @(/root) @(/root) -- ??? # echo @(/root*) @(/root*) -- ??? # I'm confused why @(/root) and @(/root*) do not work here. Globbing operators (*, ?, [/], @(..)) don't match /. / has to be inserted literally. See the doc: When a pattern is used for filename expansion, the character `.' at the start of a filename or immediately following a slash must be matched explicitly, unless the shell option `dotglob' is set. When matching a file name, the slash character must always be matched explicitly. In other cases, the `.' character is not treated specially. ~~ Thanks. I see the point now. I never really noticed that before since things like `echo /root*' always worked fine. :) -- Stephane -- -Clark
Re: super annoying completion change
On Fri, Dec 9, 2011 at 11:24, Chet Ramey chet.ra...@case.edu wrote: On 12/8/11 9:14 PM, Clark J. Wang wrote: http://lists.gnu.org/archive/html/bug-bash/2011-09/msg7.html contains a basic summary and includes a patch that adds a `direxpand' shell option to restore the 4.1 behavior. You can download a version of bash-4.2.20 with this patch already applied from the `direxpand' branch on the bash git tree on savannah. Bash-4.2.20 does not have `direxpand'. Did I misunderstand you? Yes. I need to learn English much harder. :) You can either take bash-4.2.20 and manually apply the patch I posted, or, as above, check out the `direxpand' branch from the git tree, which already has that patch applied on top of bash-4.2.20. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- -Clark
Re: super annoying completion change
On Thu, Dec 8, 2011 at 23:58, Chet Ramey chet.ra...@case.edu wrote: On 12/7/11 9:43 PM, Miles Bader wrote: I notice that recently the behavior of bash completion w/r/t environment variables has changed, in a realy annoying way: This has enjoyed detailed discussion in the past, on several occasions. http://lists.gnu.org/archive/html/bug-bash/2011-09/msg7.html contains a basic summary and includes a patch that adds a `direxpand' shell option to restore the 4.1 behavior. You can download a version of bash-4.2.20 with this patch already applied from the `direxpand' branch on the bash git tree on savannah. Bash-4.2.20 does not have `direxpand'. Did I misunderstand you? # echo $BASH_VERSION 4.2.20(1)-release # shopt -s direxpand bash: shopt: direxpand: invalid shell option name # If one has an environment variable like: ls=/usr/local/src and then hit TAB to complete the following command line: $ cd $ls/emaTAB where the intent is to do cd /usr/local/src/emacs, then: * The _old_ behavior of bash was to (1) expand $ls to /usr/local/src, and then (2) proceed to complete /usr/local/src/ema into /usr/local/src/emacs. Handy! Not everyone considers that to be true. * The _new_ behavior is to just add a backslash before $ and then (apparently) try to complete on the literal-$-prefixed string -- which of course usually fails, as there is no such subdirectory. It's slightly more complicated than that, but that's the gist: a filename containing a character that requires quoting gets quoted. Given that filenames/directories containing a literal $ are quite rare in general, Not as rare as you might think, given the existence of Windows shares mounted on different systems. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- -Clark
Re: A programmable completoin bug?
On Sat, Dec 3, 2011 at 09:32, Chet Ramey chet.ra...@case.edu wrote:
On 11/30/11 2:08 AM, Clark J. Wang wrote:
(Tested with bash 4.2.10 and 4.1.9)
[bash-4.2.10] # cat foo.compspec
compspec_foo()
{
local cmd=$1 cur=$2 pre=$3
if [[ $cur = :* ]]; then
COMPREPLY=( changed changed/IGNORE_ME )
fi
}
complete -F compspec_foo foo
[bash-4.2.10] # source foo.compspec
[bash-4.2.10] # foo :shortTAB
[bash-4.2.10] # foo changed -- Fine, this is what I want
[bash-4.2.10] # foo :this-is-a-long-wordTAB
[bash-4.2.10] # foo :this-i -- Bug here?
First of all, you must have removed `:' from $COMP_WORDBREAKS, because
you won't get any matches unless you have.
Sorry I forgot to mention that. `:' is removed from $COMP_WORDBREAKS in my
global rc files. To be more exact:
[bash-4.2.10] # printf '%q\n' $COMP_WORDBREAKS
$' \t\n\'=;|('
[bash-4.2.10] #
I can't reproduce this behavior using bash-4.2.20 (after modifying
COMP_WORDBREAKS); I get `changed' as the completion in both cases.
I just compiled the latest 4.2.20 and I could still reproduce it. And I
also tested in Cygwin (bash 4.1.10) and Debian 6.0 (bash 4.1.5), they all
have the same problem.
Have you done `set -x' to get an idea of what's happening when the
completion function runs?
Seems like `set -x' gives no more info:
[bash-4.2.20 ~/tmp] # printf '%q\n' $COMP_WORDBREAKS
$' \t\n\'=;|('
[bash-4.2.20 ~/tmp] # cat foo.compspec
+ cat foo.compspec
compspec_foo()
{
local cmd=$1 cur=$2 pre=$3
if [[ $cur = :* ]]; then
COMPREPLY=( changed changed/IGNORE_ME )
fi
}
complete -F compspec_foo foo
[bash-4.2.20 ~/tmp] # source foo.compspec
[bash-4.2.20 ~/tmp] # set -x
[bash-4.2.20 ~/tmp] # foo :this-is-a-long-wordPress TAB and then ENTER
[bash-4.2.20 ~/tmp] # foo :this-is-a-long-word+ local cmd=foo
cur=:this-is-a-long-word pre=foo
+ [[ :this-is-a-long-word = :* ]]
+ COMPREPLY=(changed changed/IGNORE_ME)
+ foo :this-i
bash: foo: command not found
[bash-4.2.20 ~/tmp] #
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
--
-Clark
Re: A programmable completoin bug?
On Mon, Dec 5, 2011 at 11:10, Chet Ramey chet.ra...@case.edu wrote:
I still can't reproduce it on Mac OS X or RHEL 5.7:
It's weird. :) Any other settings can affect this? What can I do to debug
more?
$ echo $BASH_VERSION
4.2.20(8)-release
$ type -a compspec_foo
compspec_foo is a function
compspec_foo ()
{
local cmd=$1 cur=$2 pre=$3;
if [[ $cur = :* ]]; then
COMPREPLY=(changed changed/IGNORE_ME);
fi
}
$ complete
complete -F compspec_foo foo
$ set -x
$ COMP_WORDBREAKS=${COMP_WORDBREAKS%?}
+ COMP_WORDBREAKS='
'\''@=;|('
$ echo $COMP_WORDBREAKS
+ echo ''\''@=;|('
'@=;|(
$ foo :this-is-a-+ local cmd=foo cur=:this-is-a- pre=foo
+ [[ :this-is-a- = :* ]]
+ COMPREPLY=(changed changed/IGNORE_ME)
changed
+ foo changed
bash: foo: command not found
$ foo :this-is-a-long-word+ local cmd=foo cur=:this-is-a-long-word pre=foo
+ [[ :this-is-a-long-word = :* ]]
+ COMPREPLY=(changed changed/IGNORE_ME)
changed
+ foo changed
bash: foo: command not found
I wonder if there's some difference in our environments that's the cause.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
Re: A programmable completoin bug?
On Mon, Dec 5, 2011 at 11:42, Chet Ramey chet.ra...@case.edu wrote: On 12/4/11 10:26 PM, Clark J. Wang wrote: On Mon, Dec 5, 2011 at 11:10, Chet Ramey chet.ra...@case.edu mailto:chet.ra...@case.edu wrote: I still can't reproduce it on Mac OS X or RHEL 5.7: It's weird. :) Any other settings can affect this? What can I do to debug more? Well, if it were me, I'd fire up gdb and set a breakpoint in pcomplete.c:gen_shell_function_matches. I wonder if you've got something filtering out or ignoring those matches. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ After more investigation I found that it's caused by set completion-ignore-case on. After turning completion-ignore-case off it works fine. You can give it a try. Still remember another bind issue ( http://lists.gnu.org/archive/html/bug-bash/2011-03/msg00094.html ) I reported before? Maybe it's the similar problem. -- -Clark
Re: A programmable completoin bug?
On Mon, Dec 5, 2011 at 13:15, Clark J. Wang dearv...@gmail.com wrote: On Mon, Dec 5, 2011 at 11:42, Chet Ramey chet.ra...@case.edu wrote: On 12/4/11 10:26 PM, Clark J. Wang wrote: On Mon, Dec 5, 2011 at 11:10, Chet Ramey chet.ra...@case.edu mailto:chet.ra...@case.edu wrote: I still can't reproduce it on Mac OS X or RHEL 5.7: It's weird. :) Any other settings can affect this? What can I do to debug more? Well, if it were me, I'd fire up gdb and set a breakpoint in pcomplete.c:gen_shell_function_matches. I wonder if you've got something filtering out or ignoring those matches. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ After more investigation I found that it's caused by set completion-ignore-case on. After turning completion-ignore-case off it works fine. You can give it a try. Note that I used the `bind' command to turn `completion-ignore-case' on/off and I did not use $HOME/.inputrc, in case that makes a difference. Still remember another bind issue ( http://lists.gnu.org/archive/html/bug-bash/2011-03/msg00094.html ) I reported before? Maybe it's the similar problem. -- -Clark -- -Clark
A programmable completoin bug?
(Tested with bash 4.2.10 and 4.1.9)
[bash-4.2.10] # cat foo.compspec
compspec_foo()
{
local cmd=$1 cur=$2 pre=$3
if [[ $cur = :* ]]; then
COMPREPLY=( changed changed/IGNORE_ME )
fi
}
complete -F compspec_foo foo
[bash-4.2.10] # source foo.compspec
[bash-4.2.10] # foo :shortTAB
[bash-4.2.10] # foo changed -- Fine, this is what I want
[bash-4.2.10] # foo :this-is-a-long-wordTAB
[bash-4.2.10] # foo :this-i -- Bug here?
--
-Clark
Re: help-b...@gnu.org mailing list
On Tue, Nov 22, 2011 at 7:50 AM, Chet Ramey chet.ra...@case.edu wrote: I just created help-b...@gnu.org. I hope that it becomes the list where folks ask questions about bash and shell programming. Please socialize its existence and subscribe if you like. So the About bug-bash description should be updated accordingly. About bug-bash This list distributes, to the active maintainers of BASH (the Bourne Again SHell), bug reports and fixes for, and suggestions for improvements in BASH. User discussion of BASH also occurs here. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: Encrypted bashrc?
On Fri, Nov 11, 2011 at 9:09 PM, Greg Wooledge wool...@eeg.ccf.org wrote: On Fri, Nov 11, 2011 at 01:48:59PM +0800, Clark J. Wang wrote: In my company all the people share a few of Solaris servers which use NIS to manage user accounts. The bad thing is that some servers' root passwords are well known so anybody can easily su to my account to access my files. To protect some private info in my bashrc I want to encrypt it. Any one has a good solution for that? The private information should be in a separate file, not in ~/.bashrc itself. Sounds like this is the correct way to go. I've ever tried openssl and it worked fine overall. The big problem is that every time I log in or create a new shell window in screen I have to enter my key to decrypt the rc file. I usually open 10 shell windows in screen so it's really annoying. More elegant solution? This is pretty off-topic for bug-bash, since it's not about bash or about a bug. It would REALLY help to know what you are doing, without all the vagueness and obfuscation. I'm talking about my bashrc so I think it's bash related. :) You could write something that works like ssh-agent and ssh-add. Run the agent at login time and run the adder when you have interactive capability, so that the agent can be given your passphrase to unlock the private file. Maybe you actually ARE talking about an ssh key. God only knows, since you couldn't be bothered to tell us. In any case, it's not a bash bug. I did not tell it's a bash bug. Just want to know if any one has done similar things and how.
Re: Encrypted bashrc?
On Fri, Nov 11, 2011 at 2:25 PM, William Park opengeome...@yahoo.ca wrote: On Fri, Nov 11, 2011 at 01:48:59PM +0800, Clark J. Wang wrote: In my company all the people share a few of Solaris servers which use NIS to manage user accounts. The bad thing is that some servers' root passwords are well known so anybody can easily su to my account to access my files. To protect some private info in my bashrc I want to encrypt it. Any one has a good solution for that? From top of my head: 1. gpg 2. openssl I've ever tried openssl and it worked fine overall. The big problem is that every time I log in or create a new shell window in screen I have to enter my key to decrypt the rc file. I usually open 10 shell windows in screen so it's really annoying. More elegant solution? -- William
Encrypted bashrc?
In my company all the people share a few of Solaris servers which use NIS to manage user accounts. The bad thing is that some servers' root passwords are well known so anybody can easily su to my account to access my files. To protect some private info in my bashrc I want to encrypt it. Any one has a good solution for that? -Clark
Re: What is the best to pass an array with specially characters as command line arguments?
(Added back the bash list)
On Mon, Nov 7, 2011 at 11:50 AM, Peng Yu pengyu...@gmail.com wrote:
On Sun, Nov 6, 2011 at 9:30 PM, Clark J. Wang dearv...@gmail.com wrote:
On Mon, Nov 7, 2011 at 11:02 AM, Peng Yu pengyu...@gmail.com wrote:
Hi,
Suppose that I have a verbatim string a b c ( a'b | in bash, and
I want to pass them as 6 command line arguments. I have to the
following conversion using quoteverb.sed to pass the 6 arguments
correctly to echo, which is a little bit cumbersome. I'm wondering if
there is any better way to pass the 6 arguments.
v= a b c ( a'b |
a=( $v )
echo ${a[@]}
There's a @ char here.
And you may need to temporariliy enable the noglob option before that.
Not working. See below. Also, 'echo ${a[@]}' will only pass 1
argument to echo, I want to pass 6 separate arguments to echo.
~$ cat main1.sh
#!/usr/bin/env bash
set -o noglob
verbatim_string= a b c ( a'b |
args=( $verbatim_string )
set +o noglob
echo ${args}
~$ ./main1.sh
a
--
Regards,
Peng
Re: What is the best to pass an array with specially characters as command line arguments?
On Mon, Nov 7, 2011 at 12:56 PM, Peng Yu pengyu...@gmail.com wrote:
Hi Clark,
v= a b c ( a'b |
a=( $v )
echo ${a[@]}
There's a @ char here.
I see. It's my mistake.
But I want to pass the 6 short arguments instead of 1 long argument to
echo.
What do you mean by 1 long argument?
[bash-4.2.10] # cat foo.sh
v= a b c ( a'b |
set -o noglob
a=( $v )
set +o noglob
for i in ${a[@]}; do
echo $i
done
[bash-4.2.10] # bash foo.sh
a
b
c
(
a'b
|
[bash-4.2.10] #
(echo is just an example, it can be any command that accepts
multiple arguments.)
~$ cat ./main1.sh
#!/usr/bin/env bash
#set -o noglob
verbatim_string= a b c ( a'b |
args=( $verbatim_string )
#set +o noglob
echo ${args[@]}
~$ ./main1.sh
a b c ( a'b |
--
Regards,
Peng
Re: bash tab variable expansion question?
On Sat, Sep 3, 2011 at 3:32 AM, Chet Ramey chet.ra...@case.edu wrote: The attached patch adds a new shell option that, when enabled, is intended to restore the bash-4.1 behavior of expanding directory names in filenames being completed. I have done some testing, and it seems to work the way I intend. This, or some later version, will be part of the next bash release. I am soliciting feedback on this iteration. I'm sending this directly to everyone who's commented negatively about the default bash-4.2 behavior, as well as bug-bash. Please try the new option (`direxpand') and let me know if it's missing anything. The patch includes the original heuristic I sent out back in March, the new shopt option, and updates to the documentation and test suite. It should apply cleanly to bash-4.2.10. Tested with 4.2.10. Overall it works fine for me. But it still has problem for following scenario: $ complete -d -o bashdefault cd $ cd $PWDTAB # it expands to this: $ cd \$PWDSPACE Bash 4.1 also behaves like that so I'm not sure if it's OK. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: equivalent of Linux readlink -f in pure bash?
On Wed, Aug 10, 2011 at 6:00 PM, Bernd Eggink mono...@sudrala.de wrote:
On 09.08.2011 15:50, Steven W. Orr wrote:
*) You reset OPTIND to 1 but you didn't declare it local. This will
cause any caller of getlink which uses getopts to reset its variable
to 1. (I mention this because it cost me a couple of hours a while
back.)
The reason I didn't declare OPTIND local is that OPTIND is handled
specially by the shell; there is always exactly _one_ instance of this
variable. In other words, OPTIND is always global, even if declared local
(which is indeed pretty weird). Try this:
I always declare OPTIND as local. I didn't know it does not work at all.
Bug?
--**-
function f
{
local OPTIND=1
echo \$1=$1
}
while getopts abcdefg opt
do
echo opt=$opt
f $opt
done
--**--
Calling the sript like this works fine:
script -a -b -c
But calling it like this leads to an endless loop:
script -abc
One could of course save and restore the original:
--**-
function f
{
local oldind=$OPTIND
OPTIND=1
echo \$1=$1
OPTIND=$oldind
}
--**-
However, this also loops endlessly. The reason is most likely that bash
maintains an additional internal variable holding the index of the current
character, relative to the current word. While this variable is not directly
accessible by the user, it is set to 0 whenever OPTIND is assigned a value.
So the only safe way is to _never_ use getopts within another getopts
block, but always wait until the first one has finished.
Re: Is bash dying or dead (was Re: 4.1 is $((( ))) an 'official operator, if $(( )) isn't?
On Thu, Aug 11, 2011 at 5:59 AM, Linda Walsh b...@tlinx.org wrote: Bash is becoming very unstable -- programs that work in 3.1 won't necessarily work in 3.2, those in 3.2 aren't compat with 4.0, 4.0 is different than 4.1, and now 4.2 is different than 4.1. How can people write stable scripts in an enironment of constant change? This is creating the exact opposite of what POSIX is supposed to help! I found the similar problem. Bash has changed a lot since 2.05b which is the 1st version of bash I've used. That's fine for everyday interactive use but introduces some incompatibility for scripts. I'm now learning ksh and see if it's better for scripting purpose. Any suggestions?
Re: bash completion
On Sun, Aug 7, 2011 at 11:35 PM, jonathan MERCIER bioinfornat...@gmail.comwrote: I have a bash completion file (see below) It works fine, but i would like add a feature = not expand the flag by a space when it contain '=' curently when i do: $ ldc2 -Dftab ldc2 -Df=⊔ i would like: ldc2 -Dftab ldc2 -Df= without space Try like this: complete -o nospace -F _ldc ldc2
Re: feature request: option to start script not from the very beginning of file
On Tue, Aug 2, 2011 at 10:34 PM, Steven W. Orr ste...@syslang.net wrote: On 8/2/2011 9:05 AM, Dmitry Bolshakov wrote: hi perl has -x switch which makes it skip leading file contents until the #!/bin/perl line imho it would be good to have the same feature in bash Huge misteak. The shebang is processed by the exec system call. Only true when a script, e.g. foo.sh, is invoked by ``./foo.sh''. What Dmitry wants is a new option, say ``--perl-x'', and he wants to invoke the script by ``bash --perl-x foo.sh''. You can take a look at Perl's ``-x'' explanation. I like that. :-) As such, it must occupy the first 16 bits of the file. The #! is the magic number that makes it work. What possible value is there in subverting a perfectly good system call? -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net
Re: ``complete -d -o default cd'' issue
On Wed, Jul 27, 2011 at 12:39 AM, Chet Ramey chet.ra...@case.edu wrote: Globbing is not part of readline's set of filename completions. It is implemented by the shell, hence the need for the bashdefault option. Thanks all for the explanation. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: ``complete -d -o default cd'' issue
On Tue, Jul 26, 2011 at 12:00 AM, Andreas Schwab sch...@linux-m68k.orgwrote: Clark J. Wang dearv...@gmail.com writes: Here the TAB cannot expand ``*.d'' to ``long-dir-name.d''. Bug? You need to add -o bashdefault for that. ``-o bashdefault'' works fine for me, thanks. But from the Bash manual I think ``-o default'' should also work: -o defaultUse readline's default filename completion if the compspec generates no matches. -Clark Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Signals ignored by a shell cannot be handled by its sub-shells?
For example:
[bash-4.2.8] # cat a.sh
trap '' TERM
bash b.sh
[bash-4.2.8] # cat b.sh
echo Now in $0 ...
trap sig_TERM TERM
sig_TERM()
{
echo got SIGTERM, exiting ...
exit
}
kill -TERM $$
sleep 1
echo Not killed?
[bash-4.2.8] # bash a.sh
Now in b.sh ...
Not killed?
[bash-4.2.8] #
-Clark
Re: Signals ignored by a shell cannot be handled by its sub-shells?
On Tue, Jul 12, 2011 at 3:34 PM, Andreas Schwab sch...@linux-m68k.orgwrote: Clark J. Wang dearv...@gmail.com writes: For example: [bash-4.2.8] # cat a.sh trap '' TERM bash b.sh [bash-4.2.8] # cat b.sh echo Now in $0 ... trap sig_TERM TERM http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap Signals that were ignored on entry to a non-interactive shell cannot be trapped or reset, although no error need be reported when attempting to do so. An interactive shell may reset or catch signals ignored on entry. Thanks and I also found that in Bash's man page. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
reverse-i-search not work fine when mapping jj to ESC in vi mode
Try like this: [bash-4.2.8] # set -o vi [bash-4.2.8] # bind -m vi-insert 'jj: \e' [bash-4.2.8] # echo jk [bash-4.2.8] # echo k [bash-4.2.8] # Then press ctrl-r and enter jk to search. It'll find ``echo k'' instead of ``echo jk''. Bug?
Re: path completion with cd tab - similar to tcsh
On Fri, Apr 15, 2011 at 6:19 AM, Peter Toft p...@linuxbog.dk wrote: Hi all I have been using tcsh for a long time on Red Hat Linux boxes, and bash on other UNIX-boxes. One thing I really love with tcsh is the way I can swiftly operate using the TAB to do auto-complete, when having a deep directory hierarchy. I have that... With bash I surely could use your skills to improve my usage of bash (read; allow me to ditch tcsh fully). I have an annoying bash-problem on Red Hat Linux 5.x. If I e.g. try to move to a subdirectory of another directory (e.g. $HOME), where the tab-expand works poorly; Assume $HOME=/home/pto cd $HOMETAB is expanded to cd /home/pto (without the quotes). I get $HOME expanded - quite ok - but I get an annoying space efter the path. I will never like that space, I strongly prefer if I could get cd $HOMETAB expanded to cd /home/pto/ (without the quotes) so I could continue to press TAB and see the allowed sub-directories - much faster for me. I have also understood I can do $ complete -o nospace cd to change the mode of operation, but this seems to disable the auto-complete function when doing cd $VARIABLETAB. I am guestimating, that you have discussed this in February (cf. http://www.gossamer-threads.com/lists/gentoo/user/227574) but the February archive seems to be lost; http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00274.html so I cannot get the details of it. That cited link is suggesting; ESC ctrl-e gets rid of the backslash, and if you want to keep the $VAR as $VAR, backspace over the terminal space and continue. Or you can ESC ctrl-e again, and convert the $VAR to its value, so you won't need to repeat the single ESC ctrl-e for each further tab. which IMHO is not really what I want. Any hints on this? Can I set the mode of operation as I like where the infamous space is replaced by a slash when doing cd ... TAB? Best -- Peter Toft, PhD http://petertoft.dk That also annoys me much. Try like this: $ complete -o default -o nospace -d cd $ cd $VAR/TAB -- Clark J. Wang
Re: multi line bash commands in a Makefile
On Sun, Apr 10, 2011 at 6:17 PM, ali hagigat hagigat...@gmail.com wrote: How can i specify a multi line shell instruction as a recipe? The following returns an error: makefile27: e14: @echo var1=$(var1) makefile25: include makefile27 e12: @echo insidee12 makefile27: e13 if ( test $$count -eq 0) then echo all: ;echo ppp makefile27;count=1;fi When you test $count it's not assigned with a value yet. e13: ; make -f makefile25 if ( test $count -eq 0) then echo all: ;echo ppp makefile27;count=1;fi /bin/sh: line 0: test: -eq: unary operator expected var1= Why it complains about needing a unary operator? -- Clark J. Wang
Re: multi line bash commands in a Makefile
On Sun, Apr 10, 2011 at 7:30 PM, ali hagigat hagigat...@gmail.com wrote: Thanks Clark for the reply. 'count' is set by shell before doing make. like root count=0 Have you exported the 'count' var before invoking make? On Sun, Apr 10, 2011 at 3:10 PM, Clark J. Wang dearv...@gmail.com wrote: On Sun, Apr 10, 2011 at 6:17 PM, ali hagigat hagigat...@gmail.com wrote: How can i specify a multi line shell instruction as a recipe? The following returns an error: makefile27: e14: @echo var1=$(var1) makefile25: include makefile27 e12: @echo insidee12 makefile27: e13 if ( test $$count -eq 0) then echo all: ;echo ppp makefile27;count=1;fi When you test $count it's not assigned with a value yet. e13: ; make -f makefile25 if ( test $count -eq 0) then echo all: ;echo ppp makefile27;count=1;fi /bin/sh: line 0: test: -eq: unary operator expected var1= Why it complains about needing a unary operator? -- Clark J. Wang -- Clark J. Wang
Re: RFE: make [[ compatible with [ 'Option'?
On Tue, Mar 29, 2011 at 3:09 AM, Linda Walsh b...@tlinx.org wrote: Greg Wooledge wrote: On Mon, Mar 28, 2011 at 10:53:21AM -0700, Linda Walsh wrote: if [ ! -e $d/S??sshd ]; then echo sshd not enabled; fi That will fail quite colorfully if the glob matches multiple files. (Also, $d should be quoted.) --- If, in 30 years of unix experience, I'd ever seen multiple matches for the above pattern, I would be concerned... I often use [[ ]] like this: if [[ $filename = *.log ]]; then echo ...; fi You'll often see multiple matches for the above pattern. :) -- Clark J. Wang
Re: BASH_SUBSHELL documentation misleading
On Fri, Mar 25, 2011 at 2:17 AM, Greg Wooledge wool...@eeg.ccf.org wrote: On Thu, Mar 24, 2011 at 06:07:33PM +, Marc Herbert wrote: Not every feature is complicated enough that it requires special documentation care and that it raises a discussion here. BASH_SUBSHELL isn't complicated at all. It's just documented in a confusing way. It doesn't require an example to say that it reports the current subshell depth. It's just that the existing documentation can be interpreted to make someone think that it tracks a running total of how many subshells were created as children of the current shell in the past. That's where Sam got mixed up. Agree. It's not complicated compared to, for example, =~ usage. :) -- Clark J. Wang
Re: case modification won't work with pattern
On Thu, Mar 10, 2011 at 10:22 AM, Jerry Wang
jerry.j.w...@alcatel-lucent.com wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-g -O2 -Wall
uname output: Linux Xubuntu 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11
17:36:01 UTC 2011 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
The case modification won't work with pattern.
I have a simple script a.sh, please see below:
#! /bin/bash
var=abcabc
echo var: ${var}
echo replace the leading \ab\ to uppercase: ${var^ab} # expect
to get ABcabc ?
echo replace all the \ab\ to uppercase: ${var^^ab}# expect
to get ABcABc ?
Case modification does not work the way you expected. It operates on single
chars other than strings.
echo replace the first \a\ to uppercase: ${var^a}
echo replace all \a\ to uppercase: ${var^^a}
Then the result is:
mylogin@Xubuntu:~/shell$ ./a.sh
var: abcabc
replace the leading ab to uppercase: abcabc -- incorrect
replace all the ab to uppercase: abcabc -- incorrect
replace the first a to uppercase: Abcabc -- correct
replace all a to uppercase: AbcAbc-- correct
Repeat-By:
--
Jerry Wang jerry.j.w...@alcatel-lucent.com
--
Clark J. Wang
Re: case modification won't work with pattern
On Thu, Mar 10, 2011 at 10:22 AM, Jerry Wang
jerry.j.w...@alcatel-lucent.com wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-g -O2 -Wall
uname output: Linux Xubuntu 2.6.31-22-generic #73-Ubuntu SMP Fri Feb 11
17:36:01 UTC 2011 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33
Release Status: release
Description:
The case modification won't work with pattern.
I have a simple script a.sh, please see below:
#! /bin/bash
var=abcabc
echo var: ${var}
echo replace the leading \ab\ to uppercase: ${var^ab} # expect
to get ABcabc ?
echo replace all the \ab\ to uppercase: ${var^^ab}# expect
to get ABcABc ?
echo replace the first \a\ to uppercase: ${var^a}
And here it actually replaces the *leading* `a' other than the *first* `a'.
echo replace all \a\ to uppercase: ${var^^a}
Then the result is:
mylogin@Xubuntu:~/shell$ ./a.sh
var: abcabc
replace the leading ab to uppercase: abcabc -- incorrect
replace all the ab to uppercase: abcabc -- incorrect
replace the first a to uppercase: Abcabc -- correct
replace all a to uppercase: AbcAbc-- correct
Repeat-By:
--
Jerry Wang jerry.j.w...@alcatel-lucent.com
--
Clark J. Wang
Re: case modification won't work with pattern
On Thu, Mar 10, 2011 at 9:31 PM, Greg Wooledge wool...@eeg.ccf.org wrote:
On Thu, Mar 10, 2011 at 10:22:12AM +0800, Jerry Wang wrote:
var=abcabc
echo var: ${var}
echo replace the leading \ab\ to uppercase: ${var^ab} # expect
to get ABcabc ?
The documentation is a bit terse, admittedly.
Agree. Almost all of the poeple around me don't understand why it works that
way. Maybe some background of the feature requirement can help us to
understand better.
What the ^ operator
does is compare the *first character* of var to the *glob pattern* which
follows the ^. If the character matches the glob, it gets capitalized.
No single character is ever going to match the glob ab, because it's
two characters long.
--
Clark J. Wang
Re: Hightlighting in bash
On Fri, Mar 11, 2011 at 3:42 AM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: Hi. First off, this isn't a bug report so much as a feature request. I do a lot of cross-compilation of linux and various packages for embedded distros. Version bumps are always perilous because cross-compilation often suffers regression. The problem is that a lot of the regressions don't cause the build to fail... it just generates invalid results. Sometimes (not often but sometimes) an innocuous clue with will buried deep within thousands (or tends of thousands) of lines of make all output. And by output, I mean STDERR. My request is simple. Using termcap/ncurses info (which you need anyway for the readline stuff), it would be nice to have the option of running commands in a pseudo-tty and then bracketing the output from STDERR with highlight on...highlight off. I've ever seen some util like colorgcc. Is that what you want? Of course, that also implies that your writes to wherever STDERR eventually goes are atomic and won't be interspersed with output from STDOUT. I'll let someone more intimate with the particulars of stdio and tty drivers and line disciplines figure that bit out. This would be nice because it would allow one to quickly identify and isolate potentially detrimental error messages from mundane but profuse output that logs commands being invoked, etc. Does this seem doable? Thanks, -Philip -- Clark J. Wang
Re: case modification won't work with pattern
On Fri, Mar 11, 2011 at 11:56 AM, Chris F.A. Johnson
ch...@cfajohnson.comwrote:
I suggested using parameter expansion with patterns in
http://lists.gnu.org/archive/html/bug-bash/2006-02/msg00020.html:
$ foo=bar
$ echo ${foo^} ## Convert first character
Bar
$ echo ${foo^^} ## Convert all characters
BAR
$ echo ${foo^[a-m]} ## Convert first character that matches pattern
Bar
$ echo ${foo^^[a-m]} ## Convert all characters that match pattern
BAr
This sounds more reasonable to me.
--
Chris F.A. Johnson, http://cfajohnson.com/
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
--
Clark J. Wang
Re: case modification won't work with pattern
On Fri, Mar 11, 2011 at 11:33 AM, Chet Ramey chet.ra...@case.edu wrote: On 3/10/11 9:04 PM, Clark J. Wang wrote: Agree. Almost all of the poeple around me don't understand why it works that way. Maybe some background of the feature requirement can help us to understand better. The original requests were for a way to change the first letter or every letter to uppercase or lowercase, like ksh typeset -l/-u, using word expansion syntax (one request was for a new builtin command to do it). That's what you get if you don't use the pattern part of the expansion. I invented the pattern following the case specifier to allow each character to be separately modified. One specific user's requirement is specific. I think the feature can be implemented in a more flexible way which can also meet user's requirement. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- Clark J. Wang
[suggestion] Also document users' requirements for new features
When new features are added to bash I suggest some background info about the feature requirements be also included in the bash doc (like NEWS or ChangeLog). This will help people to understand the feature well. Other languages like Tcl has TIP (Tcl Improvement Proposal: http://www.tcl.tk/cgi-bin/tct/tip) and Python has PEP (Python Enhancement Proposal: http://www.python.org/dev/peps/). -- Clark J. Wang
Re: variable name and its' value are the same characters causes recursion error
On Thu, Mar 10, 2011 at 5:14 AM, Peggy Russell prusselltechgr...@gmail.comwrote: The existing documentation seems pretty clear: ... The value of a variable is evaluated as an arithmetic expression when it is referenced, or when a variable which has been given the integer attribute using declare -i is assigned a value. A null value evaluates to 0. A shell variable need not have its integer attribute turned on to be used in an expression. Hi Chet, I've reread that paragraph a number of times. It could be improved to help the end-user. After the sentence: The value of a variable is evaluated as an arithmetic expression when it is referenced, ... Add the sentence: This evaluation of the variables value will be performed recursively until an arithmetic evaluation is found or the expression recursion level exceeded. Agree. I didn't know it's recursive before. :) For example: unset a; declare a=a; [[ a -lt 3 ]]; echo $? bash: [[: a: expression recursion level exceeded (error token is a) 1 Shouldn't the return code from this expression be 2, rather than 1? Thank you. Peg -- Clark J. Wang
Re: variable name and its' value are the same characters causes recursion error
On Thu, Mar 10, 2011 at 5:14 AM, Peggy Russell prusselltechgr...@gmail.comwrote: The existing documentation seems pretty clear: ... The value of a variable is evaluated as an arithmetic expression when it is referenced, or when a variable which has been given the integer attribute using declare -i is assigned a value. A null value evaluates to 0. A shell variable need not have its integer attribute turned on to be used in an expression. Hi Chet, I've reread that paragraph a number of times. It could be improved to help the end-user. After the sentence: The value of a variable is evaluated as an arithmetic expression when it is referenced, ... Add the sentence: This evaluation of the variables value will be performed recursively until an arithmetic evaluation is found or the expression recursion level exceeded. Actually I don't like the recursion here. Does POSIX require that? For example: unset a; declare a=a; [[ a -lt 3 ]]; echo $? bash: [[: a: expression recursion level exceeded (error token is a) 1 Shouldn't the return code from this expression be 2, rather than 1? Thank you. Peg -- Clark J. Wang
Re: bash tab variable expansion question?
On Sat, Feb 26, 2011 at 10:49 PM, gnu.bash.bug michael.kal...@gmail.comwrote: Wow...I'ts good workaround: $ cd /tmp $ echo ~+ /tmp Thanks Andreas! A workaround is fine but is the 4.2 behavior bug or not? //Michael On 26 Feb, 09:09, Andreas Schwab sch...@linux-m68k.org wrote: gnu.bash.bug michael.kal...@gmail.com writes: What do you mean? ~-/. is no equal to $PWD If you want $PWD, you can use ~+/. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- Clark J. Wang
Re: bash tab variable expansion question?
On Fri, Feb 25, 2011 at 5:46 PM, Davide Brini dave...@gmx.com wrote: On Friday 25 Feb 2011 05:15:24 Eric Blake wrote: On 02/24/2011 03:14 PM, Michael Kalisz wrote: $ echo $PWD/TAB will expand the $PWD variable to your current directory while in bash, version 4.2.0(1)-release: $ echo $PWD/TAB will just escape the $ in front of the $ variable i.e: $ echo \$PWD/ The shell-expand-line (Ctrl-Alt-e) works but before I could use just TAB Any hints why? Any way to get the 4.1 behavior in 4.2? Can someone confirm... Is this a bug or a feature? I'm not the developer, but in my mind, this is a welcome feature. TAB-completion should NOT modify what I typed, and I consider the 4.1 behavior to be the bug. Maybe, but then it shouldn't escape the $ either, as the OP is reporting for 4.2 (I don't have a 4.2 handy to test it). Agree, $ should not be escaped here which is different from pathname completion. -- Clark J. Wang
Re: bash tab variable expansion question?
On Fri, Feb 25, 2011 at 1:15 PM, Eric Blake ebl...@redhat.com wrote: On 02/24/2011 03:14 PM, Michael Kalisz wrote: $ echo $PWD/TAB will expand the $PWD variable to your current directory while in bash, version 4.2.0(1)-release: $ echo $PWD/TAB will just escape the $ in front of the $ variable i.e: $ echo \$PWD/ The shell-expand-line (Ctrl-Alt-e) works but before I could use just TAB Any hints why? Any way to get the 4.1 behavior in 4.2? Can someone confirm... Is this a bug or a feature? I'm not the developer, but in my mind, this is a welcome feature. TAB-completion should NOT modify what I typed, It's not true, see this discussion: http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00163.html and I consider the 4.1 behavior to be the bug. I'd like to view it as a feature. ;) Consider if I have parallel directory structures a/c and b/c. If I do: d=a $d/c/test d=b $d/c/test I want to run two different programs. Now, instead of a one-letter name, consider that it is something longer, like $HOME. If typing TAB expands the variable, instead of keeping it intact, then I can't do: $HOME/c/t-TAB $HOME=b UP-UP-ENTER to repeat my test in a new directory, since tab completion wiped out that I want to evaluate $HOME every time. (The same goes for command substitution - bash should never pre-maturely lock me in to a single expansion during tab completion.) -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Clark J. Wang
Re: Question. Autocomplete paths starting with %.
On Sat, Feb 19, 2011 at 9:20 PM, d...@ucore.info d...@ucore.info wrote:
I can script in Bash quite well, but I've never did anything that
fancy with completion and I don't know how to plug my function to
handle this. I understand that I should register something (function
named like _bookmarkcomp) to handle filename completion for things
beginning with %.
If you help me with this one I promise to post my solution for benefit
of other bash users.
Regards,
Dawid
--
http://dpc.ucore.info
I can give you an example here:
bash# vi compgen-example.sh
_compgen_foo()
{
local cmd=$1 cur=$2 pre=$3
if [[ $cur = % ]]; then
COMPREPLY[0]='it-works'
fi
}
complete -F _compgen_foo foo
bash# source compgen-example.sh
bash# foo %TAB-- Press TAB here
bash# foo it-works-- `%' will be expanded like this
--
Clark J. Wang
``complete -b'' does not include ``coproc''
Tested with 4.2: bash-4.2# complete -b help bash-4.2# help coTABTAB command compgen complete compopt continue bash-4.2# -- Clark J. Wang
Re: ``complete -b'' does not include ``coproc''
On Mon, Feb 21, 2011 at 4:21 PM, Pierre Gaston pierre.gas...@gmail.comwrote: On Mon, Feb 21, 2011 at 10:12 AM, Clark J. Wang dearv...@gmail.comwrote: Tested with 4.2: bash-4.2# complete -b help bash-4.2# help coTABTAB command compgen complete compopt continue bash-4.2# -- Clark J. Wang It's probably because: $ type coproc coproc is a shell keyword likewise help timTAB doesn't complete time I just checked and found that I actually write this in my bashrc: complete -A helptopic help But after bash loads my bashrc the compspec was changed to: # complete -p help complete -b help # And even ``helptopic'' does not show ``coproc'' either: # compgen -A helptopic co command compgen complete compopt continue # Should ``coproc'' be included in ``-A helptopic''? -- Clark J. Wang
Re: ``complete -b'' does not include ``coproc''
On Mon, Feb 21, 2011 at 10:26 PM, Chet Ramey chet.ra...@case.edu wrote: On 2/21/11 3:55 AM, Clark J. Wang wrote: And even ``helptopic'' does not show ``coproc'' either: # compgen -A helptopic co command compgen complete compopt continue # Should ``coproc'' be included in ``-A helptopic''? At this point, helptopic is a synonym for builtin. OK. I can use ``complete -b -k help''. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- Clark J. Wang
Re: [bash4.2] ${v//[/} bug?
On Sat, Feb 19, 2011 at 1:02 PM, Chet Ramey chet.ra...@case.edu wrote:
On 2/15/11 10:16 PM, Clark J. Wang wrote:
On Wed, Feb 16, 2011 at 9:59 AM, Chet Ramey chet.ra...@case.edu
mailto:chet.ra...@case.edu wrote:
On 2/15/11 6:18 AM, Clark J. Wang wrote:
For following script:
var='[hello'
echo ${var//[/}
With bash 4.1 it outputs hello but with 4.2 it outputs [hello . And
bash 4.2
with compat41 on still outputs [hello . Bug? Or Bug fixed?
It's a bug, and I will release a patch. In the meantime, see if the
attached patch does the right thing on your platform.
The patch fixed this simple example but it does not work for more
complicated scenario:
Yes, it was a quick fix for the immediate problem. Please try the
attached patch for a more complete solution.
Works for me. Thanks.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
--
Clark J. Wang
Re: Why escape char `:' with `\' when auto completing filenames?
On Mon, Feb 21, 2011 at 9:21 AM, Chet Ramey chet.ra...@case.edu wrote:
On 2/18/11 6:52 AM, Clark J. Wang wrote:
Sth was wrong for my testing. I removed @ from COMP_WORDBREAKS but
afterwards one bind command (bind set bell-style none) added @ back.
I can't reproduce this:
$ echo $BASH_VERSION
4.2.0(22)-maint
$ echo ${COMP_WORDBREAKS}
'@=;|(:
$ COMP_WORDBREAKS=${COMP_WORDBREAKS/@/}
$ echo ${COMP_WORDBREAKS}
'=;|(:
$ bind 'set bell-style none'
$ echo ${COMP_WORDBREAKS}
'=;|(:
I can reproduce this in my 2000+ lines of bashrc but I can't if I run the
command from the command line. I'll see what's the problem.
Bash hostname completion is independent of the more-recently-added
programmable completion, which I suspect you might be using.
The default bash completion breaks words at @ and attempts to complete
hostnames from its own internal list. Look at the description of
HOSTFILE and the readline `complete' function in the manual page.
There is a shell option (`hostcomplete') to turn this on and off.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
--
Clark J. Wang
Re: Why escape char `:' with `\' when auto completing filenames?
On Mon, Feb 21, 2011 at 9:21 AM, Chet Ramey chet.ra...@case.edu wrote:
On 2/18/11 6:52 AM, Clark J. Wang wrote:
Sth was wrong for my testing. I removed @ from COMP_WORDBREAKS but
afterwards one bind command (bind set bell-style none) added @ back.
I can't reproduce this:
$ echo $BASH_VERSION
4.2.0(22)-maint
$ echo ${COMP_WORDBREAKS}
'@=;|(:
$ COMP_WORDBREAKS=${COMP_WORDBREAKS/@/}
$ echo ${COMP_WORDBREAKS}
'=;|(:
$ bind 'set bell-style none'
$ echo ${COMP_WORDBREAKS}
'=;|(:
I just tried with a very simple ~/.bashrc:
COMP_WORDBREAKS=${COMP_WORDBREAKS//[:@]/}
printf '%q\n' $COMP_WORDBREAKS
bind set bell-style none
printf '%q\n' $COMP_WORDBREAKS
When bash starts, I can see:
$' \t\n\'=;|('
$'@ \t\n\'=;|('
bash-4.2#
And other bind command like bind set completion-ignore-case on can also
reproduce.
Note that I tested on Debian 6.0 (i686).
Bash hostname completion is independent of the more-recently-added
programmable completion, which I suspect you might be using.
The default bash completion breaks words at @ and attempts to complete
hostnames from its own internal list. Look at the description of
HOSTFILE and the readline `complete' function in the manual page.
There is a shell option (`hostcomplete') to turn this on and off.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
--
Clark J. Wang
Re: Why escape char `:' with `\' when auto completing filenames?
On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab sch...@linux-m68k.orgwrote: Maarten Billemont lhun...@gmail.com writes: Why are we escaping all word break characters? rm file:name and rm file\:name are effectively identical, I'm not sure I see the need for escaping it. How do you differentiate between completing file:name and completing file:name? I don't understand what did you mean. :( Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- Clark (Jian) WANG
Re: Why escape char `:' with `\' when auto completing filenames?
On Fri, Feb 18, 2011 at 6:36 PM, Andreas Schwab sch...@linux-m68k.orgwrote: Clark J. Wang dearv...@gmail.com writes: On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab sch...@linux-m68k.org wrote: Maarten Billemont lhun...@gmail.com writes: Why are we escaping all word break characters? rm file:name and rm file\:name are effectively identical, I'm not sure I see the need for escaping it. How do you differentiate between completing file:name and completing file:name? I don't understand what did you mean. :( You just proved my point. It's funny? What's your point and how did I proved it? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- Clark J. Wang
Re: Why escape char `:' with `\' when auto completing filenames?
On Fri, Feb 18, 2011 at 6:21 PM, Clark J. Wang dearv...@gmail.com wrote: On Fri, Feb 18, 2011 at 6:02 AM, Chet Ramey chet.ra...@case.edu wrote: For pete's sake. If you don't think they should be word break characters, modify the value of COMP_WORDBREAKS. For the record, @ causes a word break so you can complete hostnames more easily, = breaks so you can complete filenames on the rhs of assignment statements, and : breaks so you can complete filenames in words that look like $PATH. I don't understand your point. I did a testing by removing @ from COMP_WORDBREAKS and then hostname autocompletion still worked fine (e.g.: ssh user@host). Sth was wrong for my testing. I removed @ from COMP_WORDBREAKS but afterwards one bind command (bind set bell-style none) added @ back. Are we really spending this much time on a cosmetic issue? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- Clark (Jian) WANG -- Clark J. Wang
Re: Why escape char `:' with `\' when auto completing filenames?
On Fri, Feb 18, 2011 at 6:48 PM, Pierre Gaston pierre.gas...@gmail.comwrote: On Fri, Feb 18, 2011 at 12:17 PM, Clark J. Wang dearv...@gmail.comwrote: On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab sch...@linux-m68k.org wrote: Maarten Billemont lhun...@gmail.com writes: Why are we escaping all word break characters? rm file:name and rm file\:name are effectively identical, I'm not sure I see the need for escaping it. How do you differentiate between completing file:name and completing file:name? I don't understand what did you mean. :( If you complete PATH, you want to be able to press tab after: PATH=/bin:/home/clark/ so that it completes /home/clark If you complete a file named 'foo:bar' you want to be able to press tab after: ls foo:b so that it completes just foo:b So how bash can decide if if it should complete just b like in the example of PATH or foo:b? That makes it more clear to me. Thanks. -- Clark J. Wang
Re: [bash 4.2] `declare -g' bug?
On Fri, Feb 18, 2011 at 9:35 PM, Greg Wooledge wool...@eeg.ccf.org wrote: On Fri, Feb 18, 2011 at 11:25:48AM +0800, Clark J. Wang wrote: A global var can always be declared out of a func (usually at the beginning of the script) so what's the main intention of introducing a new `-g' option? The main reason, as I understand it, is so that you can declare an associative array inside a function and have it be readable in the caller. Unlike all other variables (strings, regular arrays), associative arrays *must* be declared. But the declare builtin had the unfortunate (for some purposes) side effect of also marking the variable as local. Prior to bash 4.2, any such associative array would have to be declared outside the function. So, imagine a function like: # pqp - parse query parameters # Input: QUERY_STRING environment variable # Output: associative array 'qparams' containing CGI parameters as keys. # (If a parameter is repeated, only the last instance is retained.) In bash 4.2, the caller would have to pre-define the qparams associative array, because the function cannot declare it at the global scope. In bash 4.2, the function can create the array itself. Is that a huge difference? Maybe not, but it's just more natural to do it the 4.2 way. Thanks for the kind explanation, Greg. I think the problem is that if people do not understand the feature requirement so they just cannot understand the feature well unless the feature works in a straightforward way. That's why I asked the question. And If we can declare/modify a global var in a func but we cannot read it from in the func I don't think the feature is very useful to people. Your example was interesting, but it was extremely convoluted. I tell people over and over that writing big complicated shell scripts (or worse, reusable libraries of shell code... *shudder*) is simply a BAD idea. But nobody ever listens. Agree. I was offen depressed because of that. :) In the normal case, when you write a shell script that only has one or two functions in it, and there's no shadowing of global variables with local variables by the same name, everything works as you expect. I'll let you and Chet hammer out what to do in the more complex cases. -- Clark J. Wang
Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]
On Fri, Feb 18, 2011 at 9:10 PM, Greg Wooledge wool...@eeg.ccf.org wrote: On Thu, Feb 17, 2011 at 05:18:23PM -0500, Chet Ramey wrote: Maybe if the man page had read ...to force the quoted portion to be matched as a string this could have been avoided. I like this answer. Removing ambiguity (it could refer to the whole pattern or to the quoted portion) is always good. After such a long discussion and I thought about it more. Isn't so difficult for people to really understand the correct syntax of =~ matching? I just felt that 3.1 behavior is much more straightforward for me to understand. -- Clark J. Wang
Why escape char `:' with `\' when auto completing filenames?
For example: # touch ifcfg-eth-id-00:0c:29:b5:71:d2 # ls ifcfgTAB After pressing the TAB the command line will become to: # ls ifcfg-eth-id-00\:0c\:29\:b5\:71\:d2 That's a bit annoying. I think char `:' is not special in bash. Any reasonable consideration for the behavior? -- Clark
Re: Why escape char `:' with `\' when auto completing filenames?
On Thu, Feb 17, 2011 at 5:00 PM, Andreas Schwab sch...@linux-m68k.orgwrote: Clark J. Wang dearv...@gmail.com writes: I think char `:' is not special in bash. $ printf %q\n $COMP_WORDBREAKS $' \t\n\'=;|(:' I don't think that explain the issue. Try like this (tested with 4.2): # COMP_WORDBREAKS+=- # touch - # ls TAB-- Here the `-' char will not be escaped And, even the char `)' is not by default included in COMP_WORDBREAKS it'll also be escaped with filename autocompletion. Seems like the behavior has no direct relation with the var COMP_WORDBREAKS. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- Clark
Re: Why escape char `:' with `\' when auto completing filenames?
On Thu, Feb 17, 2011 at 6:19 PM, Andreas Schwab sch...@linux-m68k.orgwrote:
Clark J. Wang dearv...@gmail.com writes:
On Thu, Feb 17, 2011 at 5:00 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
Clark J. Wang dearv...@gmail.com writes:
I think char `:' is not special in bash.
$ printf %q\n $COMP_WORDBREAKS
$' \t\n\'=;|(:'
I don't think that explain the issue.
/* characters that need to be quoted when appearing in filenames. */
rl_filename_quote_characters = \t\n\\\'@=;|()#$`?*[!:{~;
/*}*/
So that's problem. I don't think @=: need to be treated specially. Any
reason?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
Clark
Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]
See following script output: bash-4.2# cat quoted-pattern.sh [[ .a == \.a* ]] echo 1 # not quoted [[ aa =~ \.a* ]] echo 2 # quoted [[ aa =~ \a. ]] echo 3 # not quoted [[ aa =~ \a\. ]] echo 4 # quoted bash-4.2# bash42 quoted-pattern.sh 1 3 bash-4.2# From my understanding 1 2 3 4 should all be printed out. -- Clark
Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]
On Thu, Feb 17, 2011 at 9:20 PM, Andreas Schwab sch...@linux-m68k.orgwrote: Clark J. Wang dearv...@gmail.com writes: See following script output: bash-4.2# cat quoted-pattern.sh [[ .a == \.a* ]] echo 1 # not quoted [[ aa =~ \.a* ]] echo 2 # quoted [[ aa =~ \a. ]] echo 3 # not quoted [[ aa =~ \a\. ]] echo 4 # quoted bash-4.2# bash42 quoted-pattern.sh 1 3 bash-4.2# From my understanding 1 2 3 4 should all be printed out. aa contains no period, so why should it be matched? If it should not be matched why I got 3 printed out? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- Clark
Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]
On Thu, Feb 17, 2011 at 7:09 PM, Clark J. Wang dearv...@gmail.com wrote: See following script output: bash-4.2# cat quoted-pattern.sh [[ .a == \.a* ]] echo 1 # not quoted [[ aa =~ \.a* ]] echo 2 # quoted [[ aa =~ \a. ]] echo 3 # not quoted [[ aa =~ \a\. ]] echo 4 # quoted bash-4.2# bash42 quoted-pattern.sh 1 3 bash-4.2# From my understanding 1 2 3 4 should all be printed out. The point is: ``Any part of the pattern may be quoted to force it to be matched as a string.'' And backslash is one of bash's quoting chars. But in my examples, a pattern with `\' in it sometimes is considered to be quoted and sometimes unquoted. It's not clear to me what's the exact rule to tell if a pattern is quoted or not. -- Clark
Re: Why escape char `:' with `\' when auto completing filenames?
On Thu, Feb 17, 2011 at 9:10 PM, Andreas Schwab sch...@linux-m68k.orgwrote:
Clark J. Wang dearv...@gmail.com writes:
On Thu, Feb 17, 2011 at 6:19 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
Clark J. Wang dearv...@gmail.com writes:
On Thu, Feb 17, 2011 at 5:00 PM, Andreas Schwab
sch...@linux-m68k.org
wrote:
Clark J. Wang dearv...@gmail.com writes:
I think char `:' is not special in bash.
$ printf %q\n $COMP_WORDBREAKS
$' \t\n\'=;|(:'
I don't think that explain the issue.
/* characters that need to be quoted when appearing in filenames. */
rl_filename_quote_characters = \t\n\\\'@=;|()#$`?*[!:{~;
/*}*/
So that's problem. I don't think @=: need to be treated specially. Any
reason?
They are used as word break characters during completion.
That's the way it's implemented but that does not mean that's reasonable.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]
On Thu, Feb 17, 2011 at 11:02 PM, Greg Wooledge wool...@eeg.ccf.org wrote: On Thu, Feb 17, 2011 at 10:56:21PM +0800, Clark J. Wang wrote: The point is: ``Any part of the pattern may be quoted to force it to be matched as a string.'' And backslash is one of bash's quoting chars. But in my examples, a pattern with `\' in it sometimes is considered to be quoted and sometimes unquoted. It's not clear to me what's the exact rule to tell if a pattern is quoted or not. Your life will be greatly simplified if you observe the following rule of thumb for =~ matching: ALWAYS put the pattern into a variable. r='whatever you want' if [[ $foo =~ $r ]]; then ... This works around the behavior change that occurred during the 3.x series, as well as all your quoting concerns and questions. I really know that's the best practice. I just want to make it clear if bash itself is doing right.
Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]
On Thu, Feb 17, 2011 at 11:04 PM, Andreas Schwab sch...@linux-m68k.orgwrote: Clark J. Wang dearv...@gmail.com writes: The point is: ``Any part of the pattern may be quoted to force it to be matched as a string.'' it == part of the pattern. So I've always been misunderstanding the bash manual (I'm not a native English speaker :-) Or the manual is actually a bit misleading? :) It's not clear to me what's the exact rule to tell if a pattern is quoted or not. The rule is the same as everywhere: a quoted character loses its special meaning. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- ``... And it's a bash bug. I don't understand why bash people can't accept that.'' - Linus Torvalds
Re: [bash 4.2] `declare -g' bug?
On Fri, Feb 18, 2011 at 8:45 AM, Chet Ramey chet.ra...@case.edu wrote: The -g option exists solely to create variables at the global scope. The intent is that functions be able to declare global variables with attributes if they desire. It doesn't change the scoping rules or variable resolution behavior. A global var can always be declared out of a func (usually at the beginning of the script) so what's the main intention of introducing a new `-g' option? And If we can declare/modify a global var in a func but we cannot read it from in the func I don't think the feature is very useful to people. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- ``... And it's a bash bug. I don't understand why bash people can't accept that.'' - Linus Torvalds
Re: typeset -r prevents local variable of same name.
On Thu, Feb 17, 2011 at 11:13 AM, Chet Ramey chet.ra...@case.edu wrote: On 2/13/11 3:17 PM, ste...@syslang.net wrote: Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables uname output: Linux saturn.syslang.net 2.6.27.41-170.2.117.fc10.i686.PAE #1 SMP Thu Dec 10 10:48:30 EST 2009 i686 athlon i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: First, I already submitted this bug from work, but I didn't realize that the address I sent from would not be allowed to receive a response. This address will work fine. If I declare a variable at the top scope using -r, it will prevent me from declaring a local copy in a subroutine. This problem happens in this version of bash as well as in bash4 under Fedora 14. This is intentional. A variable is declared readonly for a reason, and readonly variables may not be assigned to. I don't believe that you should be able to use a function to circumvent this. That makes little sense to me. I don't see any disadvantages if a local var is allowed to use the same name as a global readonly var. And with current bash behavior we may see var name collisions even with the local keyword. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- Clark
[bash 4.2] In vi mode, cc failed to change the whole line
For example, in vi insert mode, I first enter a command like this: # hello world Then I press ESC and type cc, the cursor just moves to the beginning (under the char `h') and the whole line is not emptied. If I type more chars after cc, only the first `h' char is replaced and following `ello world' keeps unchanged. Note that other vi mode commands like cw and c$ work fine. I'm using Debian 6.0 (i686) and here's some of my system info: # bash --version GNU bash, version 4.2.0(1)-release (i686-pc-linux-gnu) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. # dpkg -l | grep -E 'readline|ncurses' ii libncurses55.7+20100313-5 shared libraries for terminal handling ii libncurses5-dev5.7+20100313-5 developer's libraries and docs for ncurses ii libncursesw5 5.7+20100313-5 shared libraries for terminal handling (wide character support) ii libreadline5 5.2-7GNU readline and history libraries, run-time libraries ii libreadline6 6.1-3GNU readline and history libraries, run-time libraries ii ncurses-base 5.7+20100313-5 basic terminal type definitions ii ncurses-bin5.7+20100313-5 terminal-related programs and man pages ii ncurses-term 5.7+20100313-5 additional terminal type definitions ii readline-common6.1-3GNU readline and history libraries, common files # ldd /usr/local/bash-4.2.0/bin/bash linux-gate.so.1 = (0xb773) libncurses.so.5 = /lib/libncurses.so.5 (0xb76ec000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb76e8000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb75a1000) /lib/ld-linux.so.2 (0xb7731000) # By the way I don't understand why there's no libreadline in the output of `ldd bash'. Anyone can explain? -- Clark
Do more testing before a release?
I know little about open source development process (and control?). I just don't know where to get the bash code (like CVS, SVN respository) before it's released. I think it's better to make it open to more people so everyone can help review and test before a stable release. -- Clark
Re: Do more testing before a release?
On Thu, Feb 17, 2011 at 1:38 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, February 16, 2011 23:51:16 Clark J. Wang wrote: I know little about open source development process (and control?). I just don't know where to get the bash code (like CVS, SVN respository) before it's released. I think it's better to make it open to more people so everyone can help review and test before a stable release. the 4.2 rc1 was announced on the list and garnered testing/feedback Sorry I found no threads about 4.2 rc1 and rc2 was annouced only a few days ago. -mike -- Clark
Re: [bash 4.2] In vi mode, cc failed to change the whole line
On Thu, Feb 17, 2011 at 12:43 PM, Clark J. Wang dearv...@gmail.com wrote: # ldd /usr/local/bash-4.2.0/bin/bash linux-gate.so.1 = (0xb773) libncurses.so.5 = /lib/libncurses.so.5 (0xb76ec000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb76e8000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb75a1000) /lib/ld-linux.so.2 (0xb7731000) # By the way I don't understand why there's no libreadline in the output of `ldd bash'. Anyone can explain? Got it. Bash compiled its own version of libreadline.a (static lib). -- Clark -- Clark
[bash4.2] ${v//[/} bug?
For following script:
var='[hello'
echo ${var//[/}
With bash 4.1 it outputs hello but with 4.2 it outputs [hello . And bash 4.2
with compat41 on still outputs [hello . Bug? Or Bug fixed?
--
Clark
Re: [bash4.2] ${v//[/} bug?
On Wed, Feb 16, 2011 at 9:20 AM, Chet Ramey chet.ra...@case.edu wrote:
On 2/15/11 6:18 AM, Clark J. Wang wrote:
For following script:
var='[hello'
echo ${var//[/}
With bash 4.1 it outputs hello but with 4.2 it outputs [hello . And bash
4.2
with compat41 on still outputs [hello . Bug? Or Bug fixed?
This is strange. It echoes hello on Mac OS X, but [hello on
Red Hat. I'll have to take a look at where the difference might be.
I tested bash 4.2 on Debian 6.0. And bash 4.1 behaves the same on Linux and
Mac OS X (10.4 PPC).
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
--
Clark
Re: [bash4.2] ${v//[/} bug?
On Wed, Feb 16, 2011 at 9:59 AM, Chet Ramey chet.ra...@case.edu wrote:
On 2/15/11 6:18 AM, Clark J. Wang wrote:
For following script:
var='[hello'
echo ${var//[/}
With bash 4.1 it outputs hello but with 4.2 it outputs [hello . And bash
4.2
with compat41 on still outputs [hello . Bug? Or Bug fixed?
It's a bug, and I will release a patch. In the meantime, see if the
attached patch does the right thing on your platform.
The patch fixed this simple example but it does not work for more
complicated scenario:
bash# cat foo.sh
var='[hello'
echo ${var//[/}
red='\[\e[0;31m\]'
echo ${red//\\[\\e/}
bash# /usr/local/bash-4.1.9/bin/bash foo.sh
hello
[0;31m\]
bash# /usr/local/bash-4.2.0/bin/bash foo.sh
[hello
\[\e[0;31m\]
bash# /usr/local/bash-4.2.0-fix/bin/bash foo.sh
hello
\[\e[0;31m\]
bash#
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
--
Clark
Re: help's blank lines have four spaces appended
On Fri, Feb 11, 2011 at 11:16 PM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/11 4:02 AM, Clark J. Wang wrote: On Mon, Feb 7, 2011 at 12:01 AM, Chet Ramey chet.ra...@case.edu mailto:chet.ra...@case.edu wrote: On 2/6/11 2:01 AM, jida...@jidanni.org mailto:jida...@jidanni.org wrote: Why add the four spaces? Because all lines are prefixed by four spaces to separate the text from the usage synopsis. That makes sense but don't add the four spaces for blank lines. What does it matter? No matter. Just looks nicer. :) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- Clark
Re: Don't show help of `readonly' and `readarray' when I run `help read'
I forgot to reply to all On Fri, Feb 11, 2011 at 11:15 PM, Chet Ramey chet.ra...@case.edu wrote: On 2/11/11 3:53 AM, Clark J. Wang wrote: On Thu, Feb 10, 2011 at 10:21 PM, Chet Ramey chet.ra...@case.edu mailto:chet.ra...@case.edu wrote: On 2/10/11 4:03 AM, Clark J. Wang wrote: help: help [-dms] [pattern ...] From my understanding the *pattern* here must be a glob-style pattern (wildcard) so `readonly' does not match the pattern `read'. The pattern is composed of the same characters as a glob pattern, but it's treated more like 'grep ^pattern topic' if it doesn't contain any special pattern matching characters. Kind of like the following: $ printf %s\n read readonly readarray | grep ^read /dev/stdin read readonly readarray But the command `help rea?' can only prints help for `read' so I don't think it's treated more like 'grep ^pattern topic'. But that contains a pattern character. I said above that it was treated like grep if it didn't contain any special pattern matching characters. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- Clark
Re: help builtin bug ???
2011/1/20 Sławomir Iwanek slawomir.iwa...@poczta.fm hello, and what about this: $ help () it opens some program in an interactive mode (which one?). It seems like it does not react on any command, like '?', giving the output: bash: błąd składni przy nieoczekiwanym znaczniku `?' (it's in Polish - meaning syntax error at '?' mark) and quits immediately to the regular prompt in my shell. That's what bash should do by definition. :) Hope, it is not a way to get through any security in the system. How to analyze it? brgds, S.Iwanek PS -- I wrote about it also to Chet Ramey. Dnia 2011-01-20, o godz. 01:22:31 Sławomir Iwanek slawomir.iwa...@poczta.fm napisał(a): hello, I did something like that: $ help * and I got all the definitions of builtins starting from the letter 'c' that is from 'caller' through 'coproc'. Well, my goal was - as you probably happen to know it already ;) - to see if I could display ALL the builtins defs, but well... I got what I got. My system: Fedora 14 My bash: GNU bash, version 4.1.7(1)-release (i386-redhat-linux-gnu) Regards, Slawomir Iwanek Nie przepłacaj! Ksiegowość za 0 zł + prezent! Sprawdź http://linkint.pl/f28f5 -- Clark
Re: Making $! and $? searchable in the man page
On Fri, Jan 7, 2011 at 1:33 AM, Greg Wooledge wool...@eeg.ccf.org wrote:
On Thu, Jan 06, 2011 at 10:48:33AM +0100, Vidar Holen wrote:
Hi,
Finding the meaning of $? and $! in the man page is quite hard for people
not familiar with the layout and bash terminology (this frequently comes
up in Freenode #bash). It would be very helpful for them if you could
simply search for $! to find the description of the parameter !.
I absolutely second this. In fact, I sent a very similar patch for this
last year.
Agree. Also for this:
${parameter}
The value of parameter is substituted. The braces are
required
when parameter is a positional parameter with more than
one
digit, or when parameter is followed by a character which is
not
to be interpreted as part of its name.
If the first character of parameter is an exclamation point, a level
of
variable indirection is introduced.
I recommend to add another line just after ${parameter}:
${parameter}
${!parameter}
--
Clark
Why `echo -n hello | while read v; do echo $v; done' prints nothing?
Following command also prints nothing, confused :( for ((i = 0; i 10; ++i)); do echo -n $i; done | while read v; do echo $v; done -- Clark
Re: Why `echo -n hello | while read v; do echo $v; done' prints nothing?
On Thu, Dec 2, 2010 at 11:49 PM, Greg Wooledge wool...@eeg.ccf.org wrote: On Thu, Dec 02, 2010 at 07:04:57PM +0800, Clark J. Wang wrote: Following command also prints nothing, confused :( for ((i = 0; i 10; ++i)); do echo -n $i; done | while read v; do echo $v; done The output from the first command in the pipeline does not end with a newline. Therefore, 'read' in the second command returns 'failure' (non-zero) when it reads the first line of input, and your loop never iterates. But is that reasonable? I think read should return success in this case which makes more sense to me. Does the POSIX standards require that? -- Clark
Re: How is $string translated?
On Mon, Aug 30, 2010 at 7:30 PM, Pierre Gaston pierre.gas...@gmail.comwrote: On Mon, Aug 30, 2010 at 1:35 PM, Clark J. Wang dearv...@gmail.com wrote: The Bash manual says: A double-quoted string preceded by a dollar sign ($) will cause the string to be translated according to the current locale. If the current locale is C or POSIX, the dollar sign is ignored. If the string is translated and replaced, the replacement is double-quoted. Anyone can give an example to show how the $string is translated? see: http://mywiki.wooledge.org/BashFAQ/098 Thanks. I'll check that out.
Re: Issues when func name is the same with an alias
On Thu, Aug 5, 2010 at 4:06 PM, Marc Herbert marc.herb...@gmail.com wrote:
Le 04/08/2010 15:29, Clark J. Wang a écrit :
I do not agree. Aliases are much simpler to use than functions.
Please provide examples.
The following is a part of my aliases. I'll have to write much more code if
I define them all as functions. I don't think functions are better than
aliases here. Any idea?
A='alias | grep ^alias .= | sed -e s/^alias // | LC_ALL=C command grep
^[a-zA-Z]'
B='builtin'
C='command'
D='date +%a %Y-%m-%d %H:%M:%S (%z %Z)'
E='export'
F='find'
G='git'
H='history'
I='ifconfig'
K='killall'
L='less'
M='LC_ALL=C man'
N='netstat'
O='openssl'
P='popd'
Q='[[ $WINDOW ]] screen -X at '\''#'\'' stuff $'\''exit\n'\'''
R='route'
S='sudo'
T='touch'
U='uname'
V='echo $BASH_VERSION'
W='watch'
X='screen -X'
Y='yast2'
Z='reset'
a='alias'
b='builtin cd -'
c='clear'
d='dirs -v'
e='echo'
f='file'
g='grep'
h='help'
i='info --vi-keys'
j='jobs'
k='kill'
l='ls -l'
m='make'
n='mount'
p='pushd'
q='exit'
r='fc -s'
s='screen'
t='type'
u='umount'
v='vim'
w='w'
x='xargs'
y='yast'
z='echo ${COLUMNS}x$LINES'
Re: Issues when func name is the same with an alias
On Fri, Aug 6, 2010 at 9:54 AM, Chris F.A. Johnson ch...@cfajohnson.comwrote:
On Fri, 6 Aug 2010, Clark J. Wang wrote:
On Thu, Aug 5, 2010 at 4:06 PM, Marc Herbert marc.herb...@gmail.com
wrote:
Le 04/08/2010 15:29, Clark J. Wang a écrit :
I do not agree. Aliases are much simpler to use than functions.
Please provide examples.
The following is a part of my aliases. I'll have to write much more code
if
I define them all as functions.
This is much more code:
F(){ find $@; }
This simple func definition will be 4 lines in my coding style. :) And I
like adding at least one blank line between functions.
than:
alias F=find
I don't think functions are better than aliases here. Any idea?
Many reasons why functions are generally better have already been
given.
I understand functions are *generally* better and there're quite a lot of
functions defined in my bashrc. I just don't agree we have to avoid using
aliases.
--
Chris F.A. Johnson, http://cfajohnson.com
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: Issues when func name is the same with an alias
On Wed, Aug 4, 2010 at 7:03 PM, Marc Herbert marc.herb...@gmail.com wrote: Le 04/08/2010 11:39, Clark J. Wang a écrit : Seems like I must explicitly use the `function' keyword to define foo() for this scenario. Is that the correct behavior? The correct behaviour is simply not to use aliases, since they bring nothing to the table compared to functions. Have a look at this: http://thread.gmane.org/gmane.comp.shells.bash.bugs/13865/focus=13901 I do not agree. Aliases are much simpler to use than functions. I use almost all (51 out of 52) the single letters ([:alpha:]) to define aliases. I would not like a shell which has no aliases support. About the function keyword have a look at the discussion two days ago.
Re: function grammar
On Mon, Jul 19, 2010 at 2:53 AM, Linda Walsh b...@tlinx.org wrote:
from man bash, to define a function use;
function name compound-command
OR
name () compound-command
right?
And Compound Commands are:
( list)
{ list; )
(( expression ))
[[ expression ]]
...et al
so why do I get a syntax error for
function good_dir [[ -n $1 -d $1 -r $1 -x $1 ]]
bash: syntax error near unexpected token `[['
You should enclose the function body code in between `{' and `}':
function good_dir { [[ -n $1 -d $1 -r $1 -x $1 ]]; }
Re: BASH ignores language for command completion
On Wed, Jul 14, 2010 at 10:29 PM, Bruce Korb bk...@vmem.com wrote: I've stripped all LC_* variables plus LANG from my environment: $ env|fgrep LANG $ env|fgrep LC_ $ My understanding: For most time the language/locale is not set through LC_* vars although LC_* vars can override the default language/locale. On Linux you can run the `locale' command to see current settings.
Re: How to run something before invoking the inputted command?
On Tue, Jul 13, 2010 at 8:22 PM, Greg Wooledge wool...@eeg.ccf.org wrote: On Tue, Jul 13, 2010 at 11:19:34AM +0800, Clark J. Wang wrote: My PS1 depends much on PROMPT_COMMAND. For example, my PROMPT_COMMAND will trim very long $PWD to a shorter one (depends on the window size of current terminal): [r...@server ~/directory/lng/very/a/is/this] # [r...@server ~/.../very/a/is/this] # The same thing could be done with a command substitution inside PS1. Agree. Actually my PROMPT_COMMAND does more than that, it'll also update a few more vars. Too many command substitution in PS1 may affect the performance, I think. -Clark
Re: How to run something before invoking the inputted command?
Personally I've never found any use for PROMPT_COMMAND. It seems klunky and awkward. My PS1 depends much on PROMPT_COMMAND. For example, my PROMPT_COMMAND will trim very long $PWD to a shorter one (depends on the window size of current terminal): [r...@server ~/directory/lng/very/a/is/this] # [r...@server ~/.../very/a/is/this] # Bash 4.0 introduces a new similar feature via var PROMPT_DIRTRIM. -Clark
How to run something before invoking the inputted command?
For example, in the interactive shell, I want to track the time when every inputted command is invoked. So I want to run a `date' command before actually invoking the inputted command. For now I have to do like this: $ date; command1 $ date; command2 Is there an easy way to do that? -Clark
Re: How to run something before invoking the inputted command?
On Sat, Jul 10, 2010 at 11:30 AM, Eric Blake ebl...@redhat.com wrote: On 07/09/2010 09:22 PM, Clark J. Wang wrote: For example, in the interactive shell, I want to track the time when every inputted command is invoked. So I want to run a `date' command before actually invoking the inputted command. For now I have to do like this: $ date; command1 $ date; command2 Is there an easy way to do that? Not quite before the command, but it is very easy to include $(date) as part of PS1 to have a timestamp listed in the prompt that is printed after every command. Yes, timestamp in PS1 is fine for after-command purposes. And actually I use the PROMPT_COMMAND var for that. Except for long-running processes, there won't even be much difference in the timestamps. Looks like not a perfect solution. :) -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: Bash cannot kill itself?
On Wed, Jun 30, 2010 at 1:40 PM, Jan Schampera jan.schamp...@web.de wrote:
Clark J. Wang wrote:
Running a cmd in background (by ) would not create subshell. Simple
testing:
#!/bin/bash
function foo()
{
echo $$
}
echo $$
foo
### END OF SCRIPT ###
The 2 $$s output the same.
This doesn't mean that it doesn't create a subshell. It creates one, since
it can't replace your foreground process.
This makes sense.
It just shows that $$ does what it should do, it reports the relevant PID of
the parent (main) shell you use.
Then what's the problem with my script in my original mail? Seems like Bash
does not handle the signal in a real-time way.
As far as I can see, this applies to all kinds of subshells like
- explicit ones (...)
- pipeline components
- command substitution
- process substitution
- async shells (like above, running your function)
- ...
J.
Re: Bash cannot kill itself?
On Wed, Jun 30, 2010 at 2:52 PM, Pierre Gaston pierre.gas...@gmail.comwrote: On Wed, Jun 30, 2010 at 9:12 AM, Clark J. Wang dearv...@gmail.com wrote: On Wed, Jun 30, 2010 at 1:40 PM, Jan Schampera jan.schamp...@web.de wrote: It just shows that $$ does what it should do, it reports the relevant PID of the parent (main) shell you use. Then what's the problem with my script in my original mail? Seems like Bash does not handle the signal in a real-time way. the signal is delivered after the foreground process sleep 3600 exits, try with: sleep 3600 wait $! instead This works fine. Thanks.
Re: Bash cannot kill itself?
On Wed, Jun 30, 2010 at 12:38 PM, Chris F.A. Johnson
ch...@cfajohnson.comwrote:
On Wed, 30 Jun 2010, Clark J. Wang wrote:
I have a bash script like this:
#!/bin/bash
trap 'echo killed by SIGALRM; exit 1' ALRM
function wait_kill()
{
sleep 5
kill -ALRM $$
}
wait_kill
sleep 3600
### END OF THE SCRIPT ###
It does not work as I expected. The running script was not terminated
after
5 seconds. So what's wrong here?
$$ refers to the subshell.
There's no subshell here, I think.
Try:
trap 'echo killed by SIGALRM; exit 1' ALRM
function wait_kill()
{
sleep 5
kill -ALRM $pid
}
pid=$$
wait_kill
sleep 3600
--
Chris F.A. Johnson, http://cfajohnson.com
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: Bash cannot kill itself?
On Wed, Jun 30, 2010 at 1:17 PM, Jan Schampera jan.schamp...@web.de wrote:
Chris F.A. Johnson wrote:
$$ refers to the subshell.
There's no subshell here, I think.
The background process invoked by .
$$ is meant to always report the main shell, I'd guess this is true for
this case, too.
Running a cmd in background (by ) would not create subshell. Simple
testing:
#!/bin/bash
function foo()
{
echo $$
}
echo $$
foo
### END OF SCRIPT ###
The 2 $$s output the same.
J.
Re: How not to inherit any environment variable from parent process?
On Wed, Jun 23, 2010 at 12:32 PM, Peng Yu pengyu...@gmail.com wrote: I use bash --noprofile to start a bash session. Since this doesn't source any profile files, I'd think that no environment variable should be set. But I still see environment variables set. Are they inherit from the parent session. Is there a way to start a bash session without using parent environment variables? This is also not a bash specific question but the env command may help. -- Regards, Peng
