The default setting for Cmder is to wrap text output. But how to set Cmder do not wrap text output?
The Cmder, i meant : http://cmder.net/
As of now, I don't believe there is a way to disable text wrapping.
Someone did open an issue related to disabling line wrapping.
However, as featured in ConEmu's Roadmap:
Current ConEmu version allows neither horizontal scrolling nor setting horizontal buffer size.
Try running command mode, then you will see parameters below.
Status for device CON:
Lines: xxxx
Columns: xxxx
Keyboard rate: xx
Keyboard delay: x
Code page: xxx
Remember the value of Columns, just in case you want to roll it back. Now execute command mode 1000 and the Column parameter should change to 1000. (or use any higher number till you get desired result)
This also works on cmd and powershell.
I use the default terminal.app
I use cmd+d command to split panes so I can look at the part of the code while using another command.
This annoying bug comes up when de-splitting the panes.
What it does is that it basically reduces the vertical length of the terminal, so that after de-split, terminal is not filling my screen vertically.
Is there any solution to this?
Any true solution is going to have to depend on a bug fix. But this works for me:
Set the window default size in Preferences/Profiles/Window.
Assign a shortcut key to Window/Return to Default Size.
You could also use the inspector that you get with Shell -> Show Inspector.
I'm using Sikuli to do some tests which requires the computers resolution and text size to be set to a certain size. In this case, the text size should be set as "smaller - 100%". I'd like the computer to check to make sure this is the case before it actually wastes time attempting to run the test.
Is there a command you can type into command prompt that will tell you what the text size setting is set to? Or another quick way of finding the information? The only way I know of to get the information is Control Panel\Appearance and Personalization\Display. Using Sikuli to open up the control panel and visually check the text size wouldn't be worth the time, so I'd like a quick way of checking.
Also, I'd rather this be without any addon or anything like that.
Thanks.
HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics
AppliedDPI DWord
This is a per user setting.
I'm having some issues with my Cygwin terminal when I run 'less'. 'less' works fine, but when I come out of it, all the screen buffer history of the terminal is lost. Any suggestions?
I'm running Cygwin on WinXP.
Try running as less -X, or set the LESS environment variable to -X.
It has nothing to do with bash. What's being erased is the text displayed by your terminal emulator.
Like other full-screen programs, less saves the terminal state (including any displayed text and the cursor position) when it starts, and restores it on exit.
It does this by printing the strings defined by the smcup and rmcup terminfo entries.
These depend on the value of the $TERM environment variable.
If these strings aren't printed, or if they're configured to something that doesn't save and restore your terminal state, then less will replace whatever was on your screen by the contents of the file you want to view, and then not restore it.
Using the -X option to less (as suggested by the answer you accepted tells less not to print the smcup and rmcup strings -- which I would expect to cause the problem you're trying to solve.
If you want to save and restore your terminal state (which means that the output produced by less will vanish when you quit), you need to make sure that your $TERM environment variable is set to something with proper smcup and rmcup settings. I find that setting it to xterm usually works.
If you're ambitious, you can create your own terminfo entry and use the tic command to "compile" it to the binary format used by the system.
Dawid Ferenczy's answer suggests another possible cause for the problem; it's not something I've ever run into myself.
(Opinions differ widely on whether saving and restoring the terminal state is a good thing. This blog entry was written by someone who intensely dislikes it. Personally, I like it; if I want to run a full-screen command and keep its output visible while I'm doing something else, I just launch it in another window.)
(The original poster hasn't been on the site in about 2½ years, so we shouldn't expect any feedback, but these answers are likely to be useful to others.)
I had the same issue on my new laptop. I have been using Cygwin on the 64bit Windows 7 for a long time and I never experienced this problem. But on the new fresh system (also 64bit Windows 7) the same Cygwin with the same configuration cleared the screen buffer whenever I quit LESS, MAN, VIM etc. And it bothered me very much. Because I'm using Cygwin inside ConEmu terminal emulator, I suspected ConEmu. After a lot of hours comparing everything what potentially could be the cause (environment variables, configurations, software versions etc.), I had a conversation with the ConEmu's author (and he was really great, exemplary support for the free software!). And we finally found the cause.
The only difference (or one of few) was in the display size. The old laptop has a screen resolution of 1366 x 768 pixels, while the new one has 1920 x 1080. And I'm using the whole screen for the terminal window. It's really strange, but if the terminal window height is greater than cca 62 lines, the screen buffer is cleared after quitting the LESS, VIM etc. No matters if Cygwin is executed inside the ConEMu or plain cmd.exe. Making the terminal window smaller solved the problem. Window height of 62 lines seems to be fine for me. Also, with some of greater height values, the LESS process sometimes crashed.
It seems that it's a problem of the Cygwin.
The whole story you can read here.
Maybe it could help somebody. It took me really a lot of time to solve that. While the solution (or rather workaround) is such damn stupid :)
For some reason the Windows command prompt is "special" in that you have to go to a properties dialog to resize it horizontally rather than just dragging the corner of the window like every other app. Unsurprisingly this feature made it into P-P-P-Powershell as well -- is there any way around this via command prompt replacement or Windows hackery?
2019 Update:
Microsoft has released the terminal app on Github & the Windows Store, and it has tabs, panels, acrylic transparency, and other features.
2016 Update:
Windows 10's default conhost UI has more features, including free resize, transparency, etc (this includes cmd & powershell)
I now use ConEmu (walkthrough here) which has many features including tabs & split panes.
Other options include Cmder (which comes with additional tools built in), and ConsoleZ (a fork of Console2).
Console appears to no longer be updated
I don't know if this is what you want: Resizing the Powershell Console Window. If so, I got this awhile ago: Just type: resize and use the arrow keys to adjust width and height.
##
## Author : Roman Kuzmin
## Synopsis : Resize console window/buffer using arrow keys
##
function Size($w, $h)
{
New-Object System.Management.Automation.Host.Size($w, $h)
}
function resize()
{
Write-Host '[Arrows] resize [Esc] exit ...'
$ErrorActionPreference = 'SilentlyContinue'
for($ui = $Host.UI.RawUI;;) {
$b = $ui.BufferSize
$w = $ui.WindowSize
switch($ui.ReadKey(6).VirtualKeyCode) {
37 {
$w = Size ($w.width - 1) $w.height
$ui.WindowSize = $w
$ui.BufferSize = Size $w.width $b.height
break
}
39 {
$w = Size ($w.width + 1) $w.height
$ui.BufferSize = Size $w.width $b.height
$ui.WindowSize = $w
break
}
38 {
$ui.WindowSize = Size $w.width ($w.height - 1)
break
}
40 {
$w = Size $w.width ($w.height + 1)
if ($w.height -gt $b.height) {
$ui.BufferSize = Size $b.width $w.height
}
$ui.WindowSize = $w
break
}
27 {
return
}
}
}
}
If you don't mind installing cygwin you can use it with xterm or rxvt. You'll also be able to use Bash as the shell instead of cmd.exe which is much nicer.
This isn't quite what you're looking for, but the way I get around it is by using cygwin's rootless X-Windows mode and XTerms. I prefer the unix command line environment more then Windows' env, and the XTerm windows act just like any other window.
As for straight replacements, a quick google search shows these:
Console
econsole
I haven't tried them, so I'm not sure if they have what you're looking for, but they might be worth a shot.
PowerShell v2.0 ships with an interactive shell, called the PowerShell Integrated Script Environment (ISE). It's not fantastic, but it's usually better than the console subsystem.
Good
Includes a PowerShell script editor, with colorization
Colorization as a type at the prompt
I can have multiple PowerShell sessions, including remote sessions, as tabs.
The ISE is PowerShell-aware, so I can manipulate and extend it with PowerShell. For example, see the "IsePack", which adds a ton of features, including copy-as-HTML.
Can easily scale the text
Conventional Windows resizing, cursor navigation, selection, copy, paste, fonts, etc.
Bad
Interactive console applications block waiting for input, and thus hang.
Console applications that detect whether their standard IO are redirected will think that is so, and thus act oddly. The worst is TFS's tf.exe. For example, 'tf submit' will submit without prompting, even though the prompt is GUI, not CLI.
A limited feature set out of the box. It's obvious they would like to make a much richer PowerShell IDE but did not.
Way after the fact, but things have improved in the meantime. ConEmu is highly configurable, and can be resized horizontally and vertically. It has the somewhat odd (to me anyway) behavior of resizing the font as the window is resized. There's some discussion about it here. And Scott Hanselman has written about it, including integration with FarManager.
You might consider installing FAR. It's an excellent text mode file manager and much more. It could also be resized by dragging the corner of the window :)
If you set the property 'Layout/Screen Buffer Size/Width' then, when prompted, choose 'Modify shortcut that started this window' it will remember the buffer width. Then when you start another command prompt it will be, for example, the original 80 wide, but you can now stretch it to whatever you set the buffer width to.
Command Prompt will not wrap at the current window width, only at the buffer width. Thus if you've set the buffer width to 120, but the window is only 80 wide the lines will wrap at 120 and you'll have to scroll to read characters past 80.