Re: ...Limitation?
mwoehlke <[EMAIL PROTECTED]> wrote:
> I am trying to figure out how to run a command and pipe the output
> through tee, and then check the status of the original command.
This uses a bash-specific feature:
cmd > >(tee file); status=$?
This should work on any sh:
exec 3>&1 && status=`exec 4>&1 && { cmd; echo $? >&4; } | tee file >&3`
Or, if you don't want to clobber any descriptors, in case they might
be in use for something else:
: > file &&
{ tail -f file & } &&
pid=$! &&
{ cmd > file; status=$?; } &&
sleep 1 && # give tail a chance to print the last bits that were just written
kill "$pid"
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
...Limitation?
Not really a bug, but this seems to be the only bash list gname knows
about, so...
I am trying to figure out how to run a command and pipe the output
through tee, and then check the status of the original command. Normally
I am a very competent shell programmer, but this one has me stumped!
I have tried all of the following with no success (except of course the
last one):
my_false() { false || ret=3; }
ret=0
{ false || exit 1; } | tee none
{ false || ret=2; } | tee none ; [ $ret -eq 0 ] || exit $ret
my_false | tee none ; [ $ret -eq 0 ] || exit $ret
false | tee none || exit 4
false || exit 5
Please, someone tell me I'm just doing it wrong, and this is not a
limititation in bash!
--
Matthew
Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: ...Limitation?
On Tue, Sep 26, 2006 at 11:45:42AM -0400, Paul Jarc wrote:
> mwoehlke <[EMAIL PROTECTED]> wrote:
> > I am trying to figure out how to run a command and pipe the output
> > through tee, and then check the status of the original command.
>
> This uses a bash-specific feature:
> cmd > >(tee file); status=$?
This is a ksh feature that can also be found in zsh.
But it's true it's not standard. I may be wrong but I don't
think bash has any significant feature of its own.
What is bash specific is the $PIPESTATUS array. zsh also has it
but it's called $pipestatus there as zsh arrays are
traditionally lowercase (so that they are not confused with
scalar variables (all bash variables are both array and
scalar at the same time as in ksh)).
cmd | tee file
and cmd exit status can be found in ${PIPESTATUS[0]}.
> This should work on any sh:
> exec 3>&1 && status=`exec 4>&1 && { cmd; echo $? >&4; } | tee file >&3`
You may want to write it:
exec 3>&1 && status=`exec 4>&1 && { cmd 4>&-; echo $? >&4; } | tee file >&3`
because otherwise, if cmd spawns a process, and that process
doesn't close its fd 4, you'd have to wait for it to finish (you
may have the same problem if it doesn't close its fd 1 because
of the pipe to tee, though).
> Or, if you don't want to clobber any descriptors, in case they might
> be in use for something else:
[...]
Then do it in a subshell (unless cmd makes use of those file
descriptors) or do it this way instead of using exec (bash will
take care of restoring the fds):
{
status=$(
{
{
cmd 4>&-
echo "$?" >&4
} 3>&- |
tee file >&3 3>&-
} 4>&1
)
} 3>&1
This should work in any Unix or POSIX conformant sh, not in the
Bourne shell.
--
Stéphane
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: ...Limitation?
Paul Jarc wrote:
mwoehlke <[EMAIL PROTECTED]> wrote:
I am trying to figure out how to run a command and pipe the output
through tee, and then check the status of the original command.
This uses a bash-specific feature:
cmd > >(tee file); status=$?
Thanks Paul and Stephen for the replies. I am using bash, so the above
solution is fine, and is working.
This should work on any sh:
exec 3>&1 && status=`exec 4>&1 && { cmd; echo $? >&4; } | tee file >&3`
Or, if you don't want to clobber any descriptors, in case they might
be in use for something else:
: > file &&
{ tail -f file & } &&
pid=$! &&
{ cmd > file; status=$?; } &&
sleep 1 && # give tail a chance to print the last bits that were just written
kill "$pid"
--
Matthew
Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [BUG][bash][auto completion] if COMPREPLY contents ":" auto completion doesn't work properly
Vasily Tarasov wrote:
> I suppose I've found a bug;
I need to make this part of the FAQ. The `:' is special to readline: it
splits words for the word completion code.
The default set of such characters is available in the COMP_WORDBREAKS
variable. Removing `:' from the value of that variable should produce
the behavior you want.
Something like
COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
will do the job.
Chet
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [BUG][bash][auto completion] if COMPREPLY contents ":" auto completion doesn't work properly
Chet Ramey <[EMAIL PROTECTED]> wrote: > Vasily Tarasov wrote: > >> I suppose I've found a bug; > > I need to make this part of the FAQ. The `:' is special to readline: it > splits words for the word completion code. That explains some of what's going on in this case, but not all. For the first tab, shouldn't the text filled in by completion be "qwe\:o" instead of "qwe:o", since it includes a COMP_WORDBREAKS character? That's how filename completion behaves, so I'd expect the same behavior here. Is the completion function responsible for adding the backslash, or should bash do it? Also, after two tabs, we have "qwe:qwe:o", but further tabs don't add any more "qwe:"'s for some reason I don't understand. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [BUG][bash][auto completion] if COMPREPLY contents ":" auto completion doesn't work properly
> Chet Ramey <[EMAIL PROTECTED]> wrote: > > Vasily Tarasov wrote: > > > >> I suppose I've found a bug; > > > > I need to make this part of the FAQ. The `:' is special to readline: it > > splits words for the word completion code. > > That explains some of what's going on in this case, but not all. For > the first tab, shouldn't the text filled in by completion be "qwe\:o" > instead of "qwe:o", since it includes a COMP_WORDBREAKS character? > That's how filename completion behaves, so I'd expect the same > behavior here. Is the completion function responsible for adding the > backslash, or should bash do it? The backslash addition is a feature of filename completion, and bash's default word completion. There isn't a really good way to have such quotes stripped before handing the word to the completion function, nor is there a specific option to have filename-like quoting applied to the result (though the completion function can always add the backslash). > Also, after two tabs, we have "qwe:qwe:o", but further tabs don't add > any more "qwe:"'s for some reason I don't understand. Because the colon is still a word break character, and readline passes `o' to the completion function as the partial word to be completed. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [BUG][bash][auto completion] if COMPREPLY contents ":" auto completion doesn't work properly
Chet Ramey <[EMAIL PROTECTED]> wrote:
>> Chet Ramey <[EMAIL PROTECTED]> wrote:
>> Also, after two tabs, we have "qwe:qwe:o", but further tabs don't add
>> any more "qwe:"'s for some reason I don't understand.
>
> Because the colon is still a word break character, and readline passes `o'
> to the completion function as the partial word to be completed.
I added some echos to the completion function to check, and I see
something different.
$ echo "$COMP_WORDBREAKS"
"'><=;|&(:
$ _myfunc() {
> local cur=${COMP_WORDS[COMP_CWORD]}
> COMPREPLY=( $(compgen -W "qwe:on qwe:off" -- "$cur") )
> echo
> echo
> printf '>%s<\n' cword "$cur" words "[EMAIL PROTECTED]" reply "[EMAIL
> PROTECTED]"
> echo
> }
$ complete -F _myfunc myfunc
$ myfunc
>cword<
><
>words<
>myfunc<
><
>reply<
>qwe:on<
>qwe:off<
$ myfunc qwe:o
>cword<
>qwe:o<
>words<
>myfunc<
>qwe:o<
>reply<
>qwe:on<
>qwe:off<
$ myfunc qwe:qwe:o
>cword<
>qwe:qwe:o<
>words<
>myfunc<
>qwe:qwe:o<
>reply<
So it looks like the entire word is passed to the completion function;
COMP_WORDBREAKS is not consulted at that point. COMP_WORDBREAKS is
only used to decide how much text to erase before inserting the
completion text. Is that intended? Is the completion function
supposed to take care of splitting the word if it wants that?
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [BUG][bash][auto completion] if COMPREPLY contents ":" auto completion doesn't work properly
> So it looks like the entire word is passed to the completion function; > COMP_WORDBREAKS is not consulted at that point. COMP_WORDBREAKS is > only used to decide how much text to erase before inserting the > completion text. Is that intended? Is the completion function > supposed to take care of splitting the word if it wants that? If that's the case, my memory is faulty. My fault for not checking. I'll have to look at the code. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
out-of-range-offset or zero-length substring parameter expansion
Configuration Information [Automatically generated, do
not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash'
-DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu'
-DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc'
-DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
-Os -mcpu=i686 -pipe
uname output: Linux gseba-mobile 2.6.18-rc7 #3 Fri Sep
22 18:37:46 GMT 2006 i686 Mobile AMD Sempron(tm)
Processor 3300+ AuthenticAMD GNU/Linux
Machine Type: i386-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
when taking the substring of a variable, in
certain conditions, it behaves differently whether or
not is surrounded by other strings
Repeat-By:
$ x="alfa"
$ echo ${#x}
4
$ # now we're taking the substring of x
$ # starting from index 4 (should be null)
$ [ "${x:4}" == "" ] && echo ok
ok
$ # now we're taking the substring of x
$ # starting from index 4, but we wrap
$ # it between `|' (should be `||')
$ [ "|${x:4}|" == "||" ] && echo ok
$ # nothing was echoed
$ #
$ # now we're taking a substring of x
$ # of length 0 (should be null)
$ [ "${x::0}" == "" ] && echo ok
ok
$ # now we're taking a substring of x
$ # of length 0, but we wrap
$ # it between `|' (should be `||')
$ [ "|${x::0}|" == "||" ] && echo ok
$ # nothing was echoed
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
no parameter expansion and no special meaning to control operator
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -Os -mcpu=i686 -pipe uname output: Linux gseba-mobile 2.6.18-rc7 #3 Fri Sep 22 18:37:46 GMT 2006 i686 Mobile AMD Sempron(tm) Processor 3300+ AuthenticAMD GNU/Linux Machine Type: i386-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: my script has an option in which it receives a command file's name and a pattern of arguments to invoked the command with; at some stages of the script, the pattern is analyzed and a list of arguments for the command is created; now, to launch the command, I have found that the following line is applicable: eval "\"$CMDFILE\" $list" because i need $CMDFILE to receive more than one argument; but what happens is that if in the script's option's arguments, there are substrings like $i, those variable are expanded, if they exist, at the moment of `eval'; also other commands can be launched, through the control operators '&&', ';' etc. avoiding control operators seems to work with the following line: ( eval exec "\"$CMDFILE\" $list" ) but still, there takes place unwanted parameter expansion; Fix: so what I think of as a solution is either a flag to the `set' builtin to disable parameter expansion and one to ignore control operators, or a flag to `eval' itself, with the same intention Does this seem reasonable? Thanks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: no parameter expansion and no special meaning to control operator
Lorenzo Viali <[EMAIL PROTECTED]> wrote: > eval "\"$CMDFILE\" $list" > because i need $CMDFILE to receive more than > one argument; but what happens is that if in the > script's option's arguments, there are substrings like > $i, those variable are expanded That will also happen within $CMDFILE, since that variable is expanded before eval sees it. You could prevent the secondary expansion within $CMDFILE by escaping the "$": eval "\"\$CMDFILE\" $list" But that won't help with $list. Option 1: don't use eval. "$CMDFILE" $list In this case, you'd probably also want to use "set -f" first to disable filename expansion in the contents of $list (and "set +f" afterwards to restore filename expansion). $list will still be split at whitespace to produce multiple arguments. The only restriction is that you can't produce an argument containing whitespace. Option 2: quote before eval. When adding an arguemnt to list, quote it first by passing it through this sed command: sed " s/'/'''/g 1s/^/'/ \$s/\$/'/ " This way, you can include arguments containing whitespace, or any other special characters. They'll be quoted, so eval will only remove the quotes, without further expansion. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
