-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OMake redirects stdout' and
stderr' even for simple commands.
#112
Comments
Note that this is required in order to support -S, --output-postpone, --output-only-errors, --output-at-end options. |
@ANogin: Thanks Aleksey! I should have drawn that conclusion myself. (* Deep sigh. *) Is there a combination of |
@cspiel: I tried to figure it out when I wrote the previous commit, but even those some parts of the code look like some of the diversion is skipped under --output-normal, it still looks like things get redirected with any combination of --no-S --output-normal --no--output--postpone, etc. |
@ANogin: Indeed, the redirections are applied not matter which output option is active. Doh! Therefore I whipped up a new option that disengages the tees; see #113. I'm not |
For example if you use less(1) to page a file from OMake as in
you loose all of the controlling terminal's capabilities. Also try:
or my favorite, w3m(1), which degenerates to a fancy cat(1)
in the rule body instead of less(1).
No shell redirects
stdout
orstderr
for simple commands, not evenosh(1)! Try
to verify that it really works.
I wrote the tiny tool is-a-tty to investigate the situation. The program
inquires the TTY's name (ttyname(3)) and whether the standard file
descriptors are connected to a TTY (isatty(3)). Here are the results:
bash(1):
OK - all three descriptors are conneted to a TTY.
OK - we redirected
stderr
to err.out.osh(1):
OK - all three descriptors are connected to a TTY.
OK -
>&
redirects bothstdout
andstderr
to err.out.omake(1) with an OMakefile containing
yields:
Not OK - both
stdout
andstderr
are implicitly redirected.Obviously the redirection only kicks in inside of OMake,
not plain osh(1).
This quirk is most annoying when using any kind of pager in a rule
body, but also disables automatic technicolor error messages from
modern compilers.
The text was updated successfully, but these errors were encountered: