When I want to set 'set -x' for just one command, I do this:
(set -x; command args )
This works, but creates additional subprocess(subshell). Not that
I'm too worried about that, but I sometimes I am, only a little. If I
do
{ set -x; command args; set +x; }
then that avoids extra subprocess but prints the 'set +x' noise.

Is it possible to turn on 'set -x' for just 1 command without
overhead of a subshell ?

Thanks
Yakov

2006-11-6, 02:51(-08), Yakov:
> When I want to set 'set -x' for just one command, I do this:
> (set -x; command args )
> This works, but creates additional subprocess(subshell). Not that
> I'm too worried about that, but I sometimes I am, only a little. If I
> do
> { set -x; command args; set +x; }
> then that avoids extra subprocess but prints the 'set +x' noise.
>
> Is it possible to turn on 'set -x' for just 1 command without
> overhead of a subshell ?

(set -x; exec command args )

Or, with zsh:

+() {
local PS4=+
setopt localoptions xtrace
"$@"
}

+ command args

--
Stéphane

2006-11-06 <LkI3h.4$Tf.133251@news.sisna.com>,
SiKing wrote:
> Stephane CHAZELAS wrote:
>> 2006-11-6, 02:51(-08), Yakov:
>>> When I want to set 'set -x' for just one command, I do this:
>>> (set -x; command args )
>>> This works, but creates additional subprocess(subshell). Not that
>>> I'm too worried about that, but I sometimes I am, only a little. If I
>>> do
>>> { set -x; command args; set +x; }
>>> then that avoids extra subprocess but prints the 'set +x' noise.
>>>
>>> Is it possible to turn on 'set -x' for just 1 command without
>>> overhead of a subshell ?
>>
>> (set -x; exec command args )
>
> 'exec' is bad(tm) if you use it in the middle of a script!

Does either of you know what a subshell is?

>
> The only thing I can think of is:
> (set -x; command args; set +x &> /dev/null )
>
>

2006-11-06, 15:15(+00), SiKing:
> Stephane CHAZELAS wrote:
>> 2006-11-6, 02:51(-08), Yakov:
>>> When I want to set 'set -x' for just one command, I do this:
>>> (set -x; command args )
>>> This works, but creates additional subprocess(subshell). Not that
>>> I'm too worried about that, but I sometimes I am, only a little. If I
>>> do
>>> { set -x; command args; set +x; }
>>> then that avoids extra subprocess but prints the 'set +x' noise.
>>>
>>> Is it possible to turn on 'set -x' for just 1 command without
>>> overhead of a subshell ?
>>
>> (set -x; exec command args )
>
> 'exec' is bad(tm) if you use it in the middle of a script!

But not if you use it as the last command of a subshell.

> The only thing I can think of is:
> (set -x; command args; set +x &> /dev/null )
[...]

Won't work (and &> is bash specific). &> /dev/null will only
redirect set output, not the xtrace output.


--
Stéphane

2006-11-06 <slrnekut0e.9i1.stephane.chazelas@spam.is.invalid> ,
Stephane CHAZELAS wrote:
> 2006-11-06, 15:15(+00), SiKing:
>> Stephane CHAZELAS wrote:
>>> 2006-11-6, 02:51(-08), Yakov:
>>>> When I want to set 'set -x' for just one command, I do this:
>>>> (set -x; command args )
>>>> This works, but creates additional subprocess(subshell). Not that
>>>> I'm too worried about that, but I sometimes I am, only a little. If I
>>>> do
>>>> { set -x; command args; set +x; }
>>>> then that avoids extra subprocess but prints the 'set +x' noise.
>>>>
>>>> Is it possible to turn on 'set -x' for just 1 command without
>>>> overhead of a subshell ?
>>>
>>> (set -x; exec command args )
>>
>> 'exec' is bad(tm) if you use it in the middle of a script!
>
> But not if you use it as the last command of a subshell.
>
>> The only thing I can think of is:
>> (set -x; command args; set +x &> /dev/null )
> [...]
>
> Won't work (and &> is bash specific).

Is it any different from >& which is on all shells (even csh)?

> &> /dev/null will only
> redirect set output, not the xtrace output.

