I'm using Windows 10 and running the version of Java 9 released by Oracle yesterday.
If I open a jshell and enter System.out.println(System.getenv()) the output is as expected, as shown in the lower portion of the screen shot below.
However, if I simply enter System.getenv() there is a big chunk of data missing from the middle of the output. See the initial portion of the screen shot below. This appears to be a feature of jshell since in the screen shot below the ellipsis ("...") in the output from System.getenv() (within the second box with hand drawn yellow edges) exactly corresponds to the missing data.
The end portion for the environment variable CommonProgramFiles is missing, as is the start of the environment variable SPRING_HOME, and there are several other environment variables such as Path which are not shown at all.
(Some information in the screen shot has been blurred for privacy.)
Does anyone else see the same thing (or not), and does anyone have suggestions on why jshell is doing this?
JShell does truncate some string results that are printed in the REPL. It doesn't effect the printing to the console however.
We can see the same thing happening running this:
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
List<Integer> x = IntStream.range(0,3000).mapToObj(Integer::valueOf).collect(Collectors.toList());
x
We will see the same truncation with the ellipsis occur in that output.
If we print the result:
System.out.println(x);
we don't see this.
This is user configurable. For example, we can create a custom format mode that allows up to 40,000 characters (an excessively high number which we will likely not encounter, so no truncation occurs).
/set mode mine normal -command
/set truncation mine 40000
/set feedback mine
This creates a new feedback mode called mine which inherits from the built in mode normal† (there are apparently a lot of options, so we inherit from another mode so that we don't have to worry about setting everything). See /help /set mode for details.
The second command sets the truncation to 40000 characters. It is possible to configure this so that the truncation depends on what sort of thing is displayed. See /help /set truncation for details.
Finally, the last command here switches to this feedback mode. Now, any thing displayed in the console will no longer be truncated unless it exceeds 40,000 characters.
This link along with the official documentation and the help commands above helped with figuring this out in order to write this answer.
† The normal mode shows up to 1,000 characters before truncation. Use /set truncation by itself to display the various truncation settings or /set truncation normal to display the settings for normal mode.
Related
I've enabled GL debug logging in my app, and getting messages such as:
GTT mapping a busy miptree BO stalled and took 0,147 ms
Initially I took the numeral to mean a sub-millisecond delay. Since there's a 0 before the comma, I didn't consider the interpretation "147ms", but this page says:
Don’t use commas in decimals.
... so it can't be a decimal fraction either.
So which is the correct interpretation?
Note: I use Ubuntu Linux and my regional settings are as follows:
As you can see, a period is set to used to separate the fractional part of the number.
How a driver decides what decimal mark to use is implementation-defined (all of the debug output messages are implementation-defined). It may follow your locale settings; it may follow something else. As such, there is no way to guarantee how it formats numbers.
It could be either, though if it is intended as a comma rather than a decimal mark, what would the zero mean?
Thanks to derhass' comment I found that locale's output says LC_NUMERIC=bg_BG.UTF-8. I changed the relevant value in /etc/default/locale to en_US.UTF-8and now a period is used, as expected. So it's indeed a sub-millisecond value.
Note: That's the only way I was able to get it fixed. Nothing I did in the KDE settings page (shown in a screenshot in the question) helped.
I'm trying to figure out a way to pipe the output of a command (ag, in this case) to less -F (i.e. --quit-if-one-screen), but if the output is less than one page, the screen just flashes the content before it disappears. I've read that I can use -X (--no-init) to disable clearing the screen upon exiting less, but in that case long output doesn't get cleared either, which kinda defeats the purpose of a pager.
Is there a way to make less -X work with -F? I.e., to clear the output upon exiting less, except if the output fits in a single page?
It's 2018 now and Less is available in version 530. One of the key changes is the behavior of less -F with content of less than one full screen.
The solution is easy: Install Less 530 from your package repository, or download from Free Software Foundation and compile it yourself. Then you can have less -F leaving the content on screen if it doesn't fill up one full screen.
This very question has been answered in Unix.SE. The top-voted answer there has actually been expanded into a full-fledged command-line tool that can act as a replacement for less: https://github.com/stefanheule/smartless.
I've been using it myself with great results (plus the author is very responsive to bug reports and feature requests on Github), so I highly recommend it to anyone facing this issue.
When I SSH into a particular server and launch screen, it ignores my CTRL+a key combo. Instead of CTRL+a c creating a new screen window, it instead acts as if I had just typed c. Other key combos fail in a similar way.
I've tried launching screen using screen -e ^jj to bind to j instead of a, but I still get the same result as above.
I tried adding a .screenrc file to my homedir that I know works on other machines, but it has no impact.
I also tried launch a zsh shell instead of bash.
Any ideas where to start to try and fix this? This basically renders screen unusable.
Thanks
screen reads commands from several configuration files during startup, as described in the FILES section of the man page or the Customizing Screen section of the User's Manual (also available, if it's installed, by typing info screen).
The files read are:
The file named by the $SYSSCREENRC environment variable (this may or may not be enabled)
/etc/screenrc
The file named by the $SCREENRC environment variable`
$HOME/.screenrc
(These interact and are searched in various ways that I don't entirely understand.)
In your particular case, based on the comments, the system on which you're running screen happens to have a /etc/screenrc file that contains an escape command that overrides the default.
A digression: in my own $HOME/.screenrc I have:
escape ^#^#
This sets the escape character to the null character, which can be entered by typing Ctrl-space. I find it easier to type, and less likely to conflict with other uses, than the default Ctrl-A. The only conflict I run into is the Emac set-mark-command function, and for that it's easy enough to type it twice.
When debugging a function (which has been marked debug using debug("f"), the debugger gives you the Browser prompt which also tells you at what line number in the program you are. If run a couple of test statements at the prompt (to check variables, etc.) the screen scrolls and I no longer know what line number I am at (using SecureCRT so it scrolls past the buffer). The command where only tells you what function you are in. Does anyone know how to get the actual line number and next statement to be executed?
Thanks
When I use the regular browser(), I set max.lines to print to a low number:
options(deparse.max.lines=100)
so that if the output during debugging is long, I don't have to scroll too far up.
For our application, we need to be able to print output at a specific location on a page. For example, we need to be able to print some text at exactly (1.00", 1.00") relative to the top left corner of the page. The problem lies in the fact that all coordinates in the various GDI calls are not relative to the upper left corner of the display, but are rather relative to a device dependent offset, which one obtains with code like:
int cx = ::GetDeviceCaps(hDC, PHYSICALOFFSETX);
int cy = ::GetDeviceCaps(hDC, PHYSICALOFFSETY);
These, of course, are in device units, so you convert them to logical units as desired. And then, you may adjust your coordinates in other API calls to get the output exactly where you need it.
This works like a charm when running under Windows directly. However, when using Terminal Services to print to a redirected printer on Windows Server 2008, the DeviceCaps functions no longer report correct information, at least for a large number of different printers. Device offsets are reported as 0, and when querying the printable region on a page, incorrect information is returned (the APIs overstate the amount of available real estate). Worse, it appears that either MS or the printer driver vendor is aware of the issue, because when the print job spools to your local machine (so that it can then spool to your local printer), all of the output is shifted by some compensating amount; an amount that appears to be a hack as it is nowhere close to the correct value reported by GetDeviceCaps when querying printer capabilities locally.
So, the result is that printed output gets shifted off the page ...
Has anyone else seen issues of this sort? Am I crazy to want precise control over printed output? Certainly, in order to paginate correctly, one needs an accurate value for the amount of available printable space, no? Any help or pointers would be appreciated.
The Microsoft Knowledgebase issue 959442 and the included hotfix should resolve the problem:
"The edges of a document are truncated when you try to print the document by using Terminal Services Easy Print from a client computer that is running Windows XP SP3, Windows Vista SP1, or Windows Server 2008"