Re: How to protect > and interpret it later on? (w/o using eval)
On Fri, Dec 02, 2011 at 09:00:10AM +0200, Pierre Gaston wrote: > On Fri, Dec 2, 2011 at 8:24 AM, Peng Yu wrote: > > $ ../execute.sh ls >/tmp/tmp.txt What? You have a pipeline with nothing before it, and then another pipeline with "ls" on the right hand side. But ls doesn't even read from stdin! This is not even syntactically valid: arc3:/tmp$ | echo | ls bash: syntax error near unexpected token `|' And it's not semantically valid either, because piping to ls is ludicrous: arc3:/tmp$ echo hello world | ls arc3:/tmp$ > > '>' will not work unless eval is used in execute.sh. WHAT are you trying to DO? > > $ ../execute.sh ls '>' /tmp/tmp.txt ... another pipe to ls! What on earth is this? > > How to make execute protect > and interpret it later on w/o using eval? Your execute.sh script never even sees the > at all, because you are not passing the > as an *argument* to the ../execute.sh script. You are passing it as an argument to ls. ../execute.sh has *no* arguments whatsoever. > This really belongs to the new help-b...@gnu.org mailing list > * https://lists.gnu.org/mailman/listinfo/help-bash Agreed. Here, this is my best guess as to what he wants: http://mywiki.wooledge.org/BashFAQ/050 -- I'm trying to put a command in a variable, but the complex cases always fail! If that doesn't cover it, then post (on help-bash) an English description of the actual *goal* you are trying to achieve. If you feel you must post code, then at least make sure the code is DIRECTLY COPIED FROM YOUR TERMINAL, not made up on the spot with syntax errors in it.
Re: How to protect > and interpret it later on? (w/o using eval)
> WHAT are you trying to DO? I think that you might completely miss my point. I try to explain it better. Let me know if this time it makes more sense to you. I want to execute any command as if the 'execute.sh' does not present, except that I want to print the command so that I know want the command is executed. (This can be used when I call several commands in a script and I know what part of the output associated to what command). E.g. I can run ls > /tmp/tmp.txt When I call, execute.sh ls > /tmp/tmp.txt I want it actually to do echo "ls > /tmp/tmp.txt" ls > /tmp/tmp.txt Note that I could define execute.sh such that execute.sh "ls > /tmp/tmp.txt" means echo "ls > /tmp/tmp.txt" eval "ls > /tmp/tmp.txt" But this interface of execute.sh is not as good the previous one. Note that there could be other symbols that bash normal process, such as '2>&1'. I'm looking for a general solution, Pierre's answer is not as general as I want. The FAQ http://mywiki.wooledge.org/BashFAQ/050 doesn't really answer my question. BTW, where is the help-bash mailing list mentioned (at least not on bash home page)? I have never seen it before. http://tiswww.case.edu/php/chet/bash/bashtop.html -- Regards, Peng
Re: How to protect > and interpret it later on? (w/o using eval)
On Fri, Dec 02, 2011 at 08:26:28AM -0600, Peng Yu wrote: > When I call, > > execute.sh ls > /tmp/tmp.txt > > I want it actually to do > > echo "ls > /tmp/tmp.txt" > ls > /tmp/tmp.txt That is impossible. The redirection, being unquoted, is performed by the shell where you are actually typing that. If you want the > symbol to be passed to the script as (part of) an argument, then it must be quoted, as in your second example: > execute.sh "ls > /tmp/tmp.txt" THAT will work. But why are you writing a script to read a shell command and then execute it? There is already a program that reads shell commands and then executes them. It's called bash.
Re: *(.*) matches wrongly when dotglob unset
On 11/29/11 9:53 AM, Yongzhi Pan wrote: > Producing the bug: > > tux@dell:~$ shopt -s extglob > tux@dell:~$ shopt -u dotglob > tux@dell:~$ ls -d *(.*) > ls: cannot access *(.*): No such file or directory > tux@dell:~$ touch '*(.*)' > tux@dell:~$ ls -d *(.*) > *(.*) > > I think even if dotglob is unset *(.*) should still matches all dotfiles. Thanks for the report. This turned into a rather more complicated fix than I anticipated. The fix will be in the next release of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: A programmable completoin bug?
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 :short
> [bash-4.2.10] # foo changed <-- Fine, this is what I want
> [bash-4.2.10] # foo :this-is-a-long-word
> [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.
I can't reproduce this behavior using bash-4.2.20 (after modifying
COMP_WORDBREAKS); I get `changed' as the completion in both cases.
Have you done `set -x' to get an idea of what's happening when the
completion function runs?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
popd always has return status 0
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-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 cirrus 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26
UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 10
Release Status: release
Description:
popd does not appear to return a nonzero exit status when the directory
stack is empty anymore. The bash manual says the following for popd:
"If the popd command is successful, a dirs is performed as well, and
the return status is 0. popd returns false if an invalid option is
encountered, the directory stack is
empty, a non-existent directory stack entry is specified,
or the directory change fails."
I am seeing this problem on: Ubuntu 11.10 oneiric
bash package version: 4.2-0ubuntu4
Repeat-By:
Put some directories on the stack with pushd, then call popd and check
the return status. It is expected to be nonzero when the stack is empty or an
error occurs.
The following function should pop all dirs off the stack and then stop,
however the while loop continues infinitely:
popall ()
{
local not_done=0;
while [ $not_done -eq 0 ]; do
popd;
not_done=$?;
done
}
Re: popd always has return status 0
On Fri, Dec 2, 2011 at 2:01 AM, wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-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 cirrus 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26
> UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.2
> Patch Level: 10
> Release Status: release
>
> Description:
> popd does not appear to return a nonzero exit status when the
> directory stack is empty anymore. The bash manual says the following for
> popd:
>
> "If the popd command is successful, a dirs is performed as well, and
> the return status is 0. popd returns false if an invalid option is
> encountered, the directory stack is
> empty, a non-existent directory stack entry is
> specified, or the directory change fails."
>
> I am seeing this problem on: Ubuntu 11.10 oneiric
> bash package version: 4.2-0ubuntu4
>
> Repeat-By:
> Put some directories on the stack with pushd, then call popd and check
> the return status. It is expected to be nonzero when the stack is empty or
> an error occurs.
> The following function should pop all dirs off the stack and then
> stop, however the while loop continues infinitely:
>
> popall ()
> {
> local not_done=0;
> while [ $not_done -eq 0 ]; do
> popd;
> not_done=$?;
> done
> }
>
I don't seem to be able to reproduce this:
$ dpkg-query --show bash
bash4.2-0ubuntu4
$ echo $BASH_VERSION
4.2.10(1)-release
$ declare -f popall
popall ()
{
local not_done=0;
while [ $not_done -eq 0 ]; do
popd;
not_done=$?;
done
}
$ pushd test
~/test ~
$ popall
~
bash: popd: directory stack empty
$
Re: popd always has return status 0
On Thursday 01 December 2011 19:01:50 james.cuze...@lyraphase.com wrote: > Description: > popd does not appear to return a nonzero exit status when the directory > stack is empty anymore. works for me: $ echo $BASH_VERSION ; popd ; echo $? 4.2.20(1)-release bash: popd: directory stack empty 1 as does your popall func -mike signature.asc Description: This is a digitally signed message part.
