On Jun 20, 2013, at 9:11 AM, Teske, Devin wrote:
>
> On Jun 20, 2013, at 9:04 AM, Teske, Devin wrote:
>
>>
>> On Jun 20, 2013, at 7:57 AM, Alexander Yerenkow wrote:
>>
>>> Hello all!
>>>
>>> I have a problem with port JBoss72, which tries to behave as long-standing
>>> port jboss5:
>>>
>>> http://svnweb.freebsd.org/ports/head/java/jboss5/files/jboss5.in?revision=302141&view=markup
>>>
>>>
>>>
>>> In rc run script there is such line:
>>>
>>> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
>>> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
>>> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
>>>
>>> Which provides way to overwrite default log location in /etc/rc.conf.
>>>
>>> But this not working at all, all these redirects treated as simple
>>> parameters for run script.
>>>
>>> I made small test, to show my problem:
>>>
>>> #!/bin/sh
>>>
>>> logfile="supposed-to-be.log"
>>> log=">> ${logfile}"
>>> echo "a1" >> ${logfile}
>>> echo "a2" ${log}
>>> cmd="echo \"a3\" ${log}"
>>> echo $cmd
>>> $cmd
>>> more ${logfile}
>>>
>>> Here's execution output:
>>>
>>> # ./t1.sh
>>> a2 >> supposed-to-be.log
>>> echo "a3" >> supposed-to-be.log
>>> "a3" >> supposed-to-be.log
>>> a1
>>>
>>> 1. My question is - Which are correct way to specify such redirects to be
>>> overridden?
>>>
>>
>> If you must have a conditional redirect in the above manner (in which the
>> redirect syntax is part of a variable):
>>
>> to_foofile=">> foofile"
>> eval echo \"a1\" $to_foofile
>>
>> The shell will do a first-pass on the arguments, so what "eval" sees as
>> arguments are:
>>
>> echo "a1" >> foofile
>>
>> And thus, eval does what it does best… evaluates the expressions as a set of
>> shell statements.
>>
>> NOTE: The rc script probably assumed bash and was ported from another system
>> 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
>> conditional logging when there are so many better solutions.
>>
>> Here's one of my favorites for quick-and-dirty conditional logging:
>>
>> ===
>>
>> #!/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"
>>
>> ===
>>
>
> Yeah… don't do that… the moment I hit send, it dawned on me that the extra
> file-descriptor (however cute), is entire unnecessary…
>
> ===
>
> #!/bin/sh
> if : some condition to enable debugging; then
> exec 1>>/tmp/log.stdout 2>>/tmp/log.stderr
> fi
> echo d1
> # if debugging, goes to /tmp/log.stdout
> # if no debugging, goes to console
> ls /nosuchfile
> # if debugging, an error goes to /tmp/log.stderr
> # if no debugging, error goes to console
>
> ===
>
>
>
>> So rather than having to prefix "eval" to every command *and* escape all the
>> quotes and expansions… 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
>> destinations 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:
>>>
>>> log_args=">> ${tclhttpd_stdout_log} 2>> ${tclhttpd_stderr_log} "
>>>
>>> and after that use $log_args.
>>>
>>> Are they silently broken, or am I missing something?
>>>
>>
>> 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?
>>>
>>
>> Nah… 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 implied
>> default, so you can omit it and go for the second option if you like;
>> however 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).
>>
>
> Actually… you could potentially fix this with one line of code…
>
> [ "$logging" ] && exec 1>>/tmp/log.stdout 2>>/tmp/log.stderr
>
> And then go remove the "$logging" from the end of each line.
Even better than removing "$logging" (or $log_args) from the end of each line…
Just set it to NULL.
So in the case of your earlier example…
>>> %%APP_SHORTNAME%%_logging="${%%APP_SHORTNAME%%_logging:-">>
>>> ${%%APP_SHORTNAME%%_logdir}/stdout.log 2>>
>>> ${%%APP_SHORTNAME%%_logdir}/stderr.log"}"
I would do the following…
#
# Do the real task of enabling debug output
#
if [ "${%%APP_SHORTNAME%%_logging}" ]; then
exec 1>>"${%%APP_SHORTNAME%%_logdir}/stdout.log"
exec 2>>"${%%APP_SHORTNAME%%_logdir}/stderr.log"
fi
#
# Dirty hack to make it so I don't have to
# remove ${%%APP_SHORTNAME%%_logging}
# from each line.
#
%%APP_SHORTNAME%%_logging=
> --
> Devin
>
> _____________
> The information contained in this message is proprietary and/or confidential.
> If you are not the intended recipient, please: (i) delete the message and all
> copies; (ii) do not disclose, distribute or use the message in any manner;
> and (iii) notify the sender immediately. In addition, please be aware that
> any message addressed to our domain is subject to archiving and review by
> persons other than the intended recipient. Thank you.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
