I was pounding through the latest updates, accepting the updates over the originals, and caused etc-update to puke on something it probably should be able to handle, and incorrect input: --------------------------------------------------------------------------------- 1) Replace original with update 2) Delete update, keeping original as is 3) Interactively merge original with update 4) Show differences again Please select from the menu above (-1 to ignore this update): 1y /usr/sbin/etc-update: line 272: read: 1y: value too great for base (error token is "1y") Exiting: User termination! --------------------------------------------------------------------------------- This error should probably be handled and either redisplay the difference (like it does if you just hit enter at that prompt), redisplay the options and prompt or just the prompt even.
you neglected to post `emerge info` so i can only assume you're using an older version this is for sure fixed in latest 2.1
Nope. $ emerge --info Portage 2.1-r2 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.15-gentoo-r1 i686) ================================================================= System uname: 2.6.15-gentoo-r1 i686 Intel(R) Pentium(R) M processor 1.86GHz Gentoo Base System version 1.12.4 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O1 -march=pentium3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf" CXXFLAGS="-O1 -march=pentium3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://gentoo.chem.wisc.edu/gentoo/ http://open-systems.ufl.edu/mirrors/gentoo" LINGUAS="en" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi alsa artworkextra asf async automount avi bash-completion beagle berkdb bitmap-fonts boundschecking branding bzip2 cairo cddb cdr cli crypt css cups dbus dlloader doc dri dvd dvdr dvdread emboss encode firefox foomaticdb gd gif gimpprint glitz gnome gnutls gpm gstreamer gtk gtk2 hal i8x0 imap imlib isdnlog jack-tmpfs javascript jce jpeg libg++ libwww logrotate mad mikmod mime mmx mono motif moznoirc mozsvg mp3 mpeg ncurses nfs nptl nsplugin nvidia ogg opengl pam pcmcia pcre pdflib perl png ppds pppd python quicktime readline reflection samba sasl sdl session slp spell spl sse sse2 ssl swat syslog tcpd theora tiff truetype truetype-fonts type1-fonts udev vim-with-x vorbis win32codecs winbind xml xmms xorg xpm xprint xscreensaver xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en userland_GNU video_cards_nvidia video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I just tried it again and it still happens with portage that has that emerge --info. Take note that this is after you've selected the file and the diff has been displayed, *not* on the first "screen" -- the file selection screen. The bogus "1y" does work properly there.
This problem still exists in trunk. When given an integer variable, the read builtin terminates the shell when the input triggers a "value too great for base" error (only happens when the string has a certain format such as 1y). I'm not sure if the termination is "correct" behavior or if it's a bug in bash.
Anything I can do to help figure it out?
This is fixed in svn r4375. For those that may be interested, here's a test case: declare -i my_input while true; do read my_input; done The above code will break out of the loop when "1y" is typed. The integer conversion can be done in a subshell in order to avoid an unwanted break.
This has been released in 2.1.1_rc1-r2.
