redirection after braced block
'uname -rims'
Linux 2.6.31.1-spott i686 AuthenticAMD
'bash --version'
GNU bash, version 4.0.24(1)-release (i686-pc-linux-gnu)
I have the following construct in a script:
... a number of commands
{
... a number of commands
} 2>&1 | ${prog_log} "${logfile}"
It seems anything inside the braces is not seen by bash, and it doesn't
show up in a "sh -x ..." trace, but ${prog_log} does. I had debug
echo's at the start of the block, they aren't triggered.
The shell options right before entering the block are:
cmdhist on
extglob on
extquoteon
force_fignore on
hostcompleteon
interactive_commentson
progcompon
promptvars on
sourcepath on
Removing the redirection makes it work:
... a number of commands
{
... a number of commands
} | ${prog_log} "${logfile}"
but it changes the semantics of my script and causes problems. I could
not isolate the offender, the construct works from the command line:
$ {
echo mist; echo mast >&2
} 2>&1 | cat -t
mist
mast
I do not even know how to debug or reproduce it in five lines ...
clemens
Re: ulimit and ssh?
Thanks Adreas. That was what I suspected in my reply to Bob. But Bob disagreed. Looks like there were some confusion about this feature even among experts. Seems another reason to deprecate the feature. -peter Andreas Schwab-2 wrote: > > peter360 writes: > >> That makes sense. So the "feature" is to split all parameters on space >> even >> if they are quoted? > > The feature is that ssh concatenates all remaining arguments to a single > string and passes that to the shell on the remote side. If you want to > preserve any quoting in this process you need to quote them. > > 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." > > > > -- View this message in context: http://www.nabble.com/ulimit-and-ssh--tp25262471p25754738.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: redirection after braced block
clemens fischer writes:
> I have the following construct in a script:
>
> ... a number of commands
> {
> ... a number of commands
> } 2>&1 | ${prog_log} "${logfile}"
>
> It seems anything inside the braces is not seen by bash, and it doesn't
> show up in a "sh -x ..." trace, but ${prog_log} does. I had debug
> echo's at the start of the block, they aren't triggered.
The trace goes to stderr, but you've just redirected 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."
Re: redirection after braced block
Andreas Schwab wrote:
> clemens fischer writes:
>
>> I have the following construct in a script:
>>
>> ... a number of commands
>> {
>> ... a number of commands
>> } 2>&1 | ${prog_log} "${logfile}"
>>
>> It seems anything inside the braces is not seen by bash, and it
>> doesn't show up in a "sh -x ..." trace, but ${prog_log} does. I had
>> debug echo's at the start of the block, they aren't triggered.
>
> The trace goes to stderr, but you've just redirected it.
yeah ok, but the commands really are not executed. I have an option
dry-run in the script, which sets "prog_log=true". Then there are
a bunch of verbose commands in the block, none of get touched.
The fact that I can see the trace on the terminal instead of the logfile
should prove that it shows what bash is actually doing.
In the meantime I upgraded to "version 4.0.33(1)-release
(i686-pc-linux-gnu)", which didn't change anything.
Nonetheless you seem to implicitly confirm what I had originally
planned: the block should execute and both its stdout and stderr should
get piped into the logger.
clemens
Re: redirection after braced block
clemens fischer wrote:
Andreas Schwab wrote:
clemens fischer writes:
I have the following construct in a script:
... a number of commands
{
... a number of commands
} 2>&1 | ${prog_log} "${logfile}"
It seems anything inside the braces is not seen by bash, and it
doesn't show up in a "sh -x ..." trace, but ${prog_log} does. I had
debug echo's at the start of the block, they aren't triggered.
The trace goes to stderr, but you've just redirected it.
yeah ok, but the commands really are not executed. I have an option
dry-run in the script, which sets "prog_log=true". Then there are
a bunch of verbose commands in the block, none of get touched.
This sort of construct seems to be working fine for me. Note that the
contents of the block are executed in a subshell, and using 'true' as
prog_log will suppress both stdout and stderr, as set up (though you
might get a broken pipe error). So unless the commands in the block have
side effects observable outside of the script, you won't know whether or
not they execute.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Q: Why doesn't Fedora provides ponies? -- Benny Amorsen
A: Because they're too big to fit in the bikeshed. -- Mat Booth
Re: redirection after braced block
On Mon, Oct 05, 2009 at 07:55:33PM +0200, clemens fischer wrote:
> >> {
> >> ... a number of commands
> >> } 2>&1 | ${prog_log} "${logfile}"
> yeah ok, but the commands really are not executed. I have an option
> dry-run in the script, which sets "prog_log=true". Then there are
> a bunch of verbose commands in the block, none of get touched.
In case the other response wasn't clear enough: you've got a pipeline
here. Each command in a pipeline gets executed in its own subshell,
which means variables that are set in any part of a pipeline do not
appear (are not set) after the pipeline terminates.
If you're having trouble debugging your script, and you want to be
absolutely sure whether the commands in the braces are executing, you
should use commands that affect the file system (touch, etc.).
Re: redirection after braced block
clemens fischer wrote:
> I have the following construct in a script:
>
> ... a number of commands
> {
> ... a number of commands
> } 2>&1 | ${prog_log} "${logfile}"
>
> It seems anything inside the braces is not seen by bash, and it doesn't
> show up in a "sh -x ..." trace, but ${prog_log} does. I had debug
> echo's at the start of the block, they aren't triggered.
I don't know anything about your program or what else might be going on,
but set -x sends its output to stderr -- if you redirect fd 2, the trace
output is going to be redirected right along with it.
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: ulimit and ssh?
peter360 wrote: > Thanks Adreas. That was what I suspected in my reply to Bob. But Bob > disagreed. Looks like there were some confusion about this feature even > among experts. Seems another reason to deprecate the feature. I don't think anything I said disagreed with what Andreas said. It is just confusing you since we are talking about different points in the process. What does the local shell do, what does the ssh do, what does the remote shell do, what is the end-to-end effect and so forth. All three processes are handling the arguments and each has an affect at different points in the timeline. I was talking end-to-end (shell-ssh-shell) and Andreas was talking about ssh. And by the way but this feature can't really be changed or it would break twenty years or so of scripts which rely upon the existing behavior. Greg Wooledge wrote: > imadev:~$ $HOME/bin/args 'ulimit -a' > 1 args: 'ulimit -a' > imadev:~$ remsh localhost $HOME/bin/args 'ulimit -a' > 2 args: 'ulimit' '-a' > imadev:~$ ssh localhost $HOME/bin/args 'ulimit -a' > wool...@localhost's password: > 2 args: 'ulimit' '-a' Nice! It would also be illustrative to show what happens without any quoting and with quoting for two shell layers. $ $HOME/bin/show-args 'ulimit -a' arg1: ulimit -a $ ssh -n localhost $HOME/bin/show-args ulimit -a arg1: ulimit arg2: -a $ ssh -n localhost $HOME/bin/show-args 'ulimit -a' arg1: ulimit arg2: -a $ ssh -n localhost $HOME/bin/show-args '"ulimit -a"' arg1: ulimit -a Since there are two shells splitting words in the end-to-end result then the effect is that you need to quote your arguments twice in order to have an argument containing whitespace in one argument by the time it has been processed through two shell's argument processing. Without sufficient quoting you have this following case, which isn't what you want. The bash shell on the remote end would not see args "-c" "ulimit -a" but would see "-a" as a separate $ ssh -n localhost $HOME/bin/show-args bash -c "ulimit -a" arg1: bash arg2: -c arg3: ulimit arg4: -a That isn't what you want. You need to quote the args twice. $ ssh -n localhost $HOME/bin/show-args 'bash -c "ulimit -a"' arg1: bash arg2: -c arg3: ulimit -a In the end you want something like this: $ ssh -n localhost 'bash -c "ulimit -a"' core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-I) 8185 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 8185 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited However I think it is simpler to avoid the argument processing and instead using stdin to the shell. $ echo ulimit -a | ssh localhost bash Isn't that simpler? Bob
Re: redirection after braced block
Matthew Woehlke wrote:
>>> clemens fischer writes:
>>>
I have the following construct in a script:
... a number of commands
{
... a number of commands
} 2>&1 | ${prog_log} "${logfile}"
It seems anything inside the braces is not seen by bash, and it
doesn't show up in a "sh -x ..." trace, but ${prog_log} does. I
had debug echo's at the start of the block, they aren't triggered.
>
> This sort of construct seems to be working fine for me. Note that the
> contents of the block are executed in a subshell, and using 'true' as
> prog_log will suppress both stdout and stderr, as set up (though you
> might get a broken pipe error). So unless the commands in the block
> have side effects observable outside of the script, you won't know
> whether or not they execute.
Greg Wooledge observed in a private email that the parts of a pipeline
are executed in subshells. Presumably he thinks that I set "prog_log"
in the feeder end rendering it without a defined value in the consumer,
but this variable is a global available to both.
But you made me see the light anyway! Actually the logger was "system
${prog_log} "${logfile}"", with "system" being the customary
system()
{
local cur_fun="${FUNCNAME[0]}"
local ex=0
msg "$*"
[ ${opt_dryrun} -gt 0 ] && return 0
type -t "${1}" >/dev/null 2>&1 && {
eval "$@" || {
ex=$?
msg "$* exits ${ex}"
}
} || {
msg "${1} undefined $?"
ex=
}
return ${ex}
}
and "msg" sending output to "1>&2". As the script failed both with and
without that "system" prefix, I thought it didn't matter. I thought the
commands in "system" are neutral to any data on stdin until the eval is
reached.
Now what I needed to have both normal and dry-run working is setting the
logger to "cat" and unsetting logfile for the latter case, then
{ ... } 2>&1 | ${prog_log} ${logfile+"${logfile}"}
does what I mean. Does somebody know what's wrong with "system()" when
given data on stdin to be given to "eval"?
clemens
${!vname} not documented
Hi
I came across a script that did
$ VARIABLE1=value1
$ VARIABLE2=value2
$ for VAR in VARIABLE1 VARIABLE2
> do
> echo ${VAR}=${!VAR}
> done
VARIABLE1=value1
VARIABLE2=value2
I was unfamiliar with ${!VAR}. As far as I can tell, it's not documented in
the man page or the info pages.
I assume it was imported from Korn Shell
http://www.research.att.com/sw/download/man/man1/ksh.html
${!vname }
Expands to the name of the variable referred to by
vname. This will be vname except when vname is a name
reference.
Re: ${!vname} not documented
On Monday 05 October 2009 23:05:41 Mikel Ward wrote:
> I was unfamiliar with ${!VAR}. As far as I can tell, it's not documented
> in the man page or the info pages.
either your documentation is out of date (old bash install) or you just missed
it. it's under Parameter Expansion.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: ${!vname} not documented
Mike Frysinger wrote:
> Mikel Ward wrote:
> > I was unfamiliar with ${!VAR}. As far as I can tell, it's not documented
> > in the man page or the info pages.
>
> either your documentation is out of date (old bash install) or you just
> missed
> it. it's under Parameter Expansion.
> -mike
Ah, I see it.
It's in a block of text not using the exclamation point at all.
It would be more obvious if it had a paragraph directly below
${parameter} saying something like:
${!name}
Indirect expansion. name is expanded to produce the name of a
variable to expand.
