getApplication does not work with #calc statements in the controlDict

When there are #calc statements in the controlDict (either directly or as an #include), the function getApplication fails because the output from foamDictionary includes all the output statements from #calc. This is fixed by adding a tail -1 as follows to the getApplication function: foamDictionary -entry application -value system/controlDict | tail -1 Examples of issue shown below: controlDictinput.txt

Depending on which behaviour we want, this can be an interesting problem to try and eliminate. If we obtain the application via an #include we need to keep the various directives, which means we get the #calc as a collateral invocation (even if we don't particularly want to be compiling things). However, if we don't need the #include for the application name, this is easy enough to avoid.

foamDictionary -disableFunctionEntries

@Prashant tested and this produces other rubbish on the output, but that information should be output on stderr anyhow. Which I'll change.

mentioned in commit b0eddc32

Apparently undecided if we should redirect stderr to /dev/null or not.

Note there currently no way to selectively enable/disable dictionary directives since they are internally handled by a single bool. If we need something better (-disable-all -disable-include -disable-calc, -enable-include -enable-calc ...) we'll need to wait for next release.

mentioned in issue #893 (closed)

How do you think about introducing a silent mode - "foamDictionary -silent -entry ... -value " - which suppresses additional rubbish from the output?

mentioned in commit ce54105d

I've just finished with some changes for #722 (closed), #893 (closed), #901 (closed) which puts us in the right general direction. We still have the wmake output going to stderr, but that may not be such a bad thing. If the wmake processes take a long time, it would seem that the process has locked up, but instead it is doing something (albeit slowly).

The -silent option for foamDictionary would be closer in reach now. In ce54105d I purposely left the infoDetailLevel as a signed value - leaving it open for some special meaning with a negative value (eg, your -silent option). Might be doable, but I'd rather not commit to any special meanings so early.

assigned to @mark

closed via commit b0eddc32