From proski at gnu.org Wed Jan 2 20:09:18 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 2 Jan 2002 15:09:18 -0500 (EST) Subject: Compilation problem on FreeBSD 4.4 In-Reply-To: Message-ID: Hi! > > > I am getting: > > > edit.c: In function `free_selections': > > > edit.c:1606: `selection_history' undeclared (first use in this function) I remember compiling mc just before releasing 4.5.55 on either FreeBSD 4.2 or FreeBSD 4.3. I think that something is wrong with a hack that made it possible to initialize variables in the header file edit.h. File edit.c used to define _EDIT_C to THIS_IS, which was used to deternime whether the file wants a declaration with a value or without. My guess is that either _EDIT_C or THIS_IS is redefined somewhere. This hack doesn't exist in the current source. You may want to take the latest snapshot from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ -- Regards, Pavel Roskin From proski at gnu.org Thu Jan 3 00:32:02 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 2 Jan 2002 19:32:02 -0500 (EST) Subject: detection of xterm mouse support In-Reply-To: <20011227103944.GA14564@oskar> Message-ID: Hi, Oskar! Sorry for the late reply. I like your patch, but it has a side effect: TERM=ansi mc -x on rxvt doesn't enable the mouse. Your patch changes the meaning of "-x" - now it forces only xterm-style save/restore of the screen and the hints in the caption, but not the xterm mouse support. This would require changes in the documentation and the help. I don't want to do it at this point, because many translations will have to be changed. I would rather remove the "-x" option completely. It has been broken for a long time anyway. This would mean that xterm hintbar and xterm save/restore will only work on the terminals explicitly recognized as xterm. It would be possible to change the code later so that those capabilities are also detected automatically, like the xterm mouse support. In general, I think that the situation with termcap correctness is getting better over time. MC uses many options that allow users to override broken termcap database. However, many of those options are hacks that make the code very fragile. They also are used in a very inconsistent manner. Say, the "-c" option has a corresponding per-terminal setting in the config file, but the "-a", "-d" and "-x" options don't, although they are as much terminal-specific as "-c". My plan is to apply your patch and remove "-x" support in the same time. If anybody will need "-x", it will be reimplemented as a per-terminal setting. Please let me know if it's fine with you. -- Regards, Pavel Roskin From murban at cs.uni-magdeburg.de Thu Jan 3 00:56:26 2002 From: murban at cs.uni-magdeburg.de (Matthias Urban) Date: Thu, 03 Jan 2002 01:56:26 +0100 Subject: word completion Message-ID: <3C33AC3A.AFB99FB0@cs.uni-magdeburg.de> Hi, the calculation of the dialog metrics is not correct --- a remnant of the nocturnal development ;-) Here is the patch. Bye, Matthias -------------- next part -------------- --- editcmd.c Thu Jan 3 01:37:23 2002 +++ editcmd.c Thu Jan 3 01:34:10 2002 @@ -2519,33 +2519,24 @@ WListbox *compl_list; /* calculate the dialog metrics */ - start_x = edit->curs_col - ((max_len + 4) / 2); - start_y = edit->curs_row + 2; - compl_dlg_h = num_compl + 2; compl_dlg_w = max_len + 4; + start_x = edit->curs_col + edit->start_col - (compl_dlg_w / 2); + start_y = edit->curs_row + EDIT_TEXT_VERTICAL_OFFSET + 1; - if (start_x <= 0) + if (start_x < 0) start_x = 0; - - if (compl_dlg_w >= COLS) + if (compl_dlg_w > COLS) compl_dlg_w = COLS; + if (compl_dlg_h > LINES - 2) + compl_dlg_h = LINES - 2; - if (start_x + compl_dlg_w >= COLS) { - offset = start_x + compl_dlg_w - COLS; + offset = start_x + compl_dlg_w - COLS; + if (offset > 0) start_x -= offset; - if (start_x <= 0) - start_x = 0; - } - - if (start_y + compl_dlg_h >= LINES) { - offset = start_y + compl_dlg_h - LINES; - start_y -= offset; - if (start_y <= 0) - start_y = 1; - if (start_y + compl_dlg_h >= LINES) - compl_dlg_h = LINES - 2; - } + offset = start_y + compl_dlg_h - LINES; + if (offset > 0) + start_y -= (offset + 1); /* create the dialog */ compl_dlg = create_dlg (start_y, start_x, compl_dlg_h, compl_dlg_w, From oskar at osk.mine.nu Thu Jan 3 08:53:05 2002 From: oskar at osk.mine.nu (Oskar Liljeblad) Date: Thu, 3 Jan 2002 09:53:05 +0100 Subject: detection of xterm mouse support In-Reply-To: References: <20011227103944.GA14564@oskar> Message-ID: <20020103085305.GA581@oskar> On Wednesday, January 02, 2002 at 19:02, Pavel Roskin wrote: > Hi, Oskar! Hello Pavel! > Sorry for the late reply. I like your patch, but it has a side effect: > > TERM=ansi mc -x > > on rxvt doesn't enable the mouse. Your patch changes the meaning of "-x" > - now it forces only xterm-style save/restore of the screen and the hints > in the caption, but not the xterm mouse support. > > This would require changes in the documentation and the help. I don't > want to do it at this point, because many translations will have to be > changed. > > I would rather remove the "-x" option completely. It has been broken for > a long time anyway. This would mean that xterm hintbar and xterm > save/restore will only work on the terminals explicitly recognized as > xterm. It would be possible to change the code later so that those > capabilities are also detected automatically, like the xterm mouse > support. Sounds great. I was planning to do the same (e.g. submit patches to fix all those places where hardcoded terminal control sequences, the xterm_flag and TERM compares are used). In other words, I'm happy with this. :) The next thing I'd like to change is the handling of keypad mode - more about that in the next email. Regards, Oskar Liljeblad (oskar at osk.mine.nu) From oskar at osk.mine.nu Thu Jan 3 08:58:48 2002 From: oskar at osk.mine.nu (Oskar Liljeblad) Date: Thu, 3 Jan 2002 09:58:48 +0100 Subject: keypad mode Message-ID: <20020103085848.GA1650@oskar> In key.c the following hack is used to enable/disable keypad mode (reporting of keypad keys with special terminal sequences): /* xterm and linux console only: set keypad to numeric or application mode. Only in application keypad mode it's possible to distinguish the '+' key and the '+' on the keypad ('*' and '-' ditto)*/ void numeric_keypad_mode (void) { if (console_flag || xterm_flag) { fprintf (stdout, "\033>"); fflush (stdout); } } void application_keypad_mode (void) { if (console_flag || xterm_flag) { fprintf (stdout, "\033="); fflush (stdout); } } The correct way would be to use the terminfo capabilities "rmkx" and "smkx" instead of hardcoded strings (and console_flag/ xterm_flag). But there is one problem: How do you get this capability? If ncurses was available the correct function would be "tigetstr". But it seems more complicated with slang. Any ideas? Oskar Liljeblad (oskar at osk.mine.nu) From proski at gnu.org Thu Jan 3 16:42:51 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 3 Jan 2002 11:42:51 -0500 (EST) Subject: mcedit bug In-Reply-To: <3C25F9A1.95BD35D1@cs.uni-magdeburg.de> Message-ID: Hi, Matthias! > I'm sorry but I've just discovered that it was the wrong command :-( > Only "Do something on the tagged files" doesn't work with complex > commands. The problem is located in the following line: > > --- > set %u; CMD=%0{Enter command}; > --- I have committed the fix. Thank you for reporting the problem! > I've never thought so; I know that this is not a commercial project. And > I also know that you are sacrificing your free time when implementing > new features for it. All the more I'm impressed of the MC; there's > nothing assimilable for UNIX-like systems (in fact, even the Norton > Commander never was as powerful as the MC :-). Not quite true. There are very few new features implemented by me. Your thanks should be addressed to Miguel de Icaza and the old MC team who wrote most of the code. They are listed in the AUTHORS file. -- Regards, Pavel Roskin From frantz at sitoverde.com Sun Jan 6 06:47:47 2002 From: frantz at sitoverde.com ( (==FrantZ==)) Date: Sun, 6 Jan 2002 07:47:47 +0100 Subject: Problems with the mouse Message-ID: <20020106074747.6d80c28d.frantz@sitoverde.com> Hello, I use Linux version 2.4.16 compiled with devfs, glib version 1.2.10, gpm version 1.19.3, a PS/2 mouse with scroller (protocol imps2, device /dev/misc/psaux),ncurses version 5.2, glibc version 2.2.4, gcc version 2.95.3, and I compiled mc version 4.5.55 with S-Lang, and with gpm mouse support. When I do an ldd to the mc executable it states that it is linked against libgpm.so, but when I run mc, the mouse does not work as expected (i.e. it still copies and pastes text even if I don't hold the shift key, and menus don't get accessed by mouse). I started to think it is a problem of devfs, but when I run the devfsd daemon in order to have the symlinks of the old device names, the mouse in mc still does not work. How can I get the mouse working right in mc? Thanks. Franco - frantz at sitoverde.com Senza costi telefonici spedisci la tua posta e naviga gratis i nostri siti su http://www.edimedia.com/ From proski at gnu.org Sun Jan 6 07:47:09 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 6 Jan 2002 02:47:09 -0500 (EST) Subject: Problems with the mouse In-Reply-To: <20020106074747.6d80c28d.frantz@sitoverde.com> Message-ID: Hi, Franco! On Sun, 6 Jan 2002 frantz at sitoverde.com wrote: > When I do an ldd to the mc executable it states that it is linked > against libgpm.so, but when I run mc, the mouse does not work as > expected (i.e. it still copies and pastes text even if I don't hold the > shift key, and menus don't get accessed by mouse). Two possible problems: 1) You have gpm from RedHat with a patch that disallows users to access the mouse through libgpm. Recomplile gpm from the sources if that's the case. 2) It may happen that you don't have access to /dev/misc/psaux or to /dev/gpmctl. libgpm support is tricky to enable on modern systems, so it may be dropped in the future versions of MC if a better way of interacting with gpm will be found or developed. > I started to think it is a problem of devfs, but when I run the devfsd > daemon in order to have the symlinks of the old device names, the mouse > in mc still does not work. You are missing two steps between setting up devfs and checking mc: 1) make sure that gpm is running 2) make sure that the mouse cursor is moving when mc is not running. -- Regards, Pavel Roskin From pkozelka at centrum.cz Mon Jan 7 02:26:41 2002 From: pkozelka at centrum.cz (Petr Kozelka) Date: Mon, 7 Jan 2002 03:26:41 +0100 Subject: XML syntax highlighting Message-ID: <000e01c19722$c0966ad0$fa5adaa0@eurotel.cz> Hello, may I offer an extension for ? These two lines should come to file syntax/Syntax: ---------------------------------------------------------------------------- - file ..\*\\.(xml|XML|xsd|xsl|xslt|dtd)$ XML\sdocument (xml\sversion|DOCTYPE\s) include xml.syntax ---------------------------------------------------------------------------- - and the "xml.syntax" file is attached (gzipped) Regards, Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: xml.syntax.gz Type: application/x-gzip Size: 424 bytes Desc: not available URL: From utx at penguin.cz Mon Jan 7 09:21:18 2002 From: utx at penguin.cz (Stanislav Brabec) Date: Mon, 7 Jan 2002 10:21:18 +0100 Subject: terminal clipboard inside mc editor and viewer doesn't save EOLs (included SLang bug) Message-ID: <20020107092118.GA444@utx.vol.cz> GNU Midnight Commander 4.5.99a This bug occurs only with included slang, with slang-1.4.4 it is OK: I like using terminal clipboard between mc editor or viewer and other apps. But with included slang copying from mc doesn't save EOLs, instead it inserts lots of spaces. Example: Using gnome-terminal and Shift-left-mouse, I am able to copy any text from MC view and paste it to any other application. Included slang doesn't save EOLs in text, so clipboard is unusable for multi-line texts. Recompiling mc with slang-1.4.4 completelly resolves the problem. -- Stanislav Brabec http://www.penguin.cz/~utx From kai at cmail.ru Tue Jan 8 08:06:24 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 08 Jan 2002 10:06:24 +0200 Subject: How Duplicate SourceForge Black on White Midnight Commander? References: <3C2B5C8D.1AC7@fast.net> <20011231154742.GE4087@algonet.se> <3C308C13.C5B@fast.net> <87n0zzz65a.fsf@haitech.martin.home> Message-ID: <3C3AA880.1080704@cmail.ru> Hi, Martin! > >mc starts in colormode, if it find the terminal to be color >capable. You can force color mode, but you can't force b/w mode. > mc -b or --nocolor Regards, Andrew. From martin at internet-treff.uni-koeln.de Tue Jan 8 09:58:31 2002 From: martin at internet-treff.uni-koeln.de (Martin Bialasinski) Date: 08 Jan 2002 10:58:31 +0100 Subject: How Duplicate SourceForge Black on White Midnight Commander? In-Reply-To: <3C3AA880.1080704@cmail.ru> References: <3C2B5C8D.1AC7@fast.net> <20011231154742.GE4087@algonet.se> <3C308C13.C5B@fast.net> <87n0zzz65a.fsf@haitech.martin.home> <3C3AA880.1080704@cmail.ru> Message-ID: <878zb9p3js.fsf@haitech.martin.home> "Andrew V. Samoilov" wrote: > >mc starts in colormode, if it find the terminal to be color > >capable. You can force color mode, but you can't force b/w mode. > > > mc -b or --nocolor Oops, my bad. Sorry, Martin From mursito at eng.murdoch.edu.au Fri Jan 11 02:13:20 2002 From: mursito at eng.murdoch.edu.au (Eko Mursito Budi) Date: Fri, 11 Jan 2002 10:13:20 +0800 (WST) Subject: Request feature: secure FTP Message-ID: Dear MC developer I would like to see a "Secure FTP link ..." item in Right or Left menu. If I choose that, I can connect to Open SSH secure ftp server (sftpd). I know such a program for Windows named WinSCP but couldn't find one for Linux except the old fashioned sftp. Many thanks. Eko M. Budi From proski at gnu.org Fri Jan 11 05:27:03 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 11 Jan 2002 00:27:03 -0500 (EST) Subject: Request feature: secure FTP In-Reply-To: Message-ID: Hello, Eko! > I would like to see a "Secure FTP link ..." item in Right or Left menu. I think we have long menus already. I'd rather see one item "connect" which would invoke a dialog asking you for login name (possibly with the domain name), password and connection protocol (ftp, mcfs, FiSH). Currently we have no graphical interface to FiSH, which is bad. > If I choose that, I can connect to Open SSH secure ftp server (sftpd). Actually, FiSH transfers files over ssh. I'm afraid that implementing sftp would require linking mc against libssl, as opposed to FiSH that uses the ssh executable. I don't want to make mc depend on too many libraries, even optionally. I understand that sftp is a separate protocol, but I have't seen any server that would support sftp but not ssh. -- Regards, Pavel Roskin From lists at pervalidus.net Fri Jan 11 05:33:23 2002 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Fri, 11 Jan 2002 03:33:23 -0200 Subject: Request feature: secure FTP Message-ID: <20020111053323.GV136@pervalidus> Eko Mursito Budi wrote: > I know such a program for Windows named WinSCP but couldn't > find one for Linux except the old fashioned sftp. AFAIK at least 2 excellent clients support it: LFTP - http://lftp.yar.ru/ yafc - http://yafc.sourceforge.net/ -- 0 at pervalidus.{net, dyndns.org} From proski at gnu.org Fri Jan 11 05:52:36 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 11 Jan 2002 00:52:36 -0500 (EST) Subject: XML syntax highlighting In-Reply-To: <000e01c19722$c0966ad0$fa5adaa0@eurotel.cz> Message-ID: Hello! > These two lines should come to file syntax/Syntax: > ---------------------------------------------------------------------------- > - > file ..\*\\.(xml|XML|xsd|xsl|xslt|dtd)$ XML\sdocument > (xml\sversion|DOCTYPE\s) > include xml.syntax > ---------------------------------------------------------------------------- I improved this to include all uppercase extensions and to require "?" and "!" before "xml version" and "DOCTYPE" respectively: file ..\*\\.(xml|XML|xsd|XSD|xslt?|XSLT?|dtd|DTD)$ XML\sdocument (\\?xml\sversion|!DOCTYPE\s) include xml.syntax > and the "xml.syntax" file is attached (gzipped) Applied. Thank you! -- Regards, Pavel Roskin From kai at cmail.ru Fri Jan 11 08:47:25 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Fri, 11 Jan 2002 10:47:25 +0200 Subject: [patch] Smbfs: New options --with-configdir and --with-codepagedir Message-ID: <20020111104725.A12180@it.efp.com.ua> Hi! I added two new options for smbfs: --with-configdir=DIR Where the Samba configuration files are (/etc) --with-codepagedir=DIR Where the Samba codepage files are So smb.conf and samba codepages files locations can be defined with configure. Regards, Andrew. Patch applied, any comments are welcome. Index: mc/ChangeLog diff -u mc/ChangeLog:1.401 mc/ChangeLog:1.402 --- mc/ChangeLog:1.401 Fri Jan 11 00:51:32 2002 +++ mc/ChangeLog Fri Jan 11 02:45:11 2002 @@ -1,3 +1,9 @@ +2002-01-11 Andrew V. Samoilov + + * acinclude.m4: New options for smbfs: + --with-configdir=DIR Where the Samba configuration files are (/etc) + --with-codepagedir=DIR Where the Samba codepage files are + 2002-01-11 Pavel Roskin * syntax/xml.syntax: New file - hightlighting for XML. Index: mc/acinclude.m4 diff -u mc/acinclude.m4:1.22 mc/acinclude.m4:1.23 --- mc/acinclude.m4:1.22 Wed Jan 2 12:12:46 2002 +++ mc/acinclude.m4 Fri Jan 11 02:45:11 2002 @@ -113,7 +113,40 @@ ]) AC_SUBST(smbfs) AC_SUBST(SAMBAFILES) - + + if test "x$smbfs" != x ; then + ################################################# + # set Samba configuration directory location + configdir="/etc" + AC_ARG_WITH(configdir, + [ --with-configdir=DIR Where the Samba configuration files are (/etc)], + [ case "$withval" in + yes|no) + # + # Just in case anybody does it + # + AC_MSG_WARN([--with-configdir called without argument - will use default]) + ;; + * ) + configdir="$withval" + ;; + esac] + ) + AC_SUBST(configdir) + + AC_ARG_WITH(codepagedir, + [ --with-codepagedir=DIR Where the Samba codepage files are], + [ case "$withval" in + yes|no) + # + # Just in case anybody does it + # + AC_MSG_WARN([--with-codepagedir called without argument - will use default]) + ;; + esac] + ) + fi + dnl dnl The termnet support dnl Index: mc/vfs/ChangeLog diff -u mc/vfs/ChangeLog:1.364 mc/vfs/ChangeLog:1.365 --- mc/vfs/ChangeLog:1.364 Wed Jan 2 20:26:24 2002 +++ mc/vfs/ChangeLog Fri Jan 11 03:24:17 2002 @@ -1,4 +1,11 @@ -2001-01-02 Pavel Roskin +2002-01-11 Andrew V. Samoilov + + * Makefile.am (AM_CFLAGS): Add -DCONFIGDIR=\""@configdir@"\" + if smbfs support is enabled. + + * smbfs.c (smbfs_init): Use CONFIGDIR for smb.conf. + +2002-01-02 Pavel Roskin * Makefile.am: Add *clean-local targets to take care of the samba directory. Index: mc/vfs/Makefile.am diff -u mc/vfs/Makefile.am:1.17 mc/vfs/Makefile.am:1.18 --- mc/vfs/Makefile.am:1.17 Wed Jan 2 20:26:24 2002 +++ mc/vfs/Makefile.am Fri Jan 11 03:24:17 2002 @@ -1,6 +1,10 @@ SUBDIRS = extfs +if USE_SAMBA_FS +AM_CFLAGS = $(GLIB_CFLAGS) -DCONFIGDIR=\""@configdir@"\" +else AM_CFLAGS = $(GLIB_CFLAGS) +endif BASICFILES = \ cpio.c \ Index: mc/vfs/smbfs.c diff -u mc/vfs/smbfs.c:1.31 mc/vfs/smbfs.c:1.32 --- mc/vfs/smbfs.c:1.31 Mon Nov 5 08:16:17 2001 +++ mc/vfs/smbfs.c Fri Jan 11 03:24:17 2002 @@ -4,7 +4,7 @@ Written by Wayne Roberts - $Id: smbfs.c,v 1.31 2001/11/05 13:16:17 andrew Exp $ + $Id: smbfs.c,v 1.32 2002/01/11 08:24:17 andrew Exp $ This program is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License @@ -250,7 +250,7 @@ static int smbfs_init(vfs *me) { - char *servicesf = "/etc/smb.conf"; + char *servicesf = CONFIGDIR "/smb.conf"; /* DEBUGLEVEL = 4; */ From mursito at eng.murdoch.edu.au Fri Jan 11 09:08:53 2002 From: mursito at eng.murdoch.edu.au (Eko Mursito Budi) Date: Fri, 11 Jan 2002 17:08:53 +0800 (WST) Subject: Request feature: secure FTP In-Reply-To: Message-ID: Hi Pavel. Yeah, your suggestion is better. As an admin, my intention is to disable the unsecure FTP server. Therefore any secure file transfer will do. I hope the new version of MC will come out soon. Thanks for the quick response and ... Happy FiSHing :) Eko On Fri, 11 Jan 2002, Pavel Roskin wrote: > Hello, Eko! > > > I would like to see a "Secure FTP link ..." item in Right or Left menu. > > I think we have long menus already. I'd rather see one item "connect" > which would invoke a dialog asking you for login name (possibly with the > domain name), password and connection protocol (ftp, mcfs, FiSH). > Currently we have no graphical interface to FiSH, which is bad. > > > If I choose that, I can connect to Open SSH secure ftp server (sftpd). > > Actually, FiSH transfers files over ssh. I'm afraid that implementing > sftp would require linking mc against libssl, as opposed to FiSH that uses > the ssh executable. I don't want to make mc depend on too many libraries, > even optionally. > > I understand that sftp is a separate protocol, but I have't seen any > server that would support sftp but not ssh. > > From mursito at eng.murdoch.edu.au Fri Jan 11 09:26:08 2002 From: mursito at eng.murdoch.edu.au (Eko Mursito Budi) Date: Fri, 11 Jan 2002 17:26:08 +0800 (WST) Subject: Request feature: secure FTP In-Reply-To: <20020111053323.GV136@pervalidus> Message-ID: Dear Fr?d?ric Thanks for the pointers. I have checked both of them. However, what I expect is a secure FTP client with Norton Commander like user interface (two side by side local and remote panel), not the one with command line. Regards Eko On Fri, 11 Jan 2002, Fr?d?ric L. W. Meunier wrote: > AFAIK at least 2 excellent clients support it: > > LFTP - http://lftp.yar.ru/ > yafc - http://yafc.sourceforge.net/ > From pkozelka at centrum.cz Mon Jan 14 17:45:05 2002 From: pkozelka at centrum.cz (Petr Kozelka) Date: Mon, 14 Jan 2002 18:45:05 +0100 Subject: compiling CVS sources - errors from autogen.sh Message-ID: <002e01c19d23$3367ee70$a372daa0@eurotel.cz> Hello, I have just installed Mandrake 8.1 and checked out the latest sources of MC from CVS. I wanted to compile the sources, but this is what I got: [pk at ganymed mc]$ ./autogen.sh aclocal: gettext.m4/codeset.m4: 5: duplicated macro `AM_LANGINFO_CODESET' aclocal: gettext.m4/gettext.m4: 41: duplicated macro `AM_WITH_NLS' aclocal: gettext.m4/gettext.m4: 295: duplicated macro `AM_GNU_GETTEXT' aclocal: gettext.m4/glibc21.m4: 6: duplicated macro `jm_GLIBC21' aclocal: gettext.m4/iconv.m4: 5: duplicated macro `AM_ICONV' aclocal: gettext.m4/isc-posix.m4: 12: duplicated macro `AC_ISC_POSIX' aclocal: gettext.m4/lcmessage.m4: 13: duplicated macro `AM_LC_MESSAGES' aclocal: gettext.m4/progtest.m4: 15: duplicated macro `AM_PATH_PROG_WITH_TEST' aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library [pk at ganymed mc]$ What should I do to make it compilable ? I am not familiar with m4. TIA, Petr From mastan at hostel.sm.bmstu.ru Mon Jan 14 19:02:41 2002 From: mastan at hostel.sm.bmstu.ru (Stanislav Mayantsev) Date: Mon, 14 Jan 2002 22:02:41 +0300 Subject: mc ftpfs bug Message-ID: <16848535951.20020114220241@hostel.sm.bmstu.ru> Hello I found a bug in MC's ftpfs: uploading or downloading files containing symbol '[' fails with permission deny error. ___________________________ May the source be with you! MASTAN [mastan at hostel.sm.bmstu.ru] From metaf4 at pseudonym.org Tue Jan 15 04:54:45 2002 From: metaf4 at pseudonym.org (tHE rEAL uSER) Date: Tue, 15 Jan 2002 05:54:45 +0100 Subject: BUGREPORT/PROBLEM Message-ID: <3C43B615.4FC1F589@pseudonym.org> Hi developers ! ================ Thank you for mc - I use it daily ! Sorry, but I probably found a bug. OS: Linux SuSE 7.2; Kernel 2.4.4-4GB $ mc --version The Midnight Commander 4.5.51 with mouse support on xterm and the Linux console. Edition: text mode Virtual File System: tarfs, extfs, ftpfs, mcfs, smbfs, undelfs With builtin Editor Using S-lang library with terminfo database With subshell support: as default With support for background operations Using locale "en_EN at enuro" (from environment variable LANG) OS: Linux SuSE 6.1; Kernel 2.2.XX $ mc --version The Midnight Commander 4.5.25 with mouse support on xterm and the Linux console. Edition: text mode. Virtual File System: tarfs, extfs, ftpfs, mcfs. With builtin Editor Using S-lang library with terminfo database With subshell support: as default With support for background operations * It is repeatable with both versions. DESC: # create file named "foo" echo > /tmp/foo # create dir named "xxx/foo" mkdir -p /tmp/xxx/foo invoke mc: - the /tmp/ dir in the left panel (L), dir "/tmp/xxx/" in the right panel (R) - now copy/move directory from R to L - *** result: file permissions changed to 0755 - NO error message *** - if a file or a dir is in /tmp/xxx/foo permission changed too, but get an error message 1) [L] /tmp I /tmp/xxx [R] -------------------------|--------------------------- foo 644 (FILE) | foo/ 755 (DIR) | <========= COPY/MOVE =========== 2) [L] /tmp I /tmp/xxx [R] -------------------------|--------------------------- foo 755 (FILE) | foo/ 755 (DIR) | The other direction of copying or moving works fine with the correct error message. regards Thomas From kai at cmail.ru Tue Jan 15 08:15:07 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 15 Jan 2002 10:15:07 +0200 Subject: BUGREPORT/PROBLEM References: <3C43B615.4FC1F589@pseudonym.org> Message-ID: <3C43E50B.8000607@cmail.ru> Hi, Thomas! > >Thank you for mc - I use it daily ! Sorry, but I probably found a bug. > >OS: Linux SuSE 7.2; Kernel 2.4.4-4GB >$ mc --version >The Midnight Commander 4.5.51 > . . . > >OS: Linux SuSE 6.1; Kernel 2.2.XX >$ mc --version >The Midnight Commander 4.5.25 > . . . It was indeed a bug in src/file.c. You can use attached patch. Thanks a lot for quality bug report. Regards, Andrew. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file.c.patch URL: From maddog at linuxhall.org Tue Jan 15 23:22:26 2002 From: maddog at linuxhall.org (R.I.P. Deaddog) Date: Wed, 16 Jan 2002 07:22:26 +0800 (HKT) Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: <002e01c19d23$3367ee70$a372daa0@eurotel.cz> Message-ID: On Mon, 14 Jan 2002, Petr Kozelka wrote: > I have just installed Mandrake 8.1 and checked out the latest sources of MC > from CVS. > I wanted to compile the sources, but this is what I got: > > [pk at ganymed mc]$ ./autogen.sh > aclocal: gettext.m4/codeset.m4: 5: duplicated macro `AM_LANGINFO_CODESET' > aclocal: gettext.m4/gettext.m4: 41: duplicated macro `AM_WITH_NLS' [.....snip......] MC is including gettext .m4 files, while there's already a system-wide copy. You can either remove all the m4 files in gettext.m4 directory, or modify autogen.sh so that aclocal don't include gettext.m4 directory. Abel From kloczek at rudy.mif.pg.gda.pl Wed Jan 16 16:04:48 2002 From: kloczek at rudy.mif.pg.gda.pl (=?ISO-8859-2?Q?Tomasz_K=B3oczko?=) Date: Wed, 16 Jan 2002 17:04:48 +0100 (CET) Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: <002e01c19d23$3367ee70$a372daa0@eurotel.cz> Message-ID: On Mon, 14 Jan 2002, Petr Kozelka wrote: > Hello, > > I have just installed Mandrake 8.1 and checked out the latest sources of MC > from CVS. > I wanted to compile the sources, but this is what I got: > > [pk at ganymed mc]$ ./autogen.sh > aclocal: gettext.m4/codeset.m4: 5: duplicated macro `AM_LANGINFO_CODESET' > aclocal: gettext.m4/gettext.m4: 41: duplicated macro `AM_WITH_NLS' > aclocal: gettext.m4/gettext.m4: 295: duplicated macro `AM_GNU_GETTEXT' > aclocal: gettext.m4/glibc21.m4: 6: duplicated macro `jm_GLIBC21' > aclocal: gettext.m4/iconv.m4: 5: duplicated macro `AM_ICONV' > aclocal: gettext.m4/isc-posix.m4: 12: duplicated macro `AC_ISC_POSIX' > aclocal: gettext.m4/lcmessage.m4: 13: duplicated macro `AM_LC_MESSAGES' > aclocal: gettext.m4/progtest.m4: 15: duplicated macro > `AM_PATH_PROG_WITH_TEST' > aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library > aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library > [pk at ganymed mc]$ Replace AM_GNOME_GETTEXT macro by AM_GNU_GETTEXT and run again autogen.sh. Using AM_GNOME_GETTEXT macro in mc and all GNOME projects are bogus and seems brings *only* problems like above. kloczek -- ----------------------------------------------------------- *Ludzie nie maj? problem?w, tylko sobie sami je stwarzaj?* ----------------------------------------------------------- Tomasz K?oczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek at rudy.mif.pg.gda.pl* From pkozelka at centrum.cz Thu Jan 17 14:47:57 2002 From: pkozelka at centrum.cz (Petr Kozelka) Date: Thu, 17 Jan 2002 15:47:57 +0100 Subject: compiling CVS sources - errors from autogen.sh References: Message-ID: <006a01c19f65$f3d0b860$a372daa0@eurotel.cz> > MC is including gettext .m4 files, while there's already a system-wide > copy. You can either remove all the m4 files in gettext.m4 directory, > or modify autogen.sh so that aclocal don't include gettext.m4 directory. 1.) removing all files from gettext.m4 doesn't seem to help at all, because the files are re-created there. 2.) when I remove the line $ACLOCAL -I gettext.m4 $ACLOCAL_FLAGS || \ most of the messages disappear, but this one is still reported by autogen: aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library where do I find this macro ? Thanks Petr From pkozelka at centrum.cz Thu Jan 17 14:56:08 2002 From: pkozelka at centrum.cz (Petr Kozelka) Date: Thu, 17 Jan 2002 15:56:08 +0100 Subject: compiling CVS sources - errors from autogen.sh References: Message-ID: <007301c19f67$1884f8a0$a372daa0@eurotel.cz> Hello Tomasz, > Replace AM_GNOME_GETTEXT macro by AM_GNU_GETTEXT and run again autogen.sh. > Using AM_GNOME_GETTEXT macro in mc and all GNOME projects are bogus and > seems brings *only* problems like above. where should I replace it ? (it does not occur in the autoconf.sh script) Thanks, Petr From humilleitor at eresmas.com Thu Jan 17 08:43:03 2002 From: humilleitor at eresmas.com (Zeus) Date: Thu, 17 Jan 2002 09:43:03 +0100 Subject: MISTAKE in /etc/mc/mc.menu file!! Message-ID: <20020117094303.A269@Moira.Moira> Hello: First, sorry if I disturb you. I don't know if these are the e-mails I should address to, but I've found them in one of the documents of the mc-4.5.55 release and believe they'll be fine. I think I've discovered a mistake in the file /etc/mc/mc.menu that was as well in former releases, for in every version I've installed I've had to make the same correction: Both in lines 203 & 211 of the above mentioned file, the regular expression fed to egrep command needs putting a backslash before the "|" symbols (vertical slash?) in order for them to not lose their special meaning in the expression. I've obtained this information from the egrep manual. If not so, the command never finds no ".gz", ".z" or ".Z" extension in the input files and don't pass the "-d" option. So, when trying to decompress them with the "y" option in the User Menu, makes nothing and returns error. I believe you should fix this. Or somebody else. If you are not the man in charge, please resend this message to whom who is. Thanks. From kai at cmail.ru Fri Jan 18 07:42:10 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Fri, 18 Jan 2002 09:42:10 +0200 Subject: MISTAKE in /etc/mc/mc.menu file!! References: <20020117094303.A269@Moira.Moira> Message-ID: <3C47D1D2.4000204@cmail.ru> Hello, Zeus! . . . >Both in lines 203 & 211 of the above mentioned file, the regular >expression fed to egrep command needs putting a backslash before the >"|" symbols (vertical slash?) in order for them to not lose their >special meaning in the expression. I've obtained this information >from the egrep manual. > There are no needs to put '\' before .z Anyway these rules were rewritten without egrep and commited to CVS. > If not so, the command never finds no ".gz", ".z" or ".Z" >extension in the input files and don't pass the "-d" option. So, when >trying to decompress them with the "y" option in the User Menu, makes >nothing and returns error. > Well, but as far as I remember this worked fine for me. What OS/shell do you use? Best regards, Andrew. From murban at cs.uni-magdeburg.de Fri Jan 18 16:26:42 2002 From: murban at cs.uni-magdeburg.de (Matthias Urban) Date: Fri, 18 Jan 2002 17:26:42 +0100 Subject: mcedit bug Message-ID: <3C484CC2.16AD7321@cs.uni-magdeburg.de> Hi Steef Boerrigter, > I have to take back what I just wrote about the user menu after reading > Pavels response and further investigation. > > Good work! It has indeed irritated me that inserting of "ls -l" output > > did not produce what I expected. Thank you for the "Good work!" :-))). The bug was there but the bug report wasn't correct at all :-(. I've corrected it and Pavel already fixed it. Did you know that I've tried to implement the "word completion" feature for the editor last year? (Yes!!! ;-))) Because I vacationed for nearly a half month I was very curious to read the reactions to the patches I've sent in (Dec. 2001 and Jan. 2002). But up to now still nobody answered. Seems to take more time to validate it than I've expected :-(. But in any case I rather want to know how other users of the MC think about it. What do YOU think about the implementation? Would YOU use this feature? Best regards, Matthias PS: Do you remember the problem of converting lower case characters to upper case? Ok, it's long ago :-)) but NOW I know the best solution: shell$ tr '[:lower:]' '[:upper:]' It is sooo simple, isn't it? ;-) From pavel at suse.cz Sat Jan 12 23:35:03 2002 From: pavel at suse.cz (Pavel Machek) Date: Sat, 12 Jan 2002 23:35:03 +0000 Subject: Request feature: secure FTP In-Reply-To: ; from proski@gnu.org on Fri, Jan 11, 2002 at 12:27:03AM -0500 References: Message-ID: <20020112233503.G511@toy.ucw.cz> Hi! > > I would like to see a "Secure FTP link ..." item in Right or Left menu. > > I think we have long menus already. I'd rather see one item "connect" > which would invoke a dialog asking you for login name (possibly with the > domain name), password and connection protocol (ftp, mcfs, FiSH). > Currently we have no graphical interface to FiSH, which is bad. > > > If I choose that, I can connect to Open SSH secure ftp server (sftpd). > > Actually, FiSH transfers files over ssh. I'm afraid that implementing > sftp would require linking mc against libssl, as opposed to FiSH that uses > the ssh executable. I don't want to make mc depend on too many libraries, > even optionally. I would not depend on FiSH. It is hack, and under boundary conditions (remote dd killed by out-of-memory) bad stuff might happen. Supporting sftp would be way nicer. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From proski at gnu.org Sun Jan 20 17:55:27 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 20 Jan 2002 12:55:27 -0500 (EST) Subject: Request feature: secure FTP In-Reply-To: <20020112233503.G511@toy.ucw.cz> Message-ID: Hi, Pavel! > > Actually, FiSH transfers files over ssh. I'm afraid that implementing > > sftp would require linking mc against libssl, as opposed to FiSH that uses > > the ssh executable. I don't want to make mc depend on too many libraries, > > even optionally. > > I would not depend on FiSH. It is hack, and under boundary conditions (remote > dd killed by out-of-memory) bad stuff might happen. Supporting sftp would be > way nicer. I see. I never thought that dd can be killed by out-of-memory. Unfortunately, sftp is disabled in most ssh installations. Maybe when mc starts supporting sftp, it will be more often enabled, but it will take time. scp, on the other hand, doesn't provide directory listing. Maybe we could use scp transfers in FiSH? -- Regards, Pavel Roskin From proski at gnu.org Sun Jan 20 19:51:47 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 20 Jan 2002 14:51:47 -0500 (EST) Subject: Hiding size of "..", improvements for "bsize" Message-ID: Hello! I remember a discussion about mc loading the directory two levels above the current directory on VFS just to find the size of ".." As the first step towards fixing this problem, the size of ".." will no be displayed even in the full listing. While at this, I also changed the brief mode ("bsize" in the "User defined" listing) so that it shows "SUB-DIR" for symlinks to directories, not just for the directories. Other symlinks will be shown as "SYMLINK". =================================== --- ChangeLog +++ ChangeLog @@ -1 +1,10 @@ +2002-01-20 Pavel Roskin + + * screen.c (string_file_size): Don't display size of ".." - it + may take too much time to calculate it on VFS. Show "UP--DIR" + instead. + (string_file_size_brief): Remove ".." handling - it's now done + in string_file_size(). Show "SUB-DIR" for links to directories, + "SYMLINK" for other links. + 2002-01-17 Pavel Roskin --- screen.c +++ screen.c @@ -172,6 +172,12 @@ string_file_size (file_entry *fe, int le { static char buffer [BUF_TINY]; + /* Don't ever show size of ".." since we don't calculate it */ + if (!strcmp (fe->fname, "..")) { + strcpy (buffer, N_("UP--DIR")); + return buffer; + } + #ifdef HAVE_ST_RDEV if (S_ISBLK (fe->buf.st_mode) || S_ISCHR (fe->buf.st_mode)) g_snprintf (buffer, sizeof (buffer), "%3d,%3d", @@ -191,8 +197,13 @@ string_file_size_brief (file_entry *fe, { static char buffer [BUF_TINY]; - if (S_ISDIR (fe->buf.st_mode)){ - strcpy (buffer, _(strcmp (fe->fname, "..") ? N_("SUB-DIR") : N_("UP--DIR"))); + if (S_ISLNK (fe->buf.st_mode) && !fe->f.link_to_dir) { + strcpy (buffer, N_("SYMLINK")); + return buffer; + } + + if ((S_ISDIR (fe->buf.st_mode) || fe->f.link_to_dir) && strcmp (fe->fname, "..")) { + strcpy (buffer, N_("SUB-DIR")); return buffer; } =================================== -- Regards, Pavel Roskin From proski at gnu.org Sun Jan 20 20:05:12 2002 From: proski at gnu.org (Pavel Roskin) Date: Sun, 20 Jan 2002 15:05:12 -0500 (EST) Subject: Speeding up VFS - no more mc_stat("..") Message-ID: Hello! That's the second part of the patch that speeds up VFS. If there is no ".." in the directory list, then a fake ".." is added. However, mc will no longer go up the hierarchy to find the size of the ".." directory. So, it you have an account of a system foo and your home directory is bar, then going to /#sh:foo/home/bar/subdir won't cause mc to get the listing of all users under /home. ============================ --- ChangeLog +++ ChangeLog @@ -2,2 +2,5 @@ + * dir.c (add_dotdot_to_list): Don't use costly stat() - just put + realistic (i.e. bogus) data to the list. + * screen.c (string_file_size): Don't display size of ".." - it --- dir.c +++ dir.c @@ -342,10 +342,6 @@ clean_dir (dir_list *list, int count) static int add_dotdot_to_list (dir_list *list, int index) { - char buffer [MC_MAXPATHLEN + MC_MAXPATHLEN]; - char *p; - int i = 0; - /* Need to grow the *list? */ if (index == list->size) { list->list = g_realloc (list->list, sizeof (file_entry) * @@ -355,40 +351,14 @@ add_dotdot_to_list (dir_list *list, int list->size += RESIZE_STEPS; } + memset (&(list->list) [index], 0, sizeof(file_entry)); (list->list) [index].fnamelen = 2; (list->list) [index].fname = g_strdup (".."); (list->list) [index].f.link_to_dir = 0; (list->list) [index].f.stalled_link = 0; (list->list) [index].f.dir_size_computed = 0; - - /* FIXME: We need to get the panel definition! to use file_mark */ (list->list) [index].f.marked = 0; - mc_get_current_wd (buffer, sizeof (buffer) - 1 ); - if (buffer [strlen (buffer) - 1] == PATH_SEP) - buffer [strlen (buffer) - 1] = 0; - for (;;) { - strcat (buffer, PATH_SEP_STR ".."); - p = vfs_canon (buffer); - if (mc_stat (p, &((list->list) [index].buf)) != -1){ - g_free (p); - break; - } - i = 1; - if (!strcmp (p, PATH_SEP_STR)){ - g_free (p); - return 1; - } - strcpy (buffer, p); - g_free (p); - } - -/* Commented out to preserve a usable '..'. What's the purpose of this - * three lines? (Norbert) */ -#if 0 - if (i) { /* So there is bogus information on the .. directory's stat */ - (list->list) [index].buf.st_mode &= ~0444; - } -#endif + (list->list) [index].buf.st_mode = 040755; return 1; } ============================ -- Regards, Pavel Roskin From pavel at suse.cz Sun Jan 20 19:38:35 2002 From: pavel at suse.cz (Pavel Machek) Date: Sun, 20 Jan 2002 20:38:35 +0100 Subject: Request feature: secure FTP In-Reply-To: References: <20020112233503.G511@toy.ucw.cz> Message-ID: <20020120193835.GF336@elf.ucw.cz> Hi! > > > Actually, FiSH transfers files over ssh. I'm afraid that implementing > > > sftp would require linking mc against libssl, as opposed to FiSH that uses > > > the ssh executable. I don't want to make mc depend on too many libraries, > > > even optionally. > > > > I would not depend on FiSH. It is hack, and under boundary conditions (remote > > dd killed by out-of-memory) bad stuff might happen. Supporting sftp would be > > way nicer. > > I see. I never thought that dd can be killed by out-of-memory. If kernel decides its OOM, it can kill just about anything, anytime. > Unfortunately, sftp is disabled in most ssh installations. Maybe when mc > starts supporting sftp, it will be more often enabled, but it will take > time. > > scp, on the other hand, doesn't provide directory listing. Maybe we could > use scp transfers in FiSH? That.. should be possible, but we'd have to eat one connection per file. Pretty slow. Pavel -- (about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa From proski at gnu.org Mon Jan 21 07:10:26 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 02:10:26 -0500 (EST) Subject: mc ftpfs bug In-Reply-To: <16848535951.20020114220241@hostel.sm.bmstu.ru> Message-ID: Hi, Stanislav! > I found a bug in MC's ftpfs: uploading or downloading files containing > symbol '[' fails with permission deny error. Next time please specify the version of MC. Assuming that all versions have the same bugs is arrogant and discorages maintainers from improving the software. I tried and could not reproduce this problem on the CVS version of MC and wu-ftpd-2.6.1-20 from RedHat 7.2 as FTP server. Use the "--ftplog" option to mc to find out what's going on in your case. -- Regards, Pavel Roskin From proski at gnu.org Mon Jan 21 07:20:41 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 02:20:41 -0500 (EST) Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: <002e01c19d23$3367ee70$a372daa0@eurotel.cz> Message-ID: Hi, Petr! > I have just installed Mandrake 8.1 and checked out the latest sources of MC > from CVS. What versions of autoconf, automake and gettext do you have? Are they all installed in /usr ? > I wanted to compile the sources, but this is what I got: If you just want to compile the sources, then take the latest snapshot from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ But the problem with autogen.sh should be fixed anyway. > [pk at ganymed mc]$ ./autogen.sh > aclocal: gettext.m4/codeset.m4: 5: duplicated macro `AM_LANGINFO_CODESET' The current autogen.sh tries to avoid this problem by running aclocal with local gettext macros and then without them. Strange that it doesn't work. Could you please run autogen.sh in the debuggin mode and post the output to the list? I mean running this: bash -x autohen.sh > aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library You should install glib-devel package. > What should I do to make it compilable ? I am not familiar with m4. These are not m4 problems. The problems are with aclocal, which is not flexible enough to ignore duplicate macros. -- Regards, Pavel Roskin From proski at gnu.org Mon Jan 21 07:24:59 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 02:24:59 -0500 (EST) Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: Message-ID: Hi, Abel! > MC is including gettext .m4 files, while there's already a system-wide > copy. You can either remove all the m4 files in gettext.m4 directory, > or modify autogen.sh so that aclocal don't include gettext.m4 directory. That's what the current aclocal is doing - it is run with gettext.m4 and then without. Actually, the problem may be simply in missing glib.m4 during the _second_ run. I'm afraid that I'll have to add some testing for aclocal to skip the first run if gettext macros are available, and thus suppress confusing messages. -- Regards, Pavel Roskin From proski at gnu.org Mon Jan 21 07:26:51 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 02:26:51 -0500 (EST) Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: Message-ID: Hi, Tomasz! > Replace AM_GNOME_GETTEXT macro by AM_GNU_GETTEXT and run again autogen.sh. > Using AM_GNOME_GETTEXT macro in mc and all GNOME projects are bogus and > seems brings *only* problems like above. It wasn't said in the body of the message, but it stands in the subject - Petr is using CVS sources. There is no GNOME code in the current CVS sources, and of course AM_GNU_GETTEXT is gone long ago. -- Regards, Pavel Roskin From proski at gnu.org Mon Jan 21 07:42:07 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 02:42:07 -0500 (EST) Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: <006a01c19f65$f3d0b860$a372daa0@eurotel.cz> Message-ID: Hi, Petr! > most of the messages disappear, but this one is still reported by autogen: > aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library > > where do I find this macro ? Sorry, I should have read this message before replying to your original message. I did a great job, no need to run autogen.sh in the debugging mode. Just install the "glib-devel" package. I'm committing the patch to autogen.sh that suppresses copying the gettext macro files if they are already avalable to aclocal. Thank you! -- Regards, Pavel Roskin From proski at gnu.org Mon Jan 21 07:57:37 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 02:57:37 -0500 (EST) Subject: terminal clipboard inside mc editor and viewer doesn't save EOLs (included SLang bug) In-Reply-To: <20020107092118.GA444@utx.vol.cz> Message-ID: Hi, Stanislav! > But with included slang copying from mc doesn't save EOLs, instead it > inserts lots of spaces. Thank you for this observation! I don't think that the included slang library should be updated. It is known to be portable. Besides, it's quite small and in the same time handy if you don't have slang installed. Unless you have a specific fix, I'm not going to fix it. But it may be worth mentioning in the documentation. Also the rpm specfile should be changed to use the external slang. The bugs with the external slang have been fixed long ago. -- Regards, Pavel Roskin From proski at gnu.org Mon Jan 21 08:20:20 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 03:20:20 -0500 (EST) Subject: mcedit bug In-Reply-To: <3C484CC2.16AD7321@cs.uni-magdeburg.de> Message-ID: Hi, Matthias! > Did you know that I've tried to implement the "word completion" feature > for the editor last year? (Yes!!! ;-))) Because I vacationed for nearly > a half month I was very curious to read the reactions to the patches > I've sent in (Dec. 2001 and Jan. 2002). But up to now still nobody > answered. Seems to take more time to validate it than I've expected :-(. > But in any case I rather want to know how other users of the MC think > about it. What do YOU think about the implementation? Would YOU use this > feature? Sorry that I didn't replied earlier. Unfortunately I don't have much free time these days (it's 3 am now by the way). I'm also disappointed that there was no reaction. I don't feel good about adding a feature that nobody needs, especially because I don't recall seeing anything like that in other editors. The internal editor is designed to be a simple tool for system administrators. It is not meant to be an ultimate editor with abundant features. The implementation looks good, but I didn't try to compile it yet. I'll try to do in in the next days. Maybe we'll have some comments by then. -- Regards, Pavel Roskin From pkozelka at centrum.cz Mon Jan 21 12:22:11 2002 From: pkozelka at centrum.cz (Petr Kozelka) Date: Mon, 21 Jan 2002 13:22:11 +0100 Subject: compiling CVS sources - errors from autogen.sh References: Message-ID: <001701c1a276$40a35090$a372daa0@eurotel.cz> Hello Pavel, I am sorry but the error message: "aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library" keeps appearing and breaking the code generation. > Just install the "glib-devel" package. this is what I have: [pk at ganymed mc]$ rpm -q -a | grep glib glibc-devel-2.2.4-6mdk libglib1.2-1.2.10-3mdk glibc-2.2.4-6mdk is that what you mean ? Fyi, the fresh installation of Mandrake 8.1, where I do my experiments, uses: Autoconf version 2.13 aclocal (GNU automake) 1.4-p5 automake (GNU automake) 1.4-p5 gettext (GNU gettext) 0.10.39 I have also checked that cvs loaded the revision 1.28 of autogen.sh file (where you made the changes). And for sure, I added the output of `bash -x autohen.sh` to the end of this message. Thanks Petr ________________________________ [pk at ganymed mc]$ bash -x ./autogen.sh + : autoconf + : autoheader + : automake + : aclocal + : gettextize ++ dirname ./autogen.sh + srcdir=. + test -z . + cd . + rm -rf autom4te.cache vfs/samba/autom4te.cache ++ gettextize --version ++ sed -n '1s/^.* //p' + gettext_ver=0.10.39 + rm -rf intl + gettextize --copy --force + rm -f po/ChangeLog + mv po/ChangeLog~ po/ChangeLog + test '!' -d config ++ aclocal --print-ac-dir + test -f /usr/share/aclocal/gettext.m4 + aclocal aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library + exit 1 + exit 1 From oskar at osk.mine.nu Mon Jan 21 12:33:56 2002 From: oskar at osk.mine.nu (Oskar Liljeblad) Date: Mon, 21 Jan 2002 13:33:56 +0100 Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: <001701c1a276$40a35090$a372daa0@eurotel.cz> References: <001701c1a276$40a35090$a372daa0@eurotel.cz> Message-ID: <20020121123356.GA14773@oskar> On Monday, January 21, 2002 at 13:11, Petr Kozelka wrote: > Hello Pavel, > > I am sorry but the error message: "aclocal: configure.in: 79: > macro `AM_PATH_GLIB' not found in library" keeps appearing and > breaking the code generation. > > > Just install the "glib-devel" package. > this is what I have: > > [pk at ganymed mc]$ rpm -q -a | grep glib > glibc-devel-2.2.4-6mdk > libglib1.2-1.2.10-3mdk > glibc-2.2.4-6mdk You need something like libglib1.2-devel-1.2.10. glibc is GNU libc, glib is something different. Oskar Liljeblad (oskar at osk.mine.nu) From nerijus at users.sourceforge.net Mon Jan 21 12:39:51 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 21 Jan 2002 14:39:51 +0200 (EET) Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: <001701c1a276$40a35090$a372daa0@eurotel.cz> References: <001701c1a276$40a35090$a372daa0@eurotel.cz> Message-ID: On Mon, 21 Jan 2002 13:22:11 +0100 Petr Kozelka wrote: PK> I am sorry but the error message: "aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library" keeps appearing and PK> breaking the code generation. PK> PK> > Just install the "glib-devel" package. PK> this is what I have: PK> PK> [pk at ganymed mc]$ rpm -q -a | grep glib PK> glibc-devel-2.2.4-6mdk PK> libglib1.2-1.2.10-3mdk PK> glibc-2.2.4-6mdk PK> PK> is that what you mean ? You still don't have glib-devel, only glib (libglib1). Regards, Nerijus From pkozelka at centrum.cz Mon Jan 21 13:53:14 2002 From: pkozelka at centrum.cz (Petr Kozelka) Date: Mon, 21 Jan 2002 14:53:14 +0100 Subject: compiling CVS sources - errors from autogen.sh References: <001701c1a276$40a35090$a372daa0@eurotel.cz> <20020121123356.GA14773@oskar> Message-ID: <004701c1a282$f9105590$a372daa0@eurotel.cz> > You need something like libglib1.2-devel-1.2.10. glibc is GNU libc, > glib is something different. ok., so I finally installed it (including autoconf-2.52) and now the story continues: I successfuly executed ./autogen.sh, then I wanted to ./configure, but it stopped with an error message - here is several last displayed lines: _________ ........ checking for - option to file command... yes checking for -L option to file command... yes checking for subshell support... yes checking for SLang_init_tty in -lslang... no configure: using internal editor checking for ext2fs_close in -lext2fs... no configure: using SLang screen manager/terminfo checking for pam_start in -lpam... no configure: creating ./config.status config.status: creating Makefile config.status: error: cannot find input file: Makefile.in [pk at ganymed mc]$ _________ What's wrong now ? Thanks Petr From proski at gnu.org Mon Jan 21 15:52:22 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 10:52:22 -0500 (EST) Subject: compiling CVS sources - errors from autogen.sh In-Reply-To: <001701c1a276$40a35090$a372daa0@eurotel.cz> Message-ID: Hi, Petr! > I am sorry but the error message: "aclocal: configure.in: 79: macro `AM_PATH_GLIB' not found in library" keeps appearing and > breaking the code generation. > > > Just install the "glib-devel" package. > this is what I have: > > [pk at ganymed mc]$ rpm -q -a | grep glib > glibc-devel-2.2.4-6mdk > libglib1.2-1.2.10-3mdk > glibc-2.2.4-6mdk You need libglib1.2-devel-1.2.10-3mdk > Fyi, the fresh installation of Mandrake 8.1, where I do my experiments, uses: > Autoconf version 2.13 > aclocal (GNU automake) 1.4-p5 > automake (GNU automake) 1.4-p5 > gettext (GNU gettext) 0.10.39 CVS MC requires Autoconf 2.52 and Automake 1.5. Gettext is fine. -- Regards, Pavel Roskin From murban at mail.CS.Uni-Magdeburg.De Mon Jan 21 17:33:36 2002 From: murban at mail.CS.Uni-Magdeburg.De (Matthias Urban) Date: Mon, 21 Jan 2002 18:33:36 +0100 Subject: mcedit bug Message-ID: <3C4C50F0.51847460@cs.uni-magdeburg.de> Hi, Pavel! > I'm also disappointed that there was no reaction. I don't feel good about > adding a feature that nobody needs, especially because I don't recall > seeing anything like that in other editors. Indeed, the only editor I know supporting a similar feature is the emacs. > The internal editor is designed to be a simple tool for system > administrators. It is not meant to be an ultimate editor with abundant > features. Yes, and I think that this is the big advantage of the editor. The emacs and so on are completely overloaded with features that nobody needs. I really don't know whether the "word completion" feature is alike. I can need it and I use it for writing C++ programs (with long constants and class names :-(), but in fact I don't use it constantly. It's sometimes a help, but on the other it also makes no trouble when it's not used. I don't know. Greetings, Matthias From proski at gnu.org Mon Jan 21 17:57:21 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 21 Jan 2002 12:57:21 -0500 (EST) Subject: mcedit bug In-Reply-To: <3C4C50F0.51847460@cs.uni-magdeburg.de> Message-ID: Hi, Matthias! > Yes, and I think that this is the big advantage of the editor. The emacs > and so on are completely overloaded with features that nobody needs. I > really don't know whether the "word completion" feature is alike. I can > need it and I use it for writing C++ programs (with long constants and > class names :-(), but in fact I don't use it constantly. It's sometimes > a help, but on the other it also makes no trouble when it's not used. I > don't know. Ok, I checked the patch and it looks very good - both the implementation (with many comments) and the convenient user interface. I have just committed it to CVS. Thank you for your contribution! I guess that somebody will request case-insensitive completion soon :-) -- Regards, Pavel Roskin From lists at pervalidus.net Tue Jan 22 03:01:21 2002 From: lists at pervalidus.net (=?ISO-8859-1?Q?Fr=E9d=E9ric?= L. W. Meunier) Date: Tue, 22 Jan 2002 03:01:21 UT Subject: CVS: autoheader: error: AC_CONFIG_HEADERS not found in configure.in Message-ID: <20020122030121.48EF339406E@fastmail.fm> This is what I get running ./autogen.sh with current CVS. I'm using Autoconf 2.52 and Automake 1.5, the same versions that worked 28 October, last time I compiled. -- 0 at pervalidus.{net, dyndns.org} From pawel at sakowski.eu.org Tue Jan 22 00:42:00 2002 From: pawel at sakowski.eu.org (=?iso-8859-2?Q?Pawe=B3?= Sakowski) Date: 22 Jan 2002 01:42:00 +0100 Subject: SEGV on xterm resizing Message-ID: <1011660120.22566.5.camel@saq> When I resize my xterm (or gnome-terminal) running mc and resize it to a very small size (like 1x1), MC 4.5.55 dies: #0 0x002435f9 in memset () from /lib/libc.so.6 #1 0xbffffbb4 in ?? () #2 0x08050e2f in format_file (dest=0xbfffe610 ' ' ..., panel=0x8106318, file_index=0, width=-1, attr=5, isstatus=1) at screen.c:547 #3 0x080511e1 in repaint_file (panel=0x20202020, file_index=538976288, mv=538976288, attr=538976288, isstatus=538976288) at screen.c:618 #4 0x20202020 in ?? () Cannot access memory at address 0x20202020 -- +--------------------------------------------------------------------+ | Never trust a man who can count : Pawe? Sakowski | | up to 1023 on his fingers : | +--------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: not available URL: From jakarppi at mail.student.oulu.fi Tue Jan 22 10:26:07 2002 From: jakarppi at mail.student.oulu.fi (Jari Karppinen) Date: Tue, 22 Jan 2002 12:26:07 +0200 Subject: mc 4.5.55 has a bug with zip support Message-ID: Hi, I while ago I compiled & installed mc version 4.5.55 on Redhat 7.2 using this source package: http://rhcontrib.bero.org/RPMS/SRPMS/mc-4.5.55-1.src.rpm I have a simple shell script that I use to wgets stuff from certain webpages (mainly lecture notes, but that's not important). Now 'wget -m -np -nH' produces a directory named %7E, where the %7E is obviously a replacement for the ~ character. I used zip to compress all those directories, and later tried to browse the contents of that zip file with mc. It displays those directories as 0.000000E+00 which indicates that mc probably mistakes the %7E's for a format string. Obviously unpacking (i.e. copying from the zip) doesn't work, too. Here are the versions of zip and unzip: zip-2.3-10 unzip-5.42-1 Regards, Jari Karppinen From dmierzej at elka.pw.edu.pl Tue Jan 22 16:52:46 2002 From: dmierzej at elka.pw.edu.pl (Dominik Mierzejewski) Date: Tue, 22 Jan 2002 17:52:46 +0100 Subject: mc 4.5.55 has a bug with zip support In-Reply-To: References: Message-ID: <20020122165246.GB1039@wonko.esi.org.pl> On Tuesday, 22 January 2002, Jari Karppinen wrote: > Hi, > > I while ago I compiled & installed mc version 4.5.55 on Redhat 7.2 using > this source package: > > http://rhcontrib.bero.org/RPMS/SRPMS/mc-4.5.55-1.src.rpm I prepared it from an older RH package by replacing the source tarball and updating RH's patches. > I have a simple shell script that I use to wgets stuff from certain > webpages (mainly lecture notes, but that's not important). Now 'wget -m > -np -nH' produces a directory named %7E, where the %7E is > obviously a replacement for the ~ character. > > I used zip to compress all those directories, and later tried to browse > the contents of that zip file with mc. It displays those directories as > 0.000000E+00 which indicates that mc probably mistakes the %7E's > for a format string. Obviously unpacking (i.e. copying from the zip) > doesn't work, too. > > Here are the versions of zip and unzip: > zip-2.3-10 > unzip-5.42-1 Well, can you unzip that file manually (i.e. not using mc, but only unzip itself)? -- "The Universe doesn't give you any points for doing things that are easy." -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows" Dominik 'Rathann' Mierzejewski From proski at gnu.org Tue Jan 22 22:04:07 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 22 Jan 2002 17:04:07 -0500 (EST) Subject: mc 4.5.55 has a bug with zip support In-Reply-To: Message-ID: Hello, Jari! > I while ago I compiled & installed mc version 4.5.55 on Redhat 7.2 using > this source package: > > http://rhcontrib.bero.org/RPMS/SRPMS/mc-4.5.55-1.src.rpm Thank for the URL. I'll review the patches in that package. Most are related to gmc (now removed from the sources), but some are for the text edition. > I have a simple shell script that I use to wgets stuff from certain > webpages (mainly lecture notes, but that's not important). Now 'wget -m > -np -nH' produces a directory named %7E, where the %7E is > obviously a replacement for the ~ character. > > I used zip to compress all those directories, and later tried to browse > the contents of that zip file with mc. It displays those directories as > 0.000000E+00 which indicates that mc probably mistakes the %7E's > for a format string. Obviously unpacking (i.e. copying from the zip) > doesn't work, too. I could reproduce the problem. The problem in the uzip script. Debugging shows that an unsafe printf is guilty. I'm applying the following patch right now. ============================ --- ChangeLog +++ ChangeLog @@ -1 +1,6 @@ +2002-01-22 Pavel Roskin + + * extfs/uzip: Fix unsafe printf. + Reported by Jari Karppinen + 2002-01-21 Pavel Roskin --- extfs/uzip +++ extfs/uzip @@ -285,7 +285,8 @@ if ($platform ne 'unx') { $perms = ($filename =~ /\/$/ ? 'drwxr-xr-x' : '-rw-r--r--'); } - printf "%-10s 1 %-8d %-8d %8d $mon $day $year $hours:$mins $filename", $perms, $<, $(, $realsize; + printf "%-10s 1 %-8d %-8d %8d %s %s %s %s:%s %s", $perms, $<, + $(, $realsize, $mon, $day, $year, $hours, $mins, $filename; if ($platform eq 'unx' && $perms =~ /^l/) { my $linkdest = &get_link_destination($filename); print " -> $linkdest"; ============================ Copy is sent to Oskar Liljeblad , author of uzip. Jari, thank you for your bugreport! -- Regards, Pavel Roskin From oskar at osk.mine.nu Tue Jan 22 22:28:01 2002 From: oskar at osk.mine.nu (Oskar Liljeblad) Date: Tue, 22 Jan 2002 23:28:01 +0100 Subject: mc 4.5.55 has a bug with zip support In-Reply-To: References: Message-ID: <20020122222801.GA4842@oskar> On Tuesday, January 22, 2002 at 17:07, Pavel Roskin wrote: > > > I have a simple shell script that I use to wgets stuff from certain > > webpages (mainly lecture notes, but that's not important). Now 'wget -m > > -np -nH' produces a directory named %7E, where the %7E is > > obviously a replacement for the ~ character. > > > > I used zip to compress all those directories, and later tried to browse > > the contents of that zip file with mc. It displays those directories as > > 0.000000E+00 which indicates that mc probably mistakes the %7E's > > for a format string. Obviously unpacking (i.e. copying from the zip) > > doesn't work, too. > > I could reproduce the problem. The problem in the uzip script. > Debugging shows that an unsafe printf is guilty. I'm applying the > following patch right now. Ok, thanks. I applied the patch it to my version of uzip on http://www.student.lu.se/~nbi98oli/. Except for the version number, it should be exactly the same as the one in CVS, so there's no point that I send the whole patch. Regards, Oskar Liljeblad (oskar at osk.mine.nu) From dmierzej at elka.pw.edu.pl Tue Jan 22 22:25:17 2002 From: dmierzej at elka.pw.edu.pl (Dominik Mierzejewski) Date: Tue, 22 Jan 2002 23:25:17 +0100 Subject: mc 4.5.55 has a bug with zip support In-Reply-To: References: Message-ID: <20020122222517.GB5518@wonko.esi.org.pl> On Tuesday, 22 January 2002, Pavel Roskin wrote: > Hello, Jari! > > > I while ago I compiled & installed mc version 4.5.55 on Redhat 7.2 using > > this source package: > > > > http://rhcontrib.bero.org/RPMS/SRPMS/mc-4.5.55-1.src.rpm > > Thank for the URL. I'll review the patches in that package. Most are > related to gmc (now removed from the sources), but some are for the text > edition. As I said, these are RedHat's patches updated to apply against this mc version. Nothing new, I guess. -- "The Universe doesn't give you any points for doing things that are easy." -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows" Dominik 'Rathann' Mierzejewski From proski at gnu.org Tue Jan 22 22:45:20 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 22 Jan 2002 17:45:20 -0500 (EST) Subject: CVS: autoheader: error: AC_CONFIG_HEADERS not found in configure.in In-Reply-To: <20020122030121.48EF339406E@fastmail.fm> Message-ID: Hi, Fr?d?ric! On Tue, 22 Jan 2002, [ISO-8859-1] Fr?d?ric L. W. Meunier wrote: > This is what I get running ./autogen.sh with current CVS. I'm using > Autoconf 2.52 and Automake 1.5, the same versions that worked 28 October, > last time I compiled. It appears that aclocal is not run before autoheader. Looking at autogen.sh I cannot imagine how it can happen. Please run autogen.sh in the debug mode: bash -x autogen.sh -- Regards, Pavel Roskin From proski at gnu.org Tue Jan 22 23:35:23 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 22 Jan 2002 18:35:23 -0500 (EST) Subject: SEGV on xterm resizing In-Reply-To: <1011660120.22566.5.camel@saq> Message-ID: Hi, Pawe?! > When I resize my xterm (or gnome-terminal) running mc and resize it to a > very small size (like 1x1), MC 4.5.55 dies: > > #0 0x002435f9 in memset () from /lib/libc.so.6 > #1 0xbffffbb4 in ?? () > #2 0x08050e2f in format_file (dest=0xbfffe610 ' ' times>..., > panel=0x8106318, file_index=0, width=-1, attr=5, isstatus=1) > at screen.c:547 > #3 0x080511e1 in repaint_file (panel=0x20202020, file_index=538976288, > mv=538976288, attr=538976288, isstatus=538976288) at screen.c:618 > #4 0x20202020 in ?? () > Cannot access memory at address 0x20202020 Thanks! I'm applying the following patch: ======================== --- ChangeLog +++ ChangeLog @@ -2,2 +2,5 @@ + * screen.c: Don't try to paint anything if width is 0 or less. + Reported by Pawel Sakowski + * screen.c: Make functions static whenever possible. Remove --- screen.c +++ screen.c @@ -583,6 +583,10 @@ repaint_file (WPanel *panel, int file_in } else width = (panel->widget.cols - 2); + /* Nothing to paint */ + if (width <= 0) + return; + if (mv){ if (!isstatus && panel->split){ widget_move (&panel->widget, ======================== Sorry, I cannot use "hard l" in ChangeLog, it's in iso-8859-1. Now MC survives "compessing" to 1x1. The editor still crashes, I'll have a look. -- Regards, Pavel Roskin From lists at pervalidus.net Wed Jan 23 00:48:16 2002 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Tue, 22 Jan 2002 22:48:16 -0200 Subject: CVS: autoheader: error: AC_CONFIG_HEADERS not found in configure.in In-Reply-To: References: <20020122030121.48EF339406E@fastmail.fm> Message-ID: <20020123004816.GA28466@pervalidus> On Tue, Jan 22, 2002 at 05:45:20PM -0500, Pavel Roskin wrote: > Hi, Fr?d?ric! > > On Tue, 22 Jan 2002, [ISO-8859-1] Fr?d?ric L. W. Meunier wrote: > > > This is what I get running ./autogen.sh with current CVS. I'm using > > Autoconf 2.52 and Automake 1.5, the same versions that worked 28 October, > > last time I compiled. > > It appears that aclocal is not run before autoheader. That was it. There was no /usr/bin/aclocal anymore (strange), only the 2.13 /usr/local/old/bin/aclocal. And thanks for the tip. -- 0 at pervalidus.{net, dyndns.org} From proski at gnu.org Wed Jan 23 06:24:03 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 23 Jan 2002 01:24:03 -0500 (EST) Subject: CVS: autoheader: error: AC_CONFIG_HEADERS not found in configure.in In-Reply-To: <20020123004816.GA28466@pervalidus> Message-ID: Hi, Fr?d?ric! > > It appears that aclocal is not run before autoheader. > > That was it. There was no /usr/bin/aclocal anymore (strange), > only the 2.13 /usr/local/old/bin/aclocal. And thanks for the > tip. Well, the problem is still unsolved. autogen.sh should not run autoheader is it fails to run aclocal. Doing otherwise is a bug that needs to be fixed, not just for your convenience, but for the convenience of those who follow your steps. If I remove aclocal, that's what I'm getting: $ ./autogen.sh ./autogen.sh: aclocal: command not found ./autogen.sh: aclocal: command not found That's pretty straight, unlike the error message you got. Can you still reproduce the problem if you remove aclocal? Could you please post the output of "bash -x autogen.sh" when autogen.sh fails? -- Regards, Pavel Roskin From pavel at ucw.cz Mon Jan 21 13:18:38 2002 From: pavel at ucw.cz (Pavel Machek) Date: Mon, 21 Jan 2002 13:18:38 +0000 Subject: mc ftpfs bug In-Reply-To: <16848535951.20020114220241@hostel.sm.bmstu.ru>; from mastan@hostel.sm.bmstu.ru on Mon, Jan 14, 2002 at 10:02:41PM +0300 References: <16848535951.20020114220241@hostel.sm.bmstu.ru> Message-ID: <20020121131837.B124@toy.ucw.cz> Hi! > I found a bug in MC's ftpfs: uploading or downloading files containing > symbol '[' fails with permission deny error. Can you provide communication log? Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From kai at cmail.ru Wed Jan 23 12:05:59 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 23 Jan 2002 14:05:59 +0200 Subject: Ftpfs security hole particulary fixed Message-ID: <001a01c1a406$52684a10$8a65a8c0@sav> Hello! This patch fixes bug in ftpfs chmod implementation. After 4.5.43 chmod fails without warning if it called not from root directory at ftp site. So uploading over mc ftpfs can be insecure because uploaded files/directories have default permissions. BTW uploaded file has such permission some time after uploading before appropriative chmod call finishes. May be something like "UMASK 077" has to be passed to ftp server after establishing connection. But I don't know is this command are widely supported by ftp servers. As far as I know wu-ftpd has this command. Test case: 1. $ touch secure_file 2. $ chmod 600 secure_file 3. 4. Connect to ftp server, chdir to tmp. 5. Copy secure_file to this directory. At the most ftp servers it will has 0644 mode. Regards, Andrew. --- ftpfs.c- Mon Aug 6 18:39:08 2001 +++ ftpfs.c Tue Jan 22 22:28:17 2002 @@ -1518,7 +1551,7 @@ static int ftpfs_chmod (vfs *me, char *p { char buf[BUF_SMALL]; - g_snprintf(buf, sizeof(buf), "SITE CHMOD %4.4o %%s", mode & 07777); + g_snprintf(buf, sizeof(buf), "SITE CHMOD %4.4o /%%s", mode & 07777); return send_ftp_command(me, path, buf, OPT_IGNORE_ERROR | OPT_FLUSH); } From proski at gnu.org Wed Jan 23 16:58:07 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 23 Jan 2002 11:58:07 -0500 (EST) Subject: Ftpfs security hole particulary fixed In-Reply-To: <001a01c1a406$52684a10$8a65a8c0@sav> Message-ID: Hi, Andrew! > This patch fixes bug in ftpfs chmod implementation. Thank you for tracking it down! > After 4.5.43 chmod fails without warning if it called not > from root directory at ftp site. So uploading over mc ftpfs > can be insecure because uploaded files/directories have > default permissions. I just want to clarify that the default permissions are not necessarily bad. The server must be seriously misconfigured to allow other users to modify the uploaded files. Normally the umask is 022, i.e. other users can just read the new files. Relying on FTP when uploading the files that may not be read is not a good idea anyway, since FTP transfers data in cleartext. I acknoledge that the bug is security-related. However, it doesn't warrant an emergency release in my opinion. > BTW uploaded file has such permission some time after uploading before > appropriative chmod call finishes. May be something like "UMASK 077" > has to be passed to ftp server after establishing connection. But I > don't know is this command are widely supported by ftp servers. As far > as I know wu-ftpd has this command. Even a simple ftp client included with kerberos 1.2.2 has the "umask" command that sends "SITE UMASK" to the server, so the "umask" command has some "recognition". I don't think that using umask is worth the trouble, partly for the reasons explained above, partly because it only affects FTP upload. It also takes time to send a command and wait for the result. -- Regards, Pavel Roskin From kai at cmail.ru Thu Jan 24 10:45:01 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Thu, 24 Jan 2002 13:45:01 +0300 Subject: Speeding up VFS - no more mc_stat("..") Message-ID: <200201241045.g0OAj0s23196@cmail.ru> Hello! >That's the second part of the patch that speeds up VFS. If there is no >".." in the directory list, then a fake ".." is added. However, mc will >no longer go up the hierarchy to find the size of the ".." directory. > >So, it you have an account of a system foo and your home directory is bar, >then going to /#sh:foo/home/bar/subdir won't cause mc to get the listing >of all users under /home. > > >============================ >--- ChangeLog >+++ ChangeLog >@@ -2,2 +2,5 @@ > >+ * dir.c (add_dotdot_to_list): Don't use costly stat() - just put >+ realistic (i.e. bogus) data to the list. >+ > * screen.c (string_file_size): Don't display size of ".." - it >--- dir.c >+++ dir.c >@@ -342,10 +342,6 @@ clean_dir (dir_list *list, int count) > static int > add_dotdot_to_list (dir_list *list, int index) > { >- char buffer [MC_MAXPATHLEN + MC_MAXPATHLEN]; >- char *p; >- int i = 0; >- > /* Need to grow the *list? */ > if (index == list->size) { > list->list = g_realloc (list->list, sizeof (file_entry) * >@@ -355,40 +351,14 @@ add_dotdot_to_list (dir_list *list, int > list->size += RESIZE_STEPS; . . . >- mc_get_current_wd (buffer, sizeof (buffer) - 1 ); >- if (buffer [strlen (buffer) - 1] == PATH_SEP) >- buffer [strlen (buffer) - 1] = 0; >- for (;;) { >- strcat (buffer, PATH_SEP_STR ".."); >- p = vfs_canon (buffer); >- if (mc_stat (p, &((list->list) [index].buf)) != -1){ >- g_free (p); >- break; >- } >- i = 1; >- if (!strcmp (p, PATH_SEP_STR)){ >- g_free (p); >- return 1; >- } >- strcpy (buffer, p); >- g_free (p); >- } This patch also fixes a rare buffer overflow. If p cannot be mc_stat()ed for any reason it will append PATH_SEP_STR ".." again and again without checks for buffer size. This was a reson why mc-4.5.x crashes when extfs archives with leading ~ in name browsed before vfs_canon behavior was fixed. -- Regards, Andrew. From sav at it.efp.com.ua Thu Jan 24 11:26:25 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Thu, 24 Jan 2002 13:26:25 +0200 Subject: Ftpfs auto-reconnect feature Message-ID: <001e01c1a4c9$f5695fb0$8a65a8c0@sav> Hello! I did a first approximation of ftpfs auto-reconnect feature. This one was present before 4.5.43 and is very useful as for me. Now it is not functional yet because it set root directory as CWD after reconnect. Unfortunelly I have no time to truck down why SUP.cwdir become "" and as far as know it can become a name of directory where last symlink was resolved. But this patch can be a start point for somebody else. Regards, Andrew. ChangeLog: * ftpfs.c (reconnect): New function to restore closed session. (command): Use reconnect if EPIPE received. (dir_load): Eliminate recursion. (login_server): Constify netrcpass parameter. (is_same_dir): Constify path parameter. --- ftpfs.c- Mon Aug 6 18:39:08 2001 +++ ftpfs.c Tue Jan 22 22:28:17 2002 @@ -158,6 +158,10 @@ static char reply_str [80]; static char *ftpfs_get_current_directory (vfs *me, vfs_s_super *super); static int ftpfs_chdir_internal (vfs *me, vfs_s_super *super, char *remote_path); +static int command (vfs *me, vfs_s_super *super, int wait_reply, char *fmt, ...) + __attribute__ ((format (printf, 4, 5))); +static int ftpfs_open_socket (vfs *me, vfs_s_super *super); +static int login_server (vfs *me, vfs_s_super *super, const char *netrcpass); static char * translate_path (vfs *me, vfs_s_super *super, const char *remote_path) @@ -261,6 +265,24 @@ get_reply (vfs *me, int sock, char *stri } static int +reconnect (vfs *me, vfs_s_super *super) +{ + int sock = ftpfs_open_socket (me, super); + if (sock != -1){ + char *cwdir = SUP.cwdir; + close (SUP.sock); + SUP.sock = sock; + SUP.cwdir = NULL; + if (login_server (me, super, SUP.password)){ + sock = ftpfs_chdir_internal (me, super, cwdir); + g_free (cwdir); + return sock == COMPLETE; + } + } + return 0; +} + +static int command (vfs *me, vfs_s_super *super, int wait_reply, char *fmt, ...) { va_list ap; @@ -288,17 +310,27 @@ command (vfs *me, vfs_s_super *super, in got_sigpipe = 0; enable_interrupt_key (); status = write (SUP.sock, str, status + 2); - g_free (str); if (status < 0){ code = 421; if (errno == EPIPE){ + static int level = 0; + if (level == + level = 1; + status = reconnect (me, super); + level = 0; + if (status && write (SUP.sock, str, status + 2) > 0) + goto ok; + } got_sigpipe = 1; } + g_free (str); disable_interrupt_key (); return TRANSIENT; } + ok: + g_free (str); disable_interrupt_key (); if (wait_reply) @@ -343,7 +375,7 @@ changetype (vfs *me, vfs_s_super *super, /* This routine logs the user in */ static int -login_server (vfs *me, vfs_s_super *super, char *netrcpass) +login_server (vfs *me, vfs_s_super *super, const char *netrcpass) { #if defined(HSC_PROXY) char *proxypass, *proxyname; @@ -1177,7 +1209,7 @@ dir_load(vfs *me, vfs_s_inode *dir, char char buffer[BUF_8K]; int cd_first = (strchr (remote_path, ' ') != NULL) || ftpfs_first_cd_then_ls || (SUP.strict == RFC_STRICT); - +again: print_vfs_message(_("ftpfs: Reading FTP directory %s... %s%s"), remote_path, SUP.strict == RFC_STRICT ? _("(strict rfc959)") : "", cd_first ? _("(chdir first)") : ""); @@ -1312,7 +1344,8 @@ fallback: /* It's our first attempt to get a directory listing from this server (UNIX style LIST command) */ SUP.strict = RFC_STRICT; - return dir_load (me, dir, remote_path); + cd_first = 1; + goto again; } print_vfs_message(_("ftpfs: failed; nowhere to fallback to")); ERRNOR(-1, EACCES); @@ -1541,7 +1574,7 @@ static int ftpfs_unlink (vfs *me, char * /* Return true if path is the same directoy as the one we are on now */ static int -is_same_dir (vfs *me, vfs_s_super *super, char *path) +is_same_dir (vfs *me, vfs_s_super *super, const char *path) { if (!SUP.cwdir) return 0; From jnebrera at jazzfree.com Thu Jan 24 20:54:23 2002 From: jnebrera at jazzfree.com (Jaime Nebrera Herrera) Date: Thu, 24 Jan 2002 21:54:23 +0100 Subject: Is this a bug? Message-ID: <02012421542303.01759@jaime> Hi, I'm running mc-4.5.51-18 in a e-smith 4.1.2 I have seen an strange behaviour of your package and have been adviced from e-smith development list to ask you. OK, I report that "some times" (I don't know if allways) if you close a ssh or telnet session WITH an open mc terminal in it, the mc process goes bersek and starts to use all CPU resources. How the failure was noticed? We run a esmith addon that we have made ourselves that shows graphically some system info. Once in a while this graph goes solid 100% untill you solve the problem If I run top I can see mc process with no terminal attached is using 97% of CPU all the time. The problem is easely solved, just need to kill the program but is an annoying situation as we use mc a lot for admin tasks and sometimes you just forget to close it properly :( Wonderfull package BTW. Regards. -- Jaime Nebrera - jnebrera at jazzfree.com From proski at gnu.org Thu Jan 24 22:20:48 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 24 Jan 2002 17:20:48 -0500 (EST) Subject: Is this a bug? In-Reply-To: <02012421542303.01759@jaime> Message-ID: Hello! > I'm running mc-4.5.51-18 in a e-smith 4.1.2 I have seen an strange > behaviour of your package and have been adviced from e-smith development list > to ask you. Please upgrade to the latest released version 4.5.55. You can find it on http://www.midnightcommander.org/ > OK, I report that "some times" (I don't know if allways) if you close a ssh > or telnet session WITH an open mc terminal in it, the mc process goes bersek > and starts to use all CPU resources. Of course it's a bug. I believe that it's fixed in 4.5.55. -- Regards, Pavel Roskin From hrdo at myrealbox.com Sat Jan 26 16:28:27 2002 From: hrdo at myrealbox.com (john) Date: Sat, 26 Jan 2002 18:28:27 +0200 Subject: embedding the SLang interpreter Message-ID: <001001c1a68d$e9ce5e60$2b2221c4@yarningdale> Hello Pavel, Since the current MC version includes by default SLang, would it be possible to embed the SLang interpreter and get a macro language? Please give me a hint how this could be done if you are not interested. Thanks! john From proski at gnu.org Mon Jan 28 16:29:07 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 28 Jan 2002 11:29:07 -0500 (EST) Subject: CVS: autoheader: error: AC_CONFIG_HEADERS not found in configure.in In-Reply-To: <20020123004816.GA28466@pervalidus> Message-ID: Hi, Fr?d?ric! > > > This is what I get running ./autogen.sh with current CVS. I'm using > > > Autoconf 2.52 and Automake 1.5, the same versions that worked 28 October, > > > last time I compiled. > > > > It appears that aclocal is not run before autoheader. > > That was it. There was no /usr/bin/aclocal anymore (strange), > only the 2.13 /usr/local/old/bin/aclocal. And thanks for the > tip. You didn't give enough details about the failure, but I have committed a patch to autogen.sh that checks that autoconf and automake actually generate their output files in addition to checking their exit status. Similar problem was reported to me privately by Petr Kozelka -- Regards, Pavel Roskin From pkozelka at email.cz Mon Jan 28 17:54:13 2002 From: pkozelka at email.cz (Petr Kozelka) Date: Mon, 28 Jan 2002 18:54:13 +0100 Subject: Pascal syntax patch Message-ID: <006101c1a824$cc24b010$a372daa0@eurotel.cz> Hello, here is a patch for Pascal syntax rules. Main features: - known Delphi/Kylix source file extensions supported (*.dpr, *.inc) - many new (Delphi/Kylix) keywords added - special highlighting of CVS macros - understands singleline comments (//) Regards Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: pascal.patch.gz Type: application/x-gzip Size: 1121 bytes Desc: not available URL: From proski at gnu.org Mon Jan 28 21:05:47 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 28 Jan 2002 16:05:47 -0500 (EST) Subject: embedding the SLang interpreter In-Reply-To: <001001c1a68d$e9ce5e60$2b2221c4@yarningdale> Message-ID: Hi, John! > Since the current MC version includes by default > SLang, would it be possible to embed the SLang > interpreter and get a macro language? > > Please give me a hint how this could be done > if you are not interested. I don't understand why you would want a macro language in mc. If you want to use in the menu, extension file, syntax highlighting, then a language with a better regular expression support should be preferred, for example Perl. But then you can just make a clean start and write a file manager in an interpreted language. Although the project of that size would be easier to write in a more scalable language, e.g. Python or Ruby. -- Regards, Pavel Roskin From proski at gnu.org Mon Jan 28 22:39:07 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 28 Jan 2002 17:39:07 -0500 (EST) Subject: Pascal syntax patch In-Reply-To: <006101c1a824$cc24b010$a372daa0@eurotel.cz> Message-ID: Hi, Petr! > here is a patch for Pascal syntax rules. I've applied it, but one question remains. > - special highlighting of CVS macros What is this? I could not identify CVS macros in your patch. -- Regards, Pavel Roskin From pkozelka at centrum.cz Mon Jan 28 22:46:05 2002 From: pkozelka at centrum.cz (Petr Kozelka) Date: Mon, 28 Jan 2002 23:46:05 +0100 Subject: Pascal syntax patch References: Message-ID: <004f01c1a84d$95509940$3e0edaa0@eurotel.cz> > > - special highlighting of CVS macros > > What is this? I could not identify CVS macros in your patch. not very usual, but I have found this useful... try to put a CVS macro into a comment in a .pas file and you will see. For instance: // $Id: $ // $Log:$ Regards Petr From proski at gnu.org Mon Jan 28 23:47:09 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 28 Jan 2002 18:47:09 -0500 (EST) Subject: Pascal syntax patch In-Reply-To: <004f01c1a84d$95509940$3e0edaa0@eurotel.cz> Message-ID: > > > - special highlighting of CVS macros > > > > What is this? I could not identify CVS macros in your patch. > > not very usual, but I have found this useful... > try to put a CVS macro into a comment in a .pas file and you will see. > For instance: > > // $Id: $ > // $Log:$ These are keywords, not macros. I'm adjusting the ChangeLog. -- Regards, Pavel Roskin From pkozelka at centrum.cz Mon Jan 28 23:52:29 2002 From: pkozelka at centrum.cz (Petr Kozelka) Date: Tue, 29 Jan 2002 00:52:29 +0100 Subject: Pascal syntax patch References: Message-ID: <00df01c1a856$dbbf84a0$3e0edaa0@eurotel.cz> > > // $Id: $ > > // $Log:$ > > These are keywords, not macros. I'm adjusting the ChangeLog. ough... sorry, of course you are right. Petr From kai at cmail.ru Tue Jan 29 10:39:21 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 29 Jan 2002 12:39:21 +0200 Subject: Ftpfs security hole particulary fixed Message-ID: <009701c1a8b1$373fcb50$8a65a8c0@sav> Hello! > > After 4.5.43 chmod fails without warning if it called not > > from root directory at ftp site. So uploading over mc ftpfs > > can be insecure because uploaded files/directories have > > default permissions. > > I just want to clarify that the default permissions are not necessarily > bad. The server must be seriously misconfigured to allow other users to > modify the uploaded files. Normally the umask is 022, i.e. other users > can just read the new files. Relying on FTP when uploading the files that > may not be read is not a good idea anyway, since FTP transfers data in > cleartext. But you need some knowledge level, rights and luck to listen right ports in right time. > I acknoledge that the bug is security-related. However, it doesn't > warrant an emergency release in my opinion. Does we want to maintain 4.5.x barnch and do users need gmc is much more important question. > I don't think that using umask is worth the trouble, partly for the > reasons explained above, partly because it only affects FTP upload. > It also takes time to send a command and wait for the result. Well, it may be configurable option in VFS Option menu. BTW I want add "Use Unix ls options" there because wu-ftpd 2.6.1 understands "LIST -la" as "LIST -laR" and confuses mc parser. Regards, Andrew. From cert at cert.org Tue Jan 29 21:11:39 2002 From: cert at cert.org (CERT Coordination Center) Date: Tue, 29 Jan 2002 16:11:39 -0500 Subject: VU#203203 - midnight_commander Message-ID: <200201292111.g0TLBd117315@holmes.blue.cert.org> -----BEGIN PGP SIGNED MESSAGE----- Hello folks, We have received report regarding a vulnerability in one of your products. We would appreciate greatly your help in reviewing this issue so that we can document it in our public database. Please review the following vulnerability note for accuracy and answer these questions: 1. Have you verified the existence of this vulnerability? 2. Has it been corrected in a released update or new version of the product? If yes, please provide links to more information, including how users can obtain the update or new version. 3. If not yet released, when do you plan on releasing an update to fix this vulnerability? What should users do in the meantime to limit exposure to this vulnerability? CERT/CC Vulnerability Note Draft: VU#203203 - Buffer-overflow vulnerability in Midnight Commander CVE: KEYWORDS: Midnight Commander, /usr/bin/mcedit, mcedit, buffer overflow OVERVIEW: The mcedit component of some versions of Midnight Commander contains a buffer-overflow vulnerability. DESCRIPTION: Midnight Commander is a file manager for free operating systems, distributed under the GNU General Public License (GPL). In version 4.5.1 of Midnight Commander, the mcedit text editor component is susceptible to segmentation fault by buffer overflow. IMPACT: The complete impact of this vulnerability is not yet known. Attackers can cause mcedit to end with a segmentation fault. RESOLUTION: The CERT/CC is currently unaware of a practical solution to this problem. WORKAROUNDS: None. REFERENCES: http://www.ibiblio.org/mc/ If there are any mistakes or inaccuracies in the above vulnerability note, please let me know so they can be corrected before publication. Regards, Shawn Van Ittersum CERT Coordination Center Software Engineering Institute Carnegie Mellon University -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBPFcP6KCVPMXQI2HJAQGpPAP+I7ooapPztZETir8IfAOIzr68y/couuGH Lz9FJAAxYA9yIrk6ZuZFcNVsT2aMCmwZv2CBLBCETPHSX7umUz1uoTbfy4wqNUeL wZRHhttfWAkwnTILnformlalyZOzVPpDCx2X6pfnhtma6nyuxA00xEWW80BGRt/i vrrMuJYGbZU= =q3ct -----END PGP SIGNATURE----- From bjorn at bjornen.nu Tue Jan 29 22:09:37 2002 From: bjorn at bjornen.nu (=?iso-8859-1?Q?Bj=F6rn?= Eriksson) Date: Tue, 29 Jan 2002 23:09:37 +0100 Subject: VU#203203 - midnight_commander In-Reply-To: <200201292111.g0TLBd117315@holmes.blue.cert.org> References: <200201292111.g0TLBd117315@holmes.blue.cert.org> Message-ID: <20020129220937.GM1069@algonet.se> On Tue, Jan 29, 2002 at 04:11:39PM -0500, CERT Coordination Center wrote: > We have received report regarding a vulnerability in one of your > products. We would appreciate greatly your help in reviewing this > issue so that we can document it in our public database. <...> To bad they didn't provide a link; I couldn't find anything re. 'mcedit' or 'midnight commander' in their database nor anything re. 'VU#203203' or simply '203203'. > The complete impact of this vulnerability is not yet known. Attackers > can cause mcedit to end with a segmentation fault. I seem to remember someone claimed his mcedit segfaulted on extremely long lines. I further STR I showed him it was a simple ulimit-thing. (But I can't find this in the archives...) I didn't CC: cert on this mail. I figure someone else is in better position to make formal contact. -- //Bj?rnen. bjorn at bjornen.nu | mdeans at algonet.se | bjorn at pobox.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From proski at gnu.org Wed Jan 30 01:16:32 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 29 Jan 2002 20:16:32 -0500 (EST) Subject: Ftpfs security hole particulary fixed In-Reply-To: <009701c1a8b1$373fcb50$8a65a8c0@sav> Message-ID: Hi! > > I just want to clarify that the default permissions are not necessarily > > bad. The server must be seriously misconfigured to allow other users to > > modify the uploaded files. Normally the umask is 022, i.e. other users > > can just read the new files. Relying on FTP when uploading the files that > > may not be read is not a good idea anyway, since FTP transfers data in > > cleartext. > > But you need some knowledge level, rights and luck to listen right ports in > right time. Exactly the same is needed to read uploaded files - knowledge level, rights (i.e. shell access to the ftp server) and luck to read the right files in the right time (i.e. before chmod). I mean fixed mc. Otherwise the luck is not required :-) > > I acknoledge that the bug is security-related. However, it doesn't > > warrant an emergency release in my opinion. > > Does we want to maintain 4.5.x barnch and do users need gmc is much > more important question. I don't see any interests from GNOME users towards gmc. I searched on Google for gmc and words "love" and "hate". It turns out that gmc has more haters than lovers :-) Seriously, even Ximian didn't bother to update gmc to 4.5.55. Neither did RedHat. What's the purpose in releasing another version that very few people will use? Most GNOME users don't compile their sources, even if advised of security holes. > > I don't think that using umask is worth the trouble, partly for the > > reasons explained above, partly because it only affects FTP upload. > > It also takes time to send a command and wait for the result. > > Well, it may be configurable option in VFS Option menu. BTW I want add > "Use Unix ls options" there because wu-ftpd 2.6.1 understands "LIST -la" as > "LIST -laR" and confuses mc parser. I thing that "umask" in the menu is an overkill. "Use Unix ls options" should be there if only it's impossible to avoid. Even it that case, we should try to make it remote host-specific, not user-specific. I'm using wu-ftpd 2.6.1 (from RedHat 7.2) and it works correctly. Here's the transcript with debug enabled: ftp> ls -al ---> PASV 227 Entering Passive Mode (127,0,0,1,4,177) ---> LIST -al 150 Opening ASCII mode data connection for directory listing. total 48 drwxr-xr-x 6 root root 4096 Nov 20 16:20 . drwxr-xr-x 6 root root 4096 Nov 20 16:20 .. d--x--x--x 2 root root 4096 Nov 20 16:20 bin d--x--x--x 2 root root 4096 Dec 17 15:57 etc drwxr-xr-x 2 root root 4096 Dec 17 15:57 lib drwxr-xr-x 4 500 root 4096 Jan 29 01:36 pub 226 Transfer complete. ftp> I would prefer to try all possible solutions first (except stripping the results of "ls -alR", which can be time and bandwidth consuming) before exposing the problem to the user. Could you please send the transcript? Have you reported the bug to wu-ftpd developers? Have you tried "ls -al" instead of "ls -la" ? -- Regards, Pavel Roskin From proski at gnu.org Wed Jan 30 01:40:15 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 29 Jan 2002 20:40:15 -0500 (EST) Subject: VU#203203 - midnight_commander In-Reply-To: <200201292111.g0TLBd117315@holmes.blue.cert.org> Message-ID: Hello! I'm the maintainer of GNU Midnight Commander. If there are any details that you don't want to make public, please write me personally. You can use my public key at http://www.red-bean.com/~proski/pubring.gpg.asc to encrypt your message. > We have received report regarding a vulnerability in one of your > products. We would appreciate greatly your help in reviewing this > issue so that we can document it in our public database. Sorry, but the information in this report is insufficient. > Please review the following vulnerability note for accuracy and > answer these questions: > 1. Have you verified the existence of this vulnerability? The description is too vague to verify the vulnerability. However, the code of GNU Midnight Commander has not been audited for security as far as I know. > 2. Has it been corrected in a released update or new version of the > product? If yes, please provide links to more information, including > how users can obtain the update or new version. > 3. If not yet released, when do you plan on releasing an update to > fix this vulnerability? What should users do in the meantime to limit > exposure to this vulnerability? The same answer. > CERT/CC Vulnerability Note Draft: > > VU#203203 - Buffer-overflow vulnerability in Midnight Commander I understand that drafts are not available online, are they? > Midnight Commander is a file manager for free operating systems, > distributed under the GNU General Public License (GPL). In version > 4.5.1 of Midnight Commander, the mcedit text editor component is > susceptible to segmentation fault by buffer overflow. The current version is 4.5.55. There have been many changes in the internal editor between versions 4.5.1 and 4.5.55. > The complete impact of this vulnerability is not yet known. Attackers > can cause mcedit to end with a segmentation fault. Provided that the vulnerability exists, the attacker would have to create a special file and entice the attacked user into opening that file. I'll fix the overflow if somebody sends me a file that crashes the editor. I'm sorry, but I have neither time nor expertize to conduct a comprehensive security audit of the code without having an exploit or at least a hint to a possible exploit. -- Regards, Pavel Roskin From kai at cmail.ru Wed Jan 30 11:13:51 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 30 Jan 2002 13:13:51 +0200 Subject: feature request: delete after copy In-Reply-To: <047601c18092$b6bf85b0$1501a8c0@scar> References: <047601c18092$b6bf85b0$1501a8c0@scar> Message-ID: <20020130131351.A164@it.efp.com.ua> Hello! On Sun, Dec 09, 2001 at 10:20:15AM +0100, Klaus Ridder wrote: > I have the following problem with mc > > I have to move a lot of data to a filesystem which is remotely mounted by > smb through a ssh tunnel. > The problem is, that I cannot chown, so I am not able to use the "move" > command of midnight commander, but "copy" insted (with switching off > "preserve attributes". > However, one copy session can take some hours or even days, and it would be > great if mc really could remove sigle files as soon as they are transfered > (as move does). > > So I suggest to either > - implement the option "preserve attributes" also to the mv option > - implement an option "delete each file after successfully copied" to the > copy dialogue. > > It would be one of thos could be implemented. > Is there probably a workaround for me at the current time? > Can you test patch below? Regards, Andrew. ChangeLog: * filegui.c (file_mask_dialog): Enable "preserve Attributes" and "follow Links" features in Move dialog. Index: filegui.c =================================================================== RCS file: /cvs/gnome/mc/src/filegui.c,v retrieving revision 1.21 diff -u -p -u -p -r1.21 filegui.c --- filegui.c 2002/01/21 20:47:06 1.21 +++ filegui.c 2002/01/30 10:59:28 @@ -906,11 +908,10 @@ file_mask_dialog (FileOpContext *ctx, Fi if (operation == OP_COPY) { Quick_input.class = "quick_file_mask_copy"; - Quick_input.widgets = fmd_widgets; } else { /* operation == OP_MOVE */ Quick_input.class = "quick_file_mask_move"; - Quick_input.widgets = fmd_widgets + 2; } + Quick_input.widgets = fmd_widgets; fmd_widgets [FMDI0].text = text; fmd_widgets [FMDI2].text = def_text; fmd_widgets [FMDI2].str_result = &dest_dir; @@ -922,12 +923,12 @@ ask_file_mask: if ((val = quick_dialog_skip (&Quick_input, SKIP)) == B_CANCEL) return 0; - if (ctx->follow_links && operation != OP_MOVE) + if (ctx->follow_links) ctx->stat_func = (mc_stat_fn) mc_stat; else ctx->stat_func = (mc_stat_fn) mc_lstat; - if (ctx->op_preserve || operation == OP_MOVE) { + if (ctx->op_preserve) { ctx->preserve = 1; ctx->umask_kill = 0777777; ctx->preserve_uidgid = (geteuid () == 0) ? 1 : 0; From sav at it.efp.com.ua Wed Jan 30 11:55:26 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Wed, 30 Jan 2002 13:55:26 +0200 Subject: Ftpfs security hole particulary fixed References: Message-ID: <002b01c1a985$01575650$8a65a8c0@sav> Hello! > Exactly the same is needed to read uploaded files - knowledge level, > rights (i.e. shell access to the ftp server) Even ftp access to this ftp server is enough. > and luck to read the right > files in the right time (i.e. before chmod). I mean fixed mc. Otherwise > the luck is not required :-) > > Does we want to maintain 4.5.x barnch and do users need gmc is much > > more important question. > Seriously, even Ximian didn't bother to update gmc to 4.5.55. Neither did > RedHat. What's the purpose in releasing another version that very few > people will use? Most GNOME users don't compile their sources, even if > advised of security holes. Well, I realized the volume of work if we will do at appropriative level. You assured me :-) > > > I don't think that using umask is worth the trouble, partly for the > > > reasons explained above, partly because it only affects FTP upload. > > > It also takes time to send a command and wait for the result. > > > > Well, it may be configurable option in VFS Option menu. BTW I want add > > "Use Unix ls options" there because wu-ftpd 2.6.1 understands "LIST -la" as > > "LIST -laR" and confuses mc parser. > > I thing that "umask" in the menu is an overkill. I want to leave umask question opened. > "Use Unix ls options" > should be there if only it's impossible to avoid. Even it that case, we > should try to make it remote host-specific, not user-specific. Well, my wu-ftpd does "LIST -la" absolutely right and others understands this as "LIST -lad". So, if -d option is a common place for ftp servers I will commit patch where all of occurences of "LIST -la" will be replaced by "LIST -lad" Regards, Andrew. From sav at it.efp.com.ua Wed Jan 30 12:56:10 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Wed, 30 Jan 2002 14:56:10 +0200 Subject: Ftpfs security hole particulary fixed References: <002b01c1a985$01575650$8a65a8c0@sav> Message-ID: <003901c1a98d$7f386610$8a65a8c0@sav> Hello! > > "Use Unix ls options" > > should be there if only it's impossible to avoid. Even it that case, we > > should try to make it remote host-specific, not user-specific. > > Well, my wu-ftpd does "LIST -la" absolutely right > and others understands this as "LIST -lad". So, if -d option is a > common place for ftp servers I will commit patch where all of > occurences of "LIST -la" will be replaced by "LIST -lad" It was harry remark. Below is ftpfs logfile: 220 sav FTP server (Version wu-2.6.1(1) Fri Oct 20 18:47:23 PDT 2000) ready. MC -- remote_is_amiga = 0 USER sav 331 Password required for sav. PASS 230 User sav logged in. PWD 257 "/home/sav" is current directory. CWD / 250 CWD command successful. PASV 227 Entering Passive Mode (192,168,101,138,16,123) TYPE A 200 Type set to A. LIST -la . 150 Opening ASCII mode data connection for /bin/ls. bin: total 4172 drwxr-xr-x 2 root bin 4096 Sep 6 1999 . drwxr-xr-x 20 root root 4096 Jan 15 14:38 .. lrwxrwxrwx 1 root root 13 Jul 27 2001 Mail -> /usr/bin/Mail 82 lines removed boot: total 3228 drwxr-xr-x 2 root root 4096 Nov 5 15:34 . drwxr-xr-x 20 root root 4096 Jan 15 14:38 .. -rw-r--r-- 1 root root 195940 Jun 4 1999 System.map-2.2.5-22bc -rw-r--r-- 1 root root 512 Jul 30 2001 boot.0300 -rw-r--r-- 1 root root 512 Jul 27 2001 boot.0340 -rw-r--r-- 1 root root 4592 May 14 2000 boot.b -rw-r--r-- 1 root root 220 Jul 27 2001 boot_message.txt -rw-r--r-- 1 root root 464636 Nov 5 15:33 bzImage -rw-r--r-- 1 root root 463991 Aug 8 21:40 bzImage.oracle8i -rw-r--r-- 1 root root 462806 Jul 30 2001 bzImage.oracle8i+ps2 -rw-r--r-- 1 root root 612 May 14 2000 chain.b -rw------- 1 root root 29184 Nov 5 15:34 map -rw-r--r-- 1 root root 644 May 14 2000 os2_d.b -r-------- 1 root root 984326 Jul 27 2001 vmlinuz -rw-r--r-- 1 root root 629150 Jun 4 1999 vmlinuz-2.2.5-22bc cdrom: total 8 drwxr-xr-x 2 root root 4096 Oct 6 1997 . drwxr-xr-x 20 root root 4096 Jan 15 14:38 .. dev: total 108 drwxr-xr-x 4 root root 28672 Jan 30 12:46 . drwxr-xr-x 20 root root 4096 Jan 15 14:38 .. -rwxr-xr-x 1 root root 34490 Oct 10 1999 MAKEDEV -rw-r--r-- 1 root root 1162 Oct 10 1999 README.MAKEDEV lrwxrwxrwx 1 root root 4 Jul 27 2001 X0R -> null crw-r--r-- 1 root root 10, 134 Jun 8 1996 apm_bios crw-rw-rw- 1 root sys 10, 3 Jul 18 1994 atibm crw-rw-r-- 1 root sys 14, 4 Jul 18 1994 audio crw-rw-rw- 1 root sys 14, 20 Jul 18 1994 audio1 brw-r----- 1 root disk 29, 0 Feb 15 1995 aztcd crw-r--r-- 1 root root 10, 128 May 25 1996 beep lrwxrwxrwx 1 root root 8 Aug 1 2001 cdrom -> /dev/hdc brw-r----- 1 root disk 24, 0 Jul 18 1994 cdu535 brw-r----- 1 root disk 32, 0 Aug 18 1995 cm206cd crw------- 1 root tty 5, 1 Jan 30 12:46 console lrwxrwxrwx 1 root root 11 Jul 27 2001 core -> /proc/kcore 1756 lines removed etc, home, lib, lost+found, mnt, opt listing removed oracle: total 12 drwxr-xr-x 3 oracle dba 4096 Jul 27 2001 . drwxr-xr-x 20 root root 4096 Jan 15 14:38 .. drwxr-xr-x 3 oracle dba 4096 Jul 27 2001 app There are much more files/directories. proc: total 4 dr-xr-xr-x 55 root root 0 Jan 30 2002 . 80 lines removed sbin, var, usr and tmp listing removed, next lines are very interesing. 226 Transfer complete. PASV 227 Entering Passive Mode (192,168,101,138,110,82) LIST -lLa / 150 Opening ASCII mode data connection for /bin/ls. total 112 drwxr-xr-x 20 root root 4096 Jan 15 14:38 . drwxr-xr-x 20 root root 4096 Jan 15 14:38 .. drwxr-xr-x 2 root bin 4096 Sep 6 1999 bin drwxr-xr-x 2 root root 4096 Nov 5 15:34 boot drwxr-xr-x 2 root root 4096 Oct 6 1997 cdrom drwxr-xr-x 4 root root 28672 Jan 30 12:46 dev drwxr-xr-x 15 root root 4096 Jan 30 12:46 etc drwxr-xr-x 9 root root 4096 Nov 12 11:42 home drwxr-xr-x 4 root root 4096 Jan 15 14:38 lib drwxr-xr-x 2 root root 16384 Jul 27 2001 lost+found drwxr-xr-x 4 root root 4096 Oct 6 1997 mnt drwxr-xr-x 3 root root 4096 Jun 19 2000 opt drwxr-xr-x 3 oracle dba 4096 Jul 27 2001 oracle dr-xr-xr-x 57 root root 0 Jan 30 2002 proc drwx--x--- 12 root sys 4096 Sep 26 16:12 root drwxr-xr-x 2 root bin 4096 Oct 30 10:38 sbin drwxr-xr-x 2 bin bin 4096 Sep 25 12:08 shlib drwxrwxrwt 15 root root 4096 Jan 30 13:13 tmp drwxr-xr-x 20 root root 4096 Sep 3 1999 usr drwxr-xr-x 17 root root 4096 Jun 19 2000 var 226 Transfer complete. QUIT From proski at gnu.org Thu Jan 31 19:04:34 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 31 Jan 2002 14:04:34 -0500 (EST) Subject: Ftpfs security hole particulary fixed In-Reply-To: <002b01c1a985$01575650$8a65a8c0@sav> Message-ID: Hi, Andrew! > > I thing that "umask" in the menu is an overkill. > > I want to leave umask question opened. Ok, my only worry is that MC performs badly on slow FTP servers, so adding any other commend means that it will be even slower. However, MC performs better after it stopped calling mc_stat for ".." Please add the umode command if you insist and nobody in the list objects. > Well, my wu-ftpd does "LIST -la" absolutely right > and others understands this as "LIST -lad". So, if -d option is a > common place for ftp servers I will commit patch where all of > occurences of "LIST -la" will be replaced by "LIST -lad" Good that you found it. However, I suspect that some servers will only print the entry for "." instead of the whole listing. That's what the UNIX command does: $ ls -ald drwx------ 34 proski proski 4096 Jan 31 13:54 . It would be better it you reported the problem with that server. You could also test other FTP clients to see it they work with the broken server (try e.g. gftp and Far Manager). -- Regards, Pavel Roskin From proski at gnu.org Thu Jan 31 21:19:04 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 31 Jan 2002 16:19:04 -0500 (EST) Subject: Ftpfs security hole particulary fixed In-Reply-To: <003901c1a98d$7f386610$8a65a8c0@sav> Message-ID: Hi, Andrew! > 227 Entering Passive Mode (192,168,101,138,110,82) > LIST -lLa / Note that "-L" dereferences symbolic links. It may be good for speed, but it's not something we should be using by default. -- Regards, Pavel Roskin