Regardless, "+ set +x" is just one line, is it really such a big deal?

2006-11-6, 18:04(+00), Jordan Abel:
[...]
>> Won't work (and &> is bash specific).
>
> Is it any different from >& which is on all shells (even csh)?

It comes from csh, and is also found in tcsh, zsh and in bash
since version 2.05. It's not in any version of ksh or ash.

Both syntaxes have issues as they overlap with other common
Bourne features.

cmd >& <file>

doesn't work anymore (or not the same) if <file> is a
digit.

This means that:

echo foo >& "$1"

should be written the Bourne/POSIX way instead.

echo foo > "$1" 2>&1

And:

cmd &> foo

means something else in the Bourne shell (and other Bourne like
shells).

It's like:

cmd &
> foo


>
>> &> /dev/null will only
>> redirect set output, not the xtrace output.
>
> Regardless, "+ set +x" is just one line, is it really such a big deal?

I can understand the OP's point of view. It's nice to have the
shell selectively display what you are doing, this avoids having
to do:

echo "Now running: cmd arg..." >&2
cmd arg...

But one could write a function for that:

log_and_do() {
IFS=" " command eval '
printf "Now running: %s\n" "$*" >&2'
"$@"
}
log_and_do cmd arg...

--
Stéphane

"Stephane CHAZELAS" <this.address@is.invalid> wrote in message news:slrnekut0e.9i1.stephane.chazelas@spam.is.inva lid...
: 2006-11-06, 15:15(+00), SiKing:
: > Stephane CHAZELAS wrote:
: >> 2006-11-6, 02:51(-08), Yakov:
: >>> When I want to set 'set -x' for just one command, I do this:
: >>> (set -x; command args )
: >>> This works, but creates additional subprocess(subshell). Not that
: >>> I'm too worried about that, but I sometimes I am, only a little. If I
: >>> do
: >>> { set -x; command args; set +x; }
: >>> then that avoids extra subprocess but prints the 'set +x' noise.
: >>>
: >>> Is it possible to turn on 'set -x' for just 1 command without
: >>> overhead of a subshell ?
: >>
: >> (set -x; exec command args )
: >
: > 'exec' is bad(tm) if you use it in the middle of a script!
:
: But not if you use it as the last command of a subshell.

FWIW, in ksh it is redundant as the last command of a subshell since
that is always exec'd.

Dan Mercer

:
: > The only thing I can think of is:
: > (set -x; command args; set +x &> /dev/null )
: [...]
:
: Won't work (and &> is bash specific). &> /dev/null will only
: redirect set output, not the xtrace output.
:
:
: --
: Stiphane

In article <0VQ3h.4$rB.3@tornado.rdc-kc.rr.com>,
"Dan Mercer" <dmercer@mn.rr.com> wrote:

> "Stephane CHAZELAS" <this.address@is.invalid> wrote in message
> news:slrnekut0e.9i1.stephane.chazelas@spam.is.inva lid...
> : 2006-11-06, 15:15(+00), SiKing:
> : > Stephane CHAZELAS wrote:
> : >> 2006-11-6, 02:51(-08), Yakov:
> : >>> When I want to set 'set -x' for just one command, I do this:
> : >>> (set -x; command args )
> : >>> This works, but creates additional subprocess(subshell). Not that
> : >>> I'm too worried about that, but I sometimes I am, only a little. If I
> : >>> do
> : >>> { set -x; command args; set +x; }
> : >>> then that avoids extra subprocess but prints the 'set +x' noise.
> : >>>
> : >>> Is it possible to turn on 'set -x' for just 1 command without
> : >>> overhead of a subshell ?
> : >>
> : >> (set -x; exec command args )
> : >
> : > 'exec' is bad(tm) if you use it in the middle of a script!
> :
> : But not if you use it as the last command of a subshell.
>
> FWIW, in ksh it is redundant as the last command of a subshell since
> that is always exec'd.

And since the OP specifically asked if there's a way to do this WITHOUT
creating a subshell, the suggestion isn't really ful. The only
difference between the original version that the one with exec is
whether the subshell hangs around during the execution of the command.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***