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"
===
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).
> Thanks!
>
No problem. Glad to help.
--
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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
