resize
set environment and terminal settings to current xterm window size
see also :
tset - xterm
Synopsis
resize [
-u | -c ] [ -s [
row col ] ]
add an example, a script, a trick and tips
examples
source
Resizing the boot partition
Looks like you're installing a new kernel; those can be sizeable
(~20+ MB, even when compressed). From the error, I think
yum
is telling you it needs 9 more MB than
what you have available.
There are a few ways to fix this.
-
Remove old kernels. If you have multiple old
kernels you're no longer using, you might be able to free up
enough space to install the new one by uninstalling the very
oldest kernel image. This will only work if you have 2 or
more kernels installed, and assumes your system isn't
actually using that oldest kernel image.
-
Relocate /boot
to the root
partition. You could relocate /boot
from its own partition to a directory on the root partition
(/
). I'm not sure of the process -- I'd assume
this would get the basic setup going, but you'd need another
command to update your bootloader (Grub?) and alert it to the
new location.
These commands need root privs (use sudo
with
each, or get a root shell with su
).
-
make the new location
mkdir /boot-new
-
copy boot files
( cd /boot ; tar cf - . ) | ( cd /boot-new ; tar
xvf - )
(with sudo
...)
sudo sh -c "( cd /boot ; tar cf - . ) | ( cd
/boot-new ; tar xvf - )"
-
unmount separate partition -- maybe not doable without
rebooting? maybe need to boot to a liveCD?
umount /boot
-
remove old boot directory, rename new
mv /boot /boot-old
mv /boot-new /boot
-
edit /etc/fstab
, comment out
/boot
partition line or change mountpoint to
/boot-old
-
missing step: reconfigure your
bootloader to access /boot
on
/dev/sda7
instead of the old version on
/dev/sda6
.
-
Resize your /boot
partition.
You'll need a LiveCD for the task. Boot into it and run
gparted
. You'll probably need to resize your
system partition slightly, then move it, to make room. I
can't give you specifics without knowing the partition
table.
Expand the /boot
partition to a size of at
least 2-300MB to avoid having this
problem again.
Resizing system partitions can be dangerous.
Make backups before you attempt it, and read up on what you
are doing before you do it. This is my least
recommended option.
-
Replace your system drive. Finally, if
you've wanted a larger system hard drive, now is a
great time to do so. In the process of copying
partitions from the old drive to the new, you can expand the
/boot
partition. You'd use a LiveCD for this as
well.
Doing it this way is like resizing partitions, without the
danger of corrupting your system root partition. Plus, if
you're moving to a bigger hard drive, you get the chance to
resize other partitions as needed.
source
How do I use command line and wmctrl to make a window larger than the screen to get a huge screenshot?
Just tested with import
and a window extended beyond
/ bigger than the screen size; and it seems import
will capture an image of the same size as the big window size --
unfortunately all pixels beyond the screen size, and all pixels
covered by other windows, will be black.
So maybe the only way is to use xrandr
to enlarge
screen size (as in 'screen pannning') - or to use something else
that will provide larger screen size: for instance, "How
can I take browser screenshots at a higher resolution than my
browser supports? - Super User" notes:
Use Xephyr
to create a nested X session
(Xephyr
is apparently in sudo apt-get install
xserver-xephyr
in Ubuntu)
Hope this helps,
Cheers!
Edit: yup, xrandr
works with the usual printscreen
for me (also with import
, just needs enough space
for a terminal to fit, so it doesn't overlap the target window),
just note the Virtual size in xorg.conf
(see
"xrandr: screen cannot be larger than" ...)
source
How can I get Terminal to repaint the contents when I resize the terminal?
Since I posed this question, I've found a code-snippet out there
that solves this.
I've tested it in RHEL5, and it is successfully solving the need
I had. Thus, when get have a command output some text. Such as:
ls -al
you can then resize the window with your
mouse more-or-less than 80 pixels, and the output with wrap onto
the next line if theres not enough visible room on the screen, or
unwrap to occupy just one line, as you widen your window.
Found it on: http://codesnippets.joyent.com/posts/show/1645
tput lines
tput cols
echo $LINES
echo $COLUMNS
stty size
stty size | awk '{print $1}' # lines
stty size | awk '{print $NF}' # columns
stty size | cut -d" " -f1 # lines
stty size | cut -d" " -f2 # columns
stty -a | awk '/rows/ {print $4}' # lines
stty -a | awk '/columns/ {print $6}' # columns
stty -a | sed -E -n -e 's/^.*[^[:digit:]]([[:digit:]]+)[[:space:]]+rows;.*$/\1/p;q;'
stty -a | sed -E -n -e 's/^.*[^[:digit:]]([[:digit:]]+)[[:space:]]+columns;.*$/\1/p;q;'
# automatically resize the Terminal window if it gets smaller than the default size
# positive integer test (including zero)
function positive_int() { return $(test "$@" -eq "$@" > /dev/null 2>&1 && test "$@" -ge 0 > /dev/null 2>&1); }
# resize the Terminal window
function sizetw() {
if [[ $# -eq 2 ]] && $(positive_int "$1") && $(positive_int "$2"); then
printf "\e[8;${1};${2};t"
return 0
fi
return 1
}
# the default Terminal window size: 26 lines and 107 columns
sizetw 26 107
# automatically adjust Terminal window size
function defaultwindow() {
DEFAULTLINES=26
DEFAULTCOLUMNS=107
if [[ $(/usr/bin/tput lines) -lt $DEFAULTLINES ]] && [[ $(/usr/bin/tput cols) -lt $DEFAULTCOLUMNS ]]; then
sizetw $DEFAULTLINES $DEFAULTCOLUMNS
elif [[ $(/usr/bin/tput lines) -lt $DEFAULTLINES ]]; then
sizetw $DEFAULTLINES $(/usr/bin/tput cols)
elif [[ $(/usr/bin/tput cols) -lt $DEFAULTCOLUMNS ]]; then
sizetw $(/usr/bin/tput lines) $DEFAULTCOLUMNS
fi
return 0
}
# SIGWINCH is the window change signal
trap defaultwindow SIGWINCH
sizetw 26 70
sizetw 10 107
sizetw 4 15
For some good reason, OSX (atleast in my current 10.7.2) seems to
support resizing natively.
source
resize2fs seems stuck at pass 3 (scanning inode table) - what to do?
I finally figured out what it was. After cancelling the original
resize (just a simple ctrl+C), I ran e2fsck -f -y
/dev/sdb3
to correct any issues I made. I was able to
mount the partition still under the original size, so no data was
lost. I then ran resize2fs with the debug flag (resize2fs
-d 14 <xxx>
) and noticed that it was stuck in a
constant loop trying to relocate a chunk of inodes.
I finally got it to work by using an older version of
e2fsprogs. I put Ubuntu 9.10 (Karmic Koala) on a USB stick,
booted into it, installed the open-source rr232x drivers so I
could manipulate the array, and ran the older version of
e2fsprogs (resize2fs 1.41.9 (22-Aug-2009), to be exact).
I had originally tried the resize2fs -p /dev/sdb3
863000000
, and it had told me that it required ~26 million
blocks. So I took the target size, added that to it and did
resize2fs -p /dev/sdb3 1000000000
. 10 minutes later
I'm greeted with the message:
/dev/sdb3 is now at 1000000000 blocks
Now I guess the ultimate question is why the newer version of
e2fsprogs couldn't/wouldn't tell me that I was asking for too
small a size (and why it offered a size that small in the first
place)?
source
Enlarge partition on SD card
/dev/sdb
is the device node pointing to the entire
hard drive, and it starts at the first sector of the HDD. You
need to point resize2fs
to the specific
partition you want to resize (apparently, in
your case, /dev/sdb2
).
FYI, using the console is not necessary if you have a graphical
desktop. Just install gparted
(you didn't indicate
your Linux distro, so I don't know if it's available or, if so,
what steps to install it). It will provide a user-friendly way to
do this. You could also probably do it with the
palimpsest
Disk Utility on modern OSes.
source
Unable to resize (enlarge) Linux partition
I couldn't tell you for sure why you are not able to resize you
partition (perhaps it thinks the drive is somehow in use?), but I
can tell you what you can try to do to resize it some other way.
In my experience, drives are a lot more cooperative when you're
not running something off of them. So what I would do is download
a Linux Live CD of some kind that has a partitioning tool and
boot to it and partition the drive from there. The GParted Live CD would probably be my choice of
Live CD for this kind of thing, but most Linux Live CDs will work
for this as long as they come with GParted or another
partitioning tool.
All you need to to do is burn the disk image to a CD and then
boot to it, and use GParted to try and resize the partition. If
that still doesn't solve your problem, then try posting the
output of sudo fdisk -l
(that's a lowercase "L") at
a Linux command line and a description of what is on each
partition and maybe that'll give us some clues to the problem.
source
Issue after resizing partition for Fedora under VMware Fusion
In step 5 you're running 'lvm vgchange -a y'; shouldn't it be
'lvm vgchange -ay'? (i.e. no space between a and y)
Here's hoping it's that simple...
-pbr
source
Batch resize and compress PDF files
I'm suggesting a command line tool here, which can be
easily batched with loops in built-in scripting languages in
Windows, Linux, OS X, etc.
ImageMagick supports PDFs and has a resize
option with its convert tool. I've never used it personally, but
you can try to play around with that.
You can also use the compress
option (there's an
example here):
Rotate a PDF
$ convert -rotate 270 -density 300x300 -compress lzw in.pdf out.pdf
This assumes a TIFF-backed PDF. The density parameter is
important because otherwise ImageMagick down-samples the image
(for some reason). Adding in the compression option helps keep
the overall size of the PDF smaller, with no loss in quality.
For multipage PDFs, you may want to use pdftk
, then use mogrify
from ImageMagick to convert
each page in place:
$ pdftk in.pdf burst
$ mogrify -rotate 270 -density 300x300 -compress lzw pg_*.pdf
$ pdftk pg*.pdf cat output out.pdf
$ rm pg*.pdf
To convert PDF files with ImageMagick, you need to have
GhostScript installed.
ImageMagick can convert multipage PDFs. While
mogrify
will convert in place, I recommend you use
convert
so you can keep the originals in case of
accident.
I've done some testing on your provided sample PDF. This worked
quite well for me:
convert -density 200 -compress jpeg -quality 20 test.pdf test2.pdf
Density defaults to 72
DPI. By setting it higher we
can get a higher resolution and therefore acceptable quality. It
looked alright at 150
, and was a little smaller, but
if you want to cater for a range of PDFs 200
should
work.
JPEG compression should either auto choose a level or default to
92
on a scale of 1
to 100
with 100
being the best. Setting it at
20
, it looks almost as good as the original (a
little fuzzier and the small text at the bottom is a little hard
to read, but it was originally anyway).
These options bring your 1.7MB sample down to
0.5MB, while keeping it readable. You can
experiment a little.
If you want a smaller size (both of the file and of the
image/PDF), you can use -resize #%
, e.g.
-resize 75%
. On your example PDF, this makes the
small print at the bottom pretty much unreadable, though.
If you're still tight for space, especially for the multipage
PDFs, you could compress further by adding the files to a ZIP (or
other) archive. This brought the file size down to 0.43MB on that
test PDF (reducing the JPEG compression quality has a much more
drastic effect). You could also split the PDF file into pages
with pdftk
, as @glallen suggested
in his edit, or split the archive and recombine at the other end.
2MB is also a rather small attachment limit, you may want to look
into other email providers. From memory, GMail provides over 10MB
per email.
These options, and more, are fully documented on
their website.
source
clonezilla moving to bigger harddrive
Use a tool like Parted Magic to resize the partition and take
advantage of the full space.
description
Resize
prints a shell command for setting the appropriate
environment variables to indicate the current size of
xterm window from which the command is run. For this
output to take effect, resize must either be
evaluated as part of the command line (usually done with a
shell alias or function) or else redirected to a file which
can then be read in. From the C shell (usually known as
/bin/csh), the following alias could be defined in
the user’s .cshrc:
% alias rs 'set
noglob; eval `resize`'
After resizing
the window, the user would type:
% rs
Users of
versions of the Bourne shell (usually known as
/bin/sh) that don’t have command functions will
need to send the output to a temporary file and then read it
back in with the “.” command:
$ resize >
/tmp/out
$ . /tmp/out
Resize
determines the user’s current shell by first checking
if $SHELL is set, and using that. Otherwise it
determines the user’s shell by looking in the password
file. Generally Bourne-shell variants (including ksh)
do not modify $SHELL, so it is possible for
resize to be confused if one runs resize from
a Bourne shell spawned from a C shell.
options
The following
options may be used with resize:
-u
This option indicates that Bourne shell commands should
be generated even if the user’s current shell
isn’t /bin/sh.
-c
This option indicates that C shell commands should be
generated even if the user’s current shell isn’t
/bin/csh.
-s [rows
columns]
This option indicates that Sun
console escape sequences will be used instead of the
VT100-style xterm escape codes. If rows and
columns are given, resize will ask the
xterm to resize itself. However, the window manager
may choose to disallow the change.
Note that the
Sun console escape sequences are recognized by XFree86
xterm and by dtterm. The resize program
may be installed as sunsize, which causes makes it
assume the -s option.
The rows
and columns arguments must appear last; though they
are normally associated with the -s option,
they are parsed separately.
environment
TERM
set to "xterm" if not already set.
TERMCAP
variable set on systems using termcap
COLUMNS, LINES
variables set on systems using terminfo
files
/etc/termcap
for the base termcap entry to modify.
~/.cshrc
user’s alias for the command.
see also
csh,
tset , xterm
authors
Mark
Vandevoorde (MIT-Athena), Edward Moy (Berkeley)
Copyright (c) 1984, 1985 by X Consortium
See X(7) for a complete copyright notice.