From leonard at den.ottolander.nl Mon Nov 1 00:33:26 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 01 Nov 2004 01:33:26 +0100 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: References: <1096813412.14121.1.camel@localhost> Message-ID: <1099269205.4814.49.camel@athlon.localdomain> Hi Pavel, On Sun, 2004-10-10 at 10:40, Pavel Tsekov wrote: > I suggest that we alter the check in src/slint.c to something like that: > > if ((COLS < 10) || (LINES < 5) || > (SLang_Version < 10407 && (COLS > 255 || LINES > 255)) || > (SLang_Version >= 10407 && (COLS > 512 || LINES > 512))) > > Also the in-tree version of S-Lang should be brought to the current > version. Now we have 1.4.5 while latest stable S-Lang is 1.4.9. I don't see a crash when resizing an instance of mc in an xterm to more than 600 columns on Fedora Core 1, slang-1.4.5. I do of course get the error when starting an instance of mc in such a large terminal. The version of slang coming with FC1 is patched. Two of the patches, namely slang-debian-utf8.patch and slang-utf8-fix.patch affect send_attr_str(). I suspect the following part of the slang-debian-utf8.patch to hold the fix for this issue which is: static void send_attr_str (SLsmg_Char_Type *s) { - unsigned char out[256], ch, *p; +#ifdef UTF8 + SLsmg_Char_Type out[1024], ch, *p; +#else + unsigned char out[1024], ch, *p; +#endif /* UTF8 */ register SLtt_Char_Type attr; Indeed in 1.4.9 the above 256 has been replaced with SLTT_MAX_SCREEN_COLS. I understand Roland can reproduce the crash when resizing the screen horizontally, but is the crash also reproducible when resizing a terminal vertically? If we do patch the included version of slang by increasing the size of out[] in send_attr_str the below patch might also need a test whether the internal slang is used (patching SLang_Version in the internal slang.h and testing for this version as well as 10407). --- slint.c.000 2004-09-26 00:02:15.000000000 +0200 +++ slint.c 2004-10-31 23:07:16.000000000 +0100 @@ -183,7 +183,10 @@ slang_init (void) * (as of S-Lang 1.4.4). Detect it and abort. Also detect extremely * small, large and negative screen dimensions. */ - if ((COLS < 10) || (LINES < 5) || (COLS > 255) || (LINES > 255)) { + if ((COLS < 10) || (LINES < 5) || + (SLang_Version < 10407 && (COLS > 255 || LINES > 255)) || + (SLang_Version >= 10407 && (COLS > 512 || LINES > 512))) { + fprintf (stderr, _("Screen size %dx%d is not supported.\n" "Check the TERM environment variable.\n"), I think we should wait with upgrading the included version of slang until after 4.6.1, but if there is need we could fix the screen size according to the above. And of course there is the issue that LINES and COLS should be checked on resize and not only on initialization of slang. The segfault is probably still reproducible for COLS > 1024 on FC1 or COLS > 512 when using slang 1.4.9. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Mon Nov 1 07:36:13 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 01 Nov 2004 08:36:13 +0100 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: <1099269205.4814.49.camel@athlon.localdomain> References: <1096813412.14121.1.camel@localhost> <1099269205.4814.49.camel@athlon.localdomain> Message-ID: <4185E76D.2030404@gmx.de> Leonard den Ottolander wrote: > I understand Roland can reproduce the crash when resizing the screen > horizontally, but is the crash also reproducible when resizing a > terminal vertically? SLang (in this case mcslang) does not crash when resizing vertically to $many lines. Rxvt only shows the first 300 lines (the rest is white), and SLang only draws the first 256 lines of these. In an xterm only the first 512 lines are shown. Roland From roland.illig at gmx.de Mon Nov 1 07:47:16 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 01 Nov 2004 08:47:16 +0100 Subject: Once more tar.c ./files In-Reply-To: <1098999606.4813.38.camel@athlon.localdomain> References: <1098999606.4813.38.camel@athlon.localdomain> Message-ID: <4185EA04.10703@gmx.de> Leonard den Ottolander wrote: > Hi, > > While looking at Pavel's wiki > (http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs) I remembered that > the discussion about LGPLed VFS using GPL code was started because of > the tar.c issue. Came across the entry "three bugs" with this reference: > http://mail.gnome.org/archives/mc-devel/2004-April/msg00010.html . The > last hunk is has a much more elegant solution to the ./file problem. > Patch against current CVS attached. This effectively reverts the latest > fixes to tar.c, but it works. Tested with the appended file and committed. Thanks. Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: x.tar.gz Type: application/x-gzip Size: 161 bytes Desc: not available URL: From roland.illig at gmx.de Mon Nov 1 07:55:05 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 01 Nov 2004 08:55:05 +0100 Subject: edit_status () prints bad status line In-Reply-To: <7565.1099079355@www26.gmx.net> References: <1099071476.4781.58.camel@athlon.localdomain> <7565.1099079355@www26.gmx.net> Message-ID: <4185EBD9.8090200@gmx.de> Pavel Tsekov wrote: > For further explanation read my email regarding the > internal editor + ncurses, the section which quotes > the `addch' manpage. Also read the printf (3) manpage > regarding the use of '*'. > Might this help? Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: editdraw.c-screen-overflow.patch Type: text/x-patch Size: 1137 bytes Desc: not available URL: From roland.illig at gmx.de Mon Nov 1 08:17:38 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 01 Nov 2004 09:17:38 +0100 Subject: extfs/patchfs.in Message-ID: <4185F122.2060301@gmx.de> Hi, this patch allows to copyout and list patches for files with leading "./" or "../". See foobar.patch for an example. Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: patchfs-canonicalize-path.patch Type: text/x-patch Size: 1578 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: foobar.patch Type: text/x-patch Size: 116 bytes Desc: not available URL: From roland.illig at gmx.de Mon Nov 1 08:23:53 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 01 Nov 2004 09:23:53 +0100 Subject: building on AIX In-Reply-To: <20041028201844.2F4365087FE@mx.ktv.lt> References: <20041023143255.0CD41508412@mx.ktv.lt> <417AA819.8070302@gmx.de> <20041028201844.2F4365087FE@mx.ktv.lt> Message-ID: <4185F299.5060509@gmx.de> Nerijus Baliunas wrote: > While running configure I saw: > checking for socklen_t... no I have successfully built mc on AIX, and here is the patch I wrote for it. Please try if it works for you, too. Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: socklen_t.patch Type: text/x-patch Size: 1526 bytes Desc: not available URL: From ptsekov at gmx.net Mon Nov 1 06:56:41 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 1 Nov 2004 07:56:41 +0100 Subject: edit_status () prints bad status line In-Reply-To: <4185EBD9.8090200@gmx.de> References: <1099071476.4781.58.camel@athlon.localdomain> <7565.1099079355@www26.gmx.net> <4185EBD9.8090200@gmx.de> Message-ID: Hello, On Mon, 1 Nov 2004, Roland Illig wrote: > Pavel Tsekov wrote: > > For further explanation read my email regarding the > > internal editor + ncurses, the section which quotes > > the `addch' manpage. Also read the printf (3) manpage > > regarding the use of '*'. > > > > Might this help? Yes, but what happened with the two trailing spaces ? I thought they were supposed to be there. if (fname_len + gap < w) - printw ("%-*s ", w - (fname_len + gap), status); + printwstr (status, w - (fname_len + gap)); From me at pavelsh.pp.ru Mon Nov 1 09:46:36 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Mon, 1 Nov 2004 14:46:36 +0500 Subject: Once more tar.c ./files In-Reply-To: <4185EA04.10703@gmx.de> References: <1098999606.4813.38.camel@athlon.localdomain> <4185EA04.10703@gmx.de> Message-ID: <1302559707.20041101144636@pavelsh.pp.ru> Hello Roland, Monday, November 1, 2004, 12:47:16 PM, you wrote: >> While looking at Pavel's wiki >> (http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs) I remembered that >> the discussion about LGPLed VFS using GPL code was started because of >> the tar.c issue. Came across the entry "three bugs" with this reference: >> http://mail.gnome.org/archives/mc-devel/2004-April/msg00010.html . The >> last hunk is has a much more elegant solution to the ./file problem. >> Patch against current CVS attached. This effectively reverts the latest >> fixes to tar.c, but it works. RI> Tested with the appended file and committed. Thanks. These patches from Andriy Gritsenko http://mail.gnome.org/archives/mc-devel/2004-April/msg00010.html Sat, 17 Apr 2004 22:24:51 +0300 -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Mon Nov 1 12:13:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 01 Nov 2004 13:13:40 +0100 Subject: extfs/patchfs.in In-Reply-To: <4185F122.2060301@gmx.de> References: <4185F122.2060301@gmx.de> Message-ID: <1099311219.4786.7.camel@athlon.localdomain> Hello Roland, On Mon, 2004-11-01 at 09:17, Roland Illig wrote: > this patch allows to copyout and list patches for files with leading > "./" or "../". I'm not sure this is very useful, as I don't think diff is supposed to generate patches with trailing dot (dot) slash in their names. I don't think it is necessary to fix every artifact someone might think of, at least as long as it can't cause any harm (like overflows or the invocation of unwanted commands). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Nov 1 14:00:10 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 01 Nov 2004 15:00:10 +0100 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: <4185E76D.2030404@gmx.de> References: <1096813412.14121.1.camel@localhost> <1099269205.4814.49.camel@athlon.localdomain> <4185E76D.2030404@gmx.de> Message-ID: <1099317609.4786.23.camel@athlon.localdomain> Hello Roland, On Mon, 2004-11-01 at 08:36, Roland Illig wrote: > SLang (in this case mcslang) does not crash when resizing vertically to > $many lines. Rxvt only shows the first 300 lines (the rest is white), > and SLang only draws the first 256 lines of these. Maybe we should not fix mcslang yet, but replace it with slang-1.4.9 after the release of mc-4.6.1. However the version test that Pavel suggested to increase the number of lines for users that link against slang > 1.4.7 should be ok to add as a temporary fix. Patch attached. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: slint.c.diff Type: text/x-patch Size: 633 bytes Desc: not available URL: From ptsekov at gmx.net Mon Nov 1 12:22:01 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 1 Nov 2004 13:22:01 +0100 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: <1099317609.4786.23.camel@athlon.localdomain> References: <1096813412.14121.1.camel@localhost> <1099269205.4814.49.camel@athlon.localdomain> <4185E76D.2030404@gmx.de> <1099317609.4786.23.camel@athlon.localdomain> Message-ID: Hello, On Mon, 1 Nov 2004, Leonard den Ottolander wrote: > Maybe we should not fix mcslang yet, but replace it with slang-1.4.9 > after the release of mc-4.6.1. However the version test that Pavel > suggested to increase the number of lines for users that link against > slang > 1.4.7 should be ok to add as a temporary fix. Patch attached. http://savannah.gnu.org/cgi-bin/viewcvs/mc/mc/slang/ChangeLog.diff?r1=1.26&r2=1.27&sortby=date&diff_format=u It is already in. From leonard at den.ottolander.nl Mon Nov 1 14:56:57 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 01 Nov 2004 15:56:57 +0100 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: References: <1096813412.14121.1.camel@localhost> <1099269205.4814.49.camel@athlon.localdomain> <4185E76D.2030404@gmx.de> <1099317609.4786.23.camel@athlon.localdomain> Message-ID: <1099321017.4786.36.camel@athlon.localdomain> Hello Pavel, On Mon, 2004-11-01 at 13:22, Pavel Tsekov wrote: > > Maybe we should not fix mcslang yet, but replace it with slang-1.4.9 > > after the release of mc-4.6.1. > It is already in. The whole of slang-1.4.9 has been moved in I see. That seems like a bold move so close before the release. But that version check should also be added for those who link against an older external slang (and in general to increase the number of lines/columns). And pchel seems to have forgotten to update the wiki, or I would have known ;) . Let's hope this doesn't break too much. Maybe the replacement of the necessary files is all that is needed and this turns out to be a trivial fix. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Mon Nov 1 13:12:22 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 1 Nov 2004 14:12:22 +0100 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: <1099321017.4786.36.camel@athlon.localdomain> References: <1096813412.14121.1.camel@localhost> <1099269205.4814.49.camel@athlon.localdomain> <4185E76D.2030404@gmx.de> <1099317609.4786.23.camel@athlon.localdomain> <1099321017.4786.36.camel@athlon.localdomain> Message-ID: Hello, On Mon, 1 Nov 2004, Leonard den Ottolander wrote: > The whole of slang-1.4.9 has been moved in I see. That seems like a bold > move so close before the release. But that version check should also be > added for those who link against an older external slang (and in general > to increase the number of lines/columns). And pchel seems to have > forgotten to update the wiki, or I would have known ;) . > > Let's hope this doesn't break too much. Maybe the replacement of the > necessary files is all that is needed and this turns out to be a trivial > fix. Let's hope for the best! In any case if something is wrong we'll hear about that soon. From leonard at den.ottolander.nl Mon Nov 1 15:30:09 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 01 Nov 2004 16:30:09 +0100 Subject: Shift enter produces dot on command line Message-ID: <1099323009.4786.47.camel@athlon.localdomain> Hi, I see something odd when entering a shift-enter on the command line. A dot appears which seems not to be interpreted. Also the other characters that are typed afterwards are discarded. Vladimir, not sure if this only a problem with vanilla mc, but with the utf8 patches the same thing happens, but now the cursor moves one position backwards. As I say this might be fixed when vanilla mc is fixed but I thought I'd draw your attention to it anyway. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Mon Nov 1 13:42:42 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 1 Nov 2004 14:42:42 +0100 Subject: Shift enter produces dot on command line In-Reply-To: <1099323009.4786.47.camel@athlon.localdomain> References: <1099323009.4786.47.camel@athlon.localdomain> Message-ID: Hello, On Mon, 1 Nov 2004, Leonard den Ottolander wrote: > I see something odd when entering a shift-enter on the command line. A > dot appears which seems not to be interpreted. Also the other characters > that are typed afterwards are discarded. What is Shift+Enter supposed to do ? Under what kind of terminal do you run MC when this happens ? Maybe you terminal generates an escape sequnce for Shift + Enter and it must be filled in the list of keystrokes that should be ignored. From leonard at den.ottolander.nl Mon Nov 1 16:33:09 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 01 Nov 2004 17:33:09 +0100 Subject: Shift enter produces dot on command line In-Reply-To: References: <1099323009.4786.47.camel@athlon.localdomain> Message-ID: <1099326788.4786.57.camel@athlon.localdomain> Hello Pavel, On Mon, 2004-11-01 at 14:42, Pavel Tsekov wrote: > What is Shift+Enter supposed to do ? I don't know. I did this accidently (shift enter instead of shift backspace (pipe)). > Under what kind of terminal do you run MC when this happens ? xterm (TERM=xterm), gnome-terminal (TERM=xterm, COLORTERM=gnome-terminal) and console (TERM=linux). Don't you see it? Could be a termcap issue. I'll have to look at some other releases of FC (still running on FC1). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Mon Nov 1 22:29:33 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 01 Nov 2004 23:29:33 +0100 Subject: Shift enter produces dot on command line In-Reply-To: <1099323009.4786.47.camel@athlon.localdomain> References: <1099323009.4786.47.camel@athlon.localdomain> Message-ID: <4186B8CD.6040002@gmx.de> Leonard den Ottolander wrote: > Hi, > > I see something odd when entering a shift-enter on the command line. A > dot appears which seems not to be interpreted. Also the other characters > that are typed afterwards are discarded. Try to type the following: "echo '" & + & + & "' | hd | less" Let & be the concatenation operator, text in double quotes is to be entered verbatim. For me, it seems that + is a nice way to enter a "\n" string without executing the command. Very useful. Roland From ptsekov at gmx.net Tue Nov 2 09:07:56 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 2 Nov 2004 10:07:56 +0100 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: <1098982089.4813.10.camel@athlon.localdomain> References: <1098982089.4813.10.camel@athlon.localdomain> Message-ID: Hello, On Thu, 28 Oct 2004, Leonard den Ottolander wrote: > Hello Pavel, > > On Tue, 2004-10-26 at 10:25, Pavel Tsekov wrote: > > Attached is a patch to address this issue: > > http://mail.gnome.org/archives/mc-devel/2004-January/msg00007.html > > Patch indeed seems to fix the issue. I don't see any obvious regression. Please, test this update patch. It is a result of a discussion with Pavel Shirshov. ChangeLog: 2004-11-02 Pavel Tsekov * dialog.c (do_select_widget): Walk the whole widgets list looking for a widget accepting the focus. -------------- next part -------------- Index: dialog.c =================================================================== RCS file: /cvsroot/mc/mc/src/dialog.c,v retrieving revision 1.26 diff -u -p -r1.26 dialog.c --- dialog.c 24 Sep 2004 22:22:35 -0000 1.26 +++ dialog.c 2 Nov 2004 10:58:50 -0000 @@ -427,7 +427,7 @@ do_select_widget (Dlg_head *h, Widget *w return; h->current = w; - while (h->current != w0) { + do { if (dlg_focus (h)) break; @@ -443,7 +443,7 @@ do_select_widget (Dlg_head *h, Widget *w dlg_focus (h); return; } - } + } while (h->current != w); if (dlg_overlap (w0, h->current)) { send_message (h->current, WIDGET_DRAW, 0); From ptsekov at gmx.net Tue Nov 2 09:10:38 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 2 Nov 2004 10:10:38 +0100 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: References: <1098982089.4813.10.camel@athlon.localdomain> Message-ID: Forgot to mention that this patch is better because it avoids the risk of an endless loop. On Tue, 2 Nov 2004, Pavel Tsekov wrote: > Hello, > > On Thu, 28 Oct 2004, Leonard den Ottolander wrote: > > > Hello Pavel, > > > > On Tue, 2004-10-26 at 10:25, Pavel Tsekov wrote: > > > Attached is a patch to address this issue: > > > http://mail.gnome.org/archives/mc-devel/2004-January/msg00007.html > > > > Patch indeed seems to fix the issue. I don't see any obvious regression. > > Please, test this update patch. It is a result of a discussion with > Pavel Shirshov. > > ChangeLog: > > 2004-11-02 Pavel Tsekov > > * dialog.c (do_select_widget): Walk the whole widgets list looking > for a widget accepting the focus. From ptsekov at gmx.net Tue Nov 2 09:39:34 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 2 Nov 2004 10:39:34 +0100 Subject: Shift enter produces dot on command line In-Reply-To: References: <1099323009.4786.47.camel@athlon.localdomain> Message-ID: Hello, On Mon, 1 Nov 2004, Pavel Tsekov wrote: > Hello, > > On Mon, 1 Nov 2004, Leonard den Ottolander wrote: > > > I see something odd when entering a shift-enter on the command line. A > > dot appears which seems not to be interpreted. Also the other characters > > that are typed afterwards are discarded. > > What is Shift+Enter supposed to do ? Under what kind of terminal do you > run MC when this happens ? Maybe you terminal generates an escape sequnce > for Shift + Enter and it must be filled in the list of keystrokes that > should be ignored. Shift + Enter is passed to the command prompt widget. And is processed for some obscure reason by that code: cb_ret_t input_callback (WInput *in, widget_msg_t msg, int parm) { int v; switch (msg) { case WIDGET_KEY: if (parm == XCTRL ('q')) { quote = 1; v = handle_char (in, mi_getch ()); quote = 0; return v; } /* Keys we want others to handle */ if (parm == KEY_UP || parm == KEY_DOWN || parm == ESC_CHAR || parm == KEY_F (10) || parm == XCTRL ('g') || parm == '\n') return MSG_NOT_HANDLED; > /* When pasting multiline text, insert literal Enter */ > if ((parm & ~KEY_M_MASK) == '\n') { > quote = 1; > v = handle_char (in, '\n'); > quote = 0; > return v; > } return handle_char (in, parm); So you got the '.' because the '\n' is non-printable char. I don't know what Shift + Enter has to do with pasting though ?! From me at pavelsh.pp.ru Tue Nov 2 11:53:26 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 2 Nov 2004 16:53:26 +0500 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: References: <1098982089.4813.10.camel@athlon.localdomain> Message-ID: <299885482.20041102165326@pavelsh.pp.ru> Hello Pavel, Tuesday, November 2, 2004, 2:07:56 PM, you wrote: PT> Hello, PT> On Thu, 28 Oct 2004, Leonard den Ottolander wrote: >> Hello Pavel, >> >> On Tue, 2004-10-26 at 10:25, Pavel Tsekov wrote: >> > Attached is a patch to address this issue: >> > >> http://mail.gnome.org/archives/mc-devel/2004-January/msg00007.html >> >> Patch indeed seems to fix the issue. I don't see any obvious regression. PT> Please, test this update patch. It is a result of a discussion with PT> Pavel Shirshov. PT> ChangeLog: PT> 2004-11-02 Pavel Tsekov PT> * dialog.c (do_select_widget): Walk the whole widgets list looking PT> for a widget accepting the focus. Committed! Thx! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Tue Nov 2 12:13:55 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 02 Nov 2004 13:13:55 +0100 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: References: <1098982089.4813.10.camel@athlon.localdomain> Message-ID: <1099397635.4817.7.camel@athlon.localdomain> Hello Pavel, On Tue, 2004-11-02 at 10:10, Pavel Tsekov wrote: > Forgot to mention that this patch is better because it avoids > the risk of an endless loop. Yeah, pchel got this fear of an endless loop because of something you said in one of your mails. However, you wrote: "I get it that it is guaranteed to have at least one widget that accepts WIDGET_FOCUS. So an endless loop is unlikely to happen." If the above statement is true, then what is the need for this updated patch? Have you checked the code for the existence of a possible infinite loop? I haven't noticed it when testing the original patch. I somewhat have the feeling this new patch is redundant and pchel's fear is only based on a misunderstanding of what was written. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Tue Nov 2 12:36:58 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 2 Nov 2004 17:36:58 +0500 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: <1099397635.4817.7.camel@athlon.localdomain> References: <1098982089.4813.10.camel@athlon.localdomain> <1099397635.4817.7.camel@athlon.localdomain> Message-ID: <37036674.20041102173658@pavelsh.pp.ru> Hello Leonard, Tuesday, November 2, 2004, 5:13:55 PM, you wrote: LdO> On Tue, 2004-11-02 at 10:10, Pavel Tsekov wrote: >> Forgot to mention that this patch is better because it avoids >> the risk of an endless loop. LdO> Yeah, pchel got this fear of an endless loop because of something you LdO> said in one of your mails. However, you wrote: LdO> "I get it that it is guaranteed to have at least one widget that accepts LdO> WIDGET_FOCUS. So an endless loop is unlikely to happen." LdO> If the above statement is true, then what is the need for this updated LdO> patch? Have you checked the code for the existence of a possible LdO> infinite loop? I haven't noticed it when testing the original patch. I LdO> somewhat have the feeling this new patch is redundant and pchel's fear LdO> is only based on a misunderstanding of what was written. I excellent understand Pavel's letter. His patch was wrong. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From ptsekov at gmx.net Tue Nov 2 10:51:39 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 2 Nov 2004 11:51:39 +0100 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: <1099397635.4817.7.camel@athlon.localdomain> References: <1098982089.4813.10.camel@athlon.localdomain> <1099397635.4817.7.camel@athlon.localdomain> Message-ID: Hello Leonard, On Tue, 2 Nov 2004, Leonard den Ottolander wrote: > Hello Pavel, > > On Tue, 2004-11-02 at 10:10, Pavel Tsekov wrote: > > Forgot to mention that this patch is better because it avoids > > the risk of an endless loop. > > Yeah, pchel got this fear of an endless loop because of something you > said in one of your mails. However, you wrote: > > "I get it that it is guaranteed to have at least one widget that accepts > WIDGET_FOCUS. So an endless loop is unlikely to happen." > > If the above statement is true, then what is the need for this updated > patch? Have you checked the code for the existence of a possible > infinite loop? I haven't noticed it when testing the original patch. I > somewhat have the feeling this new patch is redundant and pchel's fear > is only based on a misunderstanding of what was written. Me and Pavel Shirshov both agree that this new patch is indeed better. What I wrote in the mail describing the problem is based on me reading the source code, but there aren't any comments or something else to proof that I was right. The new code introduced by Pavel Rosking seemed to try to avoid an endless loop too. I think the new code is clear, fool proof and better. From leonard at den.ottolander.nl Tue Nov 2 12:53:13 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 02 Nov 2004 13:53:13 +0100 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: References: <1098982089.4813.10.camel@athlon.localdomain> <1099397635.4817.7.camel@athlon.localdomain> Message-ID: <1099399993.4817.16.camel@athlon.localdomain> Hello Pavel, On Tue, 2004-11-02 at 11:51, Pavel Tsekov wrote: > Me and Pavel Shirshov both agree that this new patch is indeed better. > What I wrote in the mail describing the problem is based on me reading the > source code, but there aren't any comments or something else to proof > that I was right. The new code introduced by Pavel Rosking seemed to try > to avoid an endless loop too. I think the new code is clear, fool proof > and better. I don't say the new code is bad, I only wonder why you haven't checked the rest of the code to make sure whether your original statement about at least one item accepting WIDGET_CODE is correct. If that statement is true you have introduced a redundant check for a situation that will never occur. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Nov 2 12:59:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 02 Nov 2004 13:59:27 +0100 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: <37036674.20041102173658@pavelsh.pp.ru> References: <1098982089.4813.10.camel@athlon.localdomain> <1099397635.4817.7.camel@athlon.localdomain> <37036674.20041102173658@pavelsh.pp.ru> Message-ID: <1099400366.4817.19.camel@athlon.localdomain> Hello Pavel, On Tue, 2004-11-02 at 13:36, Pavel Shirshov (pchel) wrote: > I excellent understand Pavel's letter. His patch was wrong. As long as you haven't proven that there are situations where none of the items accepts WIDGET_FOCUS the above statement is not true. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Tue Nov 2 11:13:27 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 2 Nov 2004 12:13:27 +0100 Subject: [PATCH]: menu doesn't appear on right info panel In-Reply-To: <1099399993.4817.16.camel@athlon.localdomain> References: <1098982089.4813.10.camel@athlon.localdomain> <1099397635.4817.7.camel@athlon.localdomain> <1099399993.4817.16.camel@athlon.localdomain> Message-ID: Hello Leonard, On Tue, 2 Nov 2004, Leonard den Ottolander wrote: > On Tue, 2004-11-02 at 11:51, Pavel Tsekov wrote: > > Me and Pavel Shirshov both agree that this new patch is indeed better. > > What I wrote in the mail describing the problem is based on me reading the > > source code, but there aren't any comments or something else to proof > > that I was right. The new code introduced by Pavel Rosking seemed to try > > to avoid an endless loop too. I think the new code is clear, fool proof > > and better. > > I don't say the new code is bad, I only wonder why you haven't checked > the rest of the code to make sure whether your original statement about > at least one item accepting WIDGET_CODE is correct. If that statement is It would be a hard task to proof it - really. But I tell you - it worked that way for quite some time :) > true you have introduced a redundant check for a situation that will > never occur. No - we don't know what kind of a dialog would be introduced in the future. And it is not indicated clearly that a dialog should have at least one widget wich accepts focus. From nerijus at users.sourceforge.net Tue Nov 2 13:18:06 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Tue, 2 Nov 2004 15:18:06 +0200 (EET) Subject: building on AIX In-Reply-To: <4185F299.5060509@gmx.de> References: <20041023143255.0CD41508412@mx.ktv.lt> <417AA819.8070302@gmx.de> <20041028201844.2F4365087FE@mx.ktv.lt> <4185F299.5060509@gmx.de> Message-ID: <20041102131826.78C7650816E@mx.ktv.lt> On Mon, 01 Nov 2004 09:23:53 +0100 Roland Illig wrote: > > While running configure I saw: > > checking for socklen_t... no > > I have successfully built mc on AIX, and here is the patch I wrote for > it. Please try if it works for you, too. Yes, it works, no more warnings, thanks. Regards, Nerijus From nadvornik at suse.cz Tue Nov 2 15:40:53 2004 From: nadvornik at suse.cz (Vladimir Nadvornik) Date: Tue, 2 Nov 2004 16:40:53 +0100 Subject: UTF-8 warnings In-Reply-To: <1099409319.4817.121.camel@athlon.localdomain> References: <1099409319.4817.121.camel@athlon.localdomain> Message-ID: <200411021640.53617.nadvornik@suse.cz> On Tuesday 02 November 2004 16:28, Leonard den Ottolander wrote: > Also 1 "discard qualifier" warning in help.c. But "Unconsting" p in > help_show() does not fix this as p points to const char* paint_start. > Introducing a (redundant) cast on the call of SLsmg_write_nchars() in > the utf8-help patch. This should actually be fixed in slang. > This version of the patch compiles without warning. -- Vladimir Nadvornik developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: nadvornik at suse.cz Drahobejlova 27 tel:+420 2 9654 2373 190 00 Praha 9 fax:+420 2 9654 2374 Ceska republika http://www.suse.cz -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-utf8-help.patch Type: text/x-diff Size: 1073 bytes Desc: not available URL: From nerijus at users.sourceforge.net Tue Nov 2 18:12:06 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Tue, 2 Nov 2004 20:12:06 +0200 (EET) Subject: text selection problem Message-ID: <20041102181052.6BAD8508381@mx.ktv.lt> Hello, I am using mc from cvs compiled with included slang on AIX. If I run mc w/o any parameters, I get black and white display, but selecting text in either viewer or editor selects it correctly with EOLs. When I run mc -c, I get colour display, but selecting text selects it w/o EOLs and instead filled with spaces at the end of lines. mc --help says that -c means 'Request to run in color mode'. Why such request affects text selecting? Regards, Nerijus From leonard at den.ottolander.nl Tue Nov 2 15:28:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 02 Nov 2004 16:28:40 +0100 Subject: UTF-8 warnings Message-ID: <1099409319.4817.121.camel@athlon.localdomain> Hello Vladimir, Jindrich, I'm seeing some warnings against current CVS with the UTF-8 patches. 4 "discards qualifier"s in file.c that are fixed by removing the const qualifier from fnsource in the utf8-fix patch. Also 1 "discard qualifier" warning in help.c. But "Unconsting" p in help_show() does not fix this as p points to const char* paint_start. Introducing a (redundant) cast on the call of SLsmg_write_nchars() in the utf8-help patch. This should actually be fixed in slang. And the last warning is: "screen.c:580: warning: passing arg 1 of `wcswidth' from incompatible pointer type" which I fixed by casting buffer to wchar_t in the utf8-fix patch. Should txtlen be typed to size_t instead of int? Or would this interfere with some of the assignments elsewhere in that code? Also removed some redundant tabs and spaces on added "empty" lines in the utf8-input patch, as well as a non ANSI compliant comment and variable declarations. Attached the whole bundle of UTF-8 patches. (These are not meant as a proposal for upstream inclusion (yet), but FYI.) Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-8bitdefault.patch Type: text/x-patch Size: 361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-utf8-fix.patch Type: text/x-patch Size: 8896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-utf8-help.patch Type: text/x-patch Size: 1094 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-utf8-hint.patch Type: text/x-patch Size: 1729 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-utf8-input.patch Type: text/x-patch Size: 84846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-utf8.patch Type: text/x-patch Size: 45982 bytes Desc: not available URL: From jnovy at redhat.com Wed Nov 3 09:22:10 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 03 Nov 2004 10:22:10 +0100 Subject: subshell prompt fix Message-ID: <1099473730.19714.18.camel@localhost.localdomain> Hello, this simple one-liner fixes the following cases: a) subshell prompt is drawn at the same line after chdir in mc b) frequently subshell prompt after C-o isn't drawn at the first column in a terminal but at random position to reproduce a): 1) run mc, chdir to /usr/share 2) C-o 3) C-o again and chdir to /usr/share/doc 4) C-o in 2) you see: [jnovy at obelix share]$ in 4) you see: [jnovy at obelix share]$ [jnovy at obelix doc]$ greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041103-promptfix.patch Type: text/x-patch Size: 346 bytes Desc: not available URL: From me at pavelsh.pp.ru Wed Nov 3 10:29:39 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 3 Nov 2004 15:29:39 +0500 Subject: subshell prompt fix In-Reply-To: <1099473730.19714.18.camel@localhost.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> Message-ID: <178535947.20041103152939@pavelsh.pp.ru> Hello Jindrich, Wednesday, November 3, 2004, 2:22:10 PM, you wrote: JN> Hello, JN> this simple one-liner fixes the following cases: JN> a) subshell prompt is drawn at the same line after chdir in mc JN> b) frequently subshell prompt after C-o isn't drawn at the first column JN> in a terminal but at random position JN> to reproduce a): JN> 1) run mc, chdir to /usr/share JN> 2) C-o JN> 3) C-o again and chdir to /usr/share/doc JN> 4) C-o JN> in 2) you see: [jnovy at obelix share]$ JN> in 4) you see: [jnovy at obelix share]$ [jnovy at obelix doc]$ I can't reproduce this. But. I see another: 1) run mc 2) C-o 3) C-o again 4) C-o 2) you see: genie# 4) you see: ^^^^^^^^^^^ I can't see promt. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From jnovy at redhat.com Wed Nov 3 11:03:25 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 03 Nov 2004 12:03:25 +0100 Subject: subshell prompt fix In-Reply-To: <178535947.20041103152939@pavelsh.pp.ru> References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> Message-ID: <1099479805.19714.103.camel@localhost.localdomain> On Wed, 2004-11-03 at 11:29, Pavel Shirshov (pchel) wrote: > I can't reproduce this. I was able to reproduce this also with CVS version checked out today. > But. I see another: > 1) run mc > 2) C-o > 3) C-o again > 4) C-o > > 2) you see: genie# > 4) you see: > ^^^^^^^^^^^ I can't see promt. Weird, I'm unable to reproduce your case, which terminal do you use? It's smoothly reproducible with gnome-terminal and xterm, I haven't tried rxvt. Do you chdir in steps 2) and 4) ? -- Jindrich Novy , http://people.redhat.com/jnovy/ From ptsekov at gmx.net Wed Nov 3 10:35:05 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 3 Nov 2004 11:35:05 +0100 Subject: subshell prompt fix In-Reply-To: <1099479805.19714.103.camel@localhost.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> <1099479805.19714.103.camel@localhost.localdomain> Message-ID: Hello, On Wed, 3 Nov 2004, Jindrich Novy wrote: > On Wed, 2004-11-03 at 11:29, Pavel Shirshov (pchel) wrote: > > I can't reproduce this. > > I was able to reproduce this also with CVS version checked out today. > > > But. I see another: > > 1) run mc > > 2) C-o > > 3) C-o again > > 4) C-o > > > > 2) you see: genie# > > 4) you see: > > ^^^^^^^^^^^ I can't see promt. > > Weird, I'm unable to reproduce your case, which terminal do you use? > It's smoothly reproducible with gnome-terminal and xterm, I haven't > tried rxvt. Do you chdir in steps 2) and 4) ? I was able to reproduce this behaviour with both 4.6.0 from FC2 and current cvs on FC2. On Cygwin I've used the current cvs only. On FC2 I've tested under gnome-terminal and linux console - with linux consle it didn't happen. On Cygwin I've tested with Cygwin console, rxvt (both native windowing and X) and xterm and it happens with in all cases. The shell is bash. From leonard at den.ottolander.nl Wed Nov 3 13:03:16 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 14:03:16 +0100 Subject: subshell prompt fix In-Reply-To: <1099479805.19714.103.camel@localhost.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> <1099479805.19714.103.camel@localhost.localdomain> Message-ID: <1099486996.4819.55.camel@athlon.localdomain> Hello Jindrich, On Wed, 2004-11-03 at 12:03, Jindrich Novy wrote: > I was able to reproduce this also with CVS version checked out today. Is that with or without applied utf8 patches? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jnovy at redhat.com Wed Nov 3 13:13:53 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 03 Nov 2004 14:13:53 +0100 Subject: subshell prompt fix In-Reply-To: <1099486996.4819.55.camel@athlon.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> <1099479805.19714.103.camel@localhost.localdomain> <1099486996.4819.55.camel@athlon.localdomain> Message-ID: <1099487633.19714.187.camel@localhost.localdomain> Hello Leonard, On Wed, 2004-11-03 at 14:03, Leonard den Ottolander wrote: > Hello Jindrich, > > On Wed, 2004-11-03 at 12:03, Jindrich Novy wrote: > > I was able to reproduce this also with CVS version checked out today. > > Is that with or without applied utf8 patches? I meant pure unpatched version. Note that the bug occurs since at least mc-4.5.51 (tested). Leonard, Pavel has problems reproducing the bug, are you able to reproduce this and eventually the case Pavel presented? greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From leonard at den.ottolander.nl Wed Nov 3 13:24:49 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 14:24:49 +0100 Subject: show_dir crashes on more than 200 columns Message-ID: <1099488288.4819.68.camel@athlon.localdomain> Hi, A small fix to avoid a crash in show_dir() with a panel of more than 200 columns. Thanks to Vladimir. (Jindrich, a g_malloc0 and a free of tmp[] seem rather redundant here.) Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: screen.c.diff Type: text/x-patch Size: 649 bytes Desc: not available URL: From ptsekov at gmx.net Wed Nov 3 11:50:25 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 3 Nov 2004 12:50:25 +0100 Subject: show_dir crashes on more than 200 columns In-Reply-To: <1099488288.4819.68.camel@athlon.localdomain> References: <1099488288.4819.68.camel@athlon.localdomain> Message-ID: Hello, On Wed, 3 Nov 2004, Leonard den Ottolander wrote: > A small fix to avoid a crash in show_dir() with a panel of more than 200 > columns. Thanks to Vladimir. > > (Jindrich, a g_malloc0 and a free of tmp[] seem rather redundant here.) No, it is not. You cannot rely on MC_MAXPATHLEN - it can be too small or too big. For exmaple on Cygwin it is set to 259 . I remeber I've seen also pretty big values for MAXPATHLEN which are not suitable for allocating on the stack. Use the `widget.cols' and allocate memory from the heap. From leonard at den.ottolander.nl Wed Nov 3 14:05:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 15:05:27 +0100 Subject: show_dir crashes on more than 200 columns In-Reply-To: References: <1099488288.4819.68.camel@athlon.localdomain> Message-ID: <1099490727.4819.96.camel@athlon.localdomain> Hi Pavel, On Wed, 2004-11-03 at 12:50, Pavel Tsekov wrote: > No, it is not. You cannot rely on MC_MAXPATHLEN - it can be too small or > too big. For exmaple on Cygwin it is set to 259 . I remeber I've seen > also pretty big values for MAXPATHLEN which are not suitable for > allocating on the stack. Use the `widget.cols' and allocate memory from > the heap. Ok. Restored to original code from Jindrich. See attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: screen.c.diff Type: text/x-patch Size: 745 bytes Desc: not available URL: From ptsekov at gmx.net Wed Nov 3 12:23:07 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 3 Nov 2004 13:23:07 +0100 Subject: show_dir crashes on more than 200 columns In-Reply-To: <1099490727.4819.96.camel@athlon.localdomain> References: <1099488288.4819.68.camel@athlon.localdomain> <1099490727.4819.96.camel@athlon.localdomain> Message-ID: Hello Leonard, On Wed, 3 Nov 2004, Leonard den Ottolander wrote: > Ok. Restored to original code from Jindrich. See attached patch. Shouldn't this ` tmp = g_malloc0(MC_MAXPATHLEN) ' be `tmp = g_malloc0(panel->widget.cols)' ? From nadvornik at suse.cz Wed Nov 3 14:46:08 2004 From: nadvornik at suse.cz (Vladimir Nadvornik) Date: Wed, 3 Nov 2004 15:46:08 +0100 Subject: 8bit default Message-ID: <200411031546.08166.nadvornik@suse.cz> Hi, I think that mc should use 8bit input by default. It is useful for most languages and I don't know about any disadvantages. Please see the attached patch. -- Vladimir Nadvornik developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: nadvornik at suse.cz Drahobejlova 27 tel:+420 2 9654 2373 190 00 Praha 9 fax:+420 2 9654 2374 Ceska republika http://www.suse.cz -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-8bitdefault.patch Type: text/x-diff Size: 361 bytes Desc: not available URL: From jnovy at redhat.com Wed Nov 3 14:55:45 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 03 Nov 2004 15:55:45 +0100 Subject: show_dir crashes on more than 200 columns In-Reply-To: References: <1099488288.4819.68.camel@athlon.localdomain> Message-ID: <1099493745.19714.231.camel@localhost.localdomain> Hello Leonard, Pavel, On Wed, 2004-11-03 at 12:50, Pavel Tsekov wrote: > Hello, > > On Wed, 3 Nov 2004, Leonard den Ottolander wrote: > > > A small fix to avoid a crash in show_dir() with a panel of more than 200 > > columns. Thanks to Vladimir. > > > > (Jindrich, a g_malloc0 and a free of tmp[] seem rather redundant here.) > > No, it is not. You cannot rely on MC_MAXPATHLEN - it can be too small or > too big. For exmaple on Cygwin it is set to 259 . I remeber I've seen > also pretty big values for MAXPATHLEN which are not suitable for > allocating on the stack. Use the `widget.cols' and allocate memory from > the heap. The widget.cols is IMHO the best solution since we're not wasting any memory. Corrected patch attached. greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041103-show_dir.patch Type: text/x-patch Size: 848 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Nov 3 15:08:07 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 16:08:07 +0100 Subject: show_dir crashes on more than 200 columns In-Reply-To: <1099493745.19714.231.camel@localhost.localdomain> References: <1099488288.4819.68.camel@athlon.localdomain> <1099493745.19714.231.camel@localhost.localdomain> Message-ID: <1099494486.4819.112.camel@athlon.localdomain> Hello Jindrich, Pavel, On Wed, 2004-11-03 at 15:55, Jindrich Novy wrote: > > Use the `widget.cols' and allocate memory from the heap. > > The widget.cols is IMHO the best solution since we're not wasting any > memory. Ok. I will base the uglydir patch on this one then. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 3 15:14:56 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 16:14:56 +0100 Subject: show_dir crashes on more than 200 columns In-Reply-To: <1099493745.19714.231.camel@localhost.localdomain> References: <1099488288.4819.68.camel@athlon.localdomain> <1099493745.19714.231.camel@localhost.localdomain> Message-ID: <1099494896.4819.118.camel@athlon.localdomain> Hi, On Wed, 2004-11-03 at 15:55, Jindrich Novy wrote: > The widget.cols is IMHO the best solution since we're not wasting any > memory. Corrected patch attached. Guys, please take care with introducing unnecessary white space. There is some of this in the above mentioned patch, fixed in attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041103-show_dir.patch Type: text/x-patch Size: 845 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Nov 3 15:20:16 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 16:20:16 +0100 Subject: uglydir patch Message-ID: <1099495216.4819.121.camel@athlon.localdomain> Hi, Attached you find the uglydir patch, against my last show_dir patch. Jindrich, can you write a changelog entry for this patch? Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-uglydir.patch Type: text/x-patch Size: 1589 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Nov 3 15:36:51 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 16:36:51 +0100 Subject: uglydir patch In-Reply-To: <1099495216.4819.121.camel@athlon.localdomain> References: <1099495216.4819.121.camel@athlon.localdomain> Message-ID: <1099496210.4819.129.camel@athlon.localdomain> Hi, Spacing in the previous version was ugly, and also the code style for function calls inconsistent. Cleaned up version attached. Can we come to an agreement on coding style? People use both function (params); and function(params); sometimes both styles in one patch. This is ugly. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-uglydir.patch Type: text/x-patch Size: 1458 bytes Desc: not available URL: From me at pavelsh.pp.ru Wed Nov 3 15:39:51 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 3 Nov 2004 20:39:51 +0500 Subject: Status of FTP password hiding patches In-Reply-To: <1098894040.25673.24.camel@localhost.localdomain> References: <1098792290.4815.19.camel@athlon.localdomain> <1098894040.25673.24.camel@localhost.localdomain> Message-ID: <1237861000.20041103203951@pavelsh.pp.ru> Hello Jindrich, Wednesday, October 27, 2004, 9:20:41 PM, you wrote: JN> On Tue, 2004-10-26 at 14:04, Leonard den Ottolander wrote: >> I would like to know what the status of the various FTP password hiding >> patches is. Together with the quoting issues in vfs/extfs I believe this >> to be the only issue that needs to be fixed before the release of 4.6.1. JN> Hi, JN> I fixed the possible memory leak regarding label_string found by Andrew JN> V. Samoilov, see bug 131088 in Red Hat bugzilla. To test this patch, JN> create an user "test" for example, set his password to "testpass", JN> change your cwd by "cd /#ftp:test:testpass at localhost" and: JN> - try to upload a file to this directory and note the password is JN> removed. Copy, error and other dialogs display "/#ftp:test at localhost" JN> - try to add the new ftp directory to directory hotlist, password will JN> be also removed JN> - try to find any dialog where the password is displayed JN> I tested it and was unable to find any dialog that still shows a JN> password in it. The patch is cleanly applicable to 20th Oct mc CVS JN> snapshot. JN> HTH, JN> Jindrich ----------- $ patch -p2 < mc-CVS-strippwd.patch ----------- -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Wed Nov 3 15:41:34 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 3 Nov 2004 20:41:34 +0500 Subject: Status of FTP password hiding patches In-Reply-To: <1098894040.25673.24.camel@localhost.localdomain> References: <1098792290.4815.19.camel@athlon.localdomain> <1098894040.25673.24.camel@localhost.localdomain> Message-ID: <877372144.20041103204134@pavelsh.pp.ru> Hello Jindrich, Wednesday, October 27, 2004, 9:20:41 PM, you wrote: JN> On Tue, 2004-10-26 at 14:04, Leonard den Ottolander wrote: >> I would like to know what the status of the various FTP password hiding >> patches is. Together with the quoting issues in vfs/extfs I believe this >> to be the only issue that needs to be fixed before the release of 4.6.1. JN> Hi, JN> I fixed the possible memory leak regarding label_string found by Andrew JN> V. Samoilov, see bug 131088 in Red Hat bugzilla. To test this patch, JN> create an user "test" for example, set his password to "testpass", JN> change your cwd by "cd /#ftp:test:testpass at localhost" and: JN> - try to upload a file to this directory and note the password is JN> removed. Copy, error and other dialogs display "/#ftp:test at localhost" JN> - try to add the new ftp directory to directory hotlist, password will JN> be also removed JN> - try to find any dialog where the password is displayed JN> I tested it and was unable to find any dialog that still shows a JN> password in it. The patch is cleanly applicable to 20th Oct mc CVS JN> snapshot. I'm sorry for previous letter. Please update your patch against current cvs. Failed hunks in filegui.c is very strange. -------- $ patch -p2 < mc-CVS-strippwd.patch ...... Patching file filegui.c using Plan A... Hunk #1 failed at 68. Hunk #8 failed at 907. .......... Patching file hotlist.c using Plan A... Hunk #4 failed at 1008. -------- -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Wed Nov 3 15:54:44 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 16:54:44 +0100 Subject: Status of FTP password hiding patches In-Reply-To: <877372144.20041103204134@pavelsh.pp.ru> References: <1098792290.4815.19.camel@athlon.localdomain> <1098894040.25673.24.camel@localhost.localdomain> <877372144.20041103204134@pavelsh.pp.ru> Message-ID: <1099497284.4819.141.camel@athlon.localdomain> Hello Pavel, On Wed, 2004-11-03 at 16:41, Pavel Shirshov (pchel) wrote: > $ patch -p2 < mc-CVS-strippwd.patch > ...... > Patching file filegui.c using Plan A... > Hunk #1 failed at 68. Trivial fix. tty.h is no longer included. Insert after #include key.h. > Hunk #8 failed at 907. So the freeing of def_text was dropped, as this is a function parameter. Reintroduce the brackets and add the g_free(def_text_secure) in this block and right below it. Rather trivial fix as well. > Patching file hotlist.c using Plan A... > Hunk #4 failed at 1008. Little mistake from Jindrich. UTF-8 patched mc uses mbstrlen, vanilla CVS strlen. Insert by hand in the same place. Just removing "mb" from mbstrlen might do the trick. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 3 15:59:51 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 16:59:51 +0100 Subject: Status of FTP password hiding patches In-Reply-To: <1099497284.4819.141.camel@athlon.localdomain> References: <1098792290.4815.19.camel@athlon.localdomain> <1098894040.25673.24.camel@localhost.localdomain> <877372144.20041103204134@pavelsh.pp.ru> <1099497284.4819.141.camel@athlon.localdomain> Message-ID: <1099497591.4819.146.camel@athlon.localdomain> Hi, I wrote: > > Hunk #1 failed at 68. > > Trivial fix. tty.h is no longer included. Insert after #include key.h. Sorry. tty.h is probably also only included in UTF-8. Above fix still applies. > > Hunk #8 failed at 907. > > So the freeing of def_text was dropped, as this is a function parameter. > Reintroduce the brackets and add the g_free(def_text_secure) in this > block and right below it. Rather trivial fix as well. def_text wasn't dropped either, but is a UTF-8 introduction. Above fix still applies. Looks like I'll have to fix the UTF-8 patches after this commit. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jnovy at redhat.com Wed Nov 3 16:21:34 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 03 Nov 2004 17:21:34 +0100 Subject: Status of FTP password hiding patches In-Reply-To: <1099497284.4819.141.camel@athlon.localdomain> References: <1098792290.4815.19.camel@athlon.localdomain> <1098894040.25673.24.camel@localhost.localdomain> <877372144.20041103204134@pavelsh.pp.ru> <1099497284.4819.141.camel@athlon.localdomain> Message-ID: <1099498894.19714.237.camel@localhost.localdomain> Hello Pavel, Leonard, On Wed, 2004-11-03 at 16:54, Leonard den Ottolander wrote: > Hello Pavel, > > On Wed, 2004-11-03 at 16:41, Pavel Shirshov (pchel) wrote: > > $ patch -p2 < mc-CVS-strippwd.patch > > ...... > > Patching file filegui.c using Plan A... > > Hunk #1 failed at 68. > > Trivial fix. tty.h is no longer included. Insert after #include key.h. > > > Hunk #8 failed at 907. > > So the freeing of def_text was dropped, as this is a function parameter. > Reintroduce the brackets and add the g_free(def_text_secure) in this > block and right below it. Rather trivial fix as well. > > > Patching file hotlist.c using Plan A... > > Hunk #4 failed at 1008. > > Little mistake from Jindrich. UTF-8 patched mc uses mbstrlen, vanilla > CVS strlen. Insert by hand in the same place. Just removing "mb" from > mbstrlen might do the trick. Exactly as Leonard have said. Here comes the fixed patch applicable to the vanilla CVS. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-strippwd.patch Type: text/x-patch Size: 10802 bytes Desc: not available URL: From andrew at email.zp.ua Wed Nov 3 18:59:27 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 3 Nov 2004 20:59:27 +0200 (EET) Subject: file.c issue Message-ID: <200411031859.iA3IxRnG085707@email.zp.ua> Hello, -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file.c.patch URL: From leonard at den.ottolander.nl Wed Nov 3 20:53:41 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 21:53:41 +0100 Subject: strip_passwd partial commit Message-ID: <1099515221.4819.153.camel@athlon.localdomain> Hello pchel, Just read on IRC that you did a partial commit of the strip_passwd patch. Could you please explain what parts you didn't commit (yet) and for what reason? Then people can explain them. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 3 22:30:23 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 23:30:23 +0100 Subject: QNX patches Message-ID: <1099521023.15681.6.camel@athlon.localdomain> Hi pchel, I see you committed some changes involving QNX. Did you have contact with Mike Gorchak about these? Anything interesting discussed? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 3 22:32:22 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 23:32:22 +0100 Subject: file.c issue In-Reply-To: <200411031859.iA3IxRnG085707@email.zp.ua> References: <200411031859.iA3IxRnG085707@email.zp.ua> Message-ID: <1099521141.15681.9.camel@athlon.localdomain> On Wed, 2004-11-03 at 19:59, Andrew V. Samoilov wrote: > Hello, Patch was committed by pchel today. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 3 22:32:41 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 03 Nov 2004 23:32:41 +0100 Subject: show_dir crashes on more than 200 columns In-Reply-To: <1099494896.4819.118.camel@athlon.localdomain> References: <1099488288.4819.68.camel@athlon.localdomain> <1099493745.19714.231.camel@localhost.localdomain> <1099494896.4819.118.camel@athlon.localdomain> Message-ID: <1099521160.15681.11.camel@athlon.localdomain> Hi, Patch was committed by pchel today. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From lestat at i.com.ua Thu Nov 4 05:40:25 2004 From: lestat at i.com.ua (Mike V. Gorchak) Date: Thu, 4 Nov 2004 07:40:25 +0200 Subject: QNX patches References: <1099521023.15681.6.camel@athlon.localdomain> Message-ID: <00d001c4c230$c9f0d980$0d00200a@zero.priv.malva.com.ua> Hello, Leonard! LdO> I see you committed some changes involving QNX. Did you have contact LdO> with Mike Gorchak about these? It's my patches :) LdO> Anything interesting discussed? The main features: 1) mc.qpg.in: Synchronization with the latest files which has been added to the distro. 2) dir.c, file.c, fs.h, screen.c, util.c, cpio.c: Added initial support for the Special Named Files. They are displayed as block devices, but with '#' prefix in it's names, while showing in the directory list. Special Named Files in QNX6 - are the generic devices, which can be pipes, fifos, block and character devices by functionality, i.e. drivers without any discipline :) 3) pipethrough.c: Added sys/select.h if found according to config.h, because used fd_set, but sys/select.h is not included. btw, why pipethrough.3 is installed in the man directory ? Why it needed there ? 4) Syntax: Treat QNX6 specific files with extensions qpg and qpg.in as xml files. More to come :) With best regards, Mike V. Gorchak. E-mail: lestat at i.com.ua From me at pavelsh.pp.ru Thu Nov 4 05:42:08 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 4 Nov 2004 10:42:08 +0500 Subject: file.c issue In-Reply-To: <200411031859.iA3IxRnG085707@email.zp.ua> References: <200411031859.iA3IxRnG085707@email.zp.ua> Message-ID: <12088148.20041104104208@pavelsh.pp.ru> Hello Andrew, Wednesday, November 3, 2004, 11:59:27 PM, you wrote: AVS> Hello, Committed. Thx. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Thu Nov 4 05:43:33 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 4 Nov 2004 10:43:33 +0500 Subject: QNX patches In-Reply-To: <1099521023.15681.6.camel@athlon.localdomain> References: <1099521023.15681.6.camel@athlon.localdomain> Message-ID: <235979220.20041104104333@pavelsh.pp.ru> Hello Leonard, Thursday, November 4, 2004, 3:30:23 AM, you wrote: LdO> I see you committed some changes involving QNX. Did you have contact LdO> with Mike Gorchak about these? Anything interesting discussed? Patches are trivial. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Thu Nov 4 05:47:24 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 4 Nov 2004 10:47:24 +0500 Subject: strip_passwd partial commit In-Reply-To: <1099515221.4819.153.camel@athlon.localdomain> References: <1099515221.4819.153.camel@athlon.localdomain> Message-ID: <1562934082.20041104104724@pavelsh.pp.ru> Hello Leonard, Thursday, November 4, 2004, 1:53:41 AM, you wrote: LdO> Just read on IRC that you did a partial commit of the strip_passwd LdO> patch. Could you please explain what parts you didn't commit (yet) and LdO> for what reason? Then people can explain them. Ok. I didn't patch: hotlist.c - need some testing and improvements. I want to save full url (with password), but display title without password. util.c(strip_password()) - need some additional testing. For example around: - at = strrchr (p, '@'); + at = memchr (p, '@', host_len); It's not equal operations. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From nadvornik at suse.cz Thu Nov 4 10:58:50 2004 From: nadvornik at suse.cz (Vladimir Nadvornik) Date: Thu, 4 Nov 2004 11:58:50 +0100 Subject: rar archives with password Message-ID: <200411041158.50180.nadvornik@suse.cz> Hi, urar virtual filesystem hangs on archives with password. This patch adds an option -p- to unrar to disable password prompt. I couldn't test it with rar. -- Vladimir Nadvornik developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: nadvornik at suse.cz Drahobejlova 27 tel:+420 2 9654 2373 190 00 Praha 9 fax:+420 2 9654 2374 Ceska republika http://www.suse.cz -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-unrar-passwd.patch Type: text/x-diff Size: 457 bytes Desc: not available URL: From jnovy at redhat.com Thu Nov 4 13:48:15 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 04 Nov 2004 14:48:15 +0100 Subject: strip_passwd partial commit In-Reply-To: <1562934082.20041104104724@pavelsh.pp.ru> References: <1099515221.4819.153.camel@athlon.localdomain> <1562934082.20041104104724@pavelsh.pp.ru> Message-ID: <1099576095.24625.112.camel@localhost.localdomain> Hello Pavel, On Thu, 2004-11-04 at 06:47, Pavel Shirshov (pchel) wrote: > I didn't patch: > > hotlist.c - need some testing and improvements. I want to save > full url (with password), but display title without password. Note that it would introduce a possible security issue to mc. Because of the fact we're saving directory hotlist to ~/.mc/hotlist, superuser could read for instance ftp URLs with passwords since he has access to home directories of all the users. OTOH the next possible solution is to keep the URLs in ~/.mc/hotlist with passwords stripped and prompt an user for password first time, keep it in memory and for later connections simply add the password to URL from memory so an user needn't to type the password again. In my opinion the only secure solution is not to save URLs with passwords at all. So I decided to not implement such feature in the patch. > util.c(strip_password()) - need some additional testing. For > example around: > - at = strrchr (p, '@'); > + at = memchr (p, '@', host_len); > > It's not equal operations. Yes, they're not equal, because I changed the password stripping strategy (see also the condition above this line), because of this bug in strip_password (): It strips not only the password but everything after first PATH_SEP, so: jamesbond:007 at ci5.uk/home/secret/ is after strip_password (): jamesbond at ci5.uk what is also incorrectly written to histories, where the directory on ci5.uk is simply cut out. It's because of the fact that after: strcpy (inner_colon, at); dir points somewhere else than before, so an attempt to return the '/' to its original position: if (dir) *dir = PATH_SEP; of course fails. This is fixed in the implementation presented in the patch, furthermore with using memchr/memmove functions we needn't to write any chars into the char *p, which is also the argument of strip_password () and thus no such bug could occur again. [tested] greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From jnovy at redhat.com Thu Nov 4 14:18:10 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 04 Nov 2004 15:18:10 +0100 Subject: uglydir patch In-Reply-To: <1099495216.4819.121.camel@athlon.localdomain> References: <1099495216.4819.121.camel@athlon.localdomain> Message-ID: <1099577890.27343.2.camel@localhost.localdomain> Hello Leonard, On Wed, 2004-11-03 at 16:20, Leonard den Ottolander wrote: > Hi, > > Attached you find the uglydir patch, against my last show_dir patch. > > Jindrich, can you write a changelog entry for this patch? > > Leonard. sure, this patch is originally by Karel Zak: src/ChangeLog: * screen.c (show_dir): Don't hang when '\n' is in directory name. -- Jindrich Novy , http://people.redhat.com/jnovy/ From roland.illig at gmx.de Thu Nov 4 14:19:43 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 04 Nov 2004 15:19:43 +0100 Subject: file.c issue In-Reply-To: <200411031859.iA3IxRnG085707@email.zp.ua> References: <200411031859.iA3IxRnG085707@email.zp.ua> Message-ID: <418A3A7F.3000807@gmx.de> Andrew V. Samoilov wrote: > --- file.c~ Mon Oct 18 11:33:35 2004 > +++ file.c Wed Nov 3 20:47:06 2004 > @@ -379,11 +379,10 @@ make_symlink (FileOpContext *ctx, const > if (ctx->stable_symlinks && *link_target != PATH_SEP) { > char *p, *q, *r, *s; > > - p = g_strdup (src_path); > - r = strrchr (p, PATH_SEP); > + r = strrchr (src_path, PATH_SEP); r shall be a const char *. This issue has been discussed two months ago in depth. Roland From roland.illig at gmx.de Thu Nov 4 14:28:39 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 04 Nov 2004 15:28:39 +0100 Subject: QNX patches In-Reply-To: <00d001c4c230$c9f0d980$0d00200a@zero.priv.malva.com.ua> References: <1099521023.15681.6.camel@athlon.localdomain> <00d001c4c230$c9f0d980$0d00200a@zero.priv.malva.com.ua> Message-ID: <418A3C97.60605@gmx.de> Mike V. Gorchak wrote: > 3) pipethrough.c: Added sys/select.h if found according to config.h, because > used fd_set, but sys/select.h is not included. Thanks for this. I don't know how I could forget this file. The select() call is the main thing in this file. :) > btw, why pipethrough.3 is installed in the man directory ? Why it needed > there ? It is only installed if --enable-maintainer-mode is set. I found it useful to have the documentation for such a large function as a manpage. Roland From subscript at free.fr Thu Nov 4 16:13:03 2004 From: subscript at free.fr (wwp) Date: Thu, 4 Nov 2004 17:13:03 +0100 Subject: rar archives with password In-Reply-To: <200411041158.50180.nadvornik@suse.cz> References: <200411041158.50180.nadvornik@suse.cz> Message-ID: <20041104171303.73610951.subscript@free.fr> Hello Vladimir, On Thu, 4 Nov 2004 11:58:50 +0100 Vladimir Nadvornik wrote: > urar virtual filesystem hangs on archives with password. This patch > adds an option -p- to unrar to disable password prompt. > I couldn't test it with rar. If I did not miss anything, listing contents of .rar archives that contain password-protected files do not require to enter the password so it should not lock. Only extraction does (the archive headers themselves are not protected). So to me the first part of you patch does not make a difference. What version of (un)rar did you use? Now regarding the second part, well, extracting password-protected files without passing a password will extract 0-byte length files, with filenames altered (prefixed w/ a star: *), for instance, try to copyout the only file from the attached .rar archive would create an empty file *foo.bar. So what's the aim of the second part as well? The tst.rar attached has been created w/ rar 3.40, using command: `rar a -pfoo tst.rar foo.bar`. Now, being able to interactively type in a password to use when extracting (and optionally when adding to archive) files would be useful. Regards, -- wwp From subscript at free.fr Thu Nov 4 16:20:22 2004 From: subscript at free.fr (wwp) Date: Thu, 4 Nov 2004 17:20:22 +0100 Subject: ***UNCHECKED*** Re: rar archives with password In-Reply-To: <20041104171303.73610951.subscript@free.fr> References: <200411041158.50180.nadvornik@suse.cz> <20041104171303.73610951.subscript@free.fr> Message-ID: <20041104172022.14620e04.subscript@free.fr> > The tst.rar attached has been created w/ rar 3.40, using command: `rar a -pfoo > tst.rar foo.bar`. Tsss, I always forget the attachment! Now there's one. Regards, -- wwp -------------- next part -------------- A non-text attachment was scrubbed... Name: tst.rar Type: application/octet-stream Size: 106 bytes Desc: not available URL: From nadvornik at suse.cz Thu Nov 4 17:36:24 2004 From: nadvornik at suse.cz (Vladimir Nadvornik) Date: Thu, 4 Nov 2004 18:36:24 +0100 Subject: rar archives with password In-Reply-To: <20041104171303.73610951.subscript@free.fr> References: <200411041158.50180.nadvornik@suse.cz> <20041104171303.73610951.subscript@free.fr> Message-ID: <200411041836.24987.nadvornik@suse.cz> On Thursday 04 November 2004 17:13, wwp wrote: > Hello Vladimir, > > On Thu, 4 Nov 2004 11:58:50 +0100 Vladimir Nadvornik wrote: > > urar virtual filesystem hangs on archives with password. This patch > > adds an option -p- to unrar to disable password prompt. > > I couldn't test it with rar. > > If I did not miss anything, listing contents of .rar archives that contain > password-protected files do not require to enter the password so it should > not lock. Only extraction does (the archive headers themselves are not > protected). So to me the first part of you patch does not make a > difference. You are right. It is not needed for listing, but for consistency I'd use it here too. > Now regarding the second part, well, extracting password-protected files > without passing a password will extract 0-byte length files, with filenames > altered (prefixed w/ a star: *), for instance, try to copyout the only file > from the attached .rar archive would create an empty file *foo.bar. So > what's the aim of the second part as well? > Without the patch mc freezes completely. I had to kill it from another terminal. It can be reproduced with mc cvs from monday and unrar 3.30 on the file tst.rar > The tst.rar attached has been created w/ rar 3.40, using command: `rar a > -pfoo tst.rar foo.bar`. > > Now, being able to interactively type in a password to use when extracting > (and optionally when adding to archive) files would be useful. I fully agree, but current vfs does not support it. -- Vladimir Nadvornik developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: nadvornik at suse.cz Drahobejlova 27 tel:+420 2 9654 2373 190 00 Praha 9 fax:+420 2 9654 2374 Ceska republika http://www.suse.cz From subscript at free.fr Thu Nov 4 18:06:02 2004 From: subscript at free.fr (wwp) Date: Thu, 4 Nov 2004 19:06:02 +0100 Subject: rar archives with password In-Reply-To: <200411041836.24987.nadvornik@suse.cz> References: <200411041158.50180.nadvornik@suse.cz> <20041104171303.73610951.subscript@free.fr> <200411041836.24987.nadvornik@suse.cz> Message-ID: <20041104190602.2bdd3bed.subscript@free.fr> Hello Vladimir, On Thu, 4 Nov 2004 18:36:24 +0100 Vladimir Nadvornik wrote: [snip] > > If I did not miss anything, listing contents of .rar archives that contain > > password-protected files do not require to enter the password so it should > > not lock. Only extraction does (the archive headers themselves are not > > protected). So to me the first part of you patch does not make a > > difference. > You are right. It is not needed for listing, but for consistency I'd use it > here too. That's what I wondered, just wanted to be sure, in case previous versions of rar behave differently :-). > > Now regarding the second part, well, extracting password-protected files > > without passing a password will extract 0-byte length files, with > > filenames altered (prefixed w/ a star: *), for instance, try to copyout > > the only file from the attached .rar archive would create an empty file > > *foo.bar. So what's the aim of the second part as well? > > > Without the patch mc freezes completely. I had to kill it from another > terminal. > It can be reproduced with mc cvs from monday and unrar 3.30 on the file > tst.rar [snip] Yeah I definitely agree w/ that, I did kill unrar manually many times (I did not kill mc, eheh, causing less "damages"). What I was trying to point to was that extracting files w/o passing a password is non-sense regarding to what will be extracted (the filename and its contents. OK, now I see that your priority was to avoid locking.. Regards, -- wwp From andrew at email.zp.ua Thu Nov 4 18:34:40 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 4 Nov 2004 20:34:40 +0200 (EET) Subject: mcedit issues Message-ID: <200411041834.iA4IYewB027573@email.zp.ua> Hello, Rolland, your last "simplification" remove charset conversion. Also some people collect all of used glib stuff in our glibcompat.c to eliminate libglib dependancy, and so you enforce them to import g_string_*() there. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcedit.patch URL: From roland.illig at gmx.de Thu Nov 4 20:16:11 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 04 Nov 2004 21:16:11 +0100 Subject: mcedit issues In-Reply-To: <200411041834.iA4IYewB027573@email.zp.ua> References: <200411041834.iA4IYewB027573@email.zp.ua> Message-ID: <418A8E0B.5080104@gmx.de> Andrew V. Samoilov wrote: > Hello, Rolland, > > your last "simplification" remove charset conversion. > Also some people collect all of used glib stuff in our glibcompat.c > to eliminate libglib dependancy, and so you enforce them to import g_string_*() > there. The purpose of glibcompat.c is to provide the functions that are in glib-2, but not in glib-1.2. It is not used as an abstraction layer aroung the glib functions. > --- edit/editcmd.c.orig Thu Nov 4 20:12:16 2004 > +++ edit/editcmd.c Thu Nov 4 20:19:09 2004 > @@ -1181,15 +1181,15 @@ edit_replace_prompt (WEdit * edit, char > 0, 0, 0, 0, 0}, > NULL_QuickWidget}; > > - GString *label_text = g_string_new (_(" Replace with: ")); > + char *msg = _(" Replace with: "); msg must be a const char *. If ENABLE_NLS is not #defined, the following line is executed: #define _(str) (str) So you assign a const char * to a char * variable here. > if (*replace_text) { > - g_string_append (label_text, replace_text); > - convert_to_display (label_text->str + label_text->len); Yes, I see the mistake here. label_text->len should be replaced by the label_text->len from before the g_string_append() call. > + size_t msg_len = strlen (msg); > + msg = catstrs (msg, replace_text, (char *) NULL); > + convert_to_display (msg + msg_len); Roland From roland.illig at gmx.de Thu Nov 4 21:44:48 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 04 Nov 2004 22:44:48 +0100 Subject: mcedit issues In-Reply-To: <200411041834.iA4IYewB027573@email.zp.ua> References: <200411041834.iA4IYewB027573@email.zp.ua> Message-ID: <418AA2D0.2030205@gmx.de> Andrew V. Samoilov wrote: > your last "simplification" remove charset conversion. > Also some people collect all of used glib stuff in our glibcompat.c > to eliminate libglib dependancy, and so you enforce them to import g_string_*() > there. I would like to apply only this small patch for editcmd.c. Justification for the use of GString ==================================== I like the data type GString because it is already available in glib-1.2 as well as glib-2.0, it is easy to use, and you don't have to worry about the maximum length of your strings. from src/subshell.c:694: /* * Factor 5 because we need \, 0 and 3 other digits per character * in the worst case (tcsh and zsh). */ d = ret = g_malloc (5 * strlen (s) + 16); This could be changed to: ret = g_string_new (""); ... g_string_appendc (ret, 'x'); g_string_append (ret, "foobar"); Another feature is that getting the string's length will have a time cost of O(1), while the strlen() function has a time cost of O(strlen(s)). Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: mcedit-charset.patch Type: text/x-patch Size: 716 bytes Desc: not available URL: From roland.illig at gmx.de Thu Nov 4 21:52:59 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 04 Nov 2004 22:52:59 +0100 Subject: autogen.sh portability Message-ID: <418AA4BB.6070208@gmx.de> Hi, the autogen.sh does not work under AIX-3.4.4.0. The patch fixes this. May I commit it? Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: autogen.sh-portability.patch Type: text/x-patch Size: 1569 bytes Desc: not available URL: From leonard at den.ottolander.nl Thu Nov 4 22:03:20 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 04 Nov 2004 23:03:20 +0100 Subject: autogen.sh portability In-Reply-To: <418AA4BB.6070208@gmx.de> References: <418AA4BB.6070208@gmx.de> Message-ID: <1099605800.4782.26.camel@athlon.localdomain> Hello Roland, On Thu, 2004-11-04 at 22:52, Roland Illig wrote: > the autogen.sh does not work under AIX-3.4.4.0. The patch fixes this. How does it not work on AIX? > May I commit it? Does it break on other architectures? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Thu Nov 4 22:16:25 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 04 Nov 2004 23:16:25 +0100 Subject: autogen.sh portability In-Reply-To: <1099605800.4782.26.camel@athlon.localdomain> References: <418AA4BB.6070208@gmx.de> <1099605800.4782.26.camel@athlon.localdomain> Message-ID: <418AAA39.90300@gmx.de> Leonard den Ottolander wrote: > Hello Roland, > > On Thu, 2004-11-04 at 22:52, Roland Illig wrote: > >>the autogen.sh does not work under AIX-3.4.4.0. The patch fixes this. > > How does it not work on AIX? The "#" comments in the sed command are given as command line arguments to sed, which is then confused. I don't think it could break on other architectures. Roland From leonard at den.ottolander.nl Thu Nov 4 22:18:26 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 04 Nov 2004 23:18:26 +0100 Subject: mcedit issues In-Reply-To: <418AA2D0.2030205@gmx.de> References: <200411041834.iA4IYewB027573@email.zp.ua> <418AA2D0.2030205@gmx.de> Message-ID: <1099606705.4782.32.camel@athlon.localdomain> Hi Roland, On Thu, 2004-11-04 at 22:44, Roland Illig wrote: > I like the data type GString because it is already available in glib-1.2 > as well as glib-2.0, it is easy to use, and you don't have to worry > about the maximum length of your strings. Sorry. I thought you just introduced this and Andrew reverted it, but now I see this was introduced earlier. Thought for a moment you were introducing architectural changes just before the release :) . Andrew, does this patch fix the issue you are seeing? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Fri Nov 5 09:33:25 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 5 Nov 2004 11:33:25 +0200 (EET) Subject: mcedit issues In-Reply-To: <1099606705.4782.32.camel@athlon.localdomain> Message-ID: <200411050933.iA59XPVx051149@email.zp.ua> > Hi Roland, > > On Thu, 2004-11-04 at 22:44, Roland Illig wrote: > > I like the data type GString because it is already available in glib-1.2 > > as well as glib-2.0, it is easy to use, and you don't have to worry > > about the maximum length of your strings. There is new GString structure member "gsize allocated_len" introduced in 2.0. Line above is about version compatibility. Also as far as I remember glib 1.2 allocates initially 1K memory area on default and doubles this area each time to fit string. I am using LiveCD and embeded distros on low memory machines with specially stripped mc, so I dont glad to see this memory allocation strategy. > Sorry. I thought you just introduced this and Andrew reverted it, but > now I see this was introduced earlier. Thought for a moment you were > introducing architectural changes just before the release :) . GString was introduced by Roland on Sep 19 and "simplified" on Sep 25. > Andrew, does this patch fix the issue you are seeing? Yes. -- Regards, Andrew V. Samoilov. From andrew at email.zp.ua Fri Nov 5 09:58:40 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 5 Nov 2004 11:58:40 +0200 (EET) Subject: mcedit issues In-Reply-To: <418A8E0B.5080104@gmx.de> Message-ID: <200411050958.iA59weGo052078@email.zp.ua> > The purpose of glibcompat.c is to provide the functions that are in > glib-2, but not in glib-1.2. It is not used as an abstraction layer > aroung the glib functions. I know, but it is best place now to place glib function. > > - GString *label_text = g_string_new (_(" Replace with: ")); > > + char *msg = _(" Replace with: "); > msg must be a const char *. If ENABLE_NLS is not #defined, the following > line is executed: > #define _(str) (str) > So you assign a const char * to a char * variable here. Yes, const qualifier can be added. Well, QuickWidget.text field also can be declared const * char because query_dialog() does not modifies this one, but this change will lead to too many warnings now. -- Regards, Andrew V. Samoilov. From leonard at den.ottolander.nl Fri Nov 5 13:57:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 05 Nov 2004 14:57:40 +0100 Subject: UTF-8 warnings In-Reply-To: <200411021640.53617.nadvornik@suse.cz> References: <1099409319.4817.121.camel@athlon.localdomain> <200411021640.53617.nadvornik@suse.cz> Message-ID: <1099663059.4804.11.camel@athlon.localdomain> Hello Vladimir, On Tue, 2004-11-02 at 16:40, Vladimir Nadvornik wrote: > On Tuesday 02 November 2004 16:28, Leonard den Ottolander wrote: > > Also 1 "discard qualifier" warning in help.c. But "Unconsting" p in > > help_show() does not fix this as p points to const char* paint_start. > > Introducing a (redundant) cast on the call of SLsmg_write_nchars() in > > the utf8-help patch. This should actually be fixed in slang. > > > This version of the patch compiles without warning. According to Jindrich this patch does not work as expected. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136826 . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Fri Nov 5 14:00:47 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 05 Nov 2004 15:00:47 +0100 Subject: mcedit issues In-Reply-To: <200411050933.iA59XPVx051149@email.zp.ua> References: <200411050933.iA59XPVx051149@email.zp.ua> Message-ID: <1099663246.4804.14.camel@athlon.localdomain> Hello Andrew, On Fri, 2004-11-05 at 10:33, Andrew V. Samoilov wrote: > Also as far as I remember glib 1.2 allocates initially 1K memory area on default > and doubles this area each time to fit string. > > Andrew, does this patch fix the issue you are seeing? > > Yes. So if I get this correctly this patch fixes the issue but you are not pleased by the introduction of GString because of it's memory foot print. Any comment on this Roland? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jnovy at redhat.com Fri Nov 5 14:50:44 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 05 Nov 2004 15:50:44 +0100 Subject: 8bit default In-Reply-To: <200411031546.08166.nadvornik@suse.cz> References: <200411031546.08166.nadvornik@suse.cz> Message-ID: <1099666244.4829.56.camel@obelix.redhat.usu> Hello Vladimir, On Wed, 2004-11-03 at 15:46, Vladimir Nadvornik wrote: > Hi, > > I think that mc should use 8bit input by default. It is useful for most > languages and I don't know about any disadvantages. > Please see the attached patch. I can confirm that I'd also appreciate to see this patch committed. -- Jindrich Novy , http://people.redhat.com/jnovy/ From roland.illig at gmx.de Fri Nov 5 14:57:50 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 05 Nov 2004 15:57:50 +0100 Subject: mcedit issues In-Reply-To: <200411050933.iA59XPVx051149@email.zp.ua> References: <200411050933.iA59XPVx051149@email.zp.ua> Message-ID: <418B94EE.4060900@gmx.de> Andrew V. Samoilov wrote: > Also as far as I remember glib 1.2 allocates initially 1K memory area on default > and doubles this area each time to fit string. I am using LiveCD and > embeded distros on low memory machines with specially stripped mc, > so I dont glad to see this memory allocation strategy. Yes, you're correct. I just checked glib-1.2, too. We can argue about which strategy of allocation (glib, strcats() or n*strlen + m) is better/worse, but I don't think it makes much difference. Additionally, the string is freed in the same function call, so it is really temporary. I wrote a little test program for the glib-1.2 memory usage. You should not use glib-1.2 at all if your memory is limited. break = 0x8049924 (init) break = 0x806b000 (after g_malloc) break = 0x806a000 (after g_free) break = 0x806a000 (after g_string_new) break = 0x806a000 (after g_string_free) Here you see that glib allocates quite much memory, and that it does not matter if we use GString or not. Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: glibtest.c Type: text/x-csrc Size: 437 bytes Desc: not available URL: From andrew at email.zp.ua Fri Nov 5 17:03:12 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 5 Nov 2004 19:03:12 +0200 (EET) Subject: building on AIX In-Reply-To: <4185F299.5060509@gmx.de> Message-ID: <200411051703.iA5H3Cqr066212@email.zp.ua> Hello, Roland > > While running configure I saw: > > checking for socklen_t... no > > I have successfully built mc on AIX, and here is the patch I wrote for > it. Please try if it works for you, too. Well, this crutch breaks compilation on RedHat 7.3 and RHEL 3: ftpfs.c:97: conflicting types for `socklen_t' /usr/include/bits/socket.h:36: previous declaration of `socklen_t' Attached crutch makes this error even ;-) and allow compilation for these distros. But I am more than sure it breaks compilation for everything but Linux. Can you test it? Anyway think AC_CHECK_TYPE(socklen_t, int) is more common. BTW, maybe it's not right to break compilation on some platforms due to AIX warning fix? -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: configure.ac.patch URL: From andrew at email.zp.ua Fri Nov 5 17:24:34 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 5 Nov 2004 19:24:34 +0200 (EET) Subject: building on AIX In-Reply-To: <200411051703.iA5H3Cqr066212@email.zp.ua> Message-ID: <200411051724.iA5HOYjP067097@email.zp.ua> I am sorry, right crutch is here. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: configure.ac.patch URL: From roland.illig at gmx.de Fri Nov 5 18:28:20 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 05 Nov 2004 19:28:20 +0100 Subject: building on AIX In-Reply-To: <200411051724.iA5HOYjP067097@email.zp.ua> References: <200411051724.iA5HOYjP067097@email.zp.ua> Message-ID: <418BC644.5020203@gmx.de> Andrew V. Samoilov wrote: > -#include ]) > +#include > +#include > +]) from /usr/include/bits/socket.h: # error "Never include directly; use instead." I don't believe that the inclusion is necessary in any version of Linux. If you look at the manpage of bind(2), it states that you should #include and #include , but no word of #include . Can you send me the relevant part of the config.log file, starting with the first occurrence of the string "socklen_t". Roland From roland.illig at gmx.de Fri Nov 5 19:35:53 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 05 Nov 2004 20:35:53 +0100 Subject: [resent] Re: building on AIX In-Reply-To: <200411051724.iA5HOYjP067097@email.zp.ua> References: <200411051724.iA5HOYjP067097@email.zp.ua> Message-ID: <418BD619.3080602@gmx.de> Andrew V. Samoilov wrote: > -#include ]) > +#include > +#include > +]) from /usr/include/bits/socket.h: # error "Never include directly; use instead." I don't believe that the inclusion is necessary in any version of Linux. If you look at the manpage of bind(2), it states that you should #include and #include , but no word of #include . Can you send me the relevant part of the config.log file, starting with the first occurrence of the string "socklen_t". Roland From andrew at email.zp.ua Fri Nov 5 19:56:12 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 5 Nov 2004 21:56:12 +0200 (EET) Subject: [resent] Re: building on AIX In-Reply-To: <418BD619.3080602@gmx.de> Message-ID: <200411051956.iA5JuCMg071365@email.zp.ua> Hi, Roland! I am terrible sorry, make distclean solves this problem -- Regards, Andrew V. Samoilov. From roland.illig at gmx.de Fri Nov 5 22:09:59 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 05 Nov 2004 23:09:59 +0100 Subject: smbfs_open(): Implement O_APPEND via smbfs_lseek() In-Reply-To: <200408191847.i7JIlPpr075434@email.zp.ua> References: <200408191847.i7JIlPpr075434@email.zp.ua> Message-ID: <418BFA37.3080605@gmx.de> Andrew V. Samoilov wrote: > Hello, > > any complains/side effects? In the POSIX standard O_APPEND guarantees atomical (seek && write). Your patch would not guarantee this. From a theoretical point of view we should rather rewrite copy_file_file() to be able to handle these files (unless it is already able to do so) than to weaken the guarantee of O_APPEND. Roland From leonard at den.ottolander.nl Sat Nov 6 09:56:52 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 06 Nov 2004 10:56:52 +0100 Subject: Any objections against using 8 bit input by default? Message-ID: <1099735011.4788.1.camel@athlon.localdomain> Hi, Anybody here that has any objections against setting input to 8 bit by default? If so please formulate and send them here. If not, can we please have the 8bit-default patch committed? It's trivial. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Sun Nov 7 12:34:44 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 07 Nov 2004 13:34:44 +0100 Subject: 8bit default In-Reply-To: <1099666244.4829.56.camel@obelix.redhat.usu> References: <200411031546.08166.nadvornik@suse.cz> <1099666244.4829.56.camel@obelix.redhat.usu> Message-ID: <418E1664.9040307@gmx.de> Jindrich Novy wrote: > Hello Vladimir, > > On Wed, 2004-11-03 at 15:46, Vladimir Nadvornik wrote: > >>Hi, >> >>I think that mc should use 8bit input by default. It is useful for most >>languages and I don't know about any disadvantages. >>Please see the attached patch. > > > I can confirm that I'd also appreciate to see this patch committed. And I committed it. Roland From roland.illig at gmx.de Sun Nov 7 12:46:28 2004 From: roland.illig at gmx.de (Roland Illig) Date: Sun, 07 Nov 2004 13:46:28 +0100 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: <1099317609.4786.23.camel@athlon.localdomain> References: <1096813412.14121.1.camel@localhost> <1099269205.4814.49.camel@athlon.localdomain> <4185E76D.2030404@gmx.de> <1099317609.4786.23.camel@athlon.localdomain> Message-ID: <418E1924.6060301@gmx.de> Leonard den Ottolander wrote: > - if ((COLS < 10) || (LINES < 5) || (COLS > 255) || (LINES > 255)) { > + if ((COLS < 10) || (LINES < 5) || > + (SLang_Version < 10407 && (COLS > 255 || LINES > 255)) || > + (SLang_Version >= 10407 && (COLS > 512 || LINES > 512))) { > + Committed. Roland From andrew at email.zp.ua Mon Nov 8 14:46:52 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 8 Nov 2004 16:46:52 +0200 (EET) Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: <418E1924.6060301@gmx.de> Message-ID: <200411081446.iA8EkqHM076945@email.zp.ua> Hello, this patch fix compilation with included slang. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SLang_Version.patch URL: From andrew at email.zp.ua Mon Nov 8 14:51:27 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 8 Nov 2004 16:51:27 +0200 (EET) Subject: One more SLang issue Message-ID: <200411081451.iA8EpRu6077133@email.zp.ua> -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sldisply.patch URL: From samoilov at fromru.com Mon Nov 8 14:32:59 2004 From: samoilov at fromru.com (Andrew V. Samoilov) Date: Mon, 8 Nov 2004 17:32:59 +0300 (MSK) Subject: One more slang issue Message-ID: <200411081432.iA8EWxMp046063@www10.pochta.ru> From me at pavelsh.pp.ru Mon Nov 8 16:45:08 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Mon, 8 Nov 2004 21:45:08 +0500 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: <200411081446.iA8EkqHM076945@email.zp.ua> References: <418E1924.6060301@gmx.de> <200411081446.iA8EkqHM076945@email.zp.ua> Message-ID: <2532879.20041108214508@pavelsh.pp.ru> Hello Andrew, Monday, November 8, 2004, 7:46:52 PM, you wrote: AVS> this patch fix compilation with included slang. Committed. Thx! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From jnovy at redhat.com Mon Nov 8 16:56:46 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 08 Nov 2004 17:56:46 +0100 Subject: file_mask_dialog() memory leak fix Message-ID: <1099933006.2970.34.camel@obelix.redhat.usu> Hello, I noticed a memory leak in file_mask_dialog() in src/filegui.c in the current CVS. The attached patch should fix it. The cause of it is that g_strdup()ed def_text_secure is not g_free()d. greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041108-memleak.patch Type: text/x-patch Size: 543 bytes Desc: not available URL: From leonard at den.ottolander.nl Mon Nov 8 21:12:41 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 08 Nov 2004 22:12:41 +0100 Subject: increasing LINES and COLS [was Re: suggestion] In-Reply-To: <200411081446.iA8EkqHM076945@email.zp.ua> References: <200411081446.iA8EkqHM076945@email.zp.ua> Message-ID: <1099948361.4785.3.camel@athlon.localdomain> Hi Andrew, On Mon, 2004-11-08 at 15:46, Andrew V. Samoilov wrote: > this patch fix compilation with included slang. Maybe we should replace +const int SLang_Version = 10409; with +const int SLang_Version = SLANG_VERSION; ? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Nov 8 21:21:16 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 08 Nov 2004 22:21:16 +0100 Subject: file_mask_dialog() memory leak fix In-Reply-To: <1099933006.2970.34.camel@obelix.redhat.usu> References: <1099933006.2970.34.camel@obelix.redhat.usu> Message-ID: <1099948875.4785.7.camel@athlon.localdomain> Hi Pchel, On Mon, 2004-11-08 at 17:56, Jindrich Novy wrote: > I noticed a memory leak in file_mask_dialog() in src/filegui.c in the > current CVS. The attached patch should fix it. > > The cause of it is that g_strdup()ed def_text_secure is not g_free()d. Your partial commit of the mc-CVS-strippwd.patch seems to cause havoc. Instead of applying this patch please just commit the rest of that patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Tue Nov 9 05:54:29 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 9 Nov 2004 10:54:29 +0500 Subject: file_mask_dialog() memory leak fix In-Reply-To: <1099948875.4785.7.camel@athlon.localdomain> References: <1099933006.2970.34.camel@obelix.redhat.usu> <1099948875.4785.7.camel@athlon.localdomain> Message-ID: <1124828982.20041109105429@pavelsh.pp.ru> Hello Leonard, Tuesday, November 9, 2004, 2:21:16 AM, you wrote: >> I noticed a memory leak in file_mask_dialog() in src/filegui.c in the >> current CVS. The attached patch should fix it. >> >> The cause of it is that g_strdup()ed def_text_secure is not g_free()d. LdO> Your partial commit of the mc-CVS-strippwd.patch seems to cause havoc. Havoc? :) Why???? All working fine without patched hotlist.c and util.c. Isn't it? LdO> Instead of applying this patch please just commit the rest of that LdO> patch. :) This patch is bugfix an error, introduced by mc-CVS-strippwd.patch. I committed it. Thx for Jindrich. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Tue Nov 9 06:22:12 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 9 Nov 2004 11:22:12 +0500 Subject: strip_passwd partial commit In-Reply-To: <1099576095.24625.112.camel@localhost.localdomain> References: <1099515221.4819.153.camel@athlon.localdomain> <1562934082.20041104104724@pavelsh.pp.ru> <1099576095.24625.112.camel@localhost.localdomain> Message-ID: <1155741373.20041109112212@pavelsh.pp.ru> Hello Jindrich, Thursday, November 4, 2004, 6:48:15 PM, you wrote: >> util.c(strip_password()) - need some additional testing. For >> example around: >> - at = strrchr (p, '@'); >> + at = memchr (p, '@', host_len); >> >> It's not equal operations. JN> Yes, they're not equal, because I changed the password stripping JN> strategy (see also the condition above this line), because of this bug JN> in strip_password (): JN> It strips not only the password but everything after first PATH_SEP, so: JN> jamesbond:007 at ci5.uk/home/secret/ JN> is after strip_password (): JN> jamesbond at ci5.uk Please, apply attached patch to current mc snapshot. And run src/mc I got an output ----------------------------------------------------- genie# ./mc pavelsh at test.ru:pass at test.your.domain/path/to/file pavelsh at test.ru@test.your.domain pavelsh at test.ru:pass at test.your.domain/path/to/file ------------------------- pavelsh:pass at test.your.domain/path/to/file pavelsh at test.your.domain pavelsh at test.your.domain/path/to/file ------------------------- pavelsh at test.ru:pass at test.your.domain/ pavelsh at test.ru@test.your.domain pavelsh at test.ru:pass at test.your.domain/ ------------------------- pavelsh at test.ru:pass at test.your.domain/path/to/file/ pavelsh at test.ru@test.your.domain pavelsh at test.ru:pass at test.your.domain/path/to/file/ ------------------------- ----------------------------------------------------- -- Best regards, Pavel mailto:me at pavelsh.pp.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: test.patch Type: application/octet-stream Size: 2982 bytes Desc: not available URL: From me at pavelsh.pp.ru Tue Nov 9 07:12:55 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 9 Nov 2004 12:12:55 +0500 Subject: Bug in mc command line Message-ID: <1482740086.20041109121255@pavelsh.pp.ru> Hello mc-devel, Please, enter in command line: $ cat cisco.log | grep %LINK-3-UPDOWN Press Enter, and you'll get $ cat cisco.log | grep %INK-3-UPDOWN -- Best regards, Pavel mailto:me at pavelsh.pp.ru From jnovy at redhat.com Tue Nov 9 10:23:47 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 09 Nov 2004 11:23:47 +0100 Subject: strip_passwd partial commit In-Reply-To: <1155741373.20041109112212@pavelsh.pp.ru> References: <1099515221.4819.153.camel@athlon.localdomain> <1562934082.20041104104724@pavelsh.pp.ru> <1099576095.24625.112.camel@localhost.localdomain> <1155741373.20041109112212@pavelsh.pp.ru> Message-ID: <1099995827.30794.47.camel@obelix.redhat.usu> Hello Pavel, On Tue, 2004-11-09 at 07:22, Pavel Shirshov (pchel) wrote: > I got an output > ----------------------------------------------------- > genie# ./mc > pavelsh at test.ru:pass at test.your.domain/path/to/file > pavelsh at test.ru@test.your.domain > pavelsh at test.ru:pass at test.your.domain/path/to/file > ------------------------- > pavelsh:pass at test.your.domain/path/to/file > pavelsh at test.your.domain > pavelsh at test.your.domain/path/to/file > ------------------------- > pavelsh at test.ru:pass at test.your.domain/ > pavelsh at test.ru@test.your.domain > pavelsh at test.ru:pass at test.your.domain/ > ------------------------- > pavelsh at test.ru:pass at test.your.domain/path/to/file/ > pavelsh at test.ru@test.your.domain > pavelsh at test.ru:pass at test.your.domain/path/to/file/ > ------------------------- Please note that the test case is valid only for URL present in string txt2: > pavelsh:pass at test.your.domain/path/to/file > pavelsh at test.your.domain > pavelsh at test.your.domain/path/to/file where the strip_password_new() behaves as it should (last line). The rest of testing URLs are malformed, because they're not RFC-1738 compliant. So they *shouldn't* be used as URLs. Please see http://www.faqs.org/rfcs/rfc1738.html section 3.1. However, from the test case txt2 it's apparent the bug in the original strip_password(). greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From jnovy at redhat.com Tue Nov 9 13:02:35 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 09 Nov 2004 14:02:35 +0100 Subject: file_mask_dialog() memory leak fix In-Reply-To: <1124828982.20041109105429@pavelsh.pp.ru> References: <1099933006.2970.34.camel@obelix.redhat.usu> <1099948875.4785.7.camel@athlon.localdomain> <1124828982.20041109105429@pavelsh.pp.ru> Message-ID: <1100005355.30794.77.camel@obelix.redhat.usu> Hello Pavel, On Tue, 2004-11-09 at 06:54, Pavel Shirshov (pchel) wrote: > :) This patch is bugfix an error, introduced by mc-CVS-strippwd.patch. Unfortunately not. The leak isn't introduced by mc-CVS-strippwd.patch. Please look for "ask_file_mask:" in it and you'll see the same code as in the memory leak bugfix ;-) greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From leonard at den.ottolander.nl Tue Nov 9 13:14:14 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 14:14:14 +0100 Subject: file_mask_dialog() memory leak fix In-Reply-To: <1124828982.20041109105429@pavelsh.pp.ru> References: <1099933006.2970.34.camel@obelix.redhat.usu> <1099948875.4785.7.camel@athlon.localdomain> <1124828982.20041109105429@pavelsh.pp.ru> Message-ID: <1100006053.4810.4.camel@athlon.localdomain> Hi Pchel, On Tue, 2004-11-09 at 06:54, Pavel Shirshov (pchel) wrote: > LdO> Your partial commit of the mc-CVS-strippwd.patch seems to cause havoc. > > Havoc? :) Why???? All working fine without patched hotlist.c and > util.c. Isn't it? Well "havoc" is a bit exaggerated, but this memory leak is caused by the partial commit you did. Those two g_free(def_text_secure) are in the original patch. > LdO> Instead of applying this patch please just commit the rest of that > LdO> patch. > > :) This patch is bugfix an error, introduced by mc-CVS-strippwd.patch. No. The mc-CVS-strippwd has these frees. At least in my local copy. You made a mistake committing and forgetting an essential part. > I committed it. Thx for Jindrich. Do you mean the whole mc-CVS-strippwd patch is now committed? Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Nov 9 13:30:11 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 14:30:11 +0100 Subject: Call for development freeze Message-ID: <1100007011.4810.18.camel@athlon.localdomain> Hello Pavel, Afaict all issues we put up as a TODO targets for 4.6.1 have been fixed (also the ones put up on Pavel Shirshov's wiki at http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs ). Roland is double checking the shell scripts in extfs for quoting errors. The only issue left that needs to be fixed is the command line bug that Pchel found which might have something to do with the interpretation of '%'. Thus my request for a development freeze (apart from the above 2 issues) and the release of 4.6.1. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Nov 9 13:42:55 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 14:42:55 +0100 Subject: file_mask_dialog() memory leak fix In-Reply-To: <1100006053.4810.4.camel@athlon.localdomain> References: <1099933006.2970.34.camel@obelix.redhat.usu> <1099948875.4785.7.camel@athlon.localdomain> <1124828982.20041109105429@pavelsh.pp.ru> <1100006053.4810.4.camel@athlon.localdomain> Message-ID: <1100007774.4810.25.camel@athlon.localdomain> Hello Pchel, I wrote: > > I committed it. Thx for Jindrich. > > Do you mean the whole mc-CVS-strippwd patch is now committed? Thanks. My mistake. Could you please state more clearly what you committed? And could you be so kind to commit the rest of that mc-CVS-strippwd patch, or at least explain us why you left out extensive parts? Pchel, this patch was one integral patch that should fix the whole issue of passwords showing in FTP related dialogs. If there were issues with the patch you should have discussed these so they could have been fixed. I feel your approach of splitting up a patch that should have been committed in one go is rather ugly. You are confusing at least me with this approach, because it is totally unclear why you only committed parts and not the whole thing. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Nov 9 14:06:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 15:06:50 +0100 Subject: uglydir patch In-Reply-To: <1099496210.4819.129.camel@athlon.localdomain> References: <1099495216.4819.121.camel@athlon.localdomain> <1099496210.4819.129.camel@athlon.localdomain> Message-ID: <1100009210.4810.42.camel@athlon.localdomain> Hi, This patch still needs to be committed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Nov 9 14:07:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 15:07:40 +0100 Subject: subshell prompt fix In-Reply-To: <1099473730.19714.18.camel@localhost.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> Message-ID: <1100009259.4810.44.camel@athlon.localdomain> Hi, I believe Pchel had some issues with this patch. Can these be resolved so this patch can get committed? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jnovy at redhat.com Tue Nov 9 14:08:39 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 09 Nov 2004 15:08:39 +0100 Subject: Bug in mc command line In-Reply-To: <1482740086.20041109121255@pavelsh.pp.ru> References: <1482740086.20041109121255@pavelsh.pp.ru> Message-ID: <1100009319.30794.102.camel@obelix.redhat.usu> Hello Pavel, On Tue, 2004-11-09 at 08:12, Pavel Shirshov (pchel) wrote: > Hello mc-devel, > > Please, enter in command line: > > $ cat cisco.log | grep %LINK-3-UPDOWN > > Press Enter, and you'll get > > $ cat cisco.log | grep %INK-3-UPDOWN This looks like easyfix. It needs testing though. greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041109-cmdlinebug.patch Type: text/x-patch Size: 491 bytes Desc: not available URL: From leonard at den.ottolander.nl Tue Nov 9 14:13:26 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 15:13:26 +0100 Subject: strippwd patch against CVS20041108 Message-ID: <1100009606.4810.47.camel@athlon.localdomain> Hi, These are the hunks of the strippwd patch that have not yet been committed. Jindrich, is there anything missing from this? Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS20041108-strippwd.patch Type: text/x-patch Size: 4160 bytes Desc: not available URL: From leonard at den.ottolander.nl Tue Nov 9 14:39:54 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 15:39:54 +0100 Subject: tar # issue fixed? Message-ID: <1100011193.4810.50.camel@athlon.localdomain> Hi Pchel, What about the issue with tar file names with hashes in their names? The wiki suggests that you fixed this, but I can't find what you changed... Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jnovy at redhat.com Tue Nov 9 14:47:01 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 09 Nov 2004 15:47:01 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <1100009606.4810.47.camel@athlon.localdomain> References: <1100009606.4810.47.camel@athlon.localdomain> Message-ID: <1100011621.30794.115.camel@obelix.redhat.usu> Hello Leonard, On Tue, 2004-11-09 at 15:13, Leonard den Ottolander wrote: > Hi, > > These are the hunks of the strippwd patch that have not yet been > committed. Please don't commit hunks in filegui.c, those hunks are fixes of bad things in utf8-fix.patch included in our Red Hat mc SRPM. In CVS snapshot today all things in filegui.c are fine. > Jindrich, is there anything missing from this? I think when the remaining hunks of the patch are committed, we successfully finished the ftp password problem. greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From ptsekov at gmx.net Tue Nov 9 13:16:53 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 9 Nov 2004 14:16:53 +0100 Subject: tar # issue fixed? In-Reply-To: <1100011193.4810.50.camel@athlon.localdomain> References: <1100011193.4810.50.camel@athlon.localdomain> Message-ID: Hello Leonard, On Tue, 9 Nov 2004, Leonard den Ottolander wrote: > Hi Pchel, > > What about the issue with tar file names with hashes in their names? The > wiki suggests that you fixed this, but I can't find what you changed... This is the reason for the problem: http://savannah.gnu.org/cgi-bin/viewcvs/mc/mc/vfs/vfs.c.diff?r1=1.125&r2=1.126&sortby=date&diff_format=u Pavel, kind of reverts one of the hunks: - for (vfs = vfs_list; vfs != &vfs_local_ops; vfs = vfs->next) { + for (vfs = vfs_list; vfs; vfs = vfs->next) { I.e. the idea is to not fallback to the local fs if no other vfs matches. However I doubt that this will work with files with 2 or more # in the name. I have to test that first and then I'll report here. From ptsekov at gmx.net Tue Nov 9 13:20:40 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 9 Nov 2004 14:20:40 +0100 Subject: Call for development freeze In-Reply-To: <1100007011.4810.18.camel@athlon.localdomain> References: <1100007011.4810.18.camel@athlon.localdomain> Message-ID: Hello, On Tue, 9 Nov 2004, Leonard den Ottolander wrote: > Hello Pavel, > > Afaict all issues we put up as a TODO targets for 4.6.1 have been fixed > (also the ones put up on Pavel Shirshov's wiki at > http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs ). Roland is double > checking the shell scripts in extfs for quoting errors. The only issue > left that needs to be fixed is the command line bug that Pchel found > which might have something to do with the interpretation of '%'. > > Thus my request for a development freeze (apart from the above 2 issues) > and the release of 4.6.1. There are two patches from me regarding the editor behaviour. Please, consider them - they are important. From leonard at den.ottolander.nl Tue Nov 9 15:28:04 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 16:28:04 +0100 Subject: Call for development freeze In-Reply-To: References: <1100007011.4810.18.camel@athlon.localdomain> Message-ID: <1100014084.4810.53.camel@athlon.localdomain> Hello Pavel, On Tue, 2004-11-09 at 14:20, Pavel Tsekov wrote: > There are two patches from me regarding the editor behaviour. Please, > consider them - they are important. Please either resubmit or reply to the post where you submitted them. This way all things that need to be fixed before 4.6.1 are mentioned on the list today. See my last few posts as well. Thought these were already fixed... Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Tue Nov 9 14:29:46 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 9 Nov 2004 15:29:46 +0100 Subject: [PATCH] Internal editor brokeness with ncurses (fwd) Message-ID: Hello, As Leonard requested. ---------- Forwarded message ---------- Date: Fri, 29 Oct 2004 10:56:36 +0200 Subject: Re: Internal editor brokeness with ncurses Hello, On Sun, 2 May 2004, [ISO-8859-1] Fr?d?ric L. W. Meunier wrote: > See the thread starting at > http://sources.redhat.com/ml/cygwin/2004-05/msg00015.html Attached is a patch + testcase. The internal editor sometimes outputs more than one char on the screen for a given byte of input: 0x09 -> 8 characters 0x00 .. 0x1F -> 2 characters 0x7F -> 2 characters In these cases several columns on the screen refer to a single byte of input. Now, when the user scrolls the screen to the right it may happen that the first column that should be displayed is in the middle of a group of columns representing a single char: 0 .................. 11 .... 15 TAB1-+ TAB2-+ | | /-----+-------\ /-----+-------\ 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 ^ First col after | scrolling by 11 ------+ In this case output is generated starting at the input byte containing the column i.e. TAB2. Obviously there are 3 columns that should be ignored and MC's editor doest this by using the routine `move ()' giving it a negative index for the 'X' axis. This apparently does work for S-Lang, but does not for ncurses. So with ncurses the characters are actually not ignored and are drawn to the screen. Then the following happens: [ quote from cur_addch(3X) ] "If the advance is at the right margin, the cursor automatically wraps to the beginning of the next line." This is not immediately seen though. One should update the screen in some way i.e. pressing Ctrl + L turns to do the work without messing the screen too much. I've attached a simple patch (mc-edit-print-eol-mark.patch) which helps to understand the issue. Patch edit/editdraw.c with it and you'll see an '&' character at the place where the newline should be. It can be used with the attached testcase file (tab.txt) like this: 1. mcedit tab.txt 2. go to line longer than you screen and press End 3. press Ctrl + L 4. watch the next line Now about the patch. It doesn't use the screen library's routine move () to eat the excessive output, but rather doesn't generate output at all for those columns. I tested MC compiled wiht both S-Lang and ncurses on Cygwin and Linux. -------------- next part -------------- blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah -------------- next part -------------- Index: editdraw.c =================================================================== RCS file: /cvsroot/mc/mc/edit/editdraw.c,v retrieving revision 1.34 diff -u -p -r1.34 editdraw.c --- editdraw.c 23 Oct 2004 13:14:14 -0000 1.34 +++ editdraw.c 29 Oct 2004 09:30:27 -0000 @@ -282,7 +282,7 @@ edit_draw_this_line (WEdit *edit, long b switch (c) { case '\n': col = end_col - edit->start_col + 1; /* quit */ - *(p++) |= ' '; + *(p++) |= '&'; break; case '\t': i = TAB_SIZE - ((int) col % TAB_SIZE); -------------- next part -------------- Index: editdraw.c =================================================================== RCS file: /cvsroot/mc/mc/edit/editdraw.c,v retrieving revision 1.34 diff -u -p -r1.34 editdraw.c --- editdraw.c 23 Oct 2004 13:14:14 -0000 1.34 +++ editdraw.c 29 Oct 2004 09:35:18 -0000 @@ -21,6 +21,7 @@ */ #include +#include #include "edit.h" #include "edit-widget.h" @@ -191,18 +192,29 @@ print_to_widget (WEdit *edit, long row, int x = start_col_real + EDIT_TEXT_HORIZONTAL_OFFSET; int x1 = start_col + EDIT_TEXT_HORIZONTAL_OFFSET; int y = row + EDIT_TEXT_VERTICAL_OFFSET; + int cols_to_skip = abs (x); set_color (EDITOR_NORMAL_COLOR); edit_move (x1, y); hline (' ', end_col + 1 - EDIT_TEXT_HORIZONTAL_OFFSET - x1); - edit_move (x + FONT_OFFSET_X, y + FONT_OFFSET_Y); + edit_move (x1 + FONT_OFFSET_X, y + FONT_OFFSET_Y); p = line; while (*p) { - int style = *p & 0xFF00; - int textchar = *p & 0xFF; - int color = *p >> 16; + int style; + int textchar; + int color; + + if (cols_to_skip) { + p++; + cols_to_skip--; + continue; + } + + style = *p & 0xFF00; + textchar = *p & 0xFF; + color = *p >> 16; if (style & MOD_ABNORMAL) { /* Non-printable - use black background */ From ptsekov at gmx.net Tue Nov 9 14:31:34 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 9 Nov 2004 15:31:34 +0100 Subject: edit_status () prints bad status line (fwd) Message-ID: Hello, Please, fix this. Disregard the suggestion at the bottom. ---------- Forwarded message ---------- Date: Fri, 29 Oct 2004 15:46:40 +0200 From: Pavel Tsekov To: Roland Illig Cc: MC dev Subject: edit_status () prints bad status line Hello, While working on the editor I noticed that the status line outputs more characters than the actual number of columns. printw ("%-*s", fname_len + gap, fname); if (fname_len + gap < w) printw ("%-*s ", w - (fname_len + gap), status); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You should change the line above to: printw ("%-*s ", w - (fname_len + gap + 2), status); Also, maybe it would be much better to declare a constant like that: static const int right _pad = 2; and use it to replace all occurences of '2'. From me at pavelsh.pp.ru Tue Nov 9 16:51:05 2004 From: me at pavelsh.pp.ru (me at pavelsh.pp.ru) Date: Tue, 9 Nov 2004 21:51:05 +0500 Subject: Call for development freeze In-Reply-To: <1100007011.4810.18.camel@athlon.localdomain> References: <1100007011.4810.18.camel@athlon.localdomain> Message-ID: <823921157.20041109215105@pavelsh.pp.ru> Hello Leonard, Tuesday, November 9, 2004, 6:30:11 PM, you wrote: LdO> Afaict all issues we put up as a TODO targets for 4.6.1 have been fixed LdO> (also the ones put up on Pavel Shirshov's wiki at LdO> http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs ). Roland is double LdO> checking the shell scripts in extfs for quoting errors. The only issue LdO> left that needs to be fixed is the command line bug that Pchel found LdO> which might have something to do with the interpretation of '%'. LdO> Thus my request for a development freeze (apart from the above 2 issues) LdO> and the release of 4.6.1. We have a problem with system slang on FreeBSD. Configure script is working incorrectly. Andrew Samoilov and I are working to solve this problem. -- Best regards, me mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Tue Nov 9 16:52:44 2004 From: me at pavelsh.pp.ru (me at pavelsh.pp.ru) Date: Tue, 9 Nov 2004 21:52:44 +0500 Subject: file_mask_dialog() memory leak fix In-Reply-To: <1100006053.4810.4.camel@athlon.localdomain> References: <1099933006.2970.34.camel@obelix.redhat.usu> <1099948875.4785.7.camel@athlon.localdomain> <1124828982.20041109105429@pavelsh.pp.ru> <1100006053.4810.4.camel@athlon.localdomain> Message-ID: <172936350.20041109215244@pavelsh.pp.ru> Hello Leonard, Tuesday, November 9, 2004, 6:14:14 PM, you wrote: >> LdO> Instead of applying this patch please just commit the rest of that >> LdO> patch. >> >> :) This patch is bugfix an error, introduced by mc-CVS-strippwd.patch. LdO> No. The mc-CVS-strippwd has these frees. At least in my local copy. You made LdO> a mistake committing and forgetting an essential part. Ok. Ok. No problem. LdO> Do you mean the whole mc-CVS-strippwd patch is now committed? Thanks. No. Hotlist.c havn't committed yet. -- Best regards, me mailto:me at pavelsh.pp.ru From ossi at kde.org Tue Nov 9 18:08:01 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Tue, 9 Nov 2004 19:08:01 +0100 Subject: copy to ../ from archive Message-ID: <20041109180801.GA12182@ugly.local> until recently i could enter a tar.gz and copy the contained direcory to .., thus simply extracting it in the directory the tar lives in ... now ... well, i can't anymore. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From me at pavelsh.pp.ru Tue Nov 9 19:10:57 2004 From: me at pavelsh.pp.ru (me at pavelsh.pp.ru) Date: Wed, 10 Nov 2004 00:10:57 +0500 Subject: strippwd patch against CVS20041108 In-Reply-To: <1100009606.4810.47.camel@athlon.localdomain> References: <1100009606.4810.47.camel@athlon.localdomain> Message-ID: <119343044.20041110001057@pavelsh.pp.ru> Hello Leonard, Tuesday, November 9, 2004, 7:13:26 PM, you wrote: LdO> These are the hunks of the strippwd patch that have not yet been LdO> committed. Committed with my fixes. -- Best regards, me mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Tue Nov 9 22:46:52 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Nov 2004 23:46:52 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <119343044.20041110001057@pavelsh.pp.ru> References: <1100009606.4810.47.camel@athlon.localdomain> <119343044.20041110001057@pavelsh.pp.ru> Message-ID: <1100040412.4782.35.camel@athlon.localdomain> Hi Pavel, On Tue, 2004-11-09 at 20:10, me at pavelsh.pp.ru wrote: > LdO> These are the hunks of the strippwd patch that have not yet been > LdO> committed. > > Committed with my fixes. Changes to hotlist.c look good. Extra g_free()s on return are a good catch. Also g_strlcpy() instead of strncpy() seems the better solution. filegui.c not commited as per request of Jindrich, which is good as it touches a const char*. Jindrich, what about the fixes to util.c? Do they satisfy you? What about the - if (dir) - *dir = PATH_SEP; that Pavel reintroduces? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 03:17:58 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 04:17:58 +0100 Subject: edit_status () prints bad status line (fwd) In-Reply-To: References: Message-ID: <1100056675.4782.49.camel@athlon.localdomain> Hi Pavel, On Tue, 2004-11-09 at 15:31, Pavel Tsekov wrote: > While working on the editor I noticed that the status line outputs > more characters than the actual number of columns. I finally got to building mc with ncurses. I verified the issue exists and that the patch fixes the issue. Please commit. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 03:32:56 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 04:32:56 +0100 Subject: [PATCH] Internal editor brokeness with ncurses (fwd) In-Reply-To: References: Message-ID: <1100057576.4782.65.camel@athlon.localdomain> Hello Pavel, On Tue, 2004-11-09 at 15:29, Pavel Tsekov wrote: > The internal editor sometimes outputs more than one char on the screen for > a given byte of input: I built with ncurses, applied the eol mark patch, but I do not see anything odd when following your instructions (go to end on line longer than screen and press ctrl-L). I do have UTF-8 patches applied, but I don't think that matters. Don't see any difference no matter the state of "fake half tabs". Could it be this is an issue with ncurses? Or is the example bad? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Wed Nov 10 06:43:18 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 10 Nov 2004 07:43:18 +0100 Subject: Call for development freeze In-Reply-To: <1100007011.4810.18.camel@athlon.localdomain> References: <1100007011.4810.18.camel@athlon.localdomain> Message-ID: <4191B886.6080300@gmx.de> Leonard den Ottolander wrote: > Roland is double checking the shell scripts in extfs for quoting errors. Here are some more issues regarding the VFS shell scripts. Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: extfs-quoting.patch Type: text/x-patch Size: 3864 bytes Desc: not available URL: From roland.illig at gmx.de Wed Nov 10 06:50:38 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 10 Nov 2004 07:50:38 +0100 Subject: mcedit issues In-Reply-To: <200411050933.iA59XPVx051149@email.zp.ua> References: <200411050933.iA59XPVx051149@email.zp.ua> Message-ID: <4191BA3E.9070402@gmx.de> >>Andrew, does this patch fix the issue you are seeing? > Yes. So I committed it. Shall we still discuss the use of GString? Roland From me at pavelsh.pp.ru Wed Nov 10 08:38:16 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 10 Nov 2004 13:38:16 +0500 Subject: mctest results from FreeBSD 5.2.1 Message-ID: <1274048268.20041110133816@pavelsh.pp.ru> Hello mc-devel, -----test0.err-------- editcmd.c: In function `edit_replace_prompt': editcmd.c:1186: warning: unused variable `label_len' regex.c:57:53: warning: "HAVE_WCTYPE_H" is not defined In file included from regex.c:637: regex.c:2242:54: warning: "HAVE_WCTYPE_H" is not defined regex.c:3295:53: warning: "HAVE_WCTYPE_H" is not defined ---------------------- -----test-1.err------- ERROR: files left in build directory after distclean: ./intl/plural.c ---------------------- -- Best regards, Pavel mailto:me at pavelsh.pp.ru From ptsekov at gmx.net Wed Nov 10 07:41:14 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 10 Nov 2004 08:41:14 +0100 Subject: edit_status () prints bad status line (fwd) In-Reply-To: <1100056675.4782.49.camel@athlon.localdomain> References: <1100056675.4782.49.camel@athlon.localdomain> Message-ID: Hello, On Wed, 10 Nov 2004, Leonard den Ottolander wrote: > Hi Pavel, > > On Tue, 2004-11-09 at 15:31, Pavel Tsekov wrote: > > While working on the editor I noticed that the status line outputs > > more characters than the actual number of columns. > > I finally got to building mc with ncurses. I verified the issue exists > and that the patch fixes the issue. Please commit. Something should be made to fix this issue - if it is what I suggested or the patch that Rolland suggested doesn't matter. It is up to Rolland I guess. From andrew at email.zp.ua Wed Nov 10 10:51:37 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 10 Nov 2004 12:51:37 +0200 (EET) Subject: strippwd patch against CVS20041108 In-Reply-To: <119343044.20041110001057@pavelsh.pp.ru> Message-ID: <200411101051.iAAApblO058335@email.zp.ua> Hello, > LdO> These are the hunks of the strippwd patch that have not yet been > LdO> committed. > > Committed with my fixes. Patch below fixes double free, memory leaks and missed {}. Also it introduces new enum to do add2hotlist() calls more readable. Second part is optimization. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotlist.c.patch URL: From me at pavelsh.pp.ru Wed Nov 10 11:00:14 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 10 Nov 2004 16:00:14 +0500 Subject: strippwd patch against CVS20041108 In-Reply-To: <200411101051.iAAApblO058335@email.zp.ua> References: <119343044.20041110001057@pavelsh.pp.ru> <200411101051.iAAApblO058335@email.zp.ua> Message-ID: <1775853871.20041110160014@pavelsh.pp.ru> Hello Andrew, Wednesday, November 10, 2004, 3:51:37 PM, you wrote: >> LdO> These are the hunks of the strippwd patch that have not yet been >> LdO> committed. >> >> Committed with my fixes. AVS> Patch below fixes double free, memory leaks and missed {}. AVS> Also it introduces new enum to do add2hotlist() calls more readable. AVS> Second part is optimization. Committed. Thx! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From andrew at email.zp.ua Wed Nov 10 12:45:25 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 10 Nov 2004 14:45:25 +0200 (EET) Subject: mctest results from FreeBSD 5.2.1 In-Reply-To: <1274048268.20041110133816@pavelsh.pp.ru> Message-ID: <200411101245.iAACjPqe062617@email.zp.ua> > -----test0.err-------- > editcmd.c: In function `edit_replace_prompt': > editcmd.c:1186: warning: unused variable `label_len' Shall we still discuss the use of GString? > regex.c:57:53: warning: "HAVE_WCTYPE_H" is not defined > In file included from regex.c:637: > regex.c:2242:54: warning: "HAVE_WCTYPE_H" is not defined > regex.c:3295:53: warning: "HAVE_WCTYPE_H" is not defined Test attached patch, please. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: regex.c.patch URL: From roland.illig at gmx.de Wed Nov 10 13:45:34 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 10 Nov 2004 14:45:34 +0100 Subject: mctest results from FreeBSD 5.2.1 In-Reply-To: <200411101245.iAACjPqe062617@email.zp.ua> References: <200411101245.iAACjPqe062617@email.zp.ua> Message-ID: <41921B7E.4000302@gmx.de> Andrew V. Samoilov wrote: >>-----test0.err-------- >>editcmd.c: In function `edit_replace_prompt': >>editcmd.c:1186: warning: unused variable `label_len' > > Shall we still discuss the use of GString? If that was meant some kind of ironically, I say: No. The problem here is that the macro convert_to_display does not evaluate its argument if CHARSET is disabled. The macro should be fixed, not the source code. > +#ifndef HAVE_WCTYPE_H > +#define HAVE_WCTYPE_H 0 > +#endif > + That's streightforward and works for me. Roland From me at pavelsh.pp.ru Wed Nov 10 13:47:10 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 10 Nov 2004 18:47:10 +0500 Subject: mctest results from FreeBSD 5.2.1 In-Reply-To: <200411101245.iAACjPqe062617@email.zp.ua> References: <1274048268.20041110133816@pavelsh.pp.ru> <200411101245.iAACjPqe062617@email.zp.ua> Message-ID: <1229534606.20041110184710@pavelsh.pp.ru> Hello Andrew, Wednesday, November 10, 2004, 5:45:25 PM, you wrote: >> regex.c:57:53: warning: "HAVE_WCTYPE_H" is not defined >> In file included from regex.c:637: >> regex.c:2242:54: warning: "HAVE_WCTYPE_H" is not defined >> regex.c:3295:53: warning: "HAVE_WCTYPE_H" is not defined AVS> Test attached patch, please. Thx. It working fine. I have been committed it. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From ptsekov at gmx.net Wed Nov 10 12:02:25 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 10 Nov 2004 13:02:25 +0100 Subject: [PATCH] Internal editor brokeness with ncurses (fwd) In-Reply-To: References: Message-ID: Hello, Here is a changelog entry for this patch: 2004-11-10 Pavel Tsekov * editdraw.c (print_to_widget): Don't use addch() with negative offset to skip over excessive columns. Output only those columns that should be displayed on the screen. From me at pavelsh.pp.ru Wed Nov 10 14:09:51 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 10 Nov 2004 19:09:51 +0500 Subject: edit_status () prints bad status line (fwd) In-Reply-To: References: Message-ID: <637999786.20041110190951@pavelsh.pp.ru> Hello Pavel, Tuesday, November 9, 2004, 7:31:34 PM, you wrote: PT> While working on the editor I noticed that the status line outputs PT> more characters than the actual number of columns. PT> printw ("%-*s", fname_len + gap, fname); PT> if (fname_len + gap < w) PT> printw ("%-*s ", w - (fname_len + gap), status); PT> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PT> You should change the line above to: PT> printw ("%-*s ", w - (fname_len + gap + 2), status); Committed. Thx. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Wed Nov 10 14:10:23 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 10 Nov 2004 19:10:23 +0500 Subject: [PATCH] Internal editor brokeness with ncurses (fwd) In-Reply-To: References: Message-ID: <1374914439.20041110191023@pavelsh.pp.ru> Hello Pavel, Tuesday, November 9, 2004, 7:29:46 PM, you wrote: PT> Attached is a patch + testcase. .... PT> Now about the patch. It doesn't use the screen library's routine PT> move () to eat the excessive output, but rather doesn't generate PT> output at all for those columns. I tested MC compiled wiht both S-Lang PT> and ncurses on Cygwin and Linux. Committed. Thx. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Wed Nov 10 14:22:52 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 15:22:52 +0100 Subject: extfs shell scripts [was: Re: Call for development freeze] In-Reply-To: <4191B886.6080300@gmx.de> References: <1100007011.4810.18.camel@athlon.localdomain> <4191B886.6080300@gmx.de> Message-ID: <1100096572.4816.25.camel@athlon.localdomain> Hello Roland, On Wed, 2004-11-10 at 07:43, Roland Illig wrote: > Here are some more issues regarding the VFS shell scripts. > --- vfs/extfs/audio.in 18 Oct 2004 02:20:09 -0000 1.8 > - A=`echo $A | sed -e 's/\.//' -e 's/^\(.\)$/0\1/'` > + A=`echo "$A" | sed -e 's/\.//' -e 's/^\(.\)$/0\1/'` Unnecessary as the value of $A is only parsed, not passed to a shell, and not even interpreted by echo. > - if [ "$2" == "CDDB" ]; then > + if [ x"$2" = x"CDDB" ]; then More correct wrt old versions of bash. Ok. > Index: vfs/extfs/trpm > -name=`sed 's/.*\///;s/\.trpm$//' "$2"` > +name=`echo "$2" | sed 's/.*\///;s/\.trpm$//'` Please explain. What's the use of putting an echo "$2" in front? Again, quotes are not needed here. And shouldn't this command include an -e in this case? For the rest: Quoting of temporary file names is unnecessary as they have no spaces in their names, but technically correct, so ok. Other quotes are correct, but none of these omissions cause vulnerabilities. Still good to fix of course. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 14:24:09 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 15:24:09 +0100 Subject: edit_status () prints bad status line (fwd) In-Reply-To: References: <1100056675.4782.49.camel@athlon.localdomain> Message-ID: <1100096648.4816.28.camel@athlon.localdomain> Hello Pavel, On Wed, 2004-11-10 at 08:41, Pavel Tsekov wrote: > Something should be made to fix this issue - if it is what I suggested > or the patch that Rolland suggested doesn't matter. It is up to Rolland > I guess. I am not aware of any solutions to this problem presented by Roland, but the one line fix (adding + 2) does the trick. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 14:37:06 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 15:37:06 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <200411101051.iAAApblO058335@email.zp.ua> References: <200411101051.iAAApblO058335@email.zp.ua> Message-ID: <1100097425.4816.41.camel@athlon.localdomain> Hello Andrew, On Wed, 2004-11-10 at 11:51, Andrew V. Samoilov wrote: > Patch below fixes double free, memory leaks and missed {}. Double frees? Please explain. And what about - if (!ret || !title || !*title || !url || !*url) { + if (!ret) + return; + if (!title || !*title || !url || !*url) { ? title and url should always be g_free()d, because either of them can be non NULL even if ret is NULL. If I am not mistaken this should be dropped from the patch. I also don't see the use of to_free. What does it actually do? > Also it introduces new enum to do add2hotlist() calls more readable. enum is nice as it clears up the code and makes the comments in the code redundant. Not sure if we should introduce it before 4.6.1 though. > Second part is optimization. Even more patches to test in the time of which new patches will have emerged. Can we concentrate on fixing the last items and have a release please? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 14:40:01 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 15:40:01 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <1775853871.20041110160014@pavelsh.pp.ru> References: <119343044.20041110001057@pavelsh.pp.ru> <200411101051.iAAApblO058335@email.zp.ua> <1775853871.20041110160014@pavelsh.pp.ru> Message-ID: <1100097601.4816.45.camel@athlon.localdomain> Hello Pchel, On Wed, 2004-11-10 at 12:00, Pavel Shirshov (pchel) wrote: > AVS> Patch below fixes double free, memory leaks and missed {}. > AVS> Also it introduces new enum to do add2hotlist() calls more readable. > > AVS> Second part is optimization. > > Committed. Thx! Wow, that is fast. Did you check this patch for correctness? Can you explain me where the double free takes place? Is the optimization correct? Can we *please* concentrate on the last items on the todo list (see the wiki at http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs ) instead of introducing new and hardly tested code? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 14:41:34 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 15:41:34 +0100 Subject: [PATCH] Internal editor brokeness with ncurses (fwd) In-Reply-To: <1374914439.20041110191023@pavelsh.pp.ru> References: <1374914439.20041110191023@pavelsh.pp.ru> Message-ID: <1100097693.4816.48.camel@athlon.localdomain> Hi Pavel & Pavel, On Wed, 2004-11-10 at 15:10, Pavel Shirshov (pchel) wrote: > PT> Now about the patch. It doesn't use the screen library's routine > PT> move () to eat the excessive output, but rather doesn't generate > PT> output at all for those columns. I tested MC compiled wiht both S-Lang > PT> and ncurses on Cygwin and Linux. > > Committed. Thx. I couldn't reproduce the issue. So what does it fix? An outdated ncurses? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 14:55:01 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 15:55:01 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <200411101051.iAAApblO058335@email.zp.ua> References: <200411101051.iAAApblO058335@email.zp.ua> Message-ID: <1100098500.4816.55.camel@athlon.localdomain> On Wed, 2004-11-10 at 11:51, Andrew V. Samoilov wrote: > Patch below fixes double free, memory leaks and missed {}. Hm. So you use to_free to g_free() to_free, title and url in one go. Now please explain how you can call add2hotlist() with title and url as parameters after this? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 15:03:16 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 16:03:16 +0100 Subject: subshell prompt fix In-Reply-To: <178535947.20041103152939@pavelsh.pp.ru> References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> Message-ID: <1100098995.4816.58.camel@athlon.localdomain> Hello pchel, On Wed, 2004-11-03 at 11:29, Pavel Shirshov (pchel) wrote: > 2) you see: genie# > 4) you see: > ^^^^^^^^^^^ I can't see promt. + printf ("\n\r%s", subshell_prompt); What happens if you leave out the "\r" in the above line? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Wed Nov 10 15:13:08 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 10 Nov 2004 16:13:08 +0100 Subject: extfs shell scripts [was: Re: Call for development freeze] In-Reply-To: <1100096572.4816.25.camel@athlon.localdomain> References: <1100007011.4810.18.camel@athlon.localdomain> <4191B886.6080300@gmx.de> <1100096572.4816.25.camel@athlon.localdomain> Message-ID: <41923004.7060402@gmx.de> Leonard den Ottolander wrote: > Hello Roland, > > On Wed, 2004-11-10 at 07:43, Roland Illig wrote: > >>Here are some more issues regarding the VFS shell scripts. > > >>--- vfs/extfs/audio.in 18 Oct 2004 02:20:09 -0000 1.8 >>- A=`echo $A | sed -e 's/\.//' -e 's/^\(.\)$/0\1/'` >>+ A=`echo "$A" | sed -e 's/\.//' -e 's/^\(.\)$/0\1/'` > > > Unnecessary as the value of $A is only parsed, not passed to a shell, > and not even interpreted by echo. I always provide a single string to echo(1). $A could be splitted into many words and lose some whitespace. "$A" passes the value of $A literally to the command, $A interprets it. >>- if [ "$2" == "CDDB" ]; then >>+ if [ x"$2" = x"CDDB" ]; then > > More correct wrt old versions of bash. Ok. This has nothing to do with bash. Let $2 be "-f". Then the [(1) command line looks like: [ -f == CDDB ] The "-f" is interpreted as the command to look for the existence of a regular file. Putting an "x" (or almost every other character) in front of the "-f" makes the "==" the command. >>Index: vfs/extfs/trpm >>-name=`sed 's/.*\///;s/\.trpm$//' "$2"` >>+name=`echo "$2" | sed 's/.*\///;s/\.trpm$//'` > Please explain. What's the use of putting an echo "$2" in front? Again, > quotes are not needed here. And shouldn't this command include an -e in > this case? The sed command is most likely supposed to transform the value of $2, not the file named by $2. The "-e" option is not necessary when passing exactly one command to sed. > For the rest: Quoting of temporary file names is unnecessary as they > have no spaces in their names, but technically correct, so ok. What about MC_TMPDIR="/Users/Leonard den Ottolander/temp"? Currently most scripts will break, but I want them not to break. What if MC_TMPDIR="/tmp/foo /*"? rm -rf $MC_TMPDIR Roland From leonard at den.ottolander.nl Wed Nov 10 15:22:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 16:22:50 +0100 Subject: extfs shell scripts [was: Re: Call for development freeze] In-Reply-To: <41923004.7060402@gmx.de> References: <1100007011.4810.18.camel@athlon.localdomain> <4191B886.6080300@gmx.de> <1100096572.4816.25.camel@athlon.localdomain> <41923004.7060402@gmx.de> Message-ID: <1100100169.4816.64.camel@athlon.localdomain> Hello Roland, On Wed, 2004-11-10 at 16:13, Roland Illig wrote: > >>Index: vfs/extfs/trpm > >>-name=`sed 's/.*\///;s/\.trpm$//' "$2"` > >>+name=`echo "$2" | sed 's/.*\///;s/\.trpm$//'` > The sed command is most likely supposed to transform the value of $2, > not the file named by $2. I hadn't realized this functionality change. I suspect the original code is correct. Have you tested this? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Wed Nov 10 13:25:39 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 10 Nov 2004 14:25:39 +0100 Subject: edit_status () prints bad status line (fwd) In-Reply-To: <1100096648.4816.28.camel@athlon.localdomain> References: <1100056675.4782.49.camel@athlon.localdomain> <1100096648.4816.28.camel@athlon.localdomain> Message-ID: Hello Leonard, On Wed, 10 Nov 2004, Leonard den Ottolander wrote: > I am not aware of any solutions to this problem presented by Roland, but > the one line fix (adding + 2) does the trick. http://mail.gnome.org/archives/mc-devel/2004-November/msg00003.html From leonard at den.ottolander.nl Wed Nov 10 15:27:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 16:27:27 +0100 Subject: extfs shell scripts [was: Re: Call for development freeze] In-Reply-To: <1100100169.4816.64.camel@athlon.localdomain> References: <1100007011.4810.18.camel@athlon.localdomain> <4191B886.6080300@gmx.de> <1100096572.4816.25.camel@athlon.localdomain> <41923004.7060402@gmx.de> <1100100169.4816.64.camel@athlon.localdomain> Message-ID: <1100100447.4816.66.camel@athlon.localdomain> On Wed, 2004-11-10 at 16:22, Leonard den Ottolander wrote: > Hello Roland, > > On Wed, 2004-11-10 at 16:13, Roland Illig wrote: > > >>Index: vfs/extfs/trpm > > >>-name=`sed 's/.*\///;s/\.trpm$//' "$2"` > > >>+name=`echo "$2" | sed 's/.*\///;s/\.trpm$//'` > > > The sed command is most likely supposed to transform the value of $2, > > not the file named by $2. > > I hadn't realized this functionality change. I suspect the original code > is correct. Have you tested this? This causes breakage. Revert. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 15:38:02 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 16:38:02 +0100 Subject: subshell prompt fix In-Reply-To: <1100098995.4816.58.camel@athlon.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> <1100098995.4816.58.camel@athlon.localdomain> Message-ID: <1100101081.4816.69.camel@athlon.localdomain> Hi, I wrote: > What happens if you leave out the "\r" in the above line? That is no good. The "\r" seems to actually be needed. Disregard this suggestion. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Wed Nov 10 13:42:35 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 10 Nov 2004 14:42:35 +0100 Subject: [PATCH] Internal editor brokeness with ncurses (fwd) In-Reply-To: <1100097693.4816.48.camel@athlon.localdomain> References: <1374914439.20041110191023@pavelsh.pp.ru> <1100097693.4816.48.camel@athlon.localdomain> Message-ID: Hello Leonard, Here is a simple prog to demonstrate the problem - it shows two things: 1) If you print more than COLS characters via addch - those characters appear on the next line. 2) move with negative argument (as used in the old code) fails with -1 on ncurses. It takes two arguments - how many columns (charcters to print) and the char to use to fill the columns i.e.: ./addch 90 a should print the character 'a' 90 times - going to the next line on 80 columns display. gcc -o addch addch.c -lncurses -------------- next part -------------- #include #include #include int main (int argc, char **argv) { int i, cols; int move_ret; if (argc < 3) { printf ("%s \n", argv[0]); exit (1); } cols = atoi (argv[1]); initscr (); move_ret = move (0, -1); move (0,0); for (i = 0; i < cols; i++) { addch (*argv[2]); } refresh (); sleep (10); endwin (); printf ("move(0, -1) = %d", move_ret); exit (0); } From andrew at email.zp.ua Wed Nov 10 15:41:50 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 10 Nov 2004 17:41:50 +0200 (EET) Subject: strippwd patch against CVS20041108 In-Reply-To: <1100097425.4816.41.camel@athlon.localdomain> Message-ID: <200411101541.iAAFfopR069401@email.zp.ua> > Hello Andrew, > > On Wed, 2004-11-10 at 11:51, Andrew V. Samoilov wrote: > > Patch below fixes double free, memory leaks and missed {}. > > Double frees? Please explain. . . . if (ret == B_ENTER || ret == B_APPEND) add2hotlist (title, url, HL_TYPE_ENTRY, 2); else add2hotlist (title, url, HL_TYPE_ENTRY, 1); hotlist_state.modified = 1; g_free (title); g_free (url); . . . title and url are g_free()d here and in remove_group()|remove_from_hotlist() after. > And what about > > - if (!ret || !title || !*title || !url || !*url) { > + if (!ret) > + return; > + if (!title || !*title || !url || !*url) { > > ? title and url should always be g_free()d, because either of them can > be non NULL even if ret is NULL. Well, add_new_entry_input() returns 0 if query_dialog() is canceled. query_dialog() does not strdup() str_result's, so title and url are unchanged this way. > If I am not mistaken this should be dropped from the patch. I also don't > see the use of to_free. What does it actually do? to_free = strip_password (g_strdup (current_panel->cwd), 1), so this memory area needs its own g_free(). url and title will be newly allocated strings if user does not cancel query_dialog(). > enum is nice as it clears up the code and makes the comments in the code > redundant. Not sure if we should introduce it before 4.6.1 though. This part is trivial. > > Second part is optimization. > > Even more patches to test in the time of which new patches will have > emerged. Can we concentrate on fixing the last items and have a release > please? They are trivial too, these hunks were produced when I discovered mc crash on Pavel's report. There are some dozens of bugs to fix, and some of then are not in TODO after they were intoduced on mc-devel at gnome.org. -- Regards, Andrew V. Samoilov. From leonard at den.ottolander.nl Wed Nov 10 15:54:21 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 16:54:21 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <200411101541.iAAFfopR069401@email.zp.ua> References: <200411101541.iAAFfopR069401@email.zp.ua> Message-ID: <1100102060.4816.73.camel@athlon.localdomain> Hello Andrew, On Wed, 2004-11-10 at 16:41, Andrew V. Samoilov wrote: > There are some dozens of bugs to fix, and some of then are not in TODO > after they were intoduced on mc-devel at gnome.org. I'm not arguing that those should be fixed before the release. My concern is about introduction of new code and optimizations that make a release a very moving target. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jnovy at redhat.com Wed Nov 10 16:15:59 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 10 Nov 2004 17:15:59 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <119343044.20041110001057@pavelsh.pp.ru> References: <1100009606.4810.47.camel@athlon.localdomain> <119343044.20041110001057@pavelsh.pp.ru> Message-ID: <1100103359.7335.3.camel@obelix.redhat.usu> Hello Pavel, On Tue, 2004-11-09 at 20:10, me at pavelsh.pp.ru wrote: > Hello Leonard, > > Tuesday, November 9, 2004, 7:13:26 PM, you wrote: > > LdO> These are the hunks of the strippwd patch that have not yet been > LdO> committed. > > Committed with my fixes. Note that your "fix" actually reintroduced the bug I've been trying to fix. So the path is now cut out again. -- Jindrich Novy , http://people.redhat.com/jnovy/ From leonard at den.ottolander.nl Wed Nov 10 16:22:24 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 17:22:24 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <200411101541.iAAFfopR069401@email.zp.ua> References: <200411101541.iAAFfopR069401@email.zp.ua> Message-ID: <1100103743.4816.86.camel@athlon.localdomain> Hello Andrew, I do have some questions about add_new_entry_cmd() in its current form. Comments inlined in C99 style comments. static void add_new_entry_cmd (void) { char *title, *url, *to_free; int ret; /* Take current directory as default value for input fields */ to_free = title = url = strip_password (g_strdup (current_panel->cwd), 1); // to_free, title and url now all point to the same string, right? // They are not all duplicates? ret = add_new_entry_input (_("New hotlist entry"), _("Directory label"), _("Directory path"), "[Hotlist]", &title, &url); g_free (to_free); // So this g_free() frees that string which is now invalid if (!ret) return; if (!title || !*title || !url || !*url) { g_free (title); g_free (url); // But here you still g_free() both of them return; } if (ret == B_ENTER || ret == B_APPEND) add2hotlist (title, url, HL_TYPE_ENTRY, HL_AFTER_CURRENT); else add2hotlist (title, url, HL_TYPE_ENTRY, HL_BEFORE_CURRENT); // And here you pass them as arguments. hotlist_state.modified = 1; } Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 10 16:42:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 17:42:43 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <1100103359.7335.3.camel@obelix.redhat.usu> References: <1100009606.4810.47.camel@athlon.localdomain> <119343044.20041110001057@pavelsh.pp.ru> <1100103359.7335.3.camel@obelix.redhat.usu> Message-ID: <1100104962.4816.89.camel@athlon.localdomain> Hello Jindrich, On Wed, 2004-11-10 at 17:15, Jindrich Novy wrote: > Note that your "fix" actually reintroduced the bug I've been trying to > fix. So the path is now cut out again. I was also wondering about that "\0" and no PATH_SEP insertion. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jnovy at redhat.com Wed Nov 10 17:07:08 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 10 Nov 2004 18:07:08 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <1100103359.7335.3.camel@obelix.redhat.usu> References: <1100009606.4810.47.camel@athlon.localdomain> <119343044.20041110001057@pavelsh.pp.ru> <1100103359.7335.3.camel@obelix.redhat.usu> Message-ID: <1100106427.26251.11.camel@obelix.redhat.usu> Hello Pavel, Leonard, On Wed, 2004-11-10 at 17:15, Jindrich Novy wrote: > Hello Pavel, > > On Tue, 2004-11-09 at 20:10, me at pavelsh.pp.ru wrote: > > Hello Leonard, > > > > Tuesday, November 9, 2004, 7:13:26 PM, you wrote: > > > > LdO> These are the hunks of the strippwd patch that have not yet been > > LdO> committed. > > > > Committed with my fixes. > > Note that your "fix" actually reintroduced the bug I've been trying to > fix. So the path is now cut out again. I checked out the latest CVS snapshot and see you fixed it. Thanks for it, because moving the if (dir) condition before if (at) should fix the path bug. Anyway I don't agree with the style of the fix. The only different functionality you did is that you seek for '@' backwards (strrchr) and you need to zero out one character in p, which is also argument of the function and the return it back to PATH_SEP. The attached patch is doing the same thing, but without the ugly zero and '/' return style. Note that the only change to do is to substitute memchr with memrchr in my original patch. Patch to the latest CVS snapshot is attached. -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-4.6.1-20041110-spw.patch Type: text/x-patch Size: 855 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Nov 10 17:11:24 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Nov 2004 18:11:24 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <1100103743.4816.86.camel@athlon.localdomain> References: <200411101541.iAAFfopR069401@email.zp.ua> <1100103743.4816.86.camel@athlon.localdomain> Message-ID: <1100106684.4816.92.camel@athlon.localdomain> Hi, I wrote: > ret = add_new_entry_input (_("New hotlist entry"), _("Directory > label"), > _("Directory path"), "[Hotlist]", &title, &url); I get from Roland that title and url get created here and ret != 0 if this function is executed successfully. I get it now ;) Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Wed Nov 10 17:17:21 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Wed, 10 Nov 2004 19:17:21 +0200 (EET) Subject: strippwd patch against CVS20041108 In-Reply-To: <1100103743.4816.86.camel@athlon.localdomain> Message-ID: <200411101717.iAAHHLDx072609@email.zp.ua> Hello, Leonard! Please answer to mc-devel at gnome.org only, my mailbox is near to my disk quota. > I do have some questions about add_new_entry_cmd() in its current form. > Comments inlined in C99 style comments. > > static void add_new_entry_cmd (void) > { > char *title, *url, *to_free; > int ret; > > /* Take current directory as default value for input fields */ > to_free = title = url = strip_password (g_strdup > (current_panel->cwd), 1); > > // to_free, title and url now all point to the same string, right? Yes. > // They are not all duplicates? Yes if I parse this right. Well, add_new_entry_input() use title and url in two ways: 1) it use their string values to display 2) it use their addresses to return g_strdup()ed user input > ret = add_new_entry_input (_("New hotlist entry"), _("Directory > label"), > _("Directory path"), "[Hotlist]", &title, &url); > g_free (to_free); > // So this g_free() frees that string which is now invalid Right. Let user does not cancel query_dialog: title and url point now to different memory areas allocated in query_dialog() to_free != url to_free != title title != url > if (!ret) > return; > if (!title || !*title || !url || !*url) { > g_free (title); > g_free (url); > // But here you still g_free() both of them To fix memory leaks. > return; > } And return. > if (ret == B_ENTER || ret == B_APPEND) > add2hotlist (title, url, HL_TYPE_ENTRY, HL_AFTER_CURRENT); > else > add2hotlist (title, url, HL_TYPE_ENTRY, HL_BEFORE_CURRENT); > // And here you pass them as arguments. Yes, they now point to g_strdup()ped user input. > hotlist_state.modified = 1; > } -- Regards, Andrew V. Samoilov. From roland.illig at gmx.de Wed Nov 10 17:21:58 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 10 Nov 2004 18:21:58 +0100 Subject: hotlist.c, code beautification Message-ID: <41924E36.4010804@gmx.de> Hi, I have rewritten parts of hotlist.c to be easier to understand. (I hope it really will.) I think the patched version makes it clear which function is responsible for freeing the allocated memory. These are the changes I made. add2hotlist gets "const char *" arguments instead of "char *". It will then create local copies with g_strdup() as needed. This way it will not be possible after the return of add2hotlist() to alter the strings that are saved. You can also be sure that add2hotlist does not free the strings you are passing. In the function add_new_entry_input the "inout" r1 and r2 arguments are splitted into "in" arguments and "out" arguments. The "in" arguments are not modified by the function and have nothing to do with the "out" arguments, so why should they be passed using the same variable? The main changes are in the function add_new_entry_cmd. All variables that probably contain allocated strings are explicitly initialized. This is especially important for title and url, as the function add_new_entry_input does not give any guarantees about the return value in case of an error. Each of these variables will never be assigned more than one value. After all the work has been done, they are freed. Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: hotlist.patch Type: text/x-patch Size: 2972 bytes Desc: not available URL: From jnovy at redhat.com Wed Nov 10 17:39:54 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 10 Nov 2004 18:39:54 +0100 Subject: strippwd patch against CVS20041108 In-Reply-To: <200411101051.iAAApblO058335@email.zp.ua> References: <200411101051.iAAApblO058335@email.zp.ua> Message-ID: <1100108394.26251.31.camel@obelix.redhat.usu> Hello Andrew, On Wed, 2004-11-10 at 11:51, Andrew V. Samoilov wrote: > Hello, > > > LdO> These are the hunks of the strippwd patch that have not yet been > > LdO> committed. > > > > Committed with my fixes. > > Patch below fixes double free, memory leaks and missed {}. > Also it introduces new enum to do add2hotlist() calls more readable. > > Second part is optimization. About the (add2hotlist_cmd): Eliminate static label_string: I implemented the label_string to be static in order to your comment #16 on Red Hat bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131088 where you replied to my question where the label_string is leaked in my original implementation of strippwd patch (where label_string is g_strdup()ed): AVS >label_string is leaked if input_dialog() returns NULL or empty string. AVS >In last case this memory (g_strdup("")) is also leaked. >From the patch I see you reintroduced this. Otherwise please make it clear to me. -- Jindrich Novy , http://people.redhat.com/jnovy/ From leonard at den.ottolander.nl Wed Nov 10 23:17:02 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 11 Nov 2004 00:17:02 +0100 Subject: g_free() url and title in add_new_entry_cmd() Message-ID: <1100128621.4781.3.camel@athlon.localdomain> Hi, Shouldn't url and title be g_free()d after the call to add2hotlist in add_new_entry_cmd()? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Thu Nov 11 06:09:27 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 11 Nov 2004 11:09:27 +0500 Subject: strippwd patch against CVS20041108 In-Reply-To: <1100106427.26251.11.camel@obelix.redhat.usu> References: <1100009606.4810.47.camel@athlon.localdomain> <119343044.20041110001057@pavelsh.pp.ru> <1100103359.7335.3.camel@obelix.redhat.usu> <1100106427.26251.11.camel@obelix.redhat.usu> Message-ID: <1751752061.20041111110927@pavelsh.pp.ru> Hello Jindrich, Wednesday, November 10, 2004, 10:07:08 PM, you wrote: JN> The attached patch is doing the same thing, but without the ugly zero JN> and '/' return style. Note that the only change to do is to substitute JN> memchr with memrchr in my original patch. memrchr isn't standard function. ........ The memrchr() function is a GNU extension, available since glibc 2.1.91. ........ memrchr isn't present in FreeBSD 5.2.1. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From andrew at email.zp.ua Thu Nov 11 08:27:31 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 11 Nov 2004 10:27:31 +0200 (EET) Subject: strippwd patch against CVS20041108 In-Reply-To: <1100108394.26251.31.camel@obelix.redhat.usu> Message-ID: <200411110827.iAB8RVVf000561@email.zp.ua> Hello Jindrich, > About the (add2hotlist_cmd): Eliminate static label_string: > > I implemented the label_string to be static in order to your comment #16 > on Red Hat bugzilla: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131088 > > where you replied to my question where the label_string is leaked in my > original implementation of strippwd patch (where label_string is > g_strdup()ed): > > AVS >label_string is leaked if input_dialog() returns NULL or empty > string. > AVS >In last case this memory (g_strdup("")) is also leaked. > > From the patch I see you reintroduced this. Otherwise please make it > clear to me. I added these lines to fix memory leak and to eliminate static buffer: if (!label || !*label) { g_free (label_string); g_free (label); return; } -- Regards, Andrew V. Samoilov. From andrew at email.zp.ua Thu Nov 11 08:35:21 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 11 Nov 2004 10:35:21 +0200 (EET) Subject: g_free() url and title in add_new_entry_cmd() In-Reply-To: <1100128621.4781.3.camel@athlon.localdomain> Message-ID: <200411110835.iAB8ZLLJ000941@email.zp.ua> Hi, Leonard > Shouldn't url and title be g_free()d after the call to add2hotlist in > add_new_entry_cmd()? No, it will lead to double free because title and url are g_free()d in remove_group() or remove_from_hotlist(). -- Regards, Andrew V. Samoilov. From andrew at email.zp.ua Thu Nov 11 08:36:27 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 11 Nov 2004 10:36:27 +0200 (EET) Subject: mcedit issues In-Reply-To: <4191BA3E.9070402@gmx.de> Message-ID: <200411110836.iAB8aRD4001019@email.zp.ua> > >>Andrew, does this patch fix the issue you are seeing? > > Yes. > > So I committed it. Thanks. There was second patch against syntax.c > Shall we still discuss the use of GString? Not now. -- Regards, Andrew V. Samoilov. From pavel at ucw.cz Thu Nov 11 09:49:36 2004 From: pavel at ucw.cz (Pavel Machek) Date: Thu, 11 Nov 2004 10:49:36 +0100 Subject: LGPL code using GPL code In-Reply-To: <200410191749.i9JHnAaJ068315@email.zp.ua> References: <1098205084.4811.129.camel@athlon.localdomain> <200410191749.i9JHnAaJ068315@email.zp.ua> Message-ID: <20041111094936.GA17104@elf.ucw.cz> Hi! > > Although we haven't had an answer on Andrew Samoilov's request to > > Jindrich Novy from Red Hat for legal advise on whether LGPL code can use > > GPL functions legally I think Roland is correct in assuming this is not > > the case. Compare > > http://www.fsf.org/licenses/gpl-faq.html#IfLibraryIsGPL . > > > > We might want to decide to change all the relevant code in vfs to GPL. > > Probably a good idea to release a tarball before the change, so people > > can easily find the last LGPL version if they want to work from that. > > This is mainly a formality. > > > > Any thoughts on when such a transition should take place? > > License may change back to GPL if all the VFS authors agree ;-( > I think it will take a long time. Idea of LGPL inside gnomevfs was that you want to use it in other projects... I'm not sure any other project actually uses it, but it would be nice to keep that possibility. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! From me at pavelsh.pp.ru Thu Nov 11 14:46:15 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 11 Nov 2004 19:46:15 +0500 Subject: Bug in mc command line In-Reply-To: <1482740086.20041109121255@pavelsh.pp.ru> References: <1482740086.20041109121255@pavelsh.pp.ru> Message-ID: <1352352659.20041111194615@pavelsh.pp.ru> Hello Pavel, Tuesday, November 9, 2004, 12:12:55 PM, you wrote: PSp> Please, enter in command line: PSp> $ cat cisco.log | grep %LINK-3-UPDOWN PSp> Press Enter, and you'll get PSp> $ cat cisco.log | grep %INK-3-UPDOWN Attached file is my fix -- Best regards, Pavel mailto:me at pavelsh.pp.ru -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mc-command-line.patch.txt URL: From leonard at den.ottolander.nl Thu Nov 11 15:08:24 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 11 Nov 2004 16:08:24 +0100 Subject: Bug in mc command line In-Reply-To: <1352352659.20041111194615@pavelsh.pp.ru> References: <1482740086.20041109121255@pavelsh.pp.ru> <1352352659.20041111194615@pavelsh.pp.ru> Message-ID: <1100185703.4782.63.camel@athlon.localdomain> Hello Pavel, On Thu, 2004-11-11 at 15:46, Pavel Shirshov (pchel) wrote: > Attached file is my fix Jindrich send a much simpler patch to fix this issue to the list already on Tuesday. If his patch fixes the issue I think you should go with that. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From egmont at uhulinux.hu Thu Nov 11 17:07:09 2004 From: egmont at uhulinux.hu (Egmont Koblinger) Date: Thu, 11 Nov 2004 18:07:09 +0100 Subject: mouse click offset in help Message-ID: <20041111170709.GA25020@cs.bme.hu> Hi, In the help screen (F1) the rectangular area which accepts mouse click for a link is shiftedtwo characters to the left. This means that the last two letters of a link don't accept mouse click, however, two characters left from the link do. Attached patch fixes both for 4.6.0 and 2004-11-04-15 snapshot. -- Egmont -------------- next part -------------- diff -Naur mc-4.6.0.orig/src/help.c mc-4.6.0/src/help.c --- mc-4.6.0.orig/src/help.c 2002-11-13 05:01:05.000000000 +0100 +++ mc-4.6.0/src/help.c 2004-11-11 02:24:47.000000000 +0100 @@ -389,11 +389,11 @@ } else attrset (HELP_LINK_COLOR); - start_link_area (col, line, p); + start_link_area (col + 2, line, p); break; case CHAR_LINK_POINTER: painting = 0; - end_link_area (col - 1, line); + end_link_area (col + 1, line); break; case CHAR_LINK_END: painting = 1; From egmont at uhulinux.hu Thu Nov 11 17:10:14 2004 From: egmont at uhulinux.hu (Egmont Koblinger) Date: Thu, 11 Nov 2004 18:10:14 +0100 Subject: /usr/bin/mc --help prints stupid path Message-ID: <20041111171014.GB25020@cs.bme.hu> Hi, "/usr/bin/mc --help" prints this: Usage: usr/bin/mc [flags] [this_dir] [other_panel_dir] ^^^ Only the leading slash is stipped, which doesn't make too much sense. Trivial patch is attached, fixes both 4.6.0 and 2004-11-04-05 snapshot. bye, -- Egmont -------------- next part -------------- diff -Naur mc-4.6.0.orig/src/popthelp.c mc-4.6.0/src/popthelp.c --- mc-4.6.0.orig/src/popthelp.c 2002-10-24 12:02:40.000000000 +0200 +++ mc-4.6.0/src/popthelp.c 2004-11-11 00:20:54.000000000 +0100 @@ -179,7 +179,7 @@ fprintf(f, _("Usage:")); if (!(con->flags & POPT_CONTEXT_KEEP_FIRST)) { fn = con->optionStack->argv[0]; - if (strchr(fn, '/')) fn = strchr(fn, '/') + 1; + if (strchr(fn, '/')) fn = strrchr(fn, '/') + 1; fprintf(f, " %s", fn); len += strlen(fn) + 1; } From egmont at uhulinux.hu Thu Nov 11 17:29:46 2004 From: egmont at uhulinux.hu (Egmont Koblinger) Date: Thu, 11 Nov 2004 18:29:46 +0100 Subject: code cleanup for file quicksearch backspace Message-ID: <20041111172946.GC25020@cs.bme.hu> Hi, When in file quicksearch mode (^S or Alt-S) and the search string is empty, and I press backspace, then the ascii code of the backspace is put into the search buffer, just as if I pressed a regular letter, and then (since no filenames begin with backspace, at least on my system :-)) this will be removed some lines later in the code. The attached patch (against current cvs) fixes backspace in this case to do nothing. The patch doesn't change the behavior of mc (except if a filename really begins with a backspace) but it cleans up the code and makes it easier to port this code to understand UTF-8. bye, -- Egmont -------------- next part -------------- diff -Naur mc.orig/src/screen.c mc/src/screen.c --- mc.orig/src/screen.c 2004-11-03 21:31:59.000000000 +0100 +++ mc/src/screen.c 2004-11-11 18:23:38.544719201 +0100 @@ -1867,9 +1867,10 @@ int found; l = strlen (panel->search_buffer); - if (l && (c_code == KEY_BACKSPACE)) - panel->search_buffer[--l] = 0; - else { + if (c_code == KEY_BACKSPACE) { + if (l) + panel->search_buffer[--l] = 0; + } else { if (c_code && l < sizeof (panel->search_buffer)) { panel->search_buffer[l] = c_code; panel->search_buffer[l + 1] = 0; From roland.illig at gmx.de Thu Nov 11 17:35:27 2004 From: roland.illig at gmx.de (Roland Illig) Date: Thu, 11 Nov 2004 18:35:27 +0100 Subject: /usr/bin/mc --help prints stupid path In-Reply-To: <20041111171014.GB25020@cs.bme.hu> References: <20041111171014.GB25020@cs.bme.hu> Message-ID: <4193A2DF.4070409@gmx.de> Egmont Koblinger wrote: > - if (strchr(fn, '/')) fn = strchr(fn, '/') + 1; > + if (strchr(fn, '/')) fn = strrchr(fn, '/') + 1; Thanks for reporting this. I committed the patch slightly modified. (I replaced both strchr with strrchr, just for consistency.) Roland From leonard at den.ottolander.nl Thu Nov 11 23:13:08 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 12 Nov 2004 00:13:08 +0100 Subject: uglydir patch In-Reply-To: <1099495216.4819.121.camel@athlon.localdomain> References: <1099495216.4819.121.camel@athlon.localdomain> Message-ID: <1100214787.4782.78.camel@athlon.localdomain> With changelog entries this time. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-uglydir.patch Type: text/x-patch Size: 1555 bytes Desc: not available URL: From leonard at den.ottolander.nl Fri Nov 12 08:39:24 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 12 Nov 2004 09:39:24 +0100 Subject: copy to ../ from archive In-Reply-To: <20041109180801.GA12182@ugly.local> References: <20041109180801.GA12182@ugly.local> Message-ID: <1100248763.4785.9.camel@athlon.localdomain> Hi Oswald, On Tue, 2004-11-09 at 19:08, Oswald Buddenhagen wrote: > until recently i could enter a tar.gz and copy the contained direcory to > .., thus simply extracting it in the directory the tar lives in ... now > ... well, i can't anymore. Well, actually you still can. If you leave "preserve attributes" checked you get a warning that the file cannot be chmod. It has however been copied. If you uncheck the "preserve attributes" check box you won't get this warning. I'm looking into this, but if you can come up with a fix yourself you're welcome. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nadvornik at suse.cz Fri Nov 12 11:47:39 2004 From: nadvornik at suse.cz (Vladimir Nadvornik) Date: Fri, 12 Nov 2004 12:47:39 +0100 Subject: [PATCH] Internal editor brokeness with ncurses (fwd) In-Reply-To: References: Message-ID: <200411121247.39429.nadvornik@suse.cz> On Wednesday 10 November 2004 13:02, Pavel Tsekov wrote: > Here is a changelog entry for this patch: > > 2004-11-10 Pavel Tsekov > > * editdraw.c (print_to_widget): Don't use addch() with negative > offset to skip over excessive columns. Output only those columns > that should be displayed on the screen. > _______________________________________________ There is similar problem in dialog.c. If the dialog is wider than the screen, it writes to negative columns. This patch fixes it. --- src/dialog.c +++ src/dialog.c @@ -196,6 +196,12 @@ if ((flags & DLG_TRYUP) && (y1 > 3)) y1 -= 2; + if (x1 < 0) + x1 = 0; + + if (y1 < 0) + y1 = 0; + new_d = g_new0 (Dlg_head, 1); new_d->color = color_set; new_d->help_ctx = const_cast(char *, help_ctx); -- Vladimir Nadvornik developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: nadvornik at suse.cz Drahobejlova 27 tel:+420 2 9654 2373 190 00 Praha 9 fax:+420 2 9654 2374 Ceska republika http://www.suse.cz From bart at friesoft.nl Thu Nov 11 16:16:43 2004 From: bart at friesoft.nl (Bart Friederichs) Date: Thu, 11 Nov 2004 17:16:43 +0100 Subject: mc burn patch, version 0.2 Message-ID: <4193906B.5000204@friesoft.nl> A few years ago (2001) I wrote a patch to enable cd-writing in mc. I got an email from Andy Shevchenko, with some additions to it.. It now patches mc-4.6.1-pre1 and the saving of settings works. Attached the patch for mcburn 0.2 Regards, Bart -------------- next part -------------- A non-text attachment was scrubbed... Name: mcburn-0.2.patch Type: text/x-patch Size: 33389 bytes Desc: not available URL: From ossi at kde.org Sat Nov 13 09:48:23 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Sat, 13 Nov 2004 10:48:23 +0100 Subject: confirm deleting from hotlist Message-ID: <20041113094823.GA7755@ugly.local> moin, it happens quite often that i accidentally delete items from the hotlist - take the wrong angle when blindly moving up from the cursor block, and you hit del instead of enter. i think it would make sense if the hotlist obeyed the "confirm delete" option as well. alternatively, don't make del the delete action (but use f8 instead), but i think this sucks more. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From jnovy at redhat.com Mon Nov 15 09:02:23 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 15 Nov 2004 10:02:23 +0100 Subject: confirm deleting from hotlist In-Reply-To: <20041113094823.GA7755@ugly.local> References: <20041113094823.GA7755@ugly.local> Message-ID: <1100509343.15220.5.camel@obelix.redhat.usu> Hello Oswald, On Sat, 2004-11-13 at 10:48 +0100, Oswald Buddenhagen wrote: > moin, > > it happens quite often that i accidentally delete items from the hotlist > - take the wrong angle when blindly moving up from the cursor block, and > you hit del instead of enter. > i think it would make sense if the hotlist obeyed the "confirm delete" > option as well. > alternatively, don't make del the delete action (but use f8 instead), > but i think this sucks more. The attached patch adds dialog prompting an user to confirm removal of selected entry. It also introduces the "Don't ask" button. When pressed, it deletes actual entry and user won't be prompted for entry deletion any more so the 'del' key will act in the same fashion as up to now. greetings, Jindrich Novy -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041115-hotdel.patch Type: text/x-patch Size: 1073 bytes Desc: not available URL: From ossi at kde.org Mon Nov 15 10:24:14 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Mon, 15 Nov 2004 11:24:14 +0100 Subject: confirm deleting from hotlist In-Reply-To: <1100509343.15220.5.camel@obelix.redhat.usu> References: <20041113094823.GA7755@ugly.local> <1100509343.15220.5.camel@obelix.redhat.usu> Message-ID: <20041115102414.GC2759@ugly.local> On Mon, Nov 15, 2004 at 10:02:23AM +0100, Jindrich Novy wrote: > It also introduces the "Don't ask" button. When pressed, it deletes > actual entry and user won't be prompted for entry deletion any more so > the 'del' key will act in the same fashion as up to now. > i don't think it makes too much sense. as far as i see, it is not persistant. and mc does not have a track record of "don't ask again" checkboxes anyway, afair. you can make it consistent with non-empty directory deletion by making it possible to select multiple entries and have an "all" button in the confirmation dialog. but that seems to be major overkill to me. so if you really feel that the confirmation is so annoying (ermm, how often do you delete bookmarks?), add a separate option to the confirmations dialog (name it generically, like "confirm low-value delete" or something, to avoid adding more options of this type). -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From ptsekov at gmx.net Mon Nov 15 09:13:46 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 15 Nov 2004 10:13:46 +0100 Subject: [PATCH] Internal editor brokeness with ncurses (fwd) In-Reply-To: <200411121247.39429.nadvornik@suse.cz> References: <200411121247.39429.nadvornik@suse.cz> Message-ID: Hello, On Fri, 12 Nov 2004, Vladimir Nadvornik wrote: > On Wednesday 10 November 2004 13:02, Pavel Tsekov wrote: > > Here is a changelog entry for this patch: > > > > 2004-11-10 Pavel Tsekov > > > > * editdraw.c (print_to_widget): Don't use addch() with negative > > offset to skip over excessive columns. Output only those columns > > that should be displayed on the screen. > > _______________________________________________ > > > There is similar problem in dialog.c. If the dialog is wider than the screen, > it writes to negative columns. > This patch fixes it. > > --- src/dialog.c > +++ src/dialog.c > @@ -196,6 +196,12 @@ > if ((flags & DLG_TRYUP) && (y1 > 3)) > y1 -= 2; > > + if (x1 < 0) > + x1 = 0; > + > + if (y1 < 0) > + y1 = 0; > + I don't think so. The patch just avoids the use of negative offsets but it doesn't deal with the excessive line length afaics. If you read my explanation of the editor problem, you'll see that the unpleasent visual effect is due to fact that when using certain ncurses routines to write lines longer then COLS you'll get the excess columns on the next line. From leonard at den.ottolander.nl Mon Nov 15 15:18:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 15 Nov 2004 16:18:43 +0100 Subject: copy_file_file() cleanup Message-ID: <1100531923.4786.8.camel@athlon.localdomain> Hi, The error with copying files out of an archive using a ../ like path had me look at the copy_file_file() code a bit. I haven't found the cause of the error yet, but did some cleanup on the code. See attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: copy_file_file.patch Type: text/x-patch Size: 11320 bytes Desc: not available URL: From leonard at den.ottolander.nl Mon Nov 15 16:02:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 15 Nov 2004 17:02:25 +0100 Subject: [PATCH] Re: copy to ../ from archive In-Reply-To: <1100248763.4785.9.camel@athlon.localdomain> References: <20041109180801.GA12182@ugly.local> <1100248763.4785.9.camel@athlon.localdomain> Message-ID: <1100534544.4786.16.camel@athlon.localdomain> Hi folks, Pavel Tsekov and I tackled this problem. Problem are the calls to MC_NAMEOP in vfs/vfs.c. The callargs use path, but should use the canonicalized path (mpath) as call argument instead. See attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: MC_NAMEOP.patch Type: text/x-patch Size: 1650 bytes Desc: not available URL: From ptsekov at gmx.net Mon Nov 15 16:20:54 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 15 Nov 2004 18:20:54 +0200 Subject: [PATCH] Re: copy to ../ from archive In-Reply-To: <1100534544.4786.16.camel@athlon.localdomain> References: <20041109180801.GA12182@ugly.local> <1100248763.4785.9.camel@athlon.localdomain> <1100534544.4786.16.camel@athlon.localdomain> Message-ID: Hello, On Mon, 15 Nov 2004, Leonard den Ottolander wrote: > Hi folks, > > Pavel Tsekov and I tackled this problem. Problem are the calls to > MC_NAMEOP in vfs/vfs.c. The callargs use path, but should use the > canonicalized path (mpath) as call argument instead. See attached patch. See this for details: http://savannah.gnu.org/cgi-bin/viewcvs/mc/mc/vfs/vfs.c.diff?r1=1.160&r2=1.161&sortby=date&diff_format=u From roland.illig at gmx.de Mon Nov 15 22:55:01 2004 From: roland.illig at gmx.de (Roland Illig) Date: Mon, 15 Nov 2004 23:55:01 +0100 Subject: [PATCH] Re: copy to ../ from archive In-Reply-To: References: <20041109180801.GA12182@ugly.local> <1100248763.4785.9.camel@athlon.localdomain> <1100534544.4786.16.camel@athlon.localdomain> Message-ID: <419933C5.6020707@gmx.de> Pavel Tsekov wrote: > http://savannah.gnu.org/cgi-bin/viewcvs/mc/mc/vfs/vfs.c.diff?r1=1.160&r2=1.161&sortby=date&diff_format=u Committed. Agreed that it had been my fault. Roland From leonard at den.ottolander.nl Mon Nov 15 23:00:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 16 Nov 2004 00:00:50 +0100 Subject: [PATCH] copy_dir_dir cleanup Message-ID: <1100559649.4786.21.camel@athlon.localdomain> Hi, Similar to the copy_file_file cleanup. See attached patch for details. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: copy_dir_dir.patch Type: text/x-patch Size: 4446 bytes Desc: not available URL: From roland.illig at gmx.de Mon Nov 15 23:40:35 2004 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 16 Nov 2004 00:40:35 +0100 Subject: copy_file_file() cleanup In-Reply-To: <1100531923.4786.8.camel@athlon.localdomain> References: <1100531923.4786.8.camel@athlon.localdomain> Message-ID: <41993E73.6030808@gmx.de> Leonard den Ottolander wrote: > Hi, > > The error with copying files out of an archive using a ../ like path had > me look at the copy_file_file() code a bit. I haven't found the cause of > the error yet, but did some cleanup on the code. See attached patch. Committed. Roland From leonard at den.ottolander.nl Tue Nov 16 00:04:12 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 16 Nov 2004 01:04:12 +0100 Subject: copy_file_file() cleanup In-Reply-To: <41993E73.6030808@gmx.de> References: <1100531923.4786.8.camel@athlon.localdomain> <41993E73.6030808@gmx.de> Message-ID: <1100563451.4786.31.camel@athlon.localdomain> Hello Roland, On Tue, 2004-11-16 at 00:40, Roland Illig wrote: > Committed. You forgot to commit the vfs.h hunk. About the goto replaced with a while, attached patch gets rid of the break. Hope I use the correct operator here ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: file.c.diff Type: text/x-patch Size: 955 bytes Desc: not available URL: From ossi at kde.org Tue Nov 16 05:51:09 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Tue, 16 Nov 2004 06:51:09 +0100 Subject: copy_file_file() cleanup In-Reply-To: <1100563451.4786.31.camel@athlon.localdomain> References: <1100531923.4786.8.camel@athlon.localdomain> <41993E73.6030808@gmx.de> <1100563451.4786.31.camel@athlon.localdomain> Message-ID: <20041116055109.GA1905@ugly.local> On Tue, Nov 16, 2004 at 01:04:12AM +0100, Leonard den Ottolander wrote: > About the goto replaced with a while, attached patch gets rid of the > break. Hope I use the correct operator here ;) . > imo this is counterproductive, as you make the "interpretation path" longer. you could make it actually more readable by inverting the conditions, thus nuking the continue and removing one indentation level. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From me at pavelsh.pp.ru Tue Nov 16 07:29:43 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 16 Nov 2004 12:29:43 +0500 Subject: Patch for acinclude.m4 Message-ID: <1053365584.20041116122943@pavelsh.pp.ru> Hello mc-devel, Please, review my patch for acinclude.m4. It fix the problem with build mc-current + system slang on FreeBSD. -- Best regards, Pavel mailto:me at pavelsh.pp.ru -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: acinclude.m4.patch.txt URL: From leonard at den.ottolander.nl Tue Nov 16 12:26:28 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 16 Nov 2004 13:26:28 +0100 Subject: copy_file_file() cleanup In-Reply-To: <20041116055109.GA1905@ugly.local> References: <1100531923.4786.8.camel@athlon.localdomain> <41993E73.6030808@gmx.de> <1100563451.4786.31.camel@athlon.localdomain> <20041116055109.GA1905@ugly.local> Message-ID: <1100607988.4827.7.camel@athlon.localdomain> Hello Oswald, On Tue, 2004-11-16 at 06:51, Oswald Buddenhagen wrote: > imo this is counterproductive, as you make the "interpretation path" > longer. > you could make it actually more readable by inverting the conditions, > thus nuking the continue and removing one indentation level. I just don't like the use of backward gotos when there are valid control structures to handle these situations. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Nov 16 13:01:28 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 16 Nov 2004 14:01:28 +0100 Subject: copy_file_file() cleanup In-Reply-To: <1100563451.4786.31.camel@athlon.localdomain> References: <1100531923.4786.8.camel@athlon.localdomain> <41993E73.6030808@gmx.de> <1100563451.4786.31.camel@athlon.localdomain> Message-ID: <1100610088.4827.10.camel@athlon.localdomain> Hello Roland, I wrote: > You forgot to commit the vfs.h hunk. And the vfs.c hunk. I hadn't noticed that :) . These are just type fixes. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mozgg at donec.net Tue Nov 16 12:32:43 2004 From: mozgg at donec.net (MozGG) Date: Tue, 16 Nov 2004 14:32:43 +0200 Subject: some advice about mc Message-ID: <20041116143243.2afcd563@mozgg> Please add support for highlighting such PHP syntax as ========== HTML; ?> ========== because if I use this, mc sees the " References: <20041116143243.2afcd563@mozgg> Message-ID: <1100615050.4827.16.camel@athlon.localdomain> Hi MozGG, On Tue, 2004-11-16 at 13:32, MozGG wrote: > Please add support for highlighting such PHP syntax as > ========== > > echo > << Patches are welcome ;-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ossi at kde.org Tue Nov 16 15:27:10 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Tue, 16 Nov 2004 16:27:10 +0100 Subject: copy_file_file() cleanup In-Reply-To: <1100607988.4827.7.camel@athlon.localdomain> References: <1100531923.4786.8.camel@athlon.localdomain> <41993E73.6030808@gmx.de> <1100563451.4786.31.camel@athlon.localdomain> <20041116055109.GA1905@ugly.local> <1100607988.4827.7.camel@athlon.localdomain> Message-ID: <20041116152710.GC6271@ugly.local> On Tue, Nov 16, 2004 at 01:26:28PM +0100, Leonard den Ottolander wrote: > On Tue, 2004-11-16 at 06:51, Oswald Buddenhagen wrote: > > imo this is counterproductive, as you make the "interpretation path" > > longer. > > you could make it actually more readable by inverting the conditions, > > thus nuking the continue and removing one indentation level. > > I just don't like the use of backward gotos when there are valid control > structures to handle these situations. > i didn't talk about the goto, but about the substitution of the break with checking the variable. otherwise i would have comented on the previous mail ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From leonard at den.ottolander.nl Tue Nov 16 15:59:53 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 16 Nov 2004 16:59:53 +0100 Subject: copy_file_file() cleanup In-Reply-To: <20041116152710.GC6271@ugly.local> References: <1100531923.4786.8.camel@athlon.localdomain> <41993E73.6030808@gmx.de> <1100563451.4786.31.camel@athlon.localdomain> <20041116055109.GA1905@ugly.local> <1100607988.4827.7.camel@athlon.localdomain> <20041116152710.GC6271@ugly.local> Message-ID: <1100620792.4827.23.camel@athlon.localdomain> Hi Oswald, On Tue, 2004-11-16 at 16:27, Oswald Buddenhagen wrote: > i didn't talk about the goto, but about the substitution of the break > with checking the variable. otherwise i would have comented on the > previous mail ... Ok. So you think the break is nicer than an extra check in the while? Hm. Whatever. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Nov 16 16:03:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 16 Nov 2004 17:03:43 +0100 Subject: [PATCH] Hiding temporary command from history Message-ID: <1100621022.4827.28.camel@athlon.localdomain> Hi, Temporary commands that are executed from the user menu end up in the history. Since HISTIGNORE is already set to ignorespace adding a space to the temporary command hides it from the history. See attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: hide_tmp_command.patch Type: text/x-patch Size: 848 bytes Desc: not available URL: From roland.illig at gmx.de Tue Nov 16 16:13:43 2004 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 16 Nov 2004 17:13:43 +0100 Subject: copy_file_file() cleanup In-Reply-To: <1100610088.4827.10.camel@athlon.localdomain> References: <1100531923.4786.8.camel@athlon.localdomain> <41993E73.6030808@gmx.de> <1100563451.4786.31.camel@athlon.localdomain> <1100610088.4827.10.camel@athlon.localdomain> Message-ID: <419A2737.3060105@gmx.de> Leonard den Ottolander wrote: > And the vfs.c hunk. I hadn't noticed that :) . These are just type > fixes. Committed. Roland From roland.illig at gmx.de Tue Nov 16 16:18:11 2004 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 16 Nov 2004 17:18:11 +0100 Subject: some advice about mc In-Reply-To: <20041116143243.2afcd563@mozgg> References: <20041116143243.2afcd563@mozgg> Message-ID: <419A2843.9010300@gmx.de> MozGG wrote: > Please add support for highlighting such PHP syntax as > ========== > > echo > << > HTML; > > ?> > ========== > because if I use this, mc sees the " > Thanks a lot! This will take some (real) time and much (development) time, as the current syntax highlighter is kind of ... primitive. It knows about keywords and contexts, but it cannot nest two contexts (Here-document inside PHP), as you suggest here. Sorry for now. Roland From leonard at den.ottolander.nl Tue Nov 16 16:37:53 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 16 Nov 2004 17:37:53 +0100 Subject: subshell.c subshell_state Message-ID: <1100623073.4827.32.camel@athlon.localdomain> Hi Jakub, Maybe you could enlighten us on the use of the different subshell states that are used in subshell.c? What is the difference between COMMAND_RUNNING and ACTIVE? A more general introduction about what these states are supposed to achieve would be welcome. I'm wondering whether the state ACTIVE should be kept around, and if so for what reason. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 17 00:59:06 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 17 Nov 2004 01:59:06 +0100 Subject: [PATCH] Already running a command (& subshell prompt?) Message-ID: <1100653145.4827.60.camel@athlon.localdomain> Hi, Removing the odd code executed on Ctrl-o in invoke_subshell() the "Already running a command" issue on C-o, tab, tab, n, C-o, seems to be fixed. But maybe there are other scenarios in which it can be reproduced. I totally got rid of the subshell state ACTIVE as it is unused except in the removed code snippet. I didn't quite get the three state logic anyway. Maybe the author wanted to indicate a difference between "panel view" and "panels hidden view"? Does this perhaps also fix the subshell prompt issue? See the comment /* Hack to make prompt reappear */ in the removed code. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: subshell.diff Type: text/x-patch Size: 1187 bytes Desc: not available URL: From nerijus at users.sourceforge.net Wed Nov 17 02:05:27 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 17 Nov 2004 04:05:27 +0200 (EET) Subject: [PATCH] Already running a command (& subshell prompt?) In-Reply-To: <1100653145.4827.60.camel@athlon.localdomain> References: <1100653145.4827.60.camel@athlon.localdomain> Message-ID: <20041117020809.2B69A508503@mx.ktv.lt> On Wed, 17 Nov 2004 01:59:06 +0100 Leonard den Ottolander wrote: > Removing the odd code executed on Ctrl-o in invoke_subshell() the > "Already running a command" issue on C-o, tab, tab, n, C-o, > seems to be fixed. But maybe there are other scenarios in which it can > be reproduced. Does it still happen on C-o, type smth, erase what you just typed with Backspace key, C-o, - I get "Already running a command"? Regards, Nerijus From leonard at den.ottolander.nl Wed Nov 17 02:45:29 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 17 Nov 2004 03:45:29 +0100 Subject: subshell prompt fix In-Reply-To: <1099473730.19714.18.camel@localhost.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> Message-ID: <1100659528.4827.68.camel@athlon.localdomain> Hi, On Wed, 2004-11-03 at 10:22, Jindrich Novy wrote: > 1) run mc, chdir to /usr/share > 2) C-o > 3) C-o again and chdir to /usr/share/doc > 4) C-o > > in 2) you see: [jnovy at obelix share]$ > in 4) you see: [jnovy at obelix share]$ [jnovy at obelix doc]$ How does the attached patch make the prompt look on BSD? Are there better ways to clear the line? Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041117-promptfix.patch Type: text/x-patch Size: 731 bytes Desc: not available URL: From leonard at den.ottolander.nl Wed Nov 17 02:49:54 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 17 Nov 2004 03:49:54 +0100 Subject: [PATCH] Already running a command (& subshell prompt?) In-Reply-To: <20041117020809.2B69A508503@mx.ktv.lt> References: <1100653145.4827.60.camel@athlon.localdomain> <20041117020809.2B69A508503@mx.ktv.lt> Message-ID: <1100659794.4827.71.camel@athlon.localdomain> Hello Nerijus, On Wed, 2004-11-17 at 03:05, Nerijus Baliunas wrote: > Does it still happen on C-o, type smth, erase what you just typed with > Backspace key, C-o, - I get "Already running a command"? Not on my box, no. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Wed Nov 17 05:45:13 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Wed, 17 Nov 2004 10:45:13 +0500 Subject: [PATCH] Hiding temporary command from history In-Reply-To: <1100621022.4827.28.camel@athlon.localdomain> References: <1100621022.4827.28.camel@athlon.localdomain> Message-ID: <306128360.20041117104513@pavelsh.pp.ru> Hello Leonard, Tuesday, November 16, 2004, 9:03:43 PM, you wrote: LdO> Temporary commands that are executed from the user menu end up in the LdO> history. Since HISTIGNORE is already set to ignorespace adding a space LdO> to the temporary command hides it from the history. See attached patch. Check my patch. It's more simple and general. -- Best regards, Pavel mailto:me at pavelsh.pp.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: hide.patch Type: application/octet-stream Size: 1425 bytes Desc: not available URL: From ptsekov at gmx.net Wed Nov 17 09:36:49 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 17 Nov 2004 11:36:49 +0200 Subject: uglydir patch In-Reply-To: <1100214787.4782.78.camel@athlon.localdomain> References: <1099495216.4819.121.camel@athlon.localdomain> <1100214787.4782.78.camel@athlon.localdomain> Message-ID: Hello, On Fri, 12 Nov 2004, Leonard den Ottolander wrote: > With changelog entries this time. This patch is IMO not ready to be checked-in in its current state. The main concern is the second hunk - several points: 1) The return value of read (), which is stored in `rbytes' is not checked against -1, a perfectly valid return value. 2) The second call to read() introduced in this patch could hang since the pipe is blocking and the first read () could drain the pipe. 3) The patch assumes that the first read () will read everything up to and including the '\n' in the dir name, but this is not guaranteed. I think these are important points and need to be addresed or proven wrong before this patch is commited. Maybe the original author should comment on the issue. From nerijus at users.sourceforge.net Wed Nov 17 18:32:57 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 17 Nov 2004 20:32:57 +0200 (EET) Subject: [PATCH] Already running a command (& subshell prompt?) In-Reply-To: <1100659794.4827.71.camel@athlon.localdomain> References: <1100653145.4827.60.camel@athlon.localdomain><20041117020809.2B69A508503@mx.ktv.lt> <1100659794.4827.71.camel@athlon.localdomain> Message-ID: <20041117183806.DA692508637@mx.ktv.lt> On Wed, 17 Nov 2004 03:49:54 +0100 Leonard den Ottolander wrote: > > Does it still happen on C-o, type smth, erase what you just typed with > > Backspace key, C-o, - I get "Already running a command"? > > Not on my box, no. Strange. It happens all the time here. Or do you mean your patch helps? I use cvs from 2004-10-28. You don't press Enter after erasing everything with Backspace, do you? Regards, Nerijus From leonard at den.ottolander.nl Wed Nov 17 18:47:48 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 17 Nov 2004 19:47:48 +0100 Subject: [PATCH] Already running a command (& subshell prompt?) In-Reply-To: <20041117183806.DA692508637@mx.ktv.lt> References: <1100653145.4827.60.camel@athlon.localdomain> <20041117020809.2B69A508503@mx.ktv.lt> <1100659794.4827.71.camel@athlon.localdomain> <20041117183806.DA692508637@mx.ktv.lt> Message-ID: <1100717267.5203.4.camel@athlon.localdomain> Hello Nerijus, On Wed, 2004-11-17 at 19:32, Nerijus Baliunas wrote: > Strange. It happens all the time here. Or do you mean your patch helps? > I use cvs from 2004-10-28. You don't press Enter after erasing > everything with Backspace, do you? Of course I am speaking of the behaviour with the patch applied. I created the patch to fix this behaviour, so I know it's there without the patch. Please try it and tell me if you still have these problems. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nerijus at users.sourceforge.net Wed Nov 17 19:35:40 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 17 Nov 2004 21:35:40 +0200 (EET) Subject: [PATCH] Already running a command (& subshell prompt?) In-Reply-To: <1100717267.5203.4.camel@athlon.localdomain> References: <1100653145.4827.60.camel@athlon.localdomain><20041117020809.2B69A508503@mx.ktv.lt><1100659794.4827.71.camel@athlon.localdomain><20041117183806.DA692508637@mx.ktv.lt> <1100717267.5203.4.camel@athlon.localdomain> Message-ID: <20041117193806.BA7F55081E4@mx.ktv.lt> On Wed, 17 Nov 2004 19:47:48 +0100 Leonard den Ottolander wrote: > Of course I am speaking of the behaviour with the patch applied. I > created the patch to fix this behaviour, so I know it's there without > the patch. Please try it and tell me if you still have these problems. The patch helps, thanks a lot! It's one of the things into which new users run a lot. Regards, Nerijus From roland.illig at gmx.de Tue Nov 16 23:55:35 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 17 Nov 2004 00:55:35 +0100 Subject: code cleanup for file quicksearch backspace In-Reply-To: <20041111172946.GC25020@cs.bme.hu> References: <20041111172946.GC25020@cs.bme.hu> Message-ID: <419A9377.2060703@gmx.de> Egmont Koblinger wrote: > Hi, > > When in file quicksearch mode (^S or Alt-S) and the search string is empty, > and I press backspace, then the ascii code of the backspace is put into the > search buffer, just as if I pressed a regular letter, and then (since no > filenames begin with backspace, at least on my system :-)) this will be > removed some lines later in the code. Committed. Thanks for reporting. Roland From roland.illig at gmx.de Tue Nov 16 23:55:39 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 17 Nov 2004 00:55:39 +0100 Subject: [PATCH] Hiding temporary command from history In-Reply-To: <1100621022.4827.28.camel@athlon.localdomain> References: <1100621022.4827.28.camel@athlon.localdomain> Message-ID: <419A937B.6060708@gmx.de> Leonard den Ottolander wrote: > Hi, > > Temporary commands that are executed from the user menu end up in the > history. Since HISTIGNORE is already set to ignorespace adding a space > to the temporary command hides it from the history. See attached patch. Committed. Roland From andrew at email.zp.ua Thu Nov 18 09:20:27 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 18 Nov 2004 11:20:27 +0200 (EET) Subject: mcedit syntax highlighting Message-ID: <200411180920.iAI9KRRd011742@email.zp.ua> Hi, this patch restores syntax highlighting. It was broken by my previous syntax.c patch. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: syntax.c.patch URL: From me at pavelsh.pp.ru Thu Nov 18 10:17:59 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Thu, 18 Nov 2004 15:17:59 +0500 Subject: mcedit syntax highlighting In-Reply-To: <200411180920.iAI9KRRd011742@email.zp.ua> References: <200411180920.iAI9KRRd011742@email.zp.ua> Message-ID: <67636105.20041118151759@pavelsh.pp.ru> Hello Andrew, Thursday, November 18, 2004, 2:20:27 PM, you wrote: AVS> Hi, AVS> this patch restores syntax highlighting. It was broken by my previous syntax.c patch. Committed. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From jnovy at redhat.com Thu Nov 18 10:16:37 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 18 Nov 2004 11:16:37 +0100 Subject: subshell prompt fix In-Reply-To: <1100659528.4827.68.camel@athlon.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> <1100659528.4827.68.camel@athlon.localdomain> Message-ID: <1100772997.3629.37.camel@obelix.redhat.usu> Hi Leonard, On Wed, 2004-11-17 at 03:45 +0100, Leonard den Ottolander wrote: > How does the attached patch make the prompt look on BSD? > > Are there better ways to clear the line? I'm sending two patches to fix the promptfix problem. The first one (promptfix-simple) is pretty simple and it uses the fact that when '\r' is sent to the shell, it not only sets the writing position to the first column, but also clears the whole line (at least in my case). This needs testing. The second patch behaves more "rigorously" as it sets the position to the beginning and assumes that '\r' won't clear the line. So it clears only the part of the line, where the previous prompt was written. So it remembers a size of previous prompt. This frees us from solving of COLS, etc. problems and won't draw more characters than needed. This version of the patches is #ifdef'd only for linux since it's tested there. As far as I had a mail-clash with pchel there is different workaround needed or different prompt drawing bug is present on other environments such as FreeBSD. Unfortunately I have no access to such box so I'll let to someone else to fix it for *BSD. greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041117-promptfix-simple.patch Type: text/x-patch Size: 498 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041117-promptfix.patch Type: text/x-patch Size: 1687 bytes Desc: not available URL: From ptsekov at gmx.net Thu Nov 18 10:54:27 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 18 Nov 2004 12:54:27 +0200 Subject: uglydir patch In-Reply-To: References: <1099495216.4819.121.camel@athlon.localdomain> <1100214787.4782.78.camel@athlon.localdomain> Message-ID: Hello, On Wed, 17 Nov 2004, Pavel Tsekov wrote: > This patch is IMO not ready to be checked-in in its current state. > The main concern is the second hunk - several points: > > 1) The return value of read (), which is stored in `rbytes' is not checked > against -1, a perfectly valid return value. > > 2) The second call to read() introduced in this patch could hang since > the pipe is blocking and the first read () could drain the pipe. > > 3) The patch assumes that the first read () will read everything up to > and including the '\n' in the dir name, but this is not guaranteed. > > I think these are important points and need to be addresed or proven > wrong before this patch is commited. Maybe the original author should > comment on the issue. Just for the record - if the subshell is set to tcsh MC hangs on FC3. 9770 pts/0 S+ 0:00 /home/ptsekov/mc-test/usr/bin/mc -U 9773 pts/5 Ts+ 0:00 -csh [ptsekov at baba-meca abcdef]$ strace -p 9770 Process 9770 attached - interrupt to quit read(6, I'm also attaching the output of lsof at the time of the hang. -------------- next part -------------- mc 9770 ptsekov cwd DIR 3,3 4096 1853198 /home/ptsekov/abc\ndef mc 9770 ptsekov rtd DIR 3,3 4096 2 / mc 9770 ptsekov txt REG 3,3 1325655 1853518 /home/ptsekov/mc-test/usr/bin/mc mc 9770 ptsekov mem REG 3,3 813224 295564 /usr/X11R6/lib/libX11.so.6.2 mc 9770 ptsekov mem REG 3,3 47244 1016923 /lib/libnss_files-2.3.3.so mc 9770 ptsekov mem REG 3,3 40259184 475279 /usr/lib/locale/locale-archive mc 9770 ptsekov mem REG 3,3 1509144 1540125 /lib/tls/libc-2.3.3.so mc 9770 ptsekov mem REG 3,3 94320 1016446 /lib/libnsl-2.3.3.so mc 9770 ptsekov mem REG 3,3 878185 361313 /usr/lib/libncurses.so.5.4 mc 9770 ptsekov mem REG 3,3 503752 360490 /usr/lib/libglib-2.0.so.0.400.7 mc 9770 ptsekov mem REG 3,3 15208 1016443 /lib/libdl-2.3.3.so mc 9770 ptsekov mem REG 3,3 9768 360492 /usr/lib/libgmodule-2.0.so.0.400.7 mc 9770 ptsekov mem REG 3,3 107148 1015813 /lib/ld-2.3.3.so mc 9770 ptsekov 0u CHR 136,0 2 /dev/pts/0 mc 9770 ptsekov 1u CHR 136,0 2 /dev/pts/0 mc 9770 ptsekov 2u CHR 136,0 2 /dev/pts/0 mc 9770 ptsekov 3u unix 0x0d845080 64799 socket mc 9770 ptsekov 4u CHR 5,2 1047 /dev/ptmx mc 9770 ptsekov 6u FIFO 3,3 214724 /tmp/mc-ptsekov/mc.pipe.9770 mc 9770 ptsekov 7u FIFO 3,3 214724 /tmp/mc-ptsekov/mc.pipe.9770 From biro_arpad at yahoo.com Thu Nov 18 09:12:54 2004 From: biro_arpad at yahoo.com (Arpad Biro) Date: Thu, 18 Nov 2004 01:12:54 -0800 (PST) Subject: [PATCH] Already running a command (& subshell prompt?) Message-ID: <20041118091254.44315.qmail@web52709.mail.yahoo.com> Hi, > Removing the odd code executed on Ctrl-o in invoke_subshell() the > "Already running a command" issue on C-o, tab, tab, n, C-o, > seems to be fixed. Thank you a thousand times for this. It was driving me mad. Does the patch work when "Lynx-like motion" is on? (That's when I'm experiencing it almost all the time.) BTW, any plans for a second pre-release? Arpad Biro __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From leonard at den.ottolander.nl Thu Nov 18 14:26:13 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 18 Nov 2004 15:26:13 +0100 Subject: [PATCH] Already running a command (& subshell prompt?) In-Reply-To: <20041118091254.44315.qmail@web52709.mail.yahoo.com> References: <20041118091254.44315.qmail@web52709.mail.yahoo.com> Message-ID: <1100787973.4786.6.camel@athlon.localdomain> Hello Arpad, On Thu, 2004-11-18 at 10:12, Arpad Biro wrote: > Thank you a thousand times for this. It was driving me mad. > Does the patch work when "Lynx-like motion" is on? (That's > when I'm experiencing it almost all the time.) Always good to hear. I haven't specifically tried lynx like motion, but I believe this to be a general fix, yes. > BTW, any plans for a second pre-release? There are only a couple of items left before the release. I'm not sure if we are going to have another pre-release, but I doubt it. Many of the developers are running from CVS and I don't believe they are experiencing major difficulties. Please have a go at CVS yourself and tell us what you think. This specific patch has not been committed yet as we are still working on subshell.c. See my next mail :-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Nov 18 14:41:46 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 18 Nov 2004 15:41:46 +0100 Subject: Deglobalize prompt_pos Message-ID: <1100788905.4786.23.camel@athlon.localdomain> Hi, The use of prompt_pos as a global static variable in subshell.c seems a bit odd. I've ripped the parameter and it's references out, except of course in read_subshell_prompt(). This patch also has the "already running a command" fix integrated. Things seem to be fine on my box (Fedora Core 1). Please test this patch on other platforms and tell me if this simplification is correct. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: prompt_pos+subshell_state.patch Type: text/x-patch Size: 3617 bytes Desc: not available URL: From leonard at den.ottolander.nl Thu Nov 18 15:26:37 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 18 Nov 2004 16:26:37 +0100 Subject: subshell prompt fix In-Reply-To: <1100772997.3629.37.camel@obelix.redhat.usu> References: <1099473730.19714.18.camel@localhost.localdomain> <1100659528.4827.68.camel@athlon.localdomain> <1100772997.3629.37.camel@obelix.redhat.usu> Message-ID: <1100791597.4786.31.camel@athlon.localdomain> Hi Jindrich, On Thu, 2004-11-18 at 11:16, Jindrich Novy wrote: > The second patch behaves more "rigorously" as it sets the position to > the beginning and assumes that '\r' won't clear the line. So it clears > only the part of the line, where the previous prompt was written. So it > remembers a size of previous prompt. This frees us from solving of COLS, > etc. problems and won't draw more characters than needed. Not entirely. The maximum number of cleared characters should be capped. Using 256 here. MAXCOLS etc should be cleaned up later as I mentioned in my patch, after which we could use that value instead of the hardcoded 256. + printf ("\r%*c\r%s", prompt_lastsize > 256 ? 256 : prompt_lastsize, ' ', subshell_prompt); But maybe we should wait with committing this patch for a while. It might be a good idea to do some cleaning up in subshell.c and we might end up with the #ifdef __linux__ turning out to be unnecessary. Actually, the #ifdef __linux__ seems redundant altogether, as this prompt fix doesn't cause any regression on FreeBSD IIUC. Prompt on FreeBSD is totally absent in some cases as I understand from Pavel Shirshov. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From buliabyak at gmail.com Thu Nov 18 16:56:14 2004 From: buliabyak at gmail.com (bulia byak) Date: Thu, 18 Nov 2004 11:56:14 -0500 Subject: [PATCH] Already running a command (& subshell prompt?) In-Reply-To: <20041118091254.44315.qmail@web52709.mail.yahoo.com> References: <20041118091254.44315.qmail@web52709.mail.yahoo.com> Message-ID: <3c78ff030411180856439d11b0@mail.gmail.com> On Thu, 18 Nov 2004 01:12:54 -0800 (PST), Arpad Biro wrote: > Thank you a thousand times for this. It was driving me mad. Hi Arpad, I watch this list too (though I don't have time to contribute yet) and I just want to second that. It was by far the worst mc bug. The fact that it's being fixed makes me very hopeful for the prospects of the revitalized mc. Thanks guys! From leonard at den.ottolander.nl Thu Nov 18 23:01:53 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 19 Nov 2004 00:01:53 +0100 Subject: [PATCH] Already running a command (& subshell prompt?) In-Reply-To: <1100653145.4827.60.camel@athlon.localdomain> References: <1100653145.4827.60.camel@athlon.localdomain> Message-ID: <1100818913.4786.43.camel@athlon.localdomain> Hi, I forgot to remove the comment about subshell state ACTIVE. Added it to the patch. No functional changes. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: subshell.diff Type: text/x-patch Size: 1516 bytes Desc: not available URL: From roland.illig at gmx.de Fri Nov 19 11:45:56 2004 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 19 Nov 2004 12:45:56 +0100 Subject: mc burn patch, version 0.2 In-Reply-To: <4193906B.5000204@friesoft.nl> References: <4193906B.5000204@friesoft.nl> Message-ID: <419DDCF4.4090107@gmx.de> Bart Friederichs wrote: > A few years ago (2001) I wrote a patch to enable cd-writing in mc. I got > an email from Andy Shevchenko, with some additions to it.. It now > patches mc-4.6.1-pre1 and the saving of settings works. > > Attached the patch for mcburn 0.2 I will not commit this patch, and I hope noone else will do. It contains a really large number of bugs: * buffer overflows (e.g. in line 192) * possible NullPointerExceptions (e.g. in line 116) * memory leaks (e.g in line 668, 695) Some minor issues are: * Some strings are not translated properly. * You should declare your functions as "void foo(void)" instead of "void foo()". * Don't use C++ comments in C. * instead of malloc/strcpy please use either concat_dir_and_file or g_strconcat. * Always check the results of calls to the functions fgets, fscanf. * After allocating a string, free it in the same function if possible. * Replace the comment in lines 628--632 with a one line comment like: /**** MC-Burn configfile functions ****/ It's visible enough. Please first fix these bugs first, and then retry. Roland From ptsekov at gmx.net Fri Nov 19 18:20:49 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Fri, 19 Nov 2004 20:20:49 +0200 Subject: mouse click offset in help In-Reply-To: <20041111170709.GA25020@cs.bme.hu> References: <20041111170709.GA25020@cs.bme.hu> Message-ID: Hello, On Thu, 11 Nov 2004, Egmont Koblinger wrote: > Hi, > > In the help screen (F1) the rectangular area which accepts mouse click for a > link is shiftedtwo characters to the left. This means that the last two > letters of a link don't accept mouse click, however, two characters left > from the link do. The help dialog has a box drawn in it - thus the offset of 2. It is not only the column number that is affected by this, but also the line number. This is how a dialog with a box looks like: 0123456789 0 1 +------+ 2 | | 3 | | 4 | x | 5 | +------ Data area 6 | | 7 | | 8 +------+ 9 The data is output in the area starting a (2,2) and ending at (7,7). > > Attached patch fixes both for 4.6.0 and 2004-11-04-15 snapshot. I don't think that the attached patch is the best possible solution. Please, consider the attached one-liner. -------------- next part -------------- Index: help.c =================================================================== RCS file: /cvsroot/mc/mc/src/help.c,v retrieving revision 1.49 diff -u -p -r1.49 help.c --- help.c 18 Sep 2004 14:30:58 -0000 1.49 +++ help.c 19 Nov 2004 17:48:45 -0000 @@ -479,6 +479,7 @@ static int help_event (Gpm_Event *event, return 0; /* The event is relative to the dialog window, adjust it: */ + event->x -= 2; event->y -= 2; if (event->buttons & GPM_B_RIGHT){ From egmont at uhulinux.hu Fri Nov 19 18:32:19 2004 From: egmont at uhulinux.hu (Egmont Koblinger) Date: Fri, 19 Nov 2004 19:32:19 +0100 Subject: mouse click offset in help In-Reply-To: References: <20041111170709.GA25020@cs.bme.hu> Message-ID: <20041119183219.GA14790@cs.bme.hu> On Fri, Nov 19, 2004 at 08:20:49PM +0200, Pavel Tsekov wrote: > I don't think that the attached patch is the best possible solution. > Please, consider the attached one-liner. Yes, your patch is definitely much better than my one. Dear developers, please apply it! bye, Egmont > Index: help.c > =================================================================== > RCS file: /cvsroot/mc/mc/src/help.c,v > retrieving revision 1.49 > diff -u -p -r1.49 help.c > --- help.c 18 Sep 2004 14:30:58 -0000 1.49 > +++ help.c 19 Nov 2004 17:48:45 -0000 > @@ -479,6 +479,7 @@ static int help_event (Gpm_Event *event, > return 0; > > /* The event is relative to the dialog window, adjust it: */ > + event->x -= 2; > event->y -= 2; > > if (event->buttons & GPM_B_RIGHT){ From me at pavelsh.pp.ru Fri Nov 19 21:03:41 2004 From: me at pavelsh.pp.ru (me at pavelsh.pp.ru) Date: Sat, 20 Nov 2004 02:03:41 +0500 Subject: mouse click offset in help In-Reply-To: <20041119183219.GA14790@cs.bme.hu> References: <20041111170709.GA25020@cs.bme.hu> <20041119183219.GA14790@cs.bme.hu> Message-ID: <1524304253.20041120020341@pavelsh.pp.ru> Hello Egmont, Friday, November 19, 2004, 11:32:19 PM, you wrote: EK> On Fri, Nov 19, 2004 at 08:20:49PM +0200, Pavel Tsekov wrote: >> I don't think that the attached patch is the best possible solution. >> Please, consider the attached one-liner. EK> Yes, your patch is definitely much better than my one. Dear developers, EK> please apply it! Committed. Thx. ;) -- Best regards, me mailto:me at pavelsh.pp.ru From it at email.su Fri Nov 19 16:20:48 2004 From: it at email.su (it at email.su) Date: Fri, 19 Nov 2004 19:20:48 +0300 Subject: For 5.3 FreeBSD Users who like MC subshell volumes!!! Message-ID: <1542814530.20041119192048@email.su> Foget about MC from ports. Set BASH as default shell for user (vipw). Get: http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/mc-4.6.1-pre1.tar.gz Goto dir with source. #./configure --with-screen=mcslang #make #make install F10 -) yes #mc Enjoj! From me at pavelsh.pp.ru Fri Nov 19 23:43:23 2004 From: me at pavelsh.pp.ru (me at pavelsh.pp.ru) Date: Sat, 20 Nov 2004 04:43:23 +0500 Subject: For 5.3 FreeBSD Users who like MC subshell volumes!!! In-Reply-To: <1542814530.20041119192048@email.su> References: <1542814530.20041119192048@email.su> Message-ID: <717348555.20041120044323@pavelsh.pp.ru> Hello it, Friday, November 19, 2004, 9:20:48 PM, you wrote: ies> Foget about MC from ports. ies> Set BASH as default shell for user (vipw). ies> Get: ies> ies> http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/mc-4.6.1-pre1.tar.gz ies> Goto dir with source. ies> #./configure --with-screen=mcslang ies> #make ies> #make install ies> F10 -) yes ies> #mc ?????? ?? ?????, ? ?? ?????? ?????? -- Best regards, me mailto:me at pavelsh.pp.ru From jnovy at centrum.cz Sat Nov 20 07:09:07 2004 From: jnovy at centrum.cz (Jindrich Novy) Date: Sat, 20 Nov 2004 08:09:07 +0100 Subject: For 5.3 FreeBSD Users who like MC subshell volumes!!! Message-ID: <20041120070912Z1619136-19656+99209@mail.centrum.cz> Hi Pavel, > ?????? ?? ?????, ? ?? ????? ?????? Fortunately I understand Russian a bit so to let also non-Russian speaking people understand: > I didn't get it at all, is it possible to write it in Russian? Please avoid using your non-English native language on mc-devel, otherwise I'll write my next posts in Czech ;-) Jindrich From me at pavelsh.pp.ru Sat Nov 20 12:58:38 2004 From: me at pavelsh.pp.ru (me at pavelsh.pp.ru) Date: Sat, 20 Nov 2004 17:58:38 +0500 Subject: For 5.3 FreeBSD Users who like MC subshell volumes!!! In-Reply-To: <20041120070912Z1619136-19656+99209@mail.centrum.cz> References: <20041120070912Z1619136-19656+99209@mail.centrum.cz> Message-ID: <945875606.20041120175838@pavelsh.pp.ru> Hello Jindrich, Saturday, November 20, 2004, 12:09:07 PM, you wrote: JN> Fortunately I understand Russian a bit so to let also JN> non-Russian speaking people understand: >> I didn't get it at all, is it possible to write it in Russian? JN> Please avoid using your non-English native language on JN> mc-devel, otherwise I'll write my next posts in Czech ;-) I'm sorry. -- Best regards, me mailto:me at pavelsh.pp.ru From esr at thyrsus.com Sun Nov 21 04:01:43 2004 From: esr at thyrsus.com (esr at thyrsus.com) Date: Sat, 20 Nov 2004 23:01:43 -0500 Subject: problems in pipethrough.3 Message-ID: <200411210401.iAL41hqQ014345@snark.thyrsus.com> This is automatically generated email about problems in a man page for which you appear to be responsible. If you are not the right person or list, tell me and I will attempt to correct my database. See http://catb.org/~esr/doclifter/problems.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the mod date of any manual page. You may wish to do that by hand. Problems with pipethrough.3: 1. mdoc name section is not marked up with .Nm and .Nd. 2. Random text in function synopsis confuses the doclifter parser. --- pipethrough.3-orig 2004-11-19 10:08:31.694705904 -0500 +++ pipethrough.3 2004-11-19 10:09:11.850601280 -0500 @@ -8,20 +8,18 @@ .Dt pipethrough 3 .Os .Sh NAME -pipethrough \- pipe a buffer through a child command and receive two -buffers containing the stdout and stderr output of the child process. +.Nm pipethrough +.Nd pipe a buffer through a child command and receive two buffers containing the stdout and stderr output of the child process. .Sh LIBRARY none -- must be included directly. .Sh SYNOPSIS -.Bd -literal #include extern int pipethrough(const char *command, const struct pipe_inbuffer *stdin_buf, - /*@out@*/ struct pipe_outbuffer *stdout_buf, - /*@out@*/ struct pipe_outbuffer *stderr_buf, - /*@out@*/ int *status); -.Ed + struct pipe_outbuffer *stdout_buf, + struct pipe_outbuffer *stderr_buf, + int *status); .Sh DESCRIPTION The pipethrough function executes the \fIcommand\fR via the shell. The command's input is the data provided in \fIstdin_buf\fR. The output buffers ----------------------------- -- Eric S. Raymond From hannibal at megapolis.pl Sun Nov 21 06:35:25 2004 From: hannibal at megapolis.pl (Hannibal) Date: Sun, 21 Nov 2004 07:35:25 +0100 Subject: 7zip vfs Message-ID: <200411210735.26282.hannibal@megapolis.pl> I'm not subscribe this list, but I wirtten basic vfs support for 7zip archives. I think it can be useful for someone. You can find it here: http://www.astral.lodz.pl/hannibal/7zip. It require 7za from http://www.7-zip.org/ . -- Hannibal From subscript at free.fr Sun Nov 21 14:21:44 2004 From: subscript at free.fr (wwp) Date: Sun, 21 Nov 2004 15:21:44 +0100 Subject: 7zip vfs In-Reply-To: <200411210735.26282.hannibal@megapolis.pl> References: <200411210735.26282.hannibal@megapolis.pl> Message-ID: <20041121152144.1ccc6aec@tethys.solarsys.org> Hello all, On Sun, 21 Nov 2004 07:35:25 +0100 Hannibal wrote: > I'm not subscribe this list, but I wirtten basic vfs support for 7zip > archives. I think it can be useful for someone. You can find it here: > http://www.astral.lodz.pl/hannibal/7zip. It require 7za from > http://www.7-zip.org/ . Also: http://p7zip.sourceforge.net/ Regards, -- wwp From leonard at den.ottolander.nl Sun Nov 21 14:24:22 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 21 Nov 2004 15:24:22 +0100 Subject: Deglobalize prompt_pos In-Reply-To: <1100788905.4786.23.camel@athlon.localdomain> References: <1100788905.4786.23.camel@athlon.localdomain> Message-ID: <1101047062.4786.2.camel@athlon.localdomain> Hi, I wrote: > The use of prompt_pos as a global static variable in subshell.c seems a > bit odd. I've ripped the parameter and it's references out, except of > course in read_subshell_prompt(). This patch also has the "already > running a command" fix integrated. It was probably a bad idea to send two integrated patches. The "already running a command" patch has some odd behaviour when using pipes in the subshell (fe "| less"). Attached is the plain "deglobalize prompt_pos" patch. Please test. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: prompt_pos.patch Type: text/x-patch Size: 2925 bytes Desc: not available URL: From leonard at den.ottolander.nl Sun Nov 21 15:51:38 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 21 Nov 2004 16:51:38 +0100 Subject: Cap command size passed to subshell Message-ID: <1101052298.4786.6.camel@athlon.localdomain> Hi, A small fix for the size of the command passed to the subshell pty. 4096 bytes should be enough, right? I believe the compiler should optimize the double call to strlen(command) away. If not we could introduce an extra variable here and set it first. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: cap_command_size.patch Type: text/x-patch Size: 631 bytes Desc: not available URL: From leonard at den.ottolander.nl Mon Nov 22 02:57:35 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 22 Nov 2004 03:57:35 +0100 Subject: [PATCH] Already running a command In-Reply-To: <1100818913.4786.43.camel@athlon.localdomain> References: <1100653145.4827.60.camel@athlon.localdomain> <1100818913.4786.43.camel@athlon.localdomain> Message-ID: <1101092255.4786.23.camel@athlon.localdomain> Hi, I wrote: > I forgot to remove the comment about subshell state ACTIVE. These improvements make subshell_ready extern, so we can test if (subshell_ready == TRUE) in shell_execute() instead of if (subshell_state == INACTIVE) before calling do_execute(). We should investigate if subshell_state is perhaps totally redundant. This improvement should fix oddities with passing keyboard input on the panel prompt if a subshell is still running (f.e. ls -R | less) with the previous patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: subshell.diff Type: text/x-patch Size: 2520 bytes Desc: not available URL: From ptsekov at gmx.net Mon Nov 22 19:42:38 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 22 Nov 2004 21:42:38 +0200 Subject: subshell prompt fix In-Reply-To: <1099479805.19714.103.camel@localhost.localdomain> References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> <1099479805.19714.103.camel@localhost.localdomain> Message-ID: Hello, On Wed, 3 Nov 2004, Jindrich Novy wrote: > On Wed, 2004-11-03 at 11:29, Pavel Shirshov (pchel) wrote: > > I can't reproduce this. > > I was able to reproduce this also with CVS version checked out today. > > > But. I see another: > > 1) run mc > > 2) C-o > > 3) C-o again > > 4) C-o > > > > 2) you see: genie# > > 4) you see: > > ^^^^^^^^^^^ I can't see promt. > > Weird, I'm unable to reproduce your case, which terminal do you use? > It's smoothly reproducible with gnome-terminal and xterm, I haven't > tried rxvt. Do you chdir in steps 2) and 4) ? I've just tried the above on a FreeBSD machine account provided by Pavel Shirshov. I run FC3 with GNOME desktop so I use gnome-terminal. When I ssh into the remote machine (FreeBSD) I have the TERM variable set to 'xterm' - in this case everything is fine. Now, I've tried changing the value of TERM to 'vt220'... surprise, surprise - the subshell prompt is missing just as Pavel says. So I've started a fresh gnome-terminal on my machine (FC3) and set TERM to 'vt220' - again no prompt. I've tried also with konsole with the same result. Soooo... what does this mean ? :) From leonard at den.ottolander.nl Tue Nov 23 12:33:07 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 23 Nov 2004 13:33:07 +0100 Subject: subshell prompt fix In-Reply-To: <1100772997.3629.37.camel@obelix.redhat.usu> References: <1099473730.19714.18.camel@localhost.localdomain> <1100659528.4827.68.camel@athlon.localdomain> <1100772997.3629.37.camel@obelix.redhat.usu> Message-ID: <1101213187.4789.6.camel@athlon.localdomain> On Thu, 2004-11-18 at 11:16, Jindrich Novy wrote: > This version of the patches is #ifdef'd only for linux since it's tested > there. Not necessary. I think the fact pchel couldn't reproduce it is because he uses the wrong terminal definition on his remote connection. But it appears prompt_lastsize gets set in the wrong place, so the patch doesn't work. The prompt line doesn't get cleared. Attached patch removes the #ifdef which is most likely *not* necessary. Stole the %c with ' ', and I clear the whole line. See attached patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research -------------- next part -------------- A non-text attachment was scrubbed... Name: prompt_fix.patch Type: text/x-patch Size: 416 bytes Desc: not available URL: From leonard at den.ottolander.nl Tue Nov 23 13:45:31 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 23 Nov 2004 14:45:31 +0100 Subject: Last remaining patches Message-ID: <1101217530.4789.11.camel@athlon.localdomain> Hi, There are a couple of subshell patches that should still get applied. See http://www.pavelsh.pp.ru/wiki/doku.php?id=mc-bugs , "Bugs with patches for MC". Patches are: Deglobalize prompt_pos Cap command size passed to subshell "already running a command" subshell prompt fix copy_dir_dir cleanup And finally the uglydir patch. Not sure if this is actually being worked on. With the above patches applied I think we can go for a release. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ptsekov at gmx.net Tue Nov 23 15:08:37 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 23 Nov 2004 17:08:37 +0200 Subject: Some information about the subshell and saving the console contents Message-ID: Hello, Two links for those interested in better understanding the subshell: http://mail.gnome.org/archives/mc-devel/2003-August/msg00003.html http://mail.gnome.org/archives/mc-devel/2002-August/msg00040.html From leonard at den.ottolander.nl Tue Nov 23 19:02:48 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 23 Nov 2004 20:02:48 +0100 Subject: man_MANS is undefined Message-ID: <1101236568.4789.15.camel@athlon.localdomain> Hi, Running autogen.sh I get the following warning: EXTRA_DIST: variable `man_MANS' is used but `man_MANS' is undefined Could it be this got introduced with the recent man page fixes? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From roland.illig at gmx.de Tue Nov 23 23:00:58 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 24 Nov 2004 00:00:58 +0100 Subject: man_MANS is undefined In-Reply-To: <1101236568.4789.15.camel@athlon.localdomain> References: <1101236568.4789.15.camel@athlon.localdomain> Message-ID: <41A3C12A.1010503@gmx.de> Leonard den Ottolander wrote: > Hi, > > Running autogen.sh I get the following warning: > > EXTRA_DIST: variable `man_MANS' is used but `man_MANS' is undefined > > Could it be this got introduced with the recent man page fixes? Yes, it could. I fixed it. Roland From nerijus at users.sourceforge.net Wed Nov 24 01:38:37 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 24 Nov 2004 03:38:37 +0200 (EET) Subject: bug with large files Message-ID: <20041124013742.C87E35086F8@mx.ktv.lt> Hello, # ls -l -rw-r--r-- 1 root root 34708799325 Nov 23 06:20 backup01.tar.gz -rw-r--r-- 1 root root 31964606217 Nov 22 06:09 backup02.tar.gz In the mc panel I see: backup01.tar.gz 33101M Nov 23 06:20 backup02.tar.gz 30484M Nov 22 06:09 But, when I try to copy backup01.tar.gz to backup02.tar.gz, in a 'Target file "./backup02.tar.gz" already exists!' dialog I see: Source date: Nov 23 06:20, size 349060957 Target date: Nov 22 06:09, size 1899835145 mc from cvs snapshot of 2004-11-04 from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ (btw, why snapshots stopped being generated at that date?). Regards, Nerijus From nerijus at users.sourceforge.net Wed Nov 24 01:59:37 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 24 Nov 2004 03:59:37 +0200 (EET) Subject: viewing rpm Message-ID: <20041124015742.9313C50806C@mx.ktv.lt> Hello, I installed http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/mc-2004110415-1.i386.rpm on Fedora core 2 and use it to view the same rpm file (with F3). I get the following warning while exiting the viewer: mcextDo2OBe: line 2: 5083 Broken pipe $RPM -qivlp --scripts mc-20041104 /tmp/mc-root/mcextDo2OBe file contains: #! /bin/sh if rpm --nosignature --version >/dev/null 2>&1; then RPM="rpm --nosignature" ; else RPM="rpm" ; fi ; $RPM -qivlp --scripts mc-2004110415-1.i386.rpm It would be nice to fix it before the release. Regards, Nerijus From jnovy at redhat.com Wed Nov 24 08:57:53 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 24 Nov 2004 09:57:53 +0100 Subject: bug with large files In-Reply-To: <20041124013742.C87E35086F8@mx.ktv.lt> References: <20041124013742.C87E35086F8@mx.ktv.lt> Message-ID: <1101286673.7636.1.camel@obelix.redhat.usu> Hello Nerijus, On Wed, 2004-11-24 at 03:38 +0200, Nerijus Baliunas wrote: > Hello, > > # ls -l > -rw-r--r-- 1 root root 34708799325 Nov 23 06:20 backup01.tar.gz > -rw-r--r-- 1 root root 31964606217 Nov 22 06:09 backup02.tar.gz > > In the mc panel I see: > > backup01.tar.gz 33101M Nov 23 06:20 > backup02.tar.gz 30484M Nov 22 06:09 > > But, when I try to copy backup01.tar.gz to backup02.tar.gz, in > a 'Target file "./backup02.tar.gz" already exists!' dialog I see: > > Source date: Nov 23 06:20, size 349060957 > Target date: Nov 22 06:09, size 1899835145 > > mc from cvs snapshot of 2004-11-04 from > http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ > (btw, why snapshots stopped being generated at that date?). > > Regards, > Nerijus The following patch fixes it. greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-badsize.patch Type: text/x-patch Size: 1032 bytes Desc: not available URL: From jnovy at redhat.com Wed Nov 24 10:21:07 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 24 Nov 2004 11:21:07 +0100 Subject: subshell prompt fix In-Reply-To: References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> <1099479805.19714.103.camel@localhost.localdomain> Message-ID: <1101291667.7636.40.camel@obelix.redhat.usu> Hello Pavel, On Mon, 2004-11-22 at 21:42 +0200, Pavel Tsekov wrote: > > On Wed, 2004-11-03 at 11:29, Pavel Shirshov (pchel) wrote: > > > But. I see another: > > > 1) run mc > > > 2) C-o > > > 3) C-o again > > > 4) C-o > > > > > > 2) you see: genie# > > > 4) you see: > > > ^^^^^^^^^^^ I can't see promt. > > > > Weird, I'm unable to reproduce your case, which terminal do you use? > > It's smoothly reproducible with gnome-terminal and xterm, I haven't > > tried rxvt. Do you chdir in steps 2) and 4) ? > > I've just tried the above on a FreeBSD machine account provided by Pavel > Shirshov. I run FC3 with GNOME desktop so I use gnome-terminal. When I > ssh into the remote machine (FreeBSD) I have the TERM variable set to > 'xterm' - in this case everything is fine. Now, I've tried changing the > value of TERM to 'vt220'... surprise, surprise - the subshell prompt is > missing just as Pavel says. So I've started a fresh gnome-terminal > on my machine (FC3) and set TERM to 'vt220' - again no prompt. I've tried > also with konsole with the same result. > > Soooo... what does this mean ? :) Please see the top of the thread: http://mail.gnome.org/archives/mc-devel/2004-November/msg00031.html Since you're running FC3 with GNOME desktop and gnome-terminal with TERM=xterm, you should smoothly reproduce the original bug I've been trying to fix since I found this bug exactly with the same configuration. To fix the both cases of the bug we should probably get TERM variable from the environment and do a specific fix related to its contents. The attached patch does the following: 1st hunk: the removed part caused to cut out the beginning of the prompt so we get: ]$ instead of: [jnovy at obelix ]$ this part of code just prints the whole prompt without shortening to subshell_prompt to let the prompt be displayed correctly via load_prompt (). 2nd hunk: fix of the prompt drawing in subshell. It should display correct prompt if it's size is less than COLS and redraw only the part of line where was a previous prompt. If the prompt is larger that COLS, it'll draw the prompt at a new line. Some additional work for this should be done since we can use escape sequences to improve it a bit. And maybe we should cap the value of COLS, etc. 3rd hunk: Displays shrinked prompt in the panel (not subshell) mode with using name_trunc(). This part is needed to let the prompt be displayed as noted in the comment to 1st hunk. Any comments are welcome. greetings, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-promptfix.patch Type: text/x-patch Size: 2474 bytes Desc: not available URL: From ptsekov at gmx.net Wed Nov 24 10:21:37 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 24 Nov 2004 12:21:37 +0200 Subject: [PATCH] widget.c: fix slow_terminal declaration Message-ID: Hello, This warning is displayed with gcc 3.4.2 ( gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) ) on FC3: widget.c: In function `listbox_new': widget.c:2099: warning: redundant redeclaration of 'slow_terminal' widget.c:1659: warning: previous declaration of 'slow_terminal' was here Changelog: 20041124 Pavel Tsekov * warning.c: Fix declaration of `slow_terminal'. -------------- next part -------------- Index: widget.c =================================================================== RCS file: /cvsroot/mc/mc/src/widget.c,v retrieving revision 1.117 diff -u -p -r1.117 widget.c --- widget.c 25 Sep 2004 20:49:15 -0000 1.117 +++ widget.c 24 Nov 2004 09:56:15 -0000 @@ -42,6 +42,7 @@ #include "key.h" /* XCTRL and ALT macros */ #include "profile.h" /* for history loading and saving */ #include "wtools.h" /* For common_dialog_repaint() */ +#include "main.h" /* for `slow_terminal' */ static int button_event (Gpm_Event *event, WButton *b); @@ -1656,7 +1657,6 @@ static int listbox_cdiff (WLEntry *s, WL static void listbox_drawscroll (WListbox *l) { - extern int slow_terminal; int line; int i, top; int max_line = l->height-1; @@ -2096,7 +2096,6 @@ WListbox * listbox_new (int y, int x, int width, int height, lcback callback) { WListbox *l = g_new (WListbox, 1); - extern int slow_terminal; init_widget (&l->widget, y, x, height, width, (callback_fn) listbox_callback, From ptsekov at gmx.net Wed Nov 24 10:31:51 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 24 Nov 2004 12:31:51 +0200 Subject: bug with large files In-Reply-To: <1101286673.7636.1.camel@obelix.redhat.usu> References: <20041124013742.C87E35086F8@mx.ktv.lt> <1101286673.7636.1.camel@obelix.redhat.usu> Message-ID: Hello, On Wed, 24 Nov 2004, Jindrich Novy wrote: > > Source date: Nov 23 06:20, size 349060957 > > Target date: Nov 22 06:09, size 1899835145 > > > > mc from cvs snapshot of 2004-11-04 from > > http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ > > (btw, why snapshots stopped being generated at that date?). > > > > Regards, > > Nerijus > > The following patch fixes it. +#if defined(_FILE_OFFSET_BITS) && _FILE_OFFSET_BITS == 64 + N_("Target date: %s, size %lu"), 6, 4, 0}, { ^^^ + N_("Source date: %s, size %lu"), 5, 4, 0} ^^^ What about %llu ? From ossi at kde.org Wed Nov 24 10:36:14 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Wed, 24 Nov 2004 11:36:14 +0100 Subject: bug with large files In-Reply-To: <1101286673.7636.1.camel@obelix.redhat.usu> References: <20041124013742.C87E35086F8@mx.ktv.lt> <1101286673.7636.1.camel@obelix.redhat.usu> Message-ID: <20041124103614.GA3793@ugly.local> On Wed, Nov 24, 2004 at 09:57:53AM +0100, Jindrich Novy wrote: > > Source date: Nov 23 06:20, size 349060957 > > Target date: Nov 22 06:09, size 1899835145 > > > The following patch fixes it. > it can't. sizeof(unsigned) == sizeof(unsigned long) on x86. %llu is the right format. i have such code in one of my projects: configure.ac: AC_CACHE_CHECK([whether off_t can be long long], ob_cv_type_off_t_ll, [ AC_TRY_RUN([#define _FILE_OFFSET_BITS 64 #include #include int main() { if (sizeof(long long) == sizeof(long)) exit(1); if (sizeof(off_t) != sizeof(long long)) exit(1); exit(0); }], ob_cv_type_off_t_ll=yes, ob_cv_type_off_t_ll=no)]) if test $ob_cv_type_off_t_ll = yes; then AC_CACHE_CHECK([whether \"%lli\" works], ob_cv_func_printf_ok, [ AC_TRY_RUN([#include int main() { char ts[20]; sprintf(ts, "%lli", 1234567890123LL); exit(strcmp(ts, "1234567890123")); }], ob_cv_func_printf_ok=yes, ob_cv_func_printf_ok=no)]) if test $ob_cv_func_printf_ok = yes; then AC_DEFINE(USE_LL, 1, [Defined if long long should be used for file offsets]) else AC_MSG_WARN([your c library fails to format long long int correctly. 64 bit file offsets were disabled.]) fi fi c file: #include #ifdef USE_LL # define _FILE_OFFSET_BITS 64 # define SSOFFT "lli" #else # define SSOFFT "li" #endif #define SOFFT "%"SSOFFT #include // off_t #include // lseek, etc. off_t off; printf(SOFFT "\n", off) printf("%20" SSOFFT "\n", off) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From jnovy at redhat.com Wed Nov 24 10:42:44 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 24 Nov 2004 11:42:44 +0100 Subject: bug with large files In-Reply-To: References: <20041124013742.C87E35086F8@mx.ktv.lt> <1101286673.7636.1.camel@obelix.redhat.usu> Message-ID: <1101292964.7636.45.camel@obelix.redhat.usu> Hello Pavel, On Wed, 2004-11-24 at 12:31 +0200, Pavel Tsekov wrote: > What about %llu ? Sure, that's my typo. Please use the attached patch instead. -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-badsize.patch Type: text/x-patch Size: 1034 bytes Desc: not available URL: From ptsekov at gmx.net Wed Nov 24 12:25:52 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 24 Nov 2004 14:25:52 +0200 Subject: subshell prompt fix In-Reply-To: <1101291667.7636.40.camel@obelix.redhat.usu> References: <1099473730.19714.18.camel@localhost.localdomain> <178535947.20041103152939@pavelsh.pp.ru> <1099479805.19714.103.camel@localhost.localdomain> <1101291667.7636.40.camel@obelix.redhat.usu> Message-ID: Hello, On Wed, 24 Nov 2004, Jindrich Novy wrote: > Hello Pavel, > > On Mon, 2004-11-22 at 21:42 +0200, Pavel Tsekov wrote: > > > On Wed, 2004-11-03 at 11:29, Pavel Shirshov (pchel) wrote: > > > > But. I see another: > > > > 1) run mc > > > > 2) C-o > > > > 3) C-o again > > > > 4) C-o > > > > > > > > 2) you see: genie# > > > > 4) you see: > > > > ^^^^^^^^^^^ I can't see promt. > > > > > > Weird, I'm unable to reproduce your case, which terminal do you use? > > > It's smoothly reproducible with gnome-terminal and xterm, I haven't > > > tried rxvt. Do you chdir in steps 2) and 4) ? > > > > I've just tried the above on a FreeBSD machine account provided by Pavel > > Shirshov. I run FC3 with GNOME desktop so I use gnome-terminal. When I > > ssh into the remote machine (FreeBSD) I have the TERM variable set to > > 'xterm' - in this case everything is fine. Now, I've tried changing the > > value of TERM to 'vt220'... surprise, surprise - the subshell prompt is > > missing just as Pavel says. So I've started a fresh gnome-terminal > > on my machine (FC3) and set TERM to 'vt220' - again no prompt. I've tried > > also with konsole with the same result. > > > > Soooo... what does this mean ? :) > > Please see the top of the thread: > http://mail.gnome.org/archives/mc-devel/2004-November/msg00031.html > > Since you're running FC3 with GNOME desktop and gnome-terminal with > TERM=xterm, you should smoothly reproduce the original bug I've been > trying to fix since I found this bug exactly with the same > configuration. I am able to reproduce the bug that you've reported. I was trying to reproduce the behaviour that Pavel Shirshov has experienced. I'll try to review the new patch. From ptsekov at gmx.net Wed Nov 24 13:40:29 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 24 Nov 2004 15:40:29 +0200 Subject: [PATCH] Already running a command In-Reply-To: <1101092255.4786.23.camel@athlon.localdomain> References: <1100653145.4827.60.camel@athlon.localdomain> <1100818913.4786.43.camel@athlon.localdomain> <1101092255.4786.23.camel@athlon.localdomain> Message-ID: Hello, On Mon, 22 Nov 2004, Leonard den Ottolander wrote: > Hi, > > I wrote: > > I forgot to remove the comment about subshell state ACTIVE. > > These improvements make subshell_ready extern, so we can test if > (subshell_ready == TRUE) in shell_execute() instead of if > (subshell_state == INACTIVE) before calling do_execute(). We should > investigate if subshell_state is perhaps totally redundant. Now, you've really broke your own patch. I see that you haven't tested your code. By doing the changes above (using subshell_ready) you actually remove the effect of your changes to invoke_subshell(). So you actully reintroduced the still get 'The shell is already running a command' message. Why ? Because `subshell_ready' is FALSE until the prompt is not reprinted by the shell i.e. a command was executed. It is set to TRUE after the prompt reappears. Now about the 'Ctrl+O tab tab n Ctrl+O' issue. I don't have a proof yet... but I think that the `precmd' is not executed in this case. So you `subshell_ready' doesn't get a value of TRUE. Thus the famous message reappearing again. I'll try to provide more info soon. From ptsekov at gmx.net Wed Nov 24 13:46:44 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Wed, 24 Nov 2004 15:46:44 +0200 Subject: [PATCH] Already running a command In-Reply-To: References: <1100653145.4827.60.camel@athlon.localdomain> <1100818913.4786.43.camel@athlon.localdomain> <1101092255.4786.23.camel@athlon.localdomain> Message-ID: Hello, On Wed, 24 Nov 2004, Pavel Tsekov wrote: > Hello, > > On Mon, 22 Nov 2004, Leonard den Ottolander wrote: > > > Hi, > > > > I wrote: > > > I forgot to remove the comment about subshell state ACTIVE. > > > > These improvements make subshell_ready extern, so we can test if > > (subshell_ready == TRUE) in shell_execute() instead of if > > (subshell_state == INACTIVE) before calling do_execute(). We should > > investigate if subshell_state is perhaps totally redundant. > > Now, you've really broke your own patch. I see that you haven't tested > your code. By doing the changes above (using subshell_ready) > you actually remove the effect of your changes to invoke_subshell(). > So you actully reintroduced the still get 'The shell is already > running a command' message. > > Why ? Because `subshell_ready' is FALSE until the prompt is not > reprinted by the shell i.e. a command was executed. It is set > to TRUE after the prompt reappears. The patch without the last changes doesn't make much sense too: 1) Ctrl + O 2) qwe 3) Ctrl + O 4) In the command prompt widget type some valid command say 'df' and type enter 5) Ctrl + O You'll get: [ptsekov at baba-meca build]$ qwedf bash: qwedf: command not found From leonard at den.ottolander.nl Wed Nov 24 14:54:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 24 Nov 2004 15:54:25 +0100 Subject: COLS > 256 ? In-Reply-To: <1101288626.7636.4.camel@obelix.redhat.usu> References: <1101288626.7636.4.camel@obelix.redhat.usu> Message-ID: <1101308064.4786.2.camel@athlon.localdomain> Hello Jindrich, On Wed, 2004-11-24 at 10:30, Jindrich Novy wrote: > only a tiny question. Why do you restrict COLS to be not bigger than > 256? Because different headers use different limits for "MAX_COLS" like constants. Slang and ncurses should be synchronized before we can use a constant here. Hence my comment in the patch and the temporary use of a fixed value. But this should be cleaned up after 4.6.1. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 24 15:01:52 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 24 Nov 2004 16:01:52 +0100 Subject: [PATCH] Already running a command In-Reply-To: References: <1100653145.4827.60.camel@athlon.localdomain> <1100818913.4786.43.camel@athlon.localdomain> <1101092255.4786.23.camel@athlon.localdomain> Message-ID: <1101308512.4786.5.camel@athlon.localdomain> Hello Pavel, On Wed, 2004-11-24 at 14:40, Pavel Tsekov wrote: > Now, you've really broke your own patch. I see that you haven't tested > your code. It would be nice if you actually applied the patch and test the real life behaviour. It appears correct to me. Anybody else that would be so kind to test the latest (4 hunk) version of this patch? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 24 15:05:32 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 24 Nov 2004 16:05:32 +0100 Subject: viewing rpm In-Reply-To: <20041124015742.9313C50806C@mx.ktv.lt> References: <20041124015742.9313C50806C@mx.ktv.lt> Message-ID: <1101308731.4786.8.camel@athlon.localdomain> Hello Nerijus, On Wed, 2004-11-24 at 02:59, Nerijus Baliunas wrote: > mcextDo2OBe: line 2: 5083 Broken pipe $RPM -qivlp --scripts mc-20041104 The broken pipe error happens because not all of the output of the command has been read into the buffer. This is not easy to fix. It has been decided to move this issue to a later release. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 24 15:45:14 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 24 Nov 2004 16:45:14 +0100 Subject: [PATCH] Already running a command In-Reply-To: <1101308512.4786.5.camel@athlon.localdomain> References: <1100653145.4827.60.camel@athlon.localdomain> <1100818913.4786.43.camel@athlon.localdomain> <1101092255.4786.23.camel@athlon.localdomain> <1101308512.4786.5.camel@athlon.localdomain> Message-ID: <1101311114.4786.11.camel@athlon.localdomain> Hi Pavel, > It would be nice if you actually applied the patch and test the real > life behaviour. It appears correct to me. I'm sorry. Although it behaves correctly in most cases indeed this patch does *not* behave correctly on the C-o, tab, tab, n, C-o, example. Dang. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Nov 24 16:01:10 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 24 Nov 2004 17:01:10 +0100 Subject: EXECUTE_HIDE Message-ID: <1101312069.4786.15.camel@athlon.localdomain> Hi pchel, I see you introduced the EXECUTE_HIDE parameter. Don't you think it's a bit overdone to introduce this parameter for a single occurrence where a command needs to be hidden? Why not just go with an explicit space in the command? Nothing wrong with general code, but it's not very useful if it used for a single occurrence only. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From eth0 at o2.pl Thu Nov 25 02:24:44 2004 From: eth0 at o2.pl (q#) Date: Thu, 25 Nov 2004 03:24:44 +0100 Subject: prompt, spaces, `cd' and system commands.. Message-ID: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> Hi, I've compiled a few minutes ago cvs'd version of mc and want to report some issue with spaces in prompt commands. I've post it some time ago: http://mail.gnome.org/archives/mc-devel/2004-October/msg00022.html It's is described in second part of that mail, but I will try simple explanation: in mc prompt1:~/> mkdir this is test in mc prompt2:~/> mkdir this\ is\ test in mc prompt3:~/> cd this is test in mc prompt4:~/> cd this\ is\ test In first ex mkdir will create 3 dirs, that's okey. In second mkdir will create 1 long dir, okey (like in stand-a-lone sh). In third example cd will change dir, that's fault, because in first mkdir had 3 parameters, cd cannot cd to 3 dirs (like in stand-a-lone sh). In fourth mc will show red dialog box, error no such file direcory(2) I often copy paths with to prompt with (CTRL+x, p) and when your path has space I've got this error when tryin co cd'in. -- best regards q# From ptsekov at gmx.net Thu Nov 25 10:51:14 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 25 Nov 2004 12:51:14 +0200 Subject: Cap command size passed to subshell In-Reply-To: <1101052298.4786.6.camel@athlon.localdomain> References: <1101052298.4786.6.camel@athlon.localdomain> Message-ID: Hello, On Sun, 21 Nov 2004, Leonard den Ottolander wrote: > Hi, > > A small fix for the size of the command passed to the subshell pty. 4096 > bytes should be enough, right? I believe the compiler should optimize > the double call to strlen(command) away. If not we could introduce an > extra variable here and set it first. Why is this patch necessary ? Besides the comment in the source code do you have any proof (testcase) that long commands cause breakage ? Is it the strlen () call or the pseudo-terminal device or the underlying shell that fails ? I think if we opt to fix that part of the code, we have to find out which part of the chain fails and find a proper workaround i.e. for example passing the big string in smaller chunks. Just removing a part of the command is obviously not what the user wants - its better to warn her that she is passing a command which is too long and just discard the whole command. Any thoughts ? From andrew at email.zp.ua Thu Nov 25 11:06:17 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 25 Nov 2004 13:06:17 +0200 (EET) Subject: Couple of patches Message-ID: <200411251106.iAPB6HW2082605@email.zp.ua> Hi, -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: direntry.c.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: execute.c.patch URL: From leonard at den.ottolander.nl Thu Nov 25 11:21:36 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 25 Nov 2004 12:21:36 +0100 Subject: Cap command size passed to subshell In-Reply-To: References: <1101052298.4786.6.camel@athlon.localdomain> Message-ID: <1101381696.4819.6.camel@athlon.localdomain> Hello Pavel, On Thu, 2004-11-25 at 11:51, Pavel Tsekov wrote: > Why is this patch necessary ? Besides the comment in the source code do > you have any proof (testcase) that long commands cause breakage ? I haven't actually tried to crash mc with a long command, but the comment clearly indicates mc "goes comma" (sic) with large command lines, so I don't doubt that comment. Since I haven't tested this the size cap of 4k is a bit arbitrary, but it seems a reasonable size and is well below the indicated estimated 8k size limit. Of course this is open for discussion and investigation. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Nov 25 11:25:23 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 25 Nov 2004 12:25:23 +0100 Subject: prompt, spaces, `cd' and system commands.. In-Reply-To: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> References: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> Message-ID: <1101381922.4819.9.camel@athlon.localdomain> Hi q#, On Thu, 2004-11-25 at 03:24, q# wrote: > I often copy paths with to prompt with (CTRL+x, p) and when your path > has space I've got this error when tryin co cd'in. As always, patches are welcome. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Nov 25 11:37:42 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 25 Nov 2004 12:37:42 +0100 Subject: Couple of patches In-Reply-To: <200411251106.iAPB6HW2082605@email.zp.ua> References: <200411251106.iAPB6HW2082605@email.zp.ua> Message-ID: <1101382661.4819.12.camel@athlon.localdomain> Hi, On Thu, 2004-11-25 at 12:06, Andrew V. Samoilov wrote: > Hi, Please apply direntry.c.patch. execute.c.patch also looks good, I assume this means you (Andrew) agree with this IMO somewhat redundant code addition? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From buc at odusz.so-cdu.ru Thu Nov 25 11:59:43 2004 From: buc at odusz.so-cdu.ru (buc) Date: Thu, 25 Nov 2004 14:59:43 +0300 Subject: [Patch] Fish upload problems. Message-ID: <41A5C92F.9000500@odu.neva.ru> Midnight Commander has a FISH virtual filesystem (FIle transfer over SHell). There is one old problem in MC implementation of it -- uploads onto remote system. To do such an upload, MC should invoke on the remote side a command, which reads appropriate number of bytes from stdin and store them in the target file. Initially, `dd' command had been chosen for this purpose. The decision was such: " ( dd bs=4096 count= ; dd bs= count=1 ) | ( cat >target_file ; cat >/dev/null ) " (Note: additional cat to /dev/null is needed to flush input on write errors). But unfortunately, this variant appeared unreliable. The design of `dd' does not assume full filling of input buffers on read (see, for example, "conv=sync" description in `dd' manual). The design of `ssh' is those that sometimes data can be written into pipe by portions of different size. Therefore the part of data could remain not read by `dd' ... In the current version, the problem is solved as: " dd bs=1 count= | ..... " i.e., `dd' reads input byte-by-byte. It is robast, but is very slow and grabs a lot of cpu time on the remote system. The better decision is possible. There is `head' command. It has `-c ' option, which does what we really need. The necessary amount of data is read from stdin reliably. Unfortunately, the remote system (any *NIX-like) may not have `head' command, or have another implementation of it. But for such systems we can still use `dd' . The final decision is: " ( head -c -q - || dd bs=1 count= ) | ( cat >target_file ; cat >/dev/null ) " Either fast `head' is used, or `dd' as a fallback. If there is no `head' on the remote side, or `head' is too old (has no `-c' option), then `dd' will be used. `-q' and `-' are used to cause most non-GNU `head's to fail (by "incorrect" option). We can not trust non-GNU implementations of `head' -- for example, AIX has `-c' option, but always adds extra newline at the end of target file :-( . There is small probability that remote `head' is not GNU head but supports all our options. Let`s believe that it is "modern" head and it suits us! :-) The new variant of FISH uploads is successfully tested by us in various environments (GNU-like, non-GNU) -- all works as it is expected. Appropriate patch attached. -- Dmitry K. Butskoj Saint-Petersburg, Russia Red Hat Certified Engineer 809003662809495 -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-4.6.1-fish.patch Type: text/x-patch Size: 1765 bytes Desc: not available URL: From ptsekov at gmx.net Thu Nov 25 12:13:38 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 25 Nov 2004 14:13:38 +0200 Subject: Cap command size passed to subshell In-Reply-To: <1101381696.4819.6.camel@athlon.localdomain> References: <1101052298.4786.6.camel@athlon.localdomain> <1101381696.4819.6.camel@athlon.localdomain> Message-ID: Hello, On Thu, 25 Nov 2004, Leonard den Ottolander wrote: > Hello Pavel, > > On Thu, 2004-11-25 at 11:51, Pavel Tsekov wrote: > > Why is this patch necessary ? Besides the comment in the source code do > > you have any proof (testcase) that long commands cause breakage ? > > I haven't actually tried to crash mc with a long command, but the > comment clearly indicates mc "goes comma" (sic) with large command > lines, so I don't doubt that comment. You better double check. What I mean - this comment may be as old as MC itself. Things for sure have changed from that time. I suspect that this comment refers to some kind of problems with the pseudo-terminal on some particular platform. Unfortunately, the comment does not give any details. > Since I haven't tested this the size cap of 4k is a bit arbitrary, but > it seems a reasonable size and is well below the indicated estimated 8k > size limit. My objection here is that you actually truncate a valid command that the user have typed. 8K or not he sometimes typed it and it is being truncated without no warning at all, silently. This may result in aa unexpected behaviour (from the users's point of view). From ptsekov at gmx.net Thu Nov 25 12:29:49 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 25 Nov 2004 14:29:49 +0200 Subject: Couple of patches In-Reply-To: <200411251106.iAPB6HW2082605@email.zp.ua> References: <200411251106.iAPB6HW2082605@email.zp.ua> Message-ID: Hello, I don't like the second hunk of direntry.c.patch. @@ -955,7 +957,7 @@ vfs_s_retrieve_file (struct vfs_class *m if (got_interrupt ()) goto error_1; - if (write (handle, buffer, n) < 0) { + if (write (handle, buffer, n) != n) { me->verrno = errno; goto error_1; } `errno' is not set if write () returns a positive value i.e. less bytes written than in the buffer. Also it is ok to have write () with n = 0 - this should return 0. From ptsekov at gmx.net Thu Nov 25 13:03:38 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Thu, 25 Nov 2004 15:03:38 +0200 Subject: Couple of patches In-Reply-To: References: <200411251106.iAPB6HW2082605@email.zp.ua> Message-ID: Hello, On Thu, 25 Nov 2004, Pavel Tsekov wrote: > Hello, > > I don't like the second hunk of direntry.c.patch. > > @@ -955,7 +957,7 @@ vfs_s_retrieve_file (struct vfs_class *m > if (got_interrupt ()) > goto error_1; > > - if (write (handle, buffer, n) < 0) { > + if (write (handle, buffer, n) != n) { > me->verrno = errno; > goto error_1; > } > > `errno' is not set if write () returns a positive value i.e. > less bytes written than in the buffer. Also it is ok to have > write () with n = 0 - this should return 0. Please, ignore the part about n = 0. Sorry. From leonard at den.ottolander.nl Thu Nov 25 13:27:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 25 Nov 2004 14:27:40 +0100 Subject: Cap command size passed to subshell In-Reply-To: References: <1101052298.4786.6.camel@athlon.localdomain> <1101381696.4819.6.camel@athlon.localdomain> Message-ID: <1101389259.4819.17.camel@athlon.localdomain> Hello Pavel, On Thu, 2004-11-25 at 13:13, Pavel Tsekov wrote: > You better double check. What I mean - this comment may be as old as MC > itself. Ok. I'll look into this. > My objection here is that you actually truncate a valid command that the > user have typed. 8K or not he sometimes typed it and it is being truncated > without no warning at all, silently. This may result in aa unexpected > behaviour (from the users's point of view). I know this is a very crude patch. It's just that the comment drew my attention, so it was sort of an invitation for discussion. If the problem still exists a warning dialog is probably a better solution. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From buc at odusz.so-cdu.ru Thu Nov 25 16:24:59 2004 From: buc at odusz.so-cdu.ru (buc) Date: Thu, 25 Nov 2004 19:24:59 +0300 Subject: [Patch] FISH freezes MC on abort of transfer Message-ID: <41A6075B.7070702@odu.neva.ru> There is a little bug in FISH vfs -- file transfer abortion is not working properly. How to reproduce: 1. Login as unprivileged user, invoke MC 2. Set on one panel any local directory where you have no write access 3. On the other panel, cd somewhere using FISH (cd /#sh: ... ) 4. Try to copy some file from remote system to local dir. 5. Because of missing write access, MC report error and then starts to abort transfer. But never finishes it... The issue is inspired by the trivial bug -- see the patch attached. Instead of flush of the same amount of bytes as the non-transferred file is, everything is flushed, including special FISH`s exit codes... -- Dmitry K. Butskoj Saint-Petersburg, Russia Red Hat Certified Engineer 809003662809495 -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-4.6.1-fish-abort.patch Type: text/x-patch Size: 548 bytes Desc: not available URL: From buc at odusz.so-cdu.ru Thu Nov 25 16:27:20 2004 From: buc at odusz.so-cdu.ru (buc) Date: Thu, 25 Nov 2004 19:27:20 +0300 Subject: [Patch] Fish uploads files very slowly. Message-ID: <41A607E8.4080006@odu.neva.ru> Midnight Commander has a FISH virtual filesystem (FIle transfer over SHell). There is one old problem in MC implementation of it -- uploads onto remote system. To do such an upload, MC should invoke on the remote side a command, which reads appropriate number of bytes from stdin and store them in the target file. Initially, `dd' command had been chosen for this purpose. The decision was such: " ( dd bs=4096 count= ; dd bs= count=1 ) | ( cat >target_file ; cat >/dev/null ) " (Note: additional cat to /dev/null is needed to flush input on write errors). But unfortunately, this variant appeared unreliable. The design of `dd' does not assume full filling of input buffers on read (see, for example, "conv=sync" description in `dd' manual). The design of `ssh' is those that sometimes data can be written into pipe by portions of different size. Therefore the part of data could remain not read by `dd' ... In the current version, the problem is solved as: " dd bs=1 count= | ..... " i.e., `dd' reads input byte-by-byte. It is robast, but is very slow and grabs a lot of cpu time on the remote system. The better decision is possible. There is `head' command. It has `-c ' option, which does what we really need. The necessary amount of data is read from stdin reliably. Unfortunately, the remote system (any *NIX-like) may not have `head' command, or have another implementation of it. But for such systems we can still use `dd' . The final decision is: " ( head -c -q - || dd bs=1 count= ) | ( cat >target_file ; cat >/dev/null ) " Either fast `head' is used, or `dd' as a fallback. If there is no `head' on the remote side, or `head' is too old (has no `-c' option), then `dd' will be used. `-q' and `-' are used to cause most non-GNU `head's to fail (by "incorrect" option). We can not trust non-GNU implementations of `head' -- for example, AIX has `-c' option, but always adds extra newline at the end of target file :-( . There is small probability that remote `head' is not GNU head but supports all our options. Let`s believe that it is "modern" head and it suits us! :-) The new variant of FISH uploads is successfully tested by us in various environments (GNU-like, non-GNU) -- all works as it is expected. Appropriate patch attached. -- Dmitry K. Butskoj Saint-Petersburg, Russia Red Hat Certified Engineer 809003662809495 -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-4.6.1-fish.patch Type: text/x-patch Size: 1765 bytes Desc: not available URL: From andrew at email.zp.ua Fri Nov 26 11:21:45 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 26 Nov 2004 13:21:45 +0200 (EET) Subject: Couple of patches In-Reply-To: Message-ID: <200411261121.iAQBLjfZ005879@email.zp.ua> Hello, > > On Thu, 25 Nov 2004, Pavel Tsekov wrote: > > > Hello, > > > > I don't like the second hunk of direntry.c.patch. > > > > @@ -955,7 +957,7 @@ vfs_s_retrieve_file (struct vfs_class *m > > if (got_interrupt ()) > > goto error_1; > > > > - if (write (handle, buffer, n) < 0) { > > + if (write (handle, buffer, n) != n) { > > me->verrno = errno; > > goto error_1; > > } > > > > `errno' is not set if write () returns a positive value i.e. > > less bytes written than in the buffer. Well, new incarnations with random me->verrno. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: direntry.c.patch URL: From me at pavelsh.pp.ru Fri Nov 26 11:57:12 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Fri, 26 Nov 2004 16:57:12 +0500 Subject: Couple of patches In-Reply-To: <200411251106.iAPB6HW2082605@email.zp.ua> References: <200411251106.iAPB6HW2082605@email.zp.ua> Message-ID: <1529822996.20041126165712@pavelsh.pp.ru> Hello Andrew, Thursday, November 25, 2004, 4:06:17 PM, you wrote: execute.c.patch committed. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Fri Nov 26 11:57:25 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Fri, 26 Nov 2004 16:57:25 +0500 Subject: Couple of patches In-Reply-To: <200411261121.iAQBLjfZ005879@email.zp.ua> References: <200411261121.iAQBLjfZ005879@email.zp.ua> Message-ID: <63926851.20041126165725@pavelsh.pp.ru> Hello Andrew, Friday, November 26, 2004, 4:21:45 PM, you wrote: AVS> Hello, >> >> On Thu, 25 Nov 2004, Pavel Tsekov wrote: >> >> > Hello, >> > >> > I don't like the second hunk of direntry.c.patch. >> > >> > @@ -955,7 +957,7 @@ vfs_s_retrieve_file (struct vfs_class *m >> > if (got_interrupt ()) >> > goto error_1; >> > >> > - if (write (handle, buffer, n) < 0) { >> > + if (write (handle, buffer, n) != n) { >> > me->verrno = errno; >> > goto error_1; >> > } >> > >> > `errno' is not set if write () returns a positive value i.e. >> > less bytes written than in the buffer. AVS> Well, new incarnations with random me->verrno. Committed. Thx. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Fri Nov 26 13:06:15 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 26 Nov 2004 14:06:15 +0100 Subject: Couple of patches In-Reply-To: <200411261121.iAQBLjfZ005879@email.zp.ua> References: <200411261121.iAQBLjfZ005879@email.zp.ua> Message-ID: <1101474375.4815.2.camel@athlon.localdomain> Hello Andrew, On Fri, 2004-11-26 at 12:21, Andrew V. Samoilov wrote: > > > `errno' is not set if write () returns a positive value i.e. > > > less bytes written than in the buffer. > > Well, new incarnations with random me->verrno. Wouldn't it be better to always set a value for me->verrno if (write (handle, buffer, n)) != n)? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andrew at email.zp.ua Fri Nov 26 15:35:58 2004 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 26 Nov 2004 17:35:58 +0200 (EET) Subject: Couple of patches In-Reply-To: <1529822996.20041126165712@pavelsh.pp.ru> Message-ID: <200411261535.iAQFZweE013778@email.zp.ua> Hello Pavel, > > Thursday, November 25, 2004, 4:06:17 PM, you wrote: > > execute.c.patch committed. Thanks! And one more memory optimization, please. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ext.c.patch URL: From me at pavelsh.pp.ru Fri Nov 26 15:44:16 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Fri, 26 Nov 2004 20:44:16 +0500 Subject: Couple of patches In-Reply-To: <200411261535.iAQFZweE013778@email.zp.ua> References: <1529822996.20041126165712@pavelsh.pp.ru> <200411261535.iAQFZweE013778@email.zp.ua> Message-ID: <1217022620.20041126204416@pavelsh.pp.ru> Hello Andrew, Friday, November 26, 2004, 8:35:58 PM, you wrote: AVS> Hello Pavel, >> >> Thursday, November 25, 2004, 4:06:17 PM, you wrote: >> >> execute.c.patch committed. AVS> Thanks! And one more memory optimization, please. Committed. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From nerijus at users.sourceforge.net Fri Nov 26 20:16:13 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Fri, 26 Nov 2004 22:16:13 +0200 (EET) Subject: Couple of patches In-Reply-To: <200411261535.iAQFZweE013778@email.zp.ua> References: <200411261535.iAQFZweE013778@email.zp.ua> Message-ID: <20041126201625.5AF213B0C77@menubar.gnome.org> On Fri, 26 Nov 2004 17:35:58 +0200 (EET) "Andrew V. Samoilov" wrote: > Thanks! And one more memory optimization, please. And one for large files (a patch was posted a few days ago), please ;-) Regards, Nerijus From eth0 at o2.pl Sat Nov 27 02:06:53 2004 From: eth0 at o2.pl (q#) Date: Sat, 27 Nov 2004 03:06:53 +0100 Subject: prompt, spaces, `cd' and system commands.. In-Reply-To: <1101381922.4819.9.camel@athlon.localdomain> References: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> <1101381922.4819.9.camel@athlon.localdomain> Message-ID: <20041127020653.GA28348@hindus.hstl5.put.poznan.pl> On Thu, Nov 25, 2004 at 12:25:23PM +0100, Leonard den Ottolander wrote: > Hi q#, > > On Thu, 2004-11-25 at 03:24, q# wrote: > > I often copy paths with to prompt with (CTRL+x, p) and when your path > > has space I've got this error when tryin co cd'in. > > As always, patches are welcome. This patch fix this issue, but please _double check_ this patch. Comments are _very_ welcome. -- best regards q# -------------- next part -------------- Index: command.c =================================================================== RCS file: /cvsroot/mc/mc/src/command.c,v retrieving revision 1.28 diff -u -r1.28 command.c --- command.c 3 Nov 2004 19:43:17 -0000 1.28 +++ command.c 27 Nov 2004 02:01:55 -0000 @@ -138,7 +138,9 @@ /* Execute the cd command on the command line */ void do_cd_command (char *cmd) { - int len; + int bs = 0; + int len = 0; + int sn; /* Any final whitespace should be removed here (to see why, try "cd fred "). */ @@ -146,20 +148,31 @@ that way, we can cd into hidden directories */ /* FIXME: what about interpreting quoted strings like the shell. so one could type "cd M-a " and it would work. */ - len = strlen (cmd) - 1; - while (len >= 0 && - (cmd [len] == ' ' || cmd [len] == '\t' || cmd [len] == '\n')){ - cmd [len] = 0; - len --; + + sn = strlen (cmd) - 1; + while (sn >= 0 && (cmd [sn - 1] != '\\') && + (cmd [sn] == ' ' || cmd [sn] == '\t' || cmd [sn] == '\n')) { + cmd [sn] = 0; + sn --; + } + + char *tmp = g_strdup(&cmd [0]); + + while (len + bs <= sn) { + if (tmp [len + bs] == '\\') + bs ++; + tmp [len] = tmp [len + bs]; + len ++; } - - if (cmd [2] == 0) - cmd = "cd "; + tmp [len] = 0; + + if (tmp [2] == 0) + tmp = "cd "; if (get_current_type () == view_tree){ - if (cmd [0] == 0){ + if (tmp [0] == 0){ sync_tree (home_dir); - } else if (strcmp (cmd+3, "..") == 0){ + } else if (strcmp (tmp+3, "..") == 0){ char *dir = current_panel->cwd; int len = strlen (dir); while (len && dir [--len] != PATH_SEP); @@ -168,23 +181,25 @@ sync_tree (dir); else sync_tree (PATH_SEP_STR); - } else if (cmd [3] == PATH_SEP){ - sync_tree (cmd+3); + } else if (tmp [3] == PATH_SEP){ + sync_tree (tmp+3); } else { char *old = current_panel->cwd; char *new; - new = concat_dir_and_file (old, cmd+3); + new = concat_dir_and_file (old, tmp+3); sync_tree (new); g_free (new); } } else - if (!examine_cd (&cmd [3])) { - char *d = strip_password (g_strdup (&cmd [3]), 1); + if (!examine_cd (&tmp [3])) { + char *d = strip_password (g_strdup (&tmp [3]), 1); message (1, MSG_ERROR, _(" Cannot chdir to \"%s\" \n %s "), d, unix_error_string (errno)); g_free (d); - return; } + + g_free (tmp); + return; } /* Handle Enter on the command line */ From ossi at kde.org Sat Nov 27 08:30:47 2004 From: ossi at kde.org (Oswald Buddenhagen) Date: Sat, 27 Nov 2004 09:30:47 +0100 Subject: prompt, spaces, `cd' and system commands.. In-Reply-To: <20041127020653.GA28348@hindus.hstl5.put.poznan.pl> References: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> <1101381922.4819.9.camel@athlon.localdomain> <20041127020653.GA28348@hindus.hstl5.put.poznan.pl> Message-ID: <20041127083047.GB1281@ugly.local> On Sat, Nov 27, 2004 at 03:06:53AM +0100, q# wrote: > This patch fix this issue, but please _double check_ this patch. > Comments are _very_ welcome. > so here we go: this patch sucks. :-P glib provides a proper shell command interpretation function; use that instead of crafting some fragile dequoting voodoo. (yes, i know you didn't start this, but once you touch that code ...) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From leonard at den.ottolander.nl Sat Nov 27 12:53:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 27 Nov 2004 13:53:27 +0100 Subject: Couple of patches In-Reply-To: <200411261121.iAQBLjfZ005879@email.zp.ua> References: <200411261121.iAQBLjfZ005879@email.zp.ua> Message-ID: <1101560007.4789.1.camel@athlon.localdomain> Hello Andrew, On Fri, 2004-11-26 at 12:21, Andrew V. Samoilov wrote: > > > `errno' is not set if write () returns a positive value i.e. > > > less bytes written than in the buffer. > > Well, new incarnations with random me->verrno. Wouldn't it be better to always set a value for me->verrno if (write (handle, buffer, n)) != n)? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Nov 27 13:06:23 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 27 Nov 2004 14:06:23 +0100 Subject: prompt, spaces, `cd' and system commands.. In-Reply-To: <20041127083047.GB1281@ugly.local> References: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> <1101381922.4819.9.camel@athlon.localdomain> <20041127020653.GA28348@hindus.hstl5.put.poznan.pl> <20041127083047.GB1281@ugly.local> Message-ID: <1101560783.4789.14.camel@athlon.localdomain> Hi q#, On Sat, 2004-11-27 at 09:30, Oswald Buddenhagen wrote: > so here we go: this patch sucks. :-P Never mind Oswald. He seems to think it's cool to scare off people. He doesn't understand that people might not always get that he is actually joking. Just ignore his style, he sometimes actually says quite useful things. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sat Nov 27 13:07:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 27 Nov 2004 14:07:25 +0100 Subject: prompt, spaces, `cd' and system commands.. In-Reply-To: <20041127020653.GA28348@hindus.hstl5.put.poznan.pl> References: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> <1101381922.4819.9.camel@athlon.localdomain> <20041127020653.GA28348@hindus.hstl5.put.poznan.pl> Message-ID: <1101560845.4789.17.camel@athlon.localdomain> Hi q#, On Sat, 2004-11-27 at 03:06, q# wrote: > This patch fix this issue, but please _double check_ this patch. > Comments are _very_ welcome. Although I haven't looked very closely at your patch there is one thing that catches the eye. You rename variables, thus introducing a lot of bloat in the patch. Why rename len to sn, and cmd to tmp? Leaving these names intact and introduce new names for the new variables. That will take of half the size of your patch and makes it easier to understand what you actually try to achieve. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From eth0 at o2.pl Sun Nov 28 03:04:08 2004 From: eth0 at o2.pl (q#) Date: Sun, 28 Nov 2004 04:04:08 +0100 Subject: prompt, spaces, `cd' and system commands.. In-Reply-To: <20041127083047.GB1281@ugly.local> References: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> <1101381922.4819.9.camel@athlon.localdomain> <20041127020653.GA28348@hindus.hstl5.put.poznan.pl> <20041127083047.GB1281@ugly.local> Message-ID: <20041128030408.GD28348@hindus.hstl5.put.poznan.pl> On Sat, Nov 27, 2004 at 09:30:47AM +0100, Oswald Buddenhagen wrote: > On Sat, Nov 27, 2004 at 03:06:53AM +0100, q# wrote: > > This patch fix this issue, but please _double check_ this patch. > > Comments are _very_ welcome. > > > so here we go: this patch sucks. :-P > glib provides a proper shell command interpretation function; use that > instead of crafting some fragile dequoting voodoo. (yes, i know you > didn't start this, but once you touch that code ...) I tried to rewrite this function. I'm stuck little with condition (get_current_type () == view_tree) I can't force mc to show me this "FIXME" dialog :/ and also don't undesrstand for what this part of code was (in old function). In `do_cd_command()' I want: remove unnecessary spaces before and after dirname, striped dir stored in cmd (it goes to mc history), unqoted dir pass on to `examine_cd()'. Comments and constructive flames are very welcome. -- best regards q# -------------- next part -------------- Index: src/command.c =================================================================== RCS file: /cvsroot/mc/mc/src/command.c,v retrieving revision 1.28 diff -u -r1.28 command.c --- src/command.c 3 Nov 2004 19:43:17 -0000 1.28 +++ src/command.c 28 Nov 2004 02:38:48 -0000 @@ -138,53 +138,35 @@ /* Execute the cd command on the command line */ void do_cd_command (char *cmd) { - int len; - /* Any final whitespace should be removed here (to see why, try "cd fred "). */ /* NOTE: I think we should not remove the extra space, that way, we can cd into hidden directories */ /* FIXME: what about interpreting quoted strings like the shell. so one could type "cd M-a " and it would work. */ - len = strlen (cmd) - 1; - while (len >= 0 && - (cmd [len] == ' ' || cmd [len] == '\t' || cmd [len] == '\n')){ - cmd [len] = 0; - len --; + char *dir = g_strstrip (g_strdup (cmd+2)); + char *unq = g_shell_unquote (g_strdup (dir), NULL); + + if (unq == NULL) { + + message (1, MSG_ERROR, _(" Cannot unquote shell string ")); + + } else if (get_current_type () == view_tree) { + + message (1, MSG_ERROR, _(" FIXME: Not implemented yet ")); + + } else if (!examine_cd (unq)) { + + char *d = strip_password (g_strdup (unq), 1); + message (1, MSG_ERROR, _(" Cannot chdir to \"%s\" \n %s "), + d, unix_error_string (errno)); + g_free (d); } - - if (cmd [2] == 0) - cmd = "cd "; - - if (get_current_type () == view_tree){ - if (cmd [0] == 0){ - sync_tree (home_dir); - } else if (strcmp (cmd+3, "..") == 0){ - char *dir = current_panel->cwd; - int len = strlen (dir); - while (len && dir [--len] != PATH_SEP); - dir [len] = 0; - if (len) - sync_tree (dir); - else - sync_tree (PATH_SEP_STR); - } else if (cmd [3] == PATH_SEP){ - sync_tree (cmd+3); - } else { - char *old = current_panel->cwd; - char *new; - new = concat_dir_and_file (old, cmd+3); - sync_tree (new); - g_free (new); - } - } else - if (!examine_cd (&cmd [3])) { - char *d = strip_password (g_strdup (&cmd [3]), 1); - message (1, MSG_ERROR, _(" Cannot chdir to \"%s\" \n %s "), - d, unix_error_string (errno)); - g_free (d); - return; - } + + g_sprintf (cmd, "cd %s", dir); + g_free (dir); + g_free (unq); + return; } /* Handle Enter on the command line */ From ptsekov at gmx.net Mon Nov 29 13:38:55 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 29 Nov 2004 15:38:55 +0200 Subject: [PATCH]: Allow select/unselect even if there is no command prompt Message-ID: Hello, Please, apply the attached patch. It fixes the following issue: 1) Disable the command prompt - Options -> Layout... -> command Prompt 2) Hit any of the keys +, - or * Instead of doing what it is supposed to do (select/unselect) MC starts a file search. I don't see any relation between the select/unselect functionality and the presence of the command prompt widget thus I consider the described behaviour a bug. This bug was reported by Alex Yosifov. -------------- next part -------------- Index: main.c =================================================================== RCS file: /cvsroot/mc/mc/src/main.c,v retrieving revision 1.344 diff -u -p -r1.344 main.c --- main.c 22 Oct 2004 05:47:25 -0000 1.344 +++ main.c 29 Nov 2004 13:20:43 -0000 @@ -1525,7 +1525,7 @@ midnight_callback (struct Dlg_head *h, d reverse_selection_cmd (); return MSG_HANDLED; } - } else if (command_prompt && !strlen (cmdline->buffer)) { + } else if (!command_prompt || !strlen (cmdline->buffer)) { /* Special treatement '+', '-', '\', '*' only when this is * first char on input line */ From samoilov at fromru.com Mon Nov 29 12:04:33 2004 From: samoilov at fromru.com (Andrew V. Samoilov) Date: Mon, 29 Nov 2004 15:04:33 +0300 (MSK) Subject: fish memory leaks Message-ID: <200411291204.iATC4XAj041394@www8.pochta.ru> Hi! -- Regards, Andrew V. Samoilov -------------- next part -------------- vfs/ChangeLog: * fish.c (fish_file_store): Check write() more carefully. (PREFIX): Fix memory leak. (fish_##name): Likewise. (fish_chown): Likewise. --- fish.c.sav Fri Oct 29 09:30:07 2004 +++ fish.c Mon Nov 29 13:42:47 2004 @@ -542,6 +542,7 @@ fish_file_store(struct vfs_class *me, st total = 0; while (1) { + int t; while ((n = read(h, buffer, sizeof(buffer))) < 0) { if ((errno == EINTR) && got_interrupt()) continue; @@ -551,8 +552,12 @@ fish_file_store(struct vfs_class *me, st } if (n == 0) break; - while (write(SUP.sockw, buffer, n) < 0) { - me->verrno = errno; + if ((t = write (SUP.sockw, buffer, n)) != n) { + if (t == -1) { + me->verrno = errno + } else { + me->verrno = EIO; + } goto error_return; } disable_interrupt_key(); @@ -692,15 +697,17 @@ fish_send_command(struct vfs_class *me, #define PREFIX \ char buf[BUF_LARGE]; \ - char *rpath, *mpath; \ + char *rpath, *mpath = g_strdup (path); \ struct vfs_s_super *super; \ - if (!(rpath = vfs_s_get_path_mangle(me, mpath = g_strdup(path), &super, 0))) \ + if (!(rpath = vfs_s_get_path_mangle (me, mpath, &super, 0))) { \ + g_free (mpath); \ return -1; \ - rpath = name_quote (rpath, 0); + } \ + rpath = name_quote (rpath, 0); \ + g_free (mpath); #define POSTFIX(flags) \ g_free (rpath); \ - g_free (mpath); \ return fish_send_command(me, super, buf, flags); static int @@ -721,17 +728,22 @@ static int fish_##name (struct vfs_class char buf[BUF_LARGE]; \ char *rpath1, *rpath2, *mpath1, *mpath2; \ struct vfs_s_super *super1, *super2; \ - if (!(rpath1 = vfs_s_get_path_mangle(me, mpath1 = g_strdup(path1), &super1, 0))) \ + if (!(rpath1 = vfs_s_get_path_mangle (me, mpath1 = g_strdup(path1), &super1, 0))) { \ + g_free (mpath1); \ return -1; \ - if (!(rpath2 = vfs_s_get_path_mangle(me, mpath2 = g_strdup(path2), &super2, 0))) \ + } \ + if (!(rpath2 = vfs_s_get_path_mangle (me, mpath2 = g_strdup(path2), &super2, 0))) { \ + g_free (mpath1); \ + g_free (mpath2); \ return -1; \ + } \ rpath1 = name_quote (rpath1, 0); \ + g_free (mpath1); \ rpath2 = name_quote (rpath2, 0); \ + g_free (mpath2); \ g_snprintf(buf, sizeof(buf), string "\n", rpath1, rpath2, rpath1, rpath2); \ g_free (rpath1); \ g_free (rpath2); \ - g_free (mpath1); \ - g_free (mpath2); \ return fish_send_command(me, super2, buf, OPT_FLUSH); \ } @@ -763,7 +775,6 @@ fish_chown (struct vfs_class *me, const char *sowner, *sgroup; struct passwd *pw; struct group *gr; - PREFIX if ((pw = getpwuid (owner)) == NULL) return 0; @@ -773,22 +784,25 @@ fish_chown (struct vfs_class *me, const sowner = pw->pw_name; sgroup = gr->gr_name; - g_snprintf(buf, sizeof(buf), - "#CHOWN /%s /%s\n" + { + PREFIX + g_snprintf (buf, sizeof(buf), + "#CHOWN /%s /%s\n" "chown %s /%s 2>/dev/null\n" "echo '### 000'\n", sowner, rpath, sowner, rpath); - fish_send_command(me, super, buf, OPT_FLUSH); - /* FIXME: what should we report if chgrp succeeds but chown fails? */ - g_snprintf(buf, sizeof(buf), + fish_send_command (me, super, buf, OPT_FLUSH); + /* FIXME: what should we report if chgrp succeeds but chown fails? */ + g_snprintf (buf, sizeof(buf), "#CHGRP /%s /%s\n" "chgrp %s /%s 2>/dev/null\n" "echo '### 000'\n", sgroup, rpath, sgroup, rpath); - /* fish_send_command(me, super, buf, OPT_FLUSH); */ - POSTFIX(OPT_FLUSH) + /* fish_send_command(me, super, buf, OPT_FLUSH); */ + POSTFIX (OPT_FLUSH) + } } static int fish_unlink (struct vfs_class *me, const char *path) From ptsekov at gmx.net Mon Nov 29 14:17:04 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 29 Nov 2004 16:17:04 +0200 Subject: Bug #11138 CRITICAL - /dev/pts/N are not freed in kernel 2.6 Message-ID: Hello, Is anyone able to reproduce this ? From jnovy at redhat.com Mon Nov 29 16:08:15 2004 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 29 Nov 2004 17:08:15 +0100 Subject: broken extraction/viewing fix from tarfs Message-ID: <1101744495.3663.10.camel@obelix.redhat.usu> Hi, this patch fixes broken extraction and displaying of symlinks from tarfs, but possibly affects any vfs that uses vfs_s_readlink (). To see description and steps to reproduce please see: http://bugzilla.redhat.com/beta/show_bug.cgi?id=141065 In vfs_s_readlink () there is incorrectly calculated length of buf instead of link name in the inode. The random size you may see when extracting symlinks from tarfs is caused by the fact that buf is mostly uninitialized so the link is truncated almost at random position. -- Jindrich Novy , http://people.redhat.com/jnovy/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-CVS-20041129-badsymlinks.patch Type: text/x-patch Size: 429 bytes Desc: not available URL: From ptsekov at gmx.net Mon Nov 29 16:53:58 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 29 Nov 2004 18:53:58 +0200 Subject: broken extraction/viewing fix from tarfs In-Reply-To: <1101744495.3663.10.camel@obelix.redhat.usu> References: <1101744495.3663.10.camel@obelix.redhat.usu> Message-ID: Hello, On Mon, 29 Nov 2004, Jindrich Novy wrote: > In vfs_s_readlink () there is incorrectly calculated length of buf > instead of link name in the inode. The random size you may see when > extracting symlinks from tarfs is caused by the fact that buf is mostly > uninitialized so the link is truncated almost at random position. I wonder how it could have gone unnoticed ?! Please, apply. From leonard at den.ottolander.nl Mon Nov 29 17:50:59 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 29 Nov 2004 18:50:59 +0100 Subject: broken extraction/viewing fix from tarfs In-Reply-To: <1101744495.3663.10.camel@obelix.redhat.usu> References: <1101744495.3663.10.camel@obelix.redhat.usu> Message-ID: <1101750658.4812.57.camel@athlon.localdomain> Hi Jindrich, On Mon, 2004-11-29 at 17:08, Jindrich Novy wrote: > http://bugzilla.redhat.com/beta/show_bug.cgi?id=141065 > > In vfs_s_readlink () there is incorrectly calculated length of buf > instead of link name in the inode. Good catch. Please commit. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Mon Nov 29 18:02:48 2004 From: me at pavelsh.pp.ru (me at pavelsh.pp.ru) Date: Mon, 29 Nov 2004 23:02:48 +0500 Subject: broken extraction/viewing fix from tarfs In-Reply-To: <1101744495.3663.10.camel@obelix.redhat.usu> References: <1101744495.3663.10.camel@obelix.redhat.usu> Message-ID: <798958982.20041129230248@pavelsh.pp.ru> Hello Jindrich, Monday, November 29, 2004, 9:08:15 PM, you wrote: JN> Hi, JN> this patch fixes broken extraction and displaying of symlinks from JN> tarfs, but possibly affects any vfs that uses vfs_s_readlink (). JN> To see description and steps to reproduce please see: JN> http://bugzilla.redhat.com/beta/show_bug.cgi?id=141065 JN> In vfs_s_readlink () there is incorrectly calculated length of buf JN> instead of link name in the inode. The random size you may see when JN> extracting symlinks from tarfs is caused by the fact that buf is mostly JN> uninitialized so the link is truncated almost at random position. Please write a ChangeLog entry for your patches. -- Best regards, me mailto:me at pavelsh.pp.ru From leonard at den.ottolander.nl Mon Nov 29 18:35:39 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 29 Nov 2004 19:35:39 +0100 Subject: broken extraction/viewing fix from tarfs In-Reply-To: <798958982.20041129230248@pavelsh.pp.ru> References: <1101744495.3663.10.camel@obelix.redhat.usu> <798958982.20041129230248@pavelsh.pp.ru> Message-ID: <1101753338.4812.61.camel@athlon.localdomain> Hi Pavel, On Mon, 2004-11-29 at 19:02, me at pavelsh.pp.ru wrote: > Please write a ChangeLog entry for your patches. I hope Jindrich doesn't mind me butting in: * direntry.c (vfs_s_readlink): Correctly calculate link length. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From me at pavelsh.pp.ru Mon Nov 29 18:44:38 2004 From: me at pavelsh.pp.ru (me at pavelsh.pp.ru) Date: Mon, 29 Nov 2004 23:44:38 +0500 Subject: broken extraction/viewing fix from tarfs In-Reply-To: <1101744495.3663.10.camel@obelix.redhat.usu> References: <1101744495.3663.10.camel@obelix.redhat.usu> Message-ID: <802878525.20041129234438@pavelsh.pp.ru> Hello Jindrich, Monday, November 29, 2004, 9:08:15 PM, you wrote: JN> Hi, JN> this patch fixes broken extraction and displaying of symlinks from JN> tarfs, but possibly affects any vfs that uses vfs_s_readlink (). JN> To see description and steps to reproduce please see: JN> http://bugzilla.redhat.com/beta/show_bug.cgi?id=141065 JN> In vfs_s_readlink () there is incorrectly calculated length of buf JN> instead of link name in the inode. The random size you may see when JN> extracting symlinks from tarfs is caused by the fact that buf is mostly JN> uninitialized so the link is truncated almost at random position. Committed. Thx! -- Best regards, me mailto:me at pavelsh.pp.ru From ptsekov at gmx.net Mon Nov 29 18:42:25 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 29 Nov 2004 20:42:25 +0200 Subject: [PATCH]: Allow select/unselect even if there is no command prompt In-Reply-To: References: Message-ID: Hello, On Mon, 29 Nov 2004, Pavel Tsekov wrote: > Hello, > > Please, apply the attached patch. It fixes the following issue: > > 1) Disable the command prompt - Options -> Layout... -> command Prompt > > 2) Hit any of the keys +, - or * > > Instead of doing what it is supposed to do (select/unselect) MC starts > a file search. I don't see any relation between the select/unselect > functionality and the presence of the command prompt widget thus I > consider the described behaviour a bug. > > This bug was reported by Alex Yosifov. 2004-11-29 Pavel Tsekov * main.c (midnight_callback): Make the the keystrokes the invoke select_cmd(), unselect_cmd() and reverse_selection_cmd () work even if the command prompt is turned off. From nerijus at users.sourceforge.net Mon Nov 29 21:37:23 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 29 Nov 2004 23:37:23 +0200 (EET) Subject: Bug #11138 CRITICAL - /dev/pts/N are not freed in kernel 2.6 In-Reply-To: References: Message-ID: <20041129213956.E075C6A68@mx.ktv.lt> On Mon, 29 Nov 2004 16:17:04 +0200 Pavel Tsekov wrote: > Is anyone able to reproduce this ? When are they not freed - when exiting mc? Here they seem to be freed: I mount /dev/pts run mc try to umount /dev/pts - it fails, as it's busy exit mc try to umount /dev/pts - it succeeds. Kernel 2.6.7. Regards, Nerijus From ptsekov at gmx.net Mon Nov 29 21:53:19 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Mon, 29 Nov 2004 23:53:19 +0200 Subject: Bug #11138 CRITICAL - /dev/pts/N are not freed in kernel 2.6 In-Reply-To: <20041129213956.E075C6A68@mx.ktv.lt> References: <20041129213956.E075C6A68@mx.ktv.lt> Message-ID: Hello, On Mon, 29 Nov 2004, Nerijus Baliunas wrote: > On Mon, 29 Nov 2004 16:17:04 +0200 Pavel Tsekov wrote: > > > Is anyone able to reproduce this ? > > When are they not freed - when exiting mc? > Here they seem to be freed: > I mount /dev/pts > run mc > try to umount /dev/pts - it fails, as it's busy > exit mc > try to umount /dev/pts - it succeeds. > > Kernel 2.6.7. Well, looking at the original report could be useful. The bug was reported on savannah.gnu.org's bugzilla. I couldn't reproduce it either. From nerijus at users.sourceforge.net Mon Nov 29 22:07:30 2004 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Tue, 30 Nov 2004 00:07:30 +0200 (EET) Subject: Bug #11138 CRITICAL - /dev/pts/N are not freed in kernel 2.6 In-Reply-To: References: <20041129213956.E075C6A68@mx.ktv.lt> Message-ID: <20041129220956.E57666DBA@mx.ktv.lt> On Mon, 29 Nov 2004 23:53:19 +0200 Pavel Tsekov wrote: > Well, looking at the original report could be useful. Well, posting a link could be useful too. > The bug was reported > on savannah.gnu.org's bugzilla. I couldn't reproduce it either. OK, found it - http://savannah.gnu.org/bugs/?func=detailitem&item_id=11138. Added comment to it. Regards, Nerijus From me at pavelsh.pp.ru Tue Nov 30 04:36:02 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 30 Nov 2004 09:36:02 +0500 Subject: [PATCH]: Allow select/unselect even if there is no command prompt In-Reply-To: References: Message-ID: <58814530.20041130093602@pavelsh.pp.ru> Hello Pavel, Monday, November 29, 2004, 6:38:55 PM, you wrote: PT> Hello, PT> Please, apply the attached patch. It fixes the following issue: PT> 1) Disable the command prompt - Options -> Layout... -> command Prompt PT> 2) Hit any of the keys +, - or * PT> Instead of doing what it is supposed to do (select/unselect) MC starts PT> a file search. I don't see any relation between the select/unselect PT> functionality and the presence of the command prompt widget thus I PT> consider the described behaviour a bug. PT> This bug was reported by Alex Yosifov. Committed. Thx! -- Best regards, Pavel mailto:me at pavelsh.pp.ru From me at pavelsh.pp.ru Tue Nov 30 05:50:55 2004 From: me at pavelsh.pp.ru (Pavel Shirshov (pchel)) Date: Tue, 30 Nov 2004 10:50:55 +0500 Subject: [PATCH] widget.c: fix slow_terminal declaration In-Reply-To: References: Message-ID: <835292671.20041130105055@pavelsh.pp.ru> Hello Pavel, Wednesday, November 24, 2004, 3:21:37 PM, you wrote: PT> Hello, PT> This warning is displayed with gcc 3.4.2 ( gcc version 3.4.2 20041017 (Red PT> Hat 3.4.2-6.fc3) ) on FC3: PT> widget.c: In function `listbox_new': PT> widget.c:2099: warning: redundant redeclaration of 'slow_terminal' PT> widget.c:1659: warning: previous declaration of 'slow_terminal' was here PT> Changelog: PT> 20041124 Pavel Tsekov PT> * warning.c: Fix declaration of `slow_terminal'. Committed. Thx. -- Best regards, Pavel mailto:me at pavelsh.pp.ru From buc at odusz.so-cdu.ru Tue Nov 30 17:32:09 2004 From: buc at odusz.so-cdu.ru (buc) Date: Tue, 30 Nov 2004 20:32:09 +0300 Subject: [Patch] Addon to 'Fish uploads slowly' patch -- better fallback Message-ID: <41ACAE99.4060706@odu.neva.ru> Hi, It is an addition to previously posted patch which solve too slow FISH uploads (" head || dd " ) Possible, I have found a better way for fallback. It is several times faster than initial "dd bs=1 count=%lu" ... The idea is we use shell loop as this: while : do set @@@ `ls -l ` [ $6 -lt ] && dd bs=4096 count=1 || break done Note: `@@@' is ised to avoid "option-like" interpretation of `ls' output. Each invokation `dd' reads only once ("count=1"), with maximum amount of 4096 bytes. Actually, reading occurs in smaller portions - as `ssh' put data in the pipe. We never read the extra data because MC do not give us anything more until we echo status code to it. This way successfully tested by us in the GNU/non-GNU environment. The patch attached, it should be applied after previous posted patch. -- Dmitry Butskoj Saint-Petersburg, Russia Red Hat Certified Engineer 809003662809495 -------------- next part -------------- A non-text attachment was scrubbed... Name: mc-4.6.1-fish1.patch Type: text/x-patch Size: 1331 bytes Desc: not available URL: From ptsekov at gmx.net Tue Nov 30 17:59:22 2004 From: ptsekov at gmx.net (Pavel Tsekov) Date: Tue, 30 Nov 2004 19:59:22 +0200 Subject: [PATCH] Allow MC to open incremental tar archives Message-ID: Hello, This patch fixes the following issue: https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=8684 ChangeLog: 20041130 Pavel Tsekov * tar.c (tar_read_header): Skip over records containing incremental tar specific info. -------------- next part -------------- Index: tar.c =================================================================== RCS file: /cvsroot/mc/mc/vfs/tar.c,v retrieving revision 1.69 diff -u -p -r1.69 tar.c --- tar.c 1 Nov 2004 07:49:36 -0000 1.69 +++ tar.c 30 Nov 2004 17:33:39 -0000 @@ -403,6 +403,13 @@ tar_read_header (struct vfs_class *me, s else *h_size = tar_from_oct (1 + 12, header->header.size); + /* + * Skip over directory snapshot info records that + * are stored in incremental tar archives. + */ + if (header->header.linkflag == LF_DUMPDIR) + return STATUS_SUCCESS; + header->header.arch_name[NAMSIZ - 1] = '\0'; if (header->header.linkflag == LF_LONGNAME || header->header.linkflag == LF_LONGLINK) { From roland.illig at gmx.de Tue Nov 30 22:40:06 2004 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 30 Nov 2004 23:40:06 +0100 Subject: glib2 dependency Message-ID: <41ACF6C6.4050608@gmx.de> Hi, Leonard suggested to use the g_shell_unquote(3) function, which is not available with glib-1.2. So we could either - add g_shell_quote and g_shell_unquote to glibcompat.c - don't support glib-1.2 anymore In FAQ, revision 1.16 (Jun 09 2003), proskin wrote: > To compile any edition you need to have glib 1.2.x or newer > installed. It's available at ftp://ftp.gtk.org/pub/gtk/. If you > don't have glib installed already, please note that glib 2.x is much > harder to compile, so your first choice should be glib 1.2.10. Do these words still apply, or can we drop support for glib-1.2? Roland From roland.illig at gmx.de Tue Nov 30 23:56:12 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 01 Dec 2004 00:56:12 +0100 Subject: prompt, spaces, `cd' and system commands.. In-Reply-To: <20041128030408.GD28348@hindus.hstl5.put.poznan.pl> References: <20041125022443.GA29945@hindus.hstl5.put.poznan.pl> <1101381922.4819.9.camel@athlon.localdomain> <20041127020653.GA28348@hindus.hstl5.put.poznan.pl> <20041127083047.GB1281@ugly.local> <20041128030408.GD28348@hindus.hstl5.put.poznan.pl> Message-ID: <41AD089C.7020407@gmx.de> q# wrote: > I tried to rewrite this function. I'm stuck little with condition > > (get_current_type () == view_tree) > > I can't force mc to show me this "FIXME" dialog :/ and also don't > undesrstand for what this part of code was (in old function). This is the case where you are in a tree widget and press the enter key. But surprisingly, all keys are caught by the tree widget itself instead of passing them to the command line. So it is correct that the code is never executed. Roland