From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 20 16:04:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5A6F530; Thu, 20 Jun 2013 16:04:28 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 944AD12BE; Thu, 20 Jun 2013 16:04:28 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r5KG4RGO026808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Jun 2013 11:04:27 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Thu, 20 Jun 2013 11:04:26 -0500 From: "Teske, Devin" To: Alexander Yerenkow Subject: Re: Shell variables containing output redirects Thread-Topic: Shell variables containing output redirects Thread-Index: AQHObcaJ9npDHNvlLE2IKQI/srBfppk/F++A Date: Thu, 20 Jun 2013 16:04:25 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F98E32@ltcfiswmsgmb21> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-20_07:2013-06-20,2013-06-20,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:04:28 -0000 On Jun 20, 2013, at 7:57 AM, Alexander Yerenkow wrote: > Hello all! >=20 > I have a problem with port JBoss72, which tries to behave as long-standing > port jboss5: >=20 > http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision= =3D302141&view=3Dmarkup >=20 >=20 >=20 > In rc run script there is such line: >=20 > %%APP_SHORTNAME%%_logging=3D"${%%APP_SHORTNAME%%_logging:-">> > ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>> > ${%%APP_SHORTNAME%%_logdir}/stderr.log"}" >=20 > Which provides way to overwrite default log location in /etc/rc.conf. >=20 > But this not working at all, all these redirects treated as simple > parameters for run script. >=20 > I made small test, to show my problem: >=20 > #!/bin/sh >=20 > logfile=3D"supposed-to-be.log" > log=3D">> ${logfile}" > echo "a1" >> ${logfile} > echo "a2" ${log} > cmd=3D"echo \"a3\" ${log}" > echo $cmd > $cmd > more ${logfile} >=20 > Here's execution output: >=20 > # ./t1.sh > a2 >> supposed-to-be.log > echo "a3" >> supposed-to-be.log > "a3" >> supposed-to-be.log > a1 >=20 > 1. My question is - Which are correct way to specify such redirects to be > overridden? >=20 If you must have a conditional redirect in the above manner (in which the r= edirect syntax is part of a variable): to_foofile=3D">> foofile" eval echo \"a1\" $to_foofile The shell will do a first-pass on the arguments, so what "eval" sees as arg= uments are: echo "a1" >> foofile And thus, eval does what it does best=85 evaluates the expressions as a set= of shell statements. NOTE: The rc script probably assumed bash and was ported from another syste= m where /bin/sh was indeed bash (but in FreeBSD, /bin/sh is not bash and is= much more strict in adhering to POSIX standards). However, I can't in all earnest recommend that approach as a method of cond= itional logging when there are so many better solutions. Here's one of my favorites for quick-and-dirty conditional logging: =3D=3D=3D #!/bin/sh if : some condition to enable debugging; then exec 3>>/tmp/log.stdout 4>>/tmp/log.stderr else exec 3>&1 4>&2 fi echo "a1" 1>&3 2>&4 # "a1" ends up in /tmp/log.stdout ls /nosuchfile 1>&3 2>&4 # You get in /tmp/log.stderr: "ls: /nosuchfile: No such file or directory" =3D=3D=3D So rather than having to prefix "eval" to every command *and* escape all th= e quotes and expansions=85 the above instead changes from (old) attempting = to use a conditional redirect syntax (by way of $logging variable) to (new/= above) having every command redirect stdout/stderr but having the destinati= ons of the redirect change based on some pre-condition. > 2. tomcat6.in, rubyrep.in, tclhttpd.in, geoserver.in, and many more rc > scripts from ports are using something like this: >=20 > log_args=3D">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} " >=20 > and after that use $log_args. >=20 > Are they silently broken, or am I missing something? >=20 I would call that broken if the invocation line at the top of the script is= #!/bin/sh (it may not be broken if you instead see something like "#!/usr/= bin/env bash"). > 3. Should I build up $cmd, and run > eval "$cmd" - would this be nice ro dirty hack? >=20 Nah=85 just go through and replace "$log_args" with either "1>&3 2>&4" or "= >&3 2>&4" (the leading 1 on ">&" in the first option is actually the implie= d default, so you can omit it and go for the second option if you like; how= ever since you can't say "exec 3>&" and have to say "exec 3>&1", I tend to = think the first option is more explicitly-clear in what's going on with the= file-descriptors). > Thanks! >=20 No problem. Glad to help. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